[Python-Dev] multiprocessing problems
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. 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? 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] segfault in struct module
On Tue, Jun 10, 2008 at 9:04 AM, Jean-Paul Calderone <[EMAIL PROTECTED]>
wrote:
>
> [EMAIL PROTECTED]:~$ ~/Projects/python/trunk/python
> Python 2.6a3+ (trunk:63964, Jun 5 2008, 16:49:12)
> [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import struct
> >>> struct.pack("357913941c", 'a')
> Segmentation fault
> [EMAIL PROTECTED]:~$
>
> The unit test for exactly this case was deleted in r60892. I would like to
> suggest that just deleting unit tests isn't a very good idea.
>
> Jean-Paul
>
That deletion was apparently in the release25-maint branch where this bug
has been fixed in order to avoid the test case from allocating 8gb on 64bit
hosts where it wouldn't need to raise a MemoryError (
http://bugs.python.org/issue2137). However it looks like it was never
committed to trunk. (release25-maint r60793 has a lot of fixes)
I'm looking into merging the fixes into trunk.
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?
-Greg
___
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
Hi Guido, glad to hear you're recovering. 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 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? Thanks, Stefan ___ 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: 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? -- Greg ___ 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 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 ___ 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__
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. --Guido On Sat, Jun 7, 2008 at 2:10 PM, Armin Ronacher <[EMAIL PROTECTED]> wrote: > Hi, > > That's just a flaming-sword thread but I want to mention it nonetheless :-) > > Basically I propose getting rid of __future__._Feature.getMandatoryRelease() > in favour of __future__._Feature.mandatory. That's backwards compatibile > and much more pythonic. Getters/Setters are considered unpythonic and the > getting rid of all that Java-like naming sounds like a good idea to me :) > > If threading/processing gets a pep8ified API with 2.6, why not __future__? > > Proposed patch: http://paste.pocoo.org/show/64512/ > > > Regards, > Armin > > ___ > 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] bug or a feature?
On Tue, Jun 10, 2008 at 9:18 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > I see no reason to invent a new custom dict to prevent people from > doing something they find to be useful. If you can't segfault with it, > who cares. Don't worry; I'm not suggesting 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] bug or a feature?
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? (Note that you cannot do the same with getattr/setattr which checks if argument is a string) Seems like a bug to me, but I don't think there is much we can do about it short of making locals a custom dict which rejects none string keys. I see no reason to invent a new custom dict to prevent people from doing something they find to be useful. If you can't segfault with it, who cares. Also, adding another custom type just makes it more difficult to remember what is returned by locals() or globals(). 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] bug or a feature?
On Tue, Jun 10, 2008 at 8:37 PM, Maciej Fijalkowski <[EMAIL PROTECTED]> wrote: > On Wed, Jun 11, 2008 at 3:36 AM, Scott Dial >> >> 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". If you have that power, I recommend you tell them to get rid of 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] bug or a feature?
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". ___ 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: 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? -- 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] bug or a feature?
Benjamin Peterson wrote: On Tue, Jun 10, 2008 at 8:10 PM, Maciej Fijalkowski <[EMAIL PROTECTED]> 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? (Note that you cannot do the same with getattr/setattr which checks if argument is a string) Seems like a bug to me, but I don't think there is much we can do about it short of making locals a custom dict which rejects none string keys. Given that the documentation has for a long time said: """locals( ) Update and return a dictionary representing the current local symbol table. Warning: The contents of this dictionary should not be modified; changes may not affect the values of local variables used by the interpreter. """ it would be hard for the people who have relied on this behavior to complain if it stopped working. Basically retaining this behavior is pandering to people who have ignored the language specification! regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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] bug or a feature?
On Tue, Jun 10, 2008 at 8:10 PM, Maciej Fijalkowski <[EMAIL PROTECTED]> 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? (Note that you cannot do the same with getattr/setattr which > checks if argument is a string) Seems like a bug to me, but I don't think there is much we can do about it short of making locals a custom dict which rejects none string keys. -- 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] bug or a feature?
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? (Note that you cannot do the same with getattr/setattr which checks if argument is a string) Cheers, fijal ___ 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] Have been sick, am behind on mail, let me know if there's anything urgent for me
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. -- --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] Nab those release blockers!
I'll try to roll an updated patch with the review info tonight for you On Jun 10, 2008, at 7:26 PM, "Benjamin Peterson" <[EMAIL PROTECTED] > wrote: On Tue, Jun 10, 2008 at 6:23 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 9, 2008, at 6:33 AM, Jesse Noller wrote: For the multiprocessing module all I have left is the docs in rest format - given I'm a rest newbie, it's taking longer than I thought It's okay if docs don't make it into the beta. That's the kind of thing that can (but still, must) be fixed up before the final release. Luckily, it's done now, and I think I will be able to check in multiprocessing tonight or tomorrow. -- 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] Nab those release blockers!
On Tue, Jun 10, 2008 at 6:23 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Jun 9, 2008, at 6:33 AM, Jesse Noller wrote: > >> For the multiprocessing module all I have left is the docs in rest format >> - given I'm a rest newbie, it's taking longer than I thought > > It's okay if docs don't make it into the beta. That's the kind of thing > that can (but still, must) be fixed up before the final release. Luckily, it's done now, and I think I will be able to check in multiprocessing tonight or tomorrow. -- 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] Nab those release blockers!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 9, 2008, at 6:33 AM, Jesse Noller wrote: For the multiprocessing module all I have left is the docs in rest format - given I'm a rest newbie, it's taking longer than I thought It's okay if docs don't make it into the beta. That's the kind of thing that can (but still, must) be fixed up before the final release. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSE8M5XEjvBPtnXfVAQIBcQP/S5BMgNS/sOXajnU7eLfXGM39/PwStL8b HOv/MZiHtjmRx5Rtro7lDnjaf9u4Ae+V90a5Pt+aAIANSLenzl1GVcJuuQNP+baa trrTvvBGD3C78au76yOIKRZ0xfvv+rxQXo3mzQ4Yf3GiyOaDdhHMiar6qHlQhesK 1j6rghX/J0Q= =r31d -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] PEP 371 trunk implementation
I've uploaded the first "rolled up" patch against trunk for PEP 371's implementation. This includes docs, tests, module, the works. The only outstanding issues with this are: * Had to comment out several unit tests due to threading._Event and multiprocessing Event API differences. * One test failing consistently on OS/X due to a change that came with rolling into trunk, I'm working on this * Bug http://bugs.python.org/issue1683 needs to have the patch reviewed and applied to trunk. * Full doc-content review The patch is both on the codereview system and the bug tracker: http://bugs.python.org/issue3050 http://codereview.appspot.com/2061 -jesse ___ 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] bogus comment in Python.h
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? --- 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/archive%40mail-archive.com
Re: [Python-Dev] Assignment to None
Thomas Lee schrieb: What happened in 3k? Were the constants in xmlrpclib renamed/removed? They were removed, as there is no way they can be accessed as attributes of a module now. 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
[Python-Dev] Exception.__unicode__ and tp_unicode
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). Each option has its draw backs. Ideally I'd like to see 3) implemented (there are already two volunteers for and some initial stabs at implementing it) but a change to Object is going to need an okay from someone quite high up. Also, if you know of any code this would break, now is the time to let me know. If we can't have 3) I'd like to see us fall back to option 2). Passing unicode exceptions back is useful in a number of common situations (non-English exception messages, database errors, pretty much anywhere that something goes wrong while dealing with potentially non-ASCII text) and encoding to some specific format is usually not an option since there is no way to know where the exception will eventually be caught. Also, unicode(ClassA) already fails for any class that implements __unicode__ so even without this effecting Exception it's already not safe to do u"%s" % SomeClass. Also, there is a readily available work around by doing u"%s" % str(SomeClass). I'm opposed to 1) because a full work around means doing something like: def unicode_exception(e): if len(e.args) == 0: return u"" elif len(e.args) == 1: return unicode(e.args[0]) else: return unicode(e.args) and then using unicode_exception(...) instead of unicode(...) whenever one needs to get a unicode value for an exception. The issue doesn't affect Python 3.0 where unicode(...) is replaced by str(...). [1] http://bugs.python.org/issue1551432 [2] http://bugs.python.org/issue2517 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
[Python-Dev] segfault in struct module
[EMAIL PROTECTED]:~$ ~/Projects/python/trunk/python
Python 2.6a3+ (trunk:63964, Jun 5 2008, 16:49:12)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.pack("357913941c", 'a')
Segmentation fault
[EMAIL PROTECTED]:~$
The unit test for exactly this case was deleted in r60892. I would like to
suggest that just deleting unit tests isn't a very good idea.
Jean-Paul
___
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] asyncore patch
On Tue, Jun 10, 2008 at 8:26 AM, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > On 10 Giu, 07:01, "Josiah Carlson" <[EMAIL PROTECTED]> wrote: >> On Mon, Jun 9, 2008 at 7:19 PM, Benjamin Peterson >> >> <[EMAIL PROTECTED]> wrote: >> > On Mon, Jun 9, 2008 at 8:42 PM, Josiah Carlson <[EMAIL PROTECTED]> wrote: >> >> >> Would it be ok if I committed the changes? Neal, do you want to >> >> commit the changes if I post an updated patch with a blurb for the >> >> NEWS file? >> >> > You are the asyncore maintainer, correct? I believe it's pretty much >> > up to you, then. :) >> >> Indeed, but I didn't want to step on anyone's toes. >> >> It's committed in revision 64062 for anyone who cares. >> >> - Josiah > > > I've started to test the new code by using the pyftpdlib test suite. > On Windows all tests passed but on Linux I get some "EBADF Bad file > descriptor" errors occurring when using poll() instead of select(). > I'll try to look into them today and open a report if necessary. > In the meanwhile I noticed some minor bugs in asyncore.py. Take a look > at the patch below: > > > Index: Lib/asyncore.py > === > --- Lib/asyncore.py (revisione 64069) > +++ Lib/asyncore.py (copia locale) > @@ -228,7 +228,7 @@ > # passed be connected. > try: > self.addr = sock.getpeername() > -except socket.error: > +except socket.error, err: > if err[0] == ENOTCONN: > # To handle the case where we got an unconnected > # socket. > @@ -424,7 +424,7 @@ > #check for errors > err = self.socket.getsockopt(socket.SOL_SOCKET, > socket.SO_ERROR) > if err != 0: > -raise socket.error(err, strerror(err)) > +raise socket.error(err, _strerror(err)) > > self.handle_connect_event() > self.handle_write() I have fixed the testcase (it was failing due to the new semantics of the filewrapper automatically duping the file handle), as well as the two NameErrors that Giampaolo pointed out. See revision 64080. - Josiah ___ 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
Martin v. Löwis wrote: The question is, what is the specification for Python. Now, that's a more interesting question than the question originally asked (which I interpreted as "why does it work the way it works"). The only indication in the specification of that feature I could find was: http://docs.python.org/dev/library/constants.html "Changed in version 2.4: Assignments to None are illegal and raise a SyntaxError." Now, given that this talks about the built-in namespace, this *doesn't* specify that foo.None=1 should also raise a syntax error. So the implementation apparently deviates from the specification. 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. Funny, I just ran into this. I was trying to figure out why the AST optimization code was breaking test_xmlrpc ... turns out xmlrpclib defines xmlrpclib.True and xmlrpclib.False and the optimizer was trying to resolve them as constants while compiling the module. Ouch. What happened in 3k? Were the constants in xmlrpclib renamed/removed? Cheers, T ___ 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] asyncore patch
On 10 Giu, 07:01, "Josiah Carlson" <[EMAIL PROTECTED]> wrote: > On Mon, Jun 9, 2008 at 7:19 PM, Benjamin Peterson > > <[EMAIL PROTECTED]> wrote: > > On Mon, Jun 9, 2008 at 8:42 PM, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > >> Would it be ok if I committed the changes? Neal, do you want to > >> commit the changes if I post an updated patch with a blurb for the > >> NEWS file? > > > You are the asyncore maintainer, correct? I believe it's pretty much > > up to you, then. :) > > Indeed, but I didn't want to step on anyone's toes. > > It's committed in revision 64062 for anyone who cares. > > - Josiah I've started to test the new code by using the pyftpdlib test suite. On Windows all tests passed but on Linux I get some "EBADF Bad file descriptor" errors occurring when using poll() instead of select(). I'll try to look into them today and open a report if necessary. In the meanwhile I noticed some minor bugs in asyncore.py. Take a look at the patch below: Index: Lib/asyncore.py === --- Lib/asyncore.py (revisione 64069) +++ Lib/asyncore.py (copia locale) @@ -228,7 +228,7 @@ # passed be connected. try: self.addr = sock.getpeername() -except socket.error: +except socket.error, err: if err[0] == ENOTCONN: # To handle the case where we got an unconnected # socket. @@ -424,7 +424,7 @@ #check for errors err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) if err != 0: -raise socket.error(err, strerror(err)) +raise socket.error(err, _strerror(err)) self.handle_connect_event() self.handle_write() --- Giampaolo http://code.google.com/p/pyftpdlib/ ___ 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] asyncore patch
I'm working on it now. I'll do my best to have a fix by the time I go to work this morning. - Josiah On Tue, Jun 10, 2008 at 6:12 AM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > On Tue, Jun 10, 2008 at 8:10 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: >>> I don't want to be picky, but it seems the commit broke the tests: >>> >>> test test_asyncore failed -- Traceback (most recent call last): >>> File "/tmp/python-test/local/lib/python2.6/test/test_asyncore.py", line >>> 387, in test_recv >>> self.assertEqual(w.fd, fd) >>> AssertionError: 6 != 3 >>> >>> Looks like a minor oversight. >> >> This needs to be fixed or backed out if we're going to make beta tomorrow. > > Oh, I think there are more pressing issues than this, but FWIW I made > a issue for it: 3074 > > > -- > 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/josiah.carlson%40gmail.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] asyncore patch
On Tue, Jun 10, 2008 at 8:10 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: >> I don't want to be picky, but it seems the commit broke the tests: >> >> test test_asyncore failed -- Traceback (most recent call last): >> File "/tmp/python-test/local/lib/python2.6/test/test_asyncore.py", line >> 387, in test_recv >> self.assertEqual(w.fd, fd) >> AssertionError: 6 != 3 >> >> Looks like a minor oversight. > > This needs to be fixed or backed out if we're going to make beta tomorrow. Oh, I think there are more pressing issues than this, but FWIW I made a issue for it: 3074 -- 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] asyncore patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 10, 2008, at 9:08 AM, Georg Brandl wrote: Nick Coghlan schrieb: Josiah Carlson wrote: On Mon, Jun 9, 2008 at 7:19 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: On Mon, Jun 9, 2008 at 8:42 PM, Josiah Carlson <[EMAIL PROTECTED] > wrote: Would it be ok if I committed the changes? Neal, do you want to commit the changes if I post an updated patch with a blurb for the NEWS file? You are the asyncore maintainer, correct? I believe it's pretty much up to you, then. :) Indeed, but I didn't want to step on anyone's toes. It's committed in revision 64062 for anyone who cares. I'm sure asyncore users will appreciate the work put into this, even if there's something of a shortage of such people on this list :) I don't want to be picky, but it seems the commit broke the tests: test test_asyncore failed -- Traceback (most recent call last): File "/tmp/python-test/local/lib/python2.6/test/test_asyncore.py", line 387, in test_recv self.assertEqual(w.fd, fd) AssertionError: 6 != 3 Looks like a minor oversight. This needs to be fixed or backed out if we're going to make beta tomorrow. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSE59Q3EjvBPtnXfVAQLVsQQAsbk6VvlabljNtDX63e9DvBnt8Gh15l0W /yw+lRp9BEThLwitp1ZllFbZElPHsyKaFJn16yOhrysjp/Hf1zWJYgYcHee1m/P4 o4eJMgYlkgIymolJFiviirPj/4YPC8XYkGVcPs1so7XvwVfRvn/u+uhmf1y/+Uwo ql6fkLjXVMo= =iLdD -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] asyncore patch
Nick Coghlan schrieb: Josiah Carlson wrote: On Mon, Jun 9, 2008 at 7:19 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: On Mon, Jun 9, 2008 at 8:42 PM, Josiah Carlson <[EMAIL PROTECTED]> wrote: Would it be ok if I committed the changes? Neal, do you want to commit the changes if I post an updated patch with a blurb for the NEWS file? You are the asyncore maintainer, correct? I believe it's pretty much up to you, then. :) Indeed, but I didn't want to step on anyone's toes. It's committed in revision 64062 for anyone who cares. I'm sure asyncore users will appreciate the work put into this, even if there's something of a shortage of such people on this list :) I don't want to be picky, but it seems the commit broke the tests: test test_asyncore failed -- Traceback (most recent call last): File "/tmp/python-test/local/lib/python2.6/test/test_asyncore.py", line 387, in test_recv self.assertEqual(w.fd, fd) AssertionError: 6 != 3 Looks like a minor oversight. 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] asyncore patch
Josiah Carlson wrote: On Mon, Jun 9, 2008 at 7:19 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: On Mon, Jun 9, 2008 at 8:42 PM, Josiah Carlson <[EMAIL PROTECTED]> wrote: Would it be ok if I committed the changes? Neal, do you want to commit the changes if I post an updated patch with a blurb for the NEWS file? You are the asyncore maintainer, correct? I believe it's pretty much up to you, then. :) Indeed, but I didn't want to step on anyone's toes. It's committed in revision 64062 for anyone who cares. I'm sure asyncore users will appreciate the work put into this, even if there's something of a shortage of such people on this list :) 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] Tuple pack/unpack and the definition of AST Assign nodes
Thomas Lee wrote:
Nick Coghlan wrote:
I haven't looked at that code recently, but I believe the ADSL
sequence in the assignment node is for statements where there are
actually multiple assignment targets, such as:
>>> p = x, y = 1, 2
>>> p, x, y
((1, 2), 1, 2)
Cheers,
Nick.
Ah I see. A quick test verifies exactly this:
>>> import _ast
>>> ast = compile("p = x, y = 1, 2", "", "exec",
_ast.PyCF_ONLY_AST)
>>> ast.body[0]
<_ast.Assign object at 0xb7d0122c>
>>> ast.body[0].targets
[<_ast.Name object at 0xb7d0124c>, <_ast.Tuple object at 0xb7d0128c>]
>>> ast.body[0].value
<_ast.Tuple object at 0xb7d0132c>
>>>
I thought this would have been implemented as nested Assign nodes, but
I'm obviously wrong. :) Thanks for the clarification.
It's one of the key differences between Python's "assignment as a
statement" and C-style "assignment as an expression" - nested Assignment
nodes are meaningful with the latter approach, but nonsensical with the
way Python defines assignment (the rightmost expression is evaluated
once and then assigned to each of the target expressions from left to
right).
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
