Re: [Python-Dev] segfault in struct module
> Martin, since you committed 60793 in Feb, any others like this that need > merging from release25-maint to trunk off the top of your head? That's the entire chunk of "Google bug fixes", and yes, all of it needs to be ported to 2.6 still. I'll look into it, unless you volunteer :-) (it doesn't need to be done before the beta, as it's bug fixes only). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
On 2008-06-11 05:42, Gregory P. Smith wrote: On Mon, Jun 9, 2008 at 1:44 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: On 2008-06-09 07:20, Gregory P. Smith wrote: On Fri, Jun 6, 2008 at 2:19 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: On 2008-06-03 01:29, Gregory P. Smith wrote: On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: I will freely admit that I haven't followed this thread in any detail, but if it were up to me, I'd have the 2.6 internal code use PyString ... Should we read this as a BDFL pronouncement and make it so? All that would mean change wise is that trunk r63675 as well as possibly r63672 and r63677 would need to be rolled back and this whole discussion over if such a big change should have happened would turn into a moot point. I would certainly welcome reverting the change. All that's needed to support PyBytes API in 2.x is a set of #defines that map the new APIs to the PyString names. That's a clean and easily understandable solution. Okay, I've reverted r63675 in trunk revision r64048. That leaves all of the python modules and internals using PyString_ api names instead of PyBytes_ api names as they were before. PyBytes_ #define's exist for the appropriate PyString methods incase anyone wants to use those. Thanks. Programmers interested in the code for a PyString API can then still look up the code in stringobject.c, e.g. to find out how a certain special case is handled or to check the ref counting - just like they did for years. The files still exist with the new names. bytesobject.c instead of stringobject.c. Those renames were done in the other CLs i mentioned which have not yet been reverted. The current state seems a bit odd because they depend on the #defines to cause method definitions to be the PyString_ names instead of the PyBytes_ names. Please restore the original state, ie. PyString APIs live in stringobject.h and stringobject.c. bytesobject.h should then have the #defines for PyBytes APIs, pointing them to the PyString names (basically what's currently in stringobject.h). all done as of 64105 Thank you ! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 11 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2008-07-07: EuroPython 2008, Vilnius, Lithuania25 days to go Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception.__unicode__ and tp_unicode
Simon Cross wrote: Originally Python exceptions had no __unicode__ method. In Python 2.5 __unicode__ was added. This led to "unicode(Exception)" failing and so the addition of __unicode__ was reverted [1]. This leaves Python 2.6 in a position where calls to "unicode(Exception(u'\xe1'))" fail as they are equivalent to "uncode(str(Exception(u'\xe1'))" which cannot convert the non-ASCII character to ASCII (or other default encoding) [2]. From here there are 3 options: 1) Leave things as they are. 2) Add back __unicode__ and have "unicode(Exception)" fail. 3) Add a tp_unicode slot to Python objects and have everything work (at the cost of adding the slot). 4) Fix PyObject_Unicode to not retrieve __unicode__ from new-style instances, and instead only look for the method on their types (similar to the way PyObject_Format looks up the __format__ method). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Assignment to None
Thomas Lee wrote: Martin v. Löwis wrote: In Python 3, None, True, and False are keywords, so clearly, the intended semantics is also the implemented one (and the language description for 2.x needs to be updated/clarified). Interestingly enough, the semantics of True, False and None are different from one another in 2.6: True = "blah" and False = 6 are perfectly legal in Python <=2.6. True and False didn't get the same treatment as None because we didn't want to break the follow compatibility workaround for Python version prior to 2.2.2: try: True except NameError: True, False = 1, 0 Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8ity __future__
Guido van Rossum wrote: I don't see it the same way; this is a terribly unimportant API, so let's not mess with it. threading.py is worth fixing (a) because it's so popular, and (b) because some folks insisted that the new multiprocessing module have an API that is as similar as possible to threading. IOW The general moratorium on pep8ifying remains; we made a specific exception for threading.py for very specific reasons. We're also only *adding* the PEP 8 compliant API to threading, and leaving the old API in-place indefinitely in the 2.x series. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bug or a feature?
Greg Ewing wrote: Maciej Fijalkowski wrote: What do you think about this code: class A: locals()[42] = 98 Seems people rely on it working. Do we consider it part of python language? Modifying the dict returned by locals() is documented as NOT being guaranteed to work, isn't it? Yep - it just happens to work for class and module level namespaces in CPython. Implementations are also permitted to restrict namespace dictionaries to only accept string keys (I believe Jython does this for performance reasons - CPython just optimised the hell out of normal dictionaries that happen to only contain string keys instead). So I don't see any reason for Maciej to mess with PyPy to support code which deliberately makes use of formally undefined behaviour. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Have been sick, am behind on mail, let me know if there's anything urgent for me
Guido van Rossum wrote: All, I've been sick since Saturday and still don't feel up to much. I've collected a severe email backlog going back to June 6th. If there's anything someone really needs me to look at ASAP (e.g. a BDFL decision affecting the impending beta release) please send me an email (a followup to this thread is fine) and I'll try to look at it soon. As it involves adding a new standard library module, my proposal [1] to add a typetools.ProxyMixin class to 2.6/3.0 to make it practical to write type-agnostic interface adapter classes as new-style classes needs a pronouncement from yourself or Barry as to whether or not it can go in. I think it's an important tool to add since 3.0 no longer has classic classes around to handle the task, and I'm suggesting a new module for it because none of the existing standard library modules seemed like a good fit for the functionality. Cheers, Nick. [1] http://bugs.python.org/issue643841 -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Betas today - I hope
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So I had planned to do a bunch of work last night looking at the release blocker issues, but nature intervened. A bunch of severe thunderstorms knock out my 'net access until this morning. I'll try to find some time during the day to look at the RB issues. Hopefully we can get Guido to look at them too and Pronounce on some of them. Guido please start with: http://bugs.python.org/issue643841 My plan is to begin building the betas tonight, at around 9 or 10pm EDT (0100 to 0200 UTC Thursday). If a showstopper comes up before then, I'll email the list. If you think we really aren't ready for beta, then I would still like to get a release out today. In that case, we'll call it alpha and delay the betas. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSE+4fXEjvBPtnXfVAQJ4AgP+MD0o3Mw5borZRnQffomXfsAFOMLD0PDr fS5PwhxkVL/qJU7ZM7v9l8j5walI7Boj1aH7w8UQdV0KpEc0ruqWhsPFCOny3L0W WgHMtyD0Wc+GAf6ckpOxxWI4Blg52MVzkhplKHaRJ5c4lNriBKt1o9xeupElWtHq awcHgApvTms= =iNK1 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exception.__unicode__ and tp_unicode
On Wed, Jun 11, 2008 at 11:34 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > 4) Fix PyObject_Unicode to not retrieve __unicode__ from new-style > instances, and instead only look for the method on their types (similar to > the way PyObject_Format looks up the __format__ method). Thanks for the suggestion Nick. I've added a patch which implements it to the bug. Schiavo Simon ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Nab those release blockers!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 9, 2008, at 7:28 AM, Nick Coghlan wrote: Benjamin Peterson wrote: As we approach the planned first betas for 2.6/3.0, my heart sinks when I see the imposing list of 16 release blockers. [1] Luckily, most of the issues have patches that just need *your* review. Others, namely the Py3k exception issues, may require a little more discussion, but I'm sure we can get it done. For issue 643841 (providing a ProxyMixin class in a new typetools module), aside from the minor tweak mentioned in the last couple of comments, I'm basically looking for a yea or nay from Barry or Guido. I think it's the best answer we're going to find to the problem of how to write type-agnostic delegation classes in a Python world without classic classes. I've updated the issue with my own opinion. Let's see what Guido thinks. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSE+/W3EjvBPtnXfVAQIP0QP7BNuejYBEZcp9n/iF8KicfKIJ9L39pNDA QWSW72ApVnwaLEebl1QPEfF5LBzjVSYqWu5RcuxYnFro61FIi6QSX91LN+fq+o0a YuPTa3P9VAIbrfpZQVT9MsLNTqcxtsrA6YtGyv5K48oPrkKCm/9/8+7EFOXeRmXQ gXBv7K+3ZT4= =qsrW -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Have been sick, am behind on mail, let me know if there's anything urgent for me
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 10, 2008, at 8:07 PM, Guido van Rossum wrote: I've been sick since Saturday and still don't feel up to much. I've collected a severe email backlog going back to June 6th. If there's anything someone really needs me to look at ASAP (e.g. a BDFL decision affecting the impending beta release) please send me an email (a followup to this thread is fine) and I'll try to look at it soon. Hi Guido, sorry you've been sick! If you're up to it, please pronounce on this issue: http://bugs.python.org/issue643841 It's a long bug thread, but needs a decision. Thanks, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSE+/4nEjvBPtnXfVAQJDzQP9FtWLT3+MIBoeRLRqFtXEZxphi+IDU7wp Jtw82cFgKz/wPPxyyGEtnLSmt6duj3MTTftuVsTKS1plqsd6puC2S1VbEOvS9otp xQ0E1mn/xb4B/BvH9n3xkS9FTiYlePkmU61IdAdmSAQ3gtFlwDPB8o5k30RuvhLl S+Ai+mBqPq4= =TUyr -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Have been sick, am behind on mail, let me know if there's anything urgent for me
[just ccing python-dev] On Tue, Jun 10, 2008 at 10:17 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > On Tue, Jun 10, 2008 at 10:08 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> On Tue, Jun 10, 2008 at 7:19 PM, Benjamin Peterson >> <[EMAIL PROTECTED]> wrote: >>> >>> I think that we should accept Antoine's patch and begin the twilight >>> years of sys.exc_info in favor of passing the exception instances >>> around. This makes for more explicit and less magical code. I don't >>> think there's any sys.exc_info case that can't be rewritten without >>> it. >> >> OK, assuming it works and doesn't break any unittests (or fixes the >> ones it expects to break), and has unittests for the new behavior, I'd >> say go for it. > > Excellent! > >> >>> I think the implicit chaining is assuming a little too much >>> about the needs of the program. >> >> That's why it's on a separate attribute. It can be handy to use when >> you need to debug an exception that happens in an exception handle. >> Sometimes it just helps to know why the handler was being invoked in >> the first place, other times you really want to know the original >> exception because that's the problem you're trying to track down. But >> I believe this is where Collin ran into a brick wall. I still think it >> could be implemented post beta 1. > > Ok. I will make an issue for it in the morning. > > Thanks for your pronouncements. > > > > -- > Cheers, > Benjamin Peterson > "There's no place like 127.0.0.1." > -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiprocessing problems
On Wed, Jun 11, 2008 at 8:23 AM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > On Wed, Jun 11, 2008 at 1:32 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: >> Currently, multiprocessing cannot be imported: >> > import multiprocessing >> Traceback (most recent call last): >> File "", line 1, in >> File "/home/gbr/devel/python/Lib/multiprocessing/__init__.py", line 63, in >> >> import _multiprocessing >> AttributeError: 'module' object has no attribute 'BufferTooShort' >> >> The test suite passes (at least for some buildbots) because it imports >> _multiprocessing first, which then in its init function imports >> multiprocessing >> to get the BufferTooShort exception. > > I fixed it by moving the _multiprocessing import below the exception > definitions. > >> >> Since BufferTooShort and other exceptions inheriting from ProcessError are >> simple derived exceptions, why aren't they created in the C module in the >> first place? > > They should eventually go to C, but I'll worry about it after the betas. :) > Thanks Ben, you beat me to it. I'll add it to the tracker. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiprocessing problems
On Wed, Jun 11, 2008 at 1:32 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: > Currently, multiprocessing cannot be imported: > import multiprocessing > Traceback (most recent call last): > File "", line 1, in > File "/home/gbr/devel/python/Lib/multiprocessing/__init__.py", line 63, in > > import _multiprocessing > AttributeError: 'module' object has no attribute 'BufferTooShort' > > The test suite passes (at least for some buildbots) because it imports > _multiprocessing first, which then in its init function imports > multiprocessing > to get the BufferTooShort exception. I fixed it by moving the _multiprocessing import below the exception definitions. > > Since BufferTooShort and other exceptions inheriting from ProcessError are > simple derived exceptions, why aren't they created in the C module in the > first place? They should eventually go to C, but I'll worry about it after the betas. :) -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Have been sick, am behind on mail, let me know if there's anything urgent for me
Barry Warsaw wrote: On Jun 10, 2008, at 8:07 PM, Guido van Rossum wrote: I've been sick since Saturday and still don't feel up to much. I've collected a severe email backlog going back to June 6th. If there's anything someone really needs me to look at ASAP (e.g. a BDFL decision affecting the impending beta release) please send me an email (a followup to this thread is fine) and I'll try to look at it soon. Hi Guido, sorry you've been sick! If you're up to it, please pronounce on this issue: http://bugs.python.org/issue643841 It's a long bug thread, but needs a decision. I just added a couple of messages at the end that recap the more recent discussions (the early responses to the issue are *really* old...) Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Betas today - I hope
On 2008-06-11 13:35, Barry Warsaw wrote: So I had planned to do a bunch of work last night looking at the release blocker issues, but nature intervened. A bunch of severe thunderstorms knock out my 'net access until this morning. I'll try to find some time during the day to look at the RB issues. Hopefully we can get Guido to look at them too and Pronounce on some of them. Guido please start with: http://bugs.python.org/issue643841 My plan is to begin building the betas tonight, at around 9 or 10pm EDT (0100 to 0200 UTC Thursday). If a showstopper comes up before then, I'll email the list. If you think we really aren't ready for beta, then I would still like to get a release out today. In that case, we'll call it alpha and delay the betas. There are two things I'd like to get in to 3.0: * .transform()/.untransform() methods (this is mostly done, just need to add the methods to PyUnicode, PyBytes and PyByteArray) * cleanup of the PyUnicode_AsString() and PyUnicode_AsStringAndSize() C APIs (these APIs don't fit into the naming scheme used in the Unicode API and have a few other issues as well, see issue 2799; at the very least they should be made interpreter internal, ie. rename them to _PyUnicode_AsString() and _PyUnicode_AsStringAndSize() to prevent their use in extensions) I did not have time in the last few days to work on these and won't in the next few days either. Next week looks much better. If it's ok to make the above changes after the release (whatever you call it ;-), that would be great. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 11 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2008-07-07: EuroPython 2008, Vilnius, Lithuania25 days to go Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] update_wrapper should preserve staticmethod behavior
I'd like to make a claim about the following example, that update_wrapper should be improved to preserve the behavior of known, built-in decorators. In this case, I'm talking about staticmethod. The order I list here feels natural, but it obviously doesn't work. The only reason it doesn't seems to be that it is trying to decorate the descriptor, not the function itself. This is expected, but it could certainly be smart enough to detect a descriptor and attempt to get the actual callable underneath, could it not? It would not work for all cases, of course. >>> def d(f): ... def nf(*a, **kw): ... print "decorated function called" ... return f(*a, **kwargs) ... functools.update_wrapper(nf, f) ... return nf ... >>> class A(object): ... @d ... @staticmethod ... def a(self): ... print "a" ... Traceback (most recent call last): File "", line 1, in File "", line 3, in A File "", line 5, in d File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/functools.py", line 33, in update_wrapper setattr(wrapper, attr, getattr(wrapped, attr)) AttributeError: 'staticmethod' object has no attribute '__module__' ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Betas today - I hope
M.-A. Lemburg wrote: On 2008-06-11 13:35, Barry Warsaw wrote: So I had planned to do a bunch of work last night looking at the release blocker issues, but nature intervened. A bunch of severe thunderstorms knock out my 'net access until this morning. I'll try to find some time during the day to look at the RB issues. Hopefully we can get Guido to look at them too and Pronounce on some of them. Guido please start with: http://bugs.python.org/issue643841 My plan is to begin building the betas tonight, at around 9 or 10pm EDT (0100 to 0200 UTC Thursday). If a showstopper comes up before then, I'll email the list. If you think we really aren't ready for beta, then I would still like to get a release out today. In that case, we'll call it alpha and delay the betas. There are two things I'd like to get in to 3.0: * .transform()/.untransform() methods (this is mostly done, just need to add the methods to PyUnicode, PyBytes and PyByteArray) What would these methods do? Use the codec machinery without any type checks? I think for transformations we don't need the full codec machinery: We probably don't need extensible error handling. There are transformation that are not invertible, so it doesn't make sense to have both operations in one object. If the operation *is* invertible, two tranformers can be used. Do we really need a registry that maps function named to functions? A simple API might look like this: class TransformInfo: # stateless transformer def transform(self, input): # return stateful incremental transformer def incrementaltransformer(self): # wrap stream in a transforming stream def streamtransformer(self, stream): incrementaltransformer() would return an object that has one method: def transform(self, input, final=False); [...] Servus, Walter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Betas today - I hope
M.-A. Lemburg schrieb: On 2008-06-11 13:35, Barry Warsaw wrote: So I had planned to do a bunch of work last night looking at the release blocker issues, but nature intervened. A bunch of severe thunderstorms knock out my 'net access until this morning. I'll try to find some time during the day to look at the RB issues. Hopefully we can get Guido to look at them too and Pronounce on some of them. Guido please start with: http://bugs.python.org/issue643841 My plan is to begin building the betas tonight, at around 9 or 10pm EDT (0100 to 0200 UTC Thursday). If a showstopper comes up before then, I'll email the list. If you think we really aren't ready for beta, then I would still like to get a release out today. In that case, we'll call it alpha and delay the betas. There are two things I'd like to get in to 3.0: Another thing that should get in is the PEP 3138 implementation, that is, the ascii() builtin and repr() changes. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bug or a feature?
At 03:37 AM 6/11/2008 +0200, Maciej Fijalkowski wrote: On Wed, Jun 11, 2008 at 3:36 AM, Scott Dial <[EMAIL PROTECTED]> wrote: > Maciej Fijalkowski wrote: >> >> What do you think about this code: >> >> class A: >> locals()[42] = 98 >> >> Seems people rely on it working. > > I apologize for my ignorance, but who? Could you please cite something > reputable that relies on this detail? > It's in tests of sqlalchemy. My question is among the lines "should I bug sqlalchemy guys to remove this, or should I change pypy to accept this". That test is there to ensure that it interoperates with code using the AddOns library from the Cheeseshop; SQLAlchemy is not the source of the usage. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] segfault in struct module
On Wed, Jun 11, 2008 at 1:19 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Martin, since you committed 60793 in Feb, any others like this that need > > merging from release25-maint to trunk off the top of your head? > > That's the entire chunk of "Google bug fixes", and yes, all of it needs > to be ported to 2.6 still. > > I'll look into it, unless you volunteer :-) (it doesn't need to be done > before the beta, as it's bug fixes only). > > Regards, > Martin > No problem, I already did it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Betas today - I hope
On 2008-06-11 17:15, Walter Dörwald wrote:
M.-A. Lemburg wrote:
On 2008-06-11 13:35, Barry Warsaw wrote:
So I had planned to do a bunch of work last night looking at the
release blocker issues, but nature intervened. A bunch of severe
thunderstorms knock out my 'net access until this morning.
I'll try to find some time during the day to look at the RB issues.
Hopefully we can get Guido to look at them too and Pronounce on some
of them. Guido please start with:
http://bugs.python.org/issue643841
My plan is to begin building the betas tonight, at around 9 or 10pm
EDT (0100 to 0200 UTC Thursday). If a showstopper comes up before
then, I'll email the list. If you think we really aren't ready for
beta, then I would still like to get a release out today. In that
case, we'll call it alpha and delay the betas.
There are two things I'd like to get in to 3.0:
* .transform()/.untransform() methods (this is mostly done, just need
to add the methods to PyUnicode, PyBytes and PyByteArray)
What would these methods do? Use the codec machinery without any type
checks?
As discussed in another thread some weeks ago:
.transform() and .untransform() use the codecs to apply same-type
conversions. They do apply type checks to make sure that the
codec does indeed return the same type.
E.g. text.transform('xml-escape') or data.transform('base64').
I think for transformations we don't need the full codec machinery:
> ...
No need to invent another wheel :-) The codecs already exist for
Py2.x and can be used by the .encode()/.decode() methods in Py2.x
(where no type checks occur).
In Py3.x, .encode()/.decode() only allow conversions of the type
unicode <-> bytes. .transform()/.untransform() add conversions
of the type unicode <-> unicode or bytes <-> bytes.
All other conversions in Py3.x have to go through codecs.encode() and
codecs.decode() which are the generic codec access functions from
the codec registry.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jun 11 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2008-07-07: EuroPython 2008, Vilnius, Lithuania25 days to go
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Betas today - I hope
On Wed, Jun 11, 2008 at 4:35 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > So I had planned to do a bunch of work last night looking at the release > blocker issues, but nature intervened. A bunch of severe thunderstorms > knock out my 'net access until this morning. > > I'll try to find some time during the day to look at the RB issues. > Hopefully we can get Guido to look at them too and Pronounce on some of > them. Guido please start with: > > http://bugs.python.org/issue643841 I've added a comment. Let me know if anything I said is unclear. > My plan is to begin building the betas tonight, at around 9 or 10pm EDT > (0100 to 0200 UTC Thursday). If a showstopper comes up before then, I'll > email the list. If you think we really aren't ready for beta, then I would > still like to get a release out today. In that case, we'll call it alpha > and delay the betas. I'd rather call it beta even if certain things are still known to change in the next release. Beta means we'll have a much easier time pushing back on random other feature change proposals. > - -Barry -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Betas today - I hope
On Wed, Jun 11, 2008 at 7:32 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> There are two things I'd like to get in to 3.0:
>
> * .transform()/.untransform() methods (this is mostly done, just need
> to add the methods to PyUnicode, PyBytes and PyByteArray)
I'm +0 on this. It is very minor syntactic sugar that typically saves
you only one import. I expect the argument will nearly always be a
literal, e.g. data.transform('gzip') rather than a variable like
data.transform(compression_method). But it *is* convenient and can
make code more readable, e.g.
if compressed:
data = data.untransform('gzip')
Nobody will have to guess what that does. (IMO the confusion about
which direction the transformation goes is theoretical. except perhaps
in the case of rot13. :-)
> * cleanup of the PyUnicode_AsString() and PyUnicode_AsStringAndSize()
> C APIs (these APIs don't fit into the naming scheme used in the
> Unicode API and have a few other issues as well, see issue 2799;
> at the very least they should be made interpreter internal, ie.
> rename them to _PyUnicode_AsString() and _PyUnicode_AsStringAndSize()
> to prevent their use in extensions)
I'm okay with this too.
> I did not have time in the last few days to work on these and won't
> in the next few days either. Next week looks much better.
>
> If it's ok to make the above changes after the release (whatever you
> call it ;-), that would be great.
That's up to the release manager, but IMO we could have a small list
of *specific* things that are not yet implemented in beta 1 but that
we know will be in beta 2. This is IMO better than just calling it
another alpha, because that keeps the floodgates for more feature
change requests open for another month.
--Guido
> Thanks,
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Source (#1, Jun 11 2008)
Python/Zope Consulting and Support ...http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
>
>
> 2008-07-07: EuroPython 2008, Vilnius, Lithuania25 days to go
>
> Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
>
>
> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
>D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
> Registered at Amtsgericht Duesseldorf: HRB 46611
> ___
> Python-3000 mailing list
> [EMAIL PROTECTED]
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Have been sick, am behind on mail, let me know if there's anything urgent for me
On Tue, Jun 10, 2008 at 10:15 PM, Stefan Behnel <[EMAIL PROTECTED]> wrote: > This seems to require a BDFL decision: > > http://bugs.python.org/issue2997 > > Executive Summary: PyNumberMethods has been changed on py3k back in 2006 with > the nb_divide removal, so it's now incompatible with Py2. But there are three > more unused struct members *behind* that field that can be removed for beta1, > but have not been removed yet. Should they be removed for cleanliness (patch > in the issue) or should nb_divide and nb_inplace_divide instead be restored > (rev 43285) to restore backwards compatibility? I've added a recommendation to apply this patch to the bug. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Have been sick, am behind on mail, let me know if there's anything urgent for me
On Wed, Jun 11, 2008 at 5:59 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> http://bugs.python.org/issue643841 >> >> It's a long bug thread, but needs a decision. > > I just added a couple of messages at the end that recap the more recent > discussions (the early responses to the issue are *really* old...) I've added my opinion to the bug: I am in favor of documenting the current behavior (making it mandatory for all implementations). I would like to hold back on adding a proxy mixin class until we've found some actual use for it. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Betas today - I hope
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 11, 2008, at 1:02 PM, Guido van Rossum wrote: On Wed, Jun 11, 2008 at 4:35 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: So I had planned to do a bunch of work last night looking at the release blocker issues, but nature intervened. A bunch of severe thunderstorms knock out my 'net access until this morning. I'll try to find some time during the day to look at the RB issues. Hopefully we can get Guido to look at them too and Pronounce on some of them. Guido please start with: http://bugs.python.org/issue643841 I've added a comment. Let me know if anything I said is unclear. Nope, it was perfect, thanks. My plan is to begin building the betas tonight, at around 9 or 10pm EDT (0100 to 0200 UTC Thursday). If a showstopper comes up before then, I'll email the list. If you think we really aren't ready for beta, then I would still like to get a release out today. In that case, we'll call it alpha and delay the betas. I'd rather call it beta even if certain things are still known to change in the next release. Beta means we'll have a much easier time pushing back on random other feature change proposals. Sounds good. I'm going to go through the other release critical issues and will follow up on this thread if there are any other questions. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFANPXEjvBPtnXfVAQIMfgQAovATNsivTKAMIUPsue+Tq5OwVlE8zxIf KqmNfXDdyAWhWjnWrao0V73A2v6TKvgL2H6SON6UT1oHvRus1ahLWXQWpTUIdn4L jiYfeek14XoVim8mRz7L8mhxThADPMj3YkhWK448QyZbMkColMqUIVCgvfaQYSxM 2+3zOWQJ/AQ= =eqAr -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] update_wrapper should preserve staticmethod behavior
Please submit a fix to the issue tracker at bugs.python.org if you care about this. On Wed, Jun 11, 2008 at 7:06 AM, Calvin Spealman <[EMAIL PROTECTED]> wrote: > I'd like to make a claim about the following example, that update_wrapper > should be improved to preserve the behavior of known, built-in decorators. > In this case, I'm talking about staticmethod. The order I list here feels > natural, but it obviously doesn't work. The only reason it doesn't seems to > be that it is trying to decorate the descriptor, not the function itself. > This is expected, but it could certainly be smart enough to detect a > descriptor and attempt to get the actual callable underneath, could it not? > It would not work for all cases, of course. > def d(f): > ... def nf(*a, **kw): > ... print "decorated function called" > ... return f(*a, **kwargs) > ... functools.update_wrapper(nf, f) > ... return nf > ... class A(object): > ... @d > ... @staticmethod > ... def a(self): > ... print "a" > ... > Traceback (most recent call last): > File "", line 1, in > File "", line 3, in A > File "", line 5, in d > File > "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/functools.py", > line 33, in update_wrapper >setattr(wrapper, attr, getattr(wrapped, attr)) > AttributeError: 'staticmethod' object has no attribute '__module__' > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] update_wrapper should preserve staticmet hod behavior
Calvin Spealman socialserve.com> writes: > Traceback (most recent call last): >File "", line 1, in >File "", line 3, in A >File "", line 5, in d >File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ > python2.5/functools.py", line 33, in update_wrapper > setattr(wrapper, attr, getattr(wrapped, attr)) > AttributeError: 'staticmethod' object has no attribute '__module__' Well, if staticmethod doesn't mirror the original function's __module__ attribute, I'd say staticmethod is the culprit. Since Python grew the update_wrapper function, it seems reasonable to ask that all decorators (or decorator-alikes) provided with Python call update_wrapper. Of course staticmethod is written in C, so is there a C function somewhere providing the same functionality as update_wrapper does? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Have been sick, am behind on mail, let me know if there's anything urgent for me
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 11, 2008, at 1:15 AM, Stefan Behnel wrote: Guido van Rossum wrote: anything someone really needs me to look at ASAP (e.g. a BDFL decision affecting the impending beta release) please send me an email This seems to require a BDFL decision: http://bugs.python.org/issue2997 Guido's approved the patch. Please go ahead and apply it. If no one gets to it before tonight, I'll put it in beta 1 if it applies cleanly. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFARanEjvBPtnXfVAQJM/AP+I7gb3VM90c6iCAkvx8EijC2LmrIPtmN2 kSMtMLlyObEZLdGGiPOQdafwx+SeuKxwY2d/RF1VvM2K6fWyWjbw0wt2ZMLxs1UB AVz4PmHSeS23jao2io75wBx4iUTmccte0dDBx6JJYojq6PZeMe4W5lJHuzuyrHWQ i4EnPJHiqag= =HaZV -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Have been sick, am behind on mail, let me know if there's anything urgent for me
On Wed, Jun 11, 2008 at 12:54 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: >> >> http://bugs.python.org/issue2997 > > Guido's approved the patch. Please go ahead and apply it. If no one gets > to it before tonight, I'll put it in beta 1 if it applies cleanly. I'm going to handle it. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Have been sick, am behind on mail, let me know if there's anything urgent for me
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 11, 2008, at 1:58 PM, Benjamin Peterson wrote: On Wed, Jun 11, 2008 at 12:54 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: http://bugs.python.org/issue2997 Guido's approved the patch. Please go ahead and apply it. If no one gets to it before tonight, I'll put it in beta 1 if it applies cleanly. I'm going to handle it. Thanks! You're awesome. :) - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFASynEjvBPtnXfVAQK9YgQAuVbLsvZd+O2RGac/Tqr0DHcCPHm7lOL9 QyqUMzideytmuGhw4IjaIIKhP2G1Dg7iskuCEqkosm5niRKz4vw6/R53kMC5xPRQ Adm+KfCxohXzJoN7+ON89wnM5AqfT1AxeYlhGkKGvxRfjTydIXMTTTSJLC4ztyT6 BWIG49zqEJY= =kLlY -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bogus comment in Python.h
On Tue, Jun 10, 2008 at 10:13 AM, Doug Evans <[EMAIL PROTECTED]> wrote: > I spent a bit of time trying to figure out what's going on here > (was getting errors regarding missing uintptr_t while trying to compile > an external module with Python 2.4). > pyport.h now includes stdint.h but can we fix up this in Python.h? > > /* For uintptr_t, intptr_t */ > #ifdef HAVE_STDDEF_H > #include > #endif > > I'm guessing removing the inclusion of stddef.h will break something. > It's a bit of a wart (or not) that Python.h includes stdlib.h, stddef.h, > et.al. > but pyport.h includes stdint.h (why not just include them all in one > place?). > > Anyways, to save some confusion for someone trying to track down > a problem in the future, could the above comment be removed? Okay. I changed it to /* For size_t? */ in trunk (2.6). > --- Python.h(revision 64082) > +++ Python.h(working copy) > @@ -43,8 +43,6 @@ > #ifdef HAVE_UNISTD_H > #include > #endif > - > -/* For uintptr_t, intptr_t */ > #ifdef HAVE_STDDEF_H > #include > #endif > > [I'd suggest rewording it except that I'm not sure exactly what stddef.h > is used for. Presumably it's size_t but I didn't want to guess.] > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 8 and optional underscores
"Function names should be lowercase, with words separated by underscores as necessary to improve readability." -- PEP 8 If I'm reading this correctly, then underscores are not required everywhere. Can some of these be shortened? function:: active_count() method:: Thread.get_name() method:: Thread.is_alive() method:: Thread.is_daemon() method:: Thread.set_daemon(daemonic) In some cases, the mental pronounciation changes and affects my perception of meaning. For example, Thread.setName or Thread.setname both feel like a setter to me, but Thread.set_name causes a mental pause and a momentary double-take (is it the name of a set?). A few months ago, I think there was a PEP 8 discussion rejecting suggestions to make underscores required everywhere (leading to getattr-->get_attr, iteritems-->iter_items, staticmethod->static_method, setdefault->set_default, popitem->pop_item, splitlines->split_lines etc.) Perhaps underscores should only be used when the contracted form lacks clarity. Food for thought, Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 and optional underscores
On Wed, Jun 11, 2008 at 1:03 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > "Function names should be lowercase, with words separated by underscores as > necessary to improve readability." -- PEP 8 > > If I'm reading this correctly, then underscores are not required > everywhere. Can some of these be shortened? > > function:: active_count() > method:: Thread.get_name() > method:: Thread.is_alive() > method:: Thread.is_daemon() > method:: Thread.set_daemon(daemonic) > > In some cases, the mental pronounciation changes and affects my perception > of meaning. For example, Thread.setName or Thread.setname both feel like a > setter to me, but Thread.set_name causes a mental pause and a momentary > double-take (is it the name of a set?). Actually, in this case, I think the Pythonic thing to do would be to use properties. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] rest markup in ctypes docs
There are a few cases where the ctypes docs are rendered incorrectly: http://docs.python.org/dev/library/ctypes.html#function-prototypes This looks as if 'prototype' would be a symbol exposed by ctypes; it is not - it is used as a placeholder for the object returned by calls to the ctypes.CFUNCTYPE, ctypes.WINFUNCTYPE, and ctypes.PYFUNCTYPE functions above. The rest markup is like this: .. function:: prototype(address) :noindex: Returns a foreign function at the specified address. Some lines below, it looks like ctypes would export '1', '2', and '4'. Here is the markup: .. function:: prototype(address) :noindex: Returns a foreign function at the specified address. How can this be fixed? -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rest markup in ctypes docs
Thomas Heller schrieb: > There are a few cases where the ctypes docs are rendered incorrectly: > > http://docs.python.org/dev/library/ctypes.html#function-prototypes > > This looks as if 'prototype' would be a symbol exposed by ctypes; it is > not - it is used as a placeholder for the object returned by calls to > the ctypes.CFUNCTYPE, ctypes.WINFUNCTYPE, and ctypes.PYFUNCTYPE functions > above. > > The rest markup is like this: > > > .. function:: prototype(address) >:noindex: > >Returns a foreign function at the specified address. > > Some lines below, it looks like ctypes would export '1', '2', and '4'. > Here is the markup: > Sorry, I meant this: .. data:: 1 :noindex: Specifies an input parameter to the function. > > How can this be fixed? > -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] update_wrapper should preserve staticmethod behavior
staticmethod doesn't wrap anything, it just creates a descriptor on the class with a __get__ that returns the original, untouched callable. Doesn't even care _what_ the thing you use it on is (function, other callable, or something else entirely.) This actually shouldn't be attempted on non-staticmethod descriptors, after thinking about it. Can't be sure that desc.__get__(cls) is usable to wrap when, at the end, you will be doing some_instance.a and now had the wrong __get__() signature used. Oh, no! class A(object): @d @some_decorator_returns_a_descriptor def a(): pass What should probably happen here is that d needs to see its decorating a descriptor and itself return a descriptor to pass along the right behavior. So, when you do A().a() you should have d.__get__ (cls, inst) calling some_decorator_returns_a_descriptor.__get__(cls, inst) and acting as if that was the thing it decorated. Of course, this would have the probably unexpected behavior of decorating such things at binding time (ie, when a classmethod is bound) rather than after definition. Not good. They could be cached and this used to implement new functionality that the decorator can be applied to the class method once for each class its bound to (interesting? useful?), but I can't think of a justification myself. Unless any of this other behavior could be justified, I'll provide an update_wrapper() patch to at least become staticmethod smart. On Jun 11, 2008, at 1:48 PM, Antoine Pitrou wrote: Calvin Spealman socialserve.com> writes: Traceback (most recent call last): File "", line 1, in File "", line 3, in A File "", line 5, in d File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/functools.py", line 33, in update_wrapper setattr(wrapper, attr, getattr(wrapped, attr)) AttributeError: 'staticmethod' object has no attribute '__module__' Well, if staticmethod doesn't mirror the original function's __module__ attribute, I'd say staticmethod is the culprit. Since Python grew the update_wrapper function, it seems reasonable to ask that all decorators (or decorator-alikes) provided with Python call update_wrapper. Of course staticmethod is written in C, so is there a C function somewhere providing the same functionality as update_wrapper does? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ ironfroggy%40socialserve.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] update_wrapper should preserve staticmet hod behavior
Calvin Spealman socialserve.com> writes: > > staticmethod doesn't wrap anything, it just creates a descriptor on > the class with a __get__ that returns the original, untouched > callable. Doesn't even care _what_ the thing you use it on is > (function, other callable, or something else entirely.) FWIW, I still disagree. Technically, it might not "wrap" anything (in the sense that it isn't defined as a function returning another function - which is a narrow definition of a wrapper by the way), but semantically it does. To the non-expert programmer, it is a decorator like any other one. The fact that it is implemented differently from other decorators is not an excuse for it to follow different rules... Unless, of course, there is a good *semantic* reason for staticmethod not to mirror the __module__ attribute. (by the way, does the same apply to classmethod as well?) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bug or a feature?
Phillip J. Eby wrote:
That test is there to ensure that it interoperates with code using the
AddOns library from the Cheeseshop; SQLAlchemy is not the source of the
usage.
Now that's interesting. The AddOns library uses class objects as keys in
the __dict__, but that doesn't says anything about the usage of
locals(). At no point in the AddOns library is locals() abused like
this, so even if one asserts that assignment to the dict returned by
locals() is a bug, the underlying behavior of interest is whether
__dict__ is allowed to have non-string keys.
>>> from peak.util.addons import AddOn
>>> class C: pass
>>> class A(AddOn): pass
>>> spam = C()
>>> print spam.__dict__
{}
>>> A(spam)
>>> print spam.__dict__
{: }
If non-string keys are not allowed in __dict__, then the AddOns library
should be changed to add another dict to the object of interest to track
these AddOn instances.
-Scott
--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rest markup in ctypes docs
Thomas Heller schrieb: Thomas Heller schrieb: There are a few cases where the ctypes docs are rendered incorrectly: http://docs.python.org/dev/library/ctypes.html#function-prototypes This looks as if 'prototype' would be a symbol exposed by ctypes; it is not - it is used as a placeholder for the object returned by calls to the ctypes.CFUNCTYPE, ctypes.WINFUNCTYPE, and ctypes.PYFUNCTYPE functions above. The rest markup is like this: .. function:: prototype(address) :noindex: Returns a foreign function at the specified address. You can use .. function:: prototype(address) :noindex: :module: here. (The :module: option gives the function's module name which is empty in this case.) Some lines below, it looks like ctypes would export '1', '2', and '4'. Here is the markup: Sorry, I meant this: ... data:: 1 :noindex: Specifies an input parameter to the function. A simple definition list or table should suffice here. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Betas today - I hope
On Wed, Jun 11, 2008 at 7:35 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > My plan is to begin building the betas tonight, at around 9 or 10pm EDT > (0100 to 0200 UTC Thursday). If a showstopper comes up before then, I'll > email the list. If you think we really aren't ready for beta, then I would > still like to get a release out today. In that case, we'll call it alpha > and delay the betas. I have two release blockers pending review: http://bugs.python.org/issue2918 http://bugs.python.org/issue2917 I believe both patches are ready to be committed to the py3k branch. However, I would certainly like that someone would review the patches (or at least test them). Right now, I am currently looking at fixing issue 2919 (http://bugs.python.org/issue2919). The profile and the cProfile module differ much more than I originally expected. So, I won't be able to get these two for the beta. I have also been looking at http://bugs.python.org/issue2874, in which Benjamin Peterson proposed an simple solution to fix it. Although I haven't tried his approach, I think I could get this one done for today. Finally, I would like to commit the patch in http://bugs.python.org/issue2523 which fix the quadratic behavior in BufferedReader.read(). It would also be nice to have someone else experienced with the io module to review the patch. Cheers, -- Alexandre ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] update_wrapper should preserve staticmethod behavior
On Wed, Jun 11, 2008 at 12:22 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > Calvin Spealman socialserve.com> writes: >> >> staticmethod doesn't wrap anything, it just creates a descriptor on >> the class with a __get__ that returns the original, untouched >> callable. Doesn't even care _what_ the thing you use it on is >> (function, other callable, or something else entirely.) > > FWIW, I still disagree. Technically, it might not "wrap" anything (in the > sense > that it isn't defined as a function returning another function - which is a > narrow definition of a wrapper by the way), but semantically it does. To the > non-expert programmer, it is a decorator like any other one. The fact that it > is > implemented differently from other decorators is not an excuse for it to > follow > different rules... > > Unless, of course, there is a good *semantic* reason for staticmethod not to > mirror the __module__ attribute. > > (by the way, does the same apply to classmethod as well?) Remember (a) these are implemented in C, and (b) they were created in Python 2.2, before we even had decorators (first introduced in 2.4). I'm fine with making them more transparent and conformant to emerging protocols, but they will always be a little different, due to being implemented as objects rather than functional wrappers. The latter approach *can* be used for decorator implementations to, it just is done rarely. I see this as something that can be done post beta 1. It has to be done while carefully remaining backwards compatible though. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Assignment to None
On Sun, Jun 8, 2008 at 10:19 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > So, it's okay to setattr the attribute name "None" but not okay to set > > it directly? Is this deliberate or is it an unintentional side effect > > of parser changes to prevent assignment to None? > > It's deliberate. setattr(o, "foo bar", "baz") also works, even though > "foo bar" is not an identifier. setattr doesn't take the Python grammar > into account, but only the object's structure. Thanks for this example; I found it useful. As Michael says, my primary interest in asking this question is because I'm working on IronPython. Compatibility with CPython is extremely important for us, so I need to understand exactly what behavior is mandated. Here's a recap of the ground this thread has covered: 1. In all versions, direct access to members whose names are reserved keywords (such as "print") is not allowed. 2. In Python 2.5 and 2.6, "True", "False" and "None" are not keywords, but direct assignment to a member named "None" is specifically prevented by the parser. Members named "None" may, however, be read directly if they are present. There is no special handling for "True" or "False". 3. In Python 3.0, "True", "False" and "None" are keywords. This eventually leads to a problem for us in interoperability with other CLR code. One example, as Michael points out, is that "None" is a relatively common member of enumeration types. Now for IronPython 2.0, we're targeting compatibility with CPython 2.5. If we duplicate 2.5's behavior and allow direct reads but not direct writes for a member named None, we'd be okay for the enumeration example. Enumerated values aren't writable anyway. However, this sets us up for a problem with some hypothetical future version of IronPython that targets 3.0 compabililty. At that point, we'll face the unpleasant task of having to choose between compability and interoperability. We haven't really had to do this before now because the convention in CLR-based code is typically that publicly-exposed symbols start with a capital letter -- and all of the existing reserved words in Python are lower-case. It's likely to be a much bigger issue with Jython, given the Java convention of having lower-cased method names. If I recall correctly, Jython handles this by appending a trailing underscore to the imported name and there's no reason why we couldn't do something similar. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Betas today - I hope
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 11, 2008, at 4:54 PM, Alexandre Vassalotti wrote: On Wed, Jun 11, 2008 at 7:35 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: My plan is to begin building the betas tonight, at around 9 or 10pm EDT (0100 to 0200 UTC Thursday). If a showstopper comes up before then, I'll email the list. If you think we really aren't ready for beta, then I would still like to get a release out today. In that case, we'll call it alpha and delay the betas. I have two release blockers pending review: http://bugs.python.org/issue2918 http://bugs.python.org/issue2917 I believe both patches are ready to be committed to the py3k branch. However, I would certainly like that someone would review the patches (or at least test them). In IRC, Benjamin agreed to review these and commit them if they look okay. I'm still 3-4 hours away from making the betas, so there's time to do this and still see how the buildbots react. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFBG43EjvBPtnXfVAQJSYAP9FwvFppbeIQX8IhCUtXAXf5jSoGkpTKHQ FT5PBhI/WmM1HTwtx3i06EA/3P+rB2yIVOJhCuK1ORoLvAZO1C8gKUp/8yvgH2KD 0OtlVYgfs4iXwgXe36dI9uBt9AIaohHNnuEgzqzH/IXIcdZ21bp3WKJTbvSgruFX q0K3SkO9ano= =TI1T -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Potential beta showstopper (was Re: Have been sick, am behind on mail, let me know if there's anything urgent for me)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Okay, we have a potential showstopper for the betas today. All the 3.0 buildbots are bloody red: http://www.python.org/dev/buildbot/stable/ Running the tests locally on OS X 10.5 and Ubuntu 8.04 confirm that the tests hang after test_xmlrpc. The tests are uninterruptible. I hereby give permission to any dev with commit privileges to checkin a fix, or back out the offending revision. I will be off-line for about 3 more hours and if this can't be fixed by then, we will have to postpone the releases. Once I'm back, I'll be on #python-dev @ freenode. Thanks to Benjamin and Alexandre for helping me get through the current crop of release critical issues today. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFBOHXEjvBPtnXfVAQK6zQP+Nnjt6Q97heAuquZgKEfMxXBL/QzodDgB Th58+w04h0gTVW39Y9NEeKynVPrjsbjxKdrbdZ0i+1pEbqJMXyV65jFmxqb+mYdd 194s5hm+U0KEk7h+64aEkmvFPAgeZ2TGBrqCu5CWDNbWmqerPWuNDzqPxQrWd4Mt wcaic8LFaaU= =4MTf -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Potential beta showstopper (was Re: Have been sick, am behind on mail, let me know if there's anything urgent for me)
On Wed, Jun 11, 2008 at 5:13 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Okay, we have a potential showstopper for the betas today. All the 3.0 > buildbots are bloody red: > > http://www.python.org/dev/buildbot/stable/ > > Running the tests locally on OS X 10.5 and Ubuntu 8.04 confirm that the > tests hang after test_xmlrpc. The tests are uninterruptible. > > I hereby give permission to any dev with commit privileges to checkin a fix, > or back out the offending revision. I will be off-line for about 3 more > hours and if this can't be fixed by then, we will have to postpone the > releases. Already done. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bug or a feature?
"Scott Dial" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] || If non-string keys are not allowed in __dict__, then the AddOns library | should be changed to add another dict to the object of interest to track | these AddOn instances. There are three possibilities with respect to __dict__ and non-string keys. 1. All implementations must reject such. 2. Each implementation decides for itself. 3. All implementations must allow such. Current, CPython does not reject, eliminating 1). Since, as I understand it, at least 1 other implementation does reject, 3) is also eliminated until Guido decrees otherwise and such implementation(s) change. This leaves 2) as the de facto situation, but this could be made clearer in the docs: "The result of trying to add non-string keys to any __dict__ attribute is implementation defined." This means that portable Python code must act as if 1) were the case. The Data Model chapter of the Reference Manual lists .__dict__ as a special attribute of callables, modules, classes, and instances. It describes __dict__ as a "namespace dictionary" or "implementation of the namespace" thereof. Since namespaces map names (or possibly non-name strings) to objects, this to me implies that an implementation is and should not be required to allow non-strings in __dict__. The same chapter has more than one sentence saying something like "o.x is equivalent to o.__dict__['x']". While one could read this as prohibiting o.__dict__[non_string], one could also read it as being silent, neither allowing nor prohibiting. The builtin interface functions setattr, hasattr, getattr all require strings for accessing the underlying __dict__. Since they could have been defined otherwise, to accept any object as an attribute 'name' (key), this again implies (to me) that __dict__s are only intended and only required to have string keys. Hence, I was initially surprised that 1) above was not true. So I might add something stronger to the docs, something like "The special __dict__ attributes are only intended to hold string keys. If an implementation allows other keys, that is only an current accidental side-effect of considerations of parsimony and efficiency." Contrariwise, if 3) were mandated, then I would think that the xxxattr functions should be changed. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bug or a feature?
On Thu, Jun 12, 2008 at 2:32 AM, Terry Reedy <[EMAIL PROTECTED]> wrote: > > "Scott Dial" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > || If non-string keys are not allowed in __dict__, then the AddOns library > | should be changed to add another dict to the object of interest to track > | these AddOn instances. > > There are three possibilities with respect to __dict__ and non-string keys. > 1. All implementations must reject such. > 2. Each implementation decides for itself. > 3. All implementations must allow such. > > Current, CPython does not reject, eliminating 1). Since, as I understand > it, at least 1 other implementation does reject, 3) is also eliminated > until Guido decrees otherwise and such implementation(s) change. This > leaves 2) as the de facto situation, but this could be made clearer in the > docs: "The result of trying to add non-string keys to any __dict__ > attribute is implementation defined." This means that portable Python code > must act as if 1) were the case. > > The Data Model chapter of the Reference Manual lists .__dict__ as a special > attribute of callables, modules, classes, and instances. It describes > __dict__ as a "namespace dictionary" or "implementation of the namespace" > thereof. Since namespaces map names (or possibly non-name strings) to > objects, this to me implies that an implementation is and should not be > required to allow non-strings in __dict__. > > The same chapter has more than one sentence saying something like "o.x is > equivalent to o.__dict__['x']". While one could read this as prohibiting > o.__dict__[non_string], one could also read it as being silent, neither > allowing nor prohibiting. > > The builtin interface functions setattr, hasattr, getattr all require > strings for accessing the underlying __dict__. Since they could have been > defined otherwise, to accept any object as an attribute 'name' (key), this > again implies (to me) that __dict__s are only intended and only required to > have string keys. Hence, I was initially surprised that 1) above was not > true. So I might add something stronger to the docs, something like "The > special __dict__ attributes are only intended to hold string keys. If an > implementation allows other keys, that is only an current accidental > side-effect of considerations of parsimony and efficiency." > > Contrariwise, if 3) were mandated, then I would think that the xxxattr > functions should be changed. > > Terry Jan Reedy > > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com > This is completely irrelevant. This post is not about assigning non-string stuff to __dict__ of class which works completely fine. It's about abusing locals, which are not even given that they'll modify this dict. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bug or a feature?
"Maciej Fijalkowski" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| On Thu, Jun 12, 2008 at 2:32 AM, Terry Reedy <[EMAIL PROTECTED]> wrote:
| >
| > "Scott Dial" <[EMAIL PROTECTED]> wrote in message
| > news:[EMAIL PROTECTED]
| > || If non-string keys are not allowed in __dict__, then the AddOns
library
| > | should be changed to add another dict to the object of interest to
track
| > | these AddOn instances.
| >
| > There are three possibilities with respect to __dict__ and non-string
keys.
| > 1. All implementations must reject such.
| > 2. Each implementation decides for itself.
| > 3. All implementations must allow such.
| >
| > Current, CPython does not reject, eliminating 1). Since, as I
understand
| > it, at least 1 other implementation does reject, 3) is also eliminated
| > until Guido decrees otherwise and such implementation(s) change. This
| > leaves 2) as the de facto situation, but this could be made clearer in
the
| > docs: "The result of trying to add non-string keys to any __dict__
| > attribute is implementation defined." This means that portable Python
code
| > must act as if 1) were the case.
| >
| > The Data Model chapter of the Reference Manual lists .__dict__ as a
special
| > attribute of callables, modules, classes, and instances. It describes
| > __dict__ as a "namespace dictionary" or "implementation of the
namespace"
| > thereof. Since namespaces map names (or possibly non-name strings) to
| > objects, this to me implies that an implementation is and should not be
| > required to allow non-strings in __dict__.
| >
| > The same chapter has more than one sentence saying something like "o.x
is
| > equivalent to o.__dict__['x']". While one could read this as
prohibiting
| > o.__dict__[non_string], one could also read it as being silent, neither
| > allowing nor prohibiting.
| >
| > The builtin interface functions setattr, hasattr, getattr all require
| > strings for accessing the underlying __dict__. Since they could have
been
| > defined otherwise, to accept any object as an attribute 'name' (key),
this
| > again implies (to me) that __dict__s are only intended and only
required to
| > have string keys. Hence, I was initially surprised that 1) above was
not
| > true. So I might add something stronger to the docs, something like
"The
| > special __dict__ attributes are only intended to hold string keys. If
an
| > implementation allows other keys, that is only an current accidental
| > side-effect of considerations of parsimony and efficiency."
| >
| > Contrariwise, if 3) were mandated, then I would think that the xxxattr
| > functions should be changed.
| This is completely irrelevant. This post is not about assigning
| non-string stuff to __dict__ of class which works completely fine.
My apologies for clipping too much of Scott's post. Here is the rest that
came before what I quoted, which makes clear, from first sentence to last
line, that *he* *is* talking about assigning non-string stuff to __dict__
of a class.
"The AddOns library uses class objects as keys in
the __dict__, but that doesn't says anything about the usage of
locals(). At no point in the AddOns library is locals() abused like
this, so even if one asserts that assignment to the dict returned by
locals() is a bug, the underlying behavior of interest is whether
__dict__ is allowed to have non-string keys.
>>> from peak.util.addons import AddOn
>>> class C: pass
>>> class A(AddOn): pass
>>> spam = C()
>>> print spam.__dict__
{}
>>> A(spam)
>>> print spam.__dict__
{: }
"
Whether non-strings keys in o.__dict__ 'works fine' depends on one's
definition of 'works fine'. In any case, as of 3.0a5, I thinks the docs
could better clarify the status of *this* 'feature'. Whatever
pronouncement Guido has made has not, that I could find, made it in.
| It's about abusing locals, which are not even given that they'll
| modify this dict.
I thought it settled that that is a bad thing to do. Here the doc is
pretty clear.
tjr
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Betas today - I hope
On Wed, Jun 11, 2008 at 2:42 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On Jun 11, 2008, at 4:54 PM, Alexandre Vassalotti wrote: >> I have two release blockers pending review: >> >> http://bugs.python.org/issue2918 >> http://bugs.python.org/issue2917 >> >> I believe both patches are ready to be committed to the py3k branch. >> However, I would certainly like that someone would review the patches >> (or at least test them). > > In IRC, Benjamin agreed to review these and commit them if they look okay. > I'm still 3-4 hours away from making the betas, so there's time to do this > and still see how the buildbots react. That's great, and I see these were committed and the bugs closed. Next time, can we also have some kind of OK from the reviewer (Benjamin, I presume) in the issue tracker? IRC does not leave a usable trail of decisions. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Potential beta showstopper (was Re: Have been sick, am behind on mail, let me know if there's anything urgent for me)
On Wed, Jun 11, 2008 at 3:18 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > On Wed, Jun 11, 2008 at 5:13 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: >> Okay, we have a potential showstopper for the betas today. All the 3.0 >> buildbots are bloody red: >> >> http://www.python.org/dev/buildbot/stable/ >> >> Running the tests locally on OS X 10.5 and Ubuntu 8.04 confirm that the >> tests hang after test_xmlrpc. The tests are uninterruptible. >> >> I hereby give permission to any dev with commit privileges to checkin a fix, >> or back out the offending revision. I will be off-line for about 3 more >> hours and if this can't be fixed by then, we will have to postpone the >> releases. > > Already done. Done what? Fixed, or backed out? Any more details? Old farts who aren't on IRC want to know. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Betas today - I hope
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 11, 2008, at 10:16 PM, Guido van Rossum wrote: On Wed, Jun 11, 2008 at 2:42 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: On Jun 11, 2008, at 4:54 PM, Alexandre Vassalotti wrote: I have two release blockers pending review: http://bugs.python.org/issue2918 http://bugs.python.org/issue2917 I believe both patches are ready to be committed to the py3k branch. However, I would certainly like that someone would review the patches (or at least test them). In IRC, Benjamin agreed to review these and commit them if they look okay. I'm still 3-4 hours away from making the betas, so there's time to do this and still see how the buildbots react. That's great, and I see these were committed and the bugs closed. Next time, can we also have some kind of OK from the reviewer (Benjamin, I presume) in the issue tracker? IRC does not leave a usable trail of decisions. Good point. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFCIJ3EjvBPtnXfVAQIvXAP/fB6WAD4lS3XEKyEt/FwEoBfgileV4/bj 4km/LPOEtjN4jNks8dSoL+JHsym/76r0uylx3s3jH1sLCKmM7i9tD/SNo/Cim6r9 5fgDmreZkDU+zyyvhdiuxUl+jxmroDPd3R6vPptVbwly4SHsftceZ6jToJUvcNPd p0nDoyCI8VU= =xktw -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Potential beta showstopper (was Re: Have been sick, am behind on mail, let me know if there's anything urgent for me)
On Wed, Jun 11, 2008 at 9:18 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Wed, Jun 11, 2008 at 3:18 PM, Benjamin Peterson >> >> Already done. > > Done what? Fixed, or backed out? Any more details? Old farts who > aren't on IRC want to know. :-) That would be fixed. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bug or a feature?
Maciej Fijalkowski wrote:
On Thu, Jun 12, 2008 at 2:32 AM, Terry Reedy <[EMAIL PROTECTED]> wrote:
"Scott Dial" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|| If non-string keys are not allowed in __dict__, then the AddOns library
| should be changed to add another dict to the object of interest to track
| these AddOn instances.
There are three possibilities with respect to __dict__ and non-string keys.
1. All implementations must reject such.
2. Each implementation decides for itself.
3. All implementations must allow such.
Current, CPython does not reject, eliminating 1). Since, as I understand
it, at least 1 other implementation does reject, 3) is also eliminated
until Guido decrees otherwise and such implementation(s) change. This
leaves 2) as the de facto situation, but this could be made clearer in the
docs: "The result of trying to add non-string keys to any __dict__
attribute is implementation defined." This means that portable Python code
must act as if 1) were the case.
This is completely irrelevant. This post is not about assigning
non-string stuff to __dict__ of class which works completely fine.
It's about abusing locals, which are not even given that they'll
modify this dict.
Not withstanding Terry's respond, this is not as off-topic as you make
it out to be. The test case you cited is in fact test this exact
'feature'. And as Terry expounded on it, it was unclear to me whether
that was even of allowed. The only reason the test used locals() was
because it was the only way to insert a non-string key into the class
namespace.
class A:
... locals()[42] = 98
A.__dict__
{'__module__': '__main__', 43: 1, '__doc__': None}
locals() has to be used because __dict__ is unavailable at definition.
class A:
... __dict__[42] = 98
NameError: name '__dict__' is not defined
So, while one can write:
class A: pass
a.__dict__[42] = 98
But that's not quite the same. Nevertheless, it was still unclear
whether there was any pronouncements on non-string keys. Sorry for
wasting your time.
-Scott
--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] No betas today
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Much thanks to Benjamin Peterson and Alexandre Vassalotti for providing much help today trying to get the betas out. Unfortunately, it's not gonna happen today. There are two issues blocking the release. http://bugs.python.org/issue3088 http://bugs.python.org/issue3089 The main problem (issue 3089) is that none of the Python 3.0 buildbots are green. Issue 3088 may only happen for me, but test_multiprocessing simply hangs for me on OS X 10.5.3. I'm going to bed now. As soon as we can turn the bots green we can try again. This weekend might be a good time for me. Please help out by resolving these two issues. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFCtZHEjvBPtnXfVAQLrHQQAoq1RCNeawpJHaefuvmZiS4VZzzvtV5Bm HFW6FWyO86NNEcCK6Delthf+H1mgjCaoymHojxBJhWm7UJK0WjMz+0RpF8zcLo0R i8I8SiFLy6kRB5UxlZHS/VXDi8QS92SogRvlnWLBwXNNK6wlgeqK8C0zt1ilL0q6 Fqk/AsGO/fA= =HlEA -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] OFF-TOPIC-BUT-IMPORTANT: End of free internet model by 2012 ?
Hi everybody on the list ! Sorry about the off-topic message, but giving the nature of the message and the nature of the list (after all, everybody here uses Internet or develops for web in some way), I decided to post this here and see what you guys think about it. http://ipower.ning.com/netneutrality To quote the article (so you know if it interests you or not): "Bell Canada and TELUS (formerly owned by Verizon) employees officially confirm that by 2012 ISP's all over the globe will reduce Internet access to a TV-like subscription model, only offering access to a small standard amount of commercial sites and require extra fees for every other site you visit. These 'other' sites would then lose all their exposure and eventually shut down, resulting in what could be seen as the end of the Internet." It is important to note that, although the article mentions Bell Canada, it is not that hard to imagine that this will eventually be expanded to all big ISPs. Thanks and again, I apologize for this off-topic message ! Daniel -- What this world needs is a good five-dollar plasma weapon. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
