[Python-Dev] Nab those release blockers!
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. Let's get this release on time! [clapping] [1] http://bugs.python.org/issue?%40sort0=activity%40sortdir0=on%40sort1=%40group0=%40group1=%40columns=title%2Cid%2Cactivity%2Cversions%2Cstatus%40filter=priority%2Cstatuspriority=1status=1%40pagesize=50%40startwith=0 -- Thanks 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] Assignment to None
Steven D'Aprano wrote: On Mon, 9 Jun 2008 12:24:55 pm Curt Hagenlocher wrote: So, it's okay to setattr the attribute name None but not okay to set it directly? I suspect this is off-topic for python-dev, and would be better on comp.lang.python or similar, but for what it's worth, I consider having an attribute named 'None' bad practise, regardless of any runtime checks. But as part of Python's we're all consenting adults here philosophy, I wouldn't approve of expensive or extensive run-time checks specifically to prevent it. If you really have to name your attribute None, and are prepared to live with the consequences, then go ahead. FWIW Curt is asking because he is on the team responsible for implementing IronPython. In .NET you have several enumerations with members called None, for example 'Alignment.None'. It would be inconvenient for IronPython users if it enforced this particular syntax rule of Python's; that not only is assignment to None disallowed but that members named None are invalid syntax. The question is, what is the specification for Python. Is it that assignment to None is disallowed and the naming of members called None being invalid syntax is merely an artefact of the implementation of this, or does Python require this... Michael Foord In a similar fashion: class Parrot(object): ... pass ... p = Parrot() p.1 = 'spam' File stdin, line 1 p.1 ^ SyntaxError: invalid syntax setattr(p, '1', 'spam') ___ 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-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). Developer who want to start differentiating between mixed byte/text data and bytes-only can start using PyBytes for byte data. I would also add macros that map the PyBytes_* APIs to PyString_*, but I would not start using these internally except in code newly written for 2.6 and intended to be in the spirit of 3.0. IOW use PyString for 8-bit strings containing text, and PyBytes for 8-bit strings containing binary data. For 8-bit strings that could contain either text or data, I'd use PyString, in the spirit of 2.x. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 09 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, Lithuania27 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] Nab those release blockers!
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 On Jun 8, 2008, at 7:38 PM, Benjamin Peterson [EMAIL PROTECTED] 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. Let's get this release on time! [clapping] [1] http://bugs.python.org/issue?%40sort0=activity%40sortdir0=on%40sort1=%40group0=%40group1=%40columns=title%2Cid%2Cactivity%2Cversions%2Cstatus%40filter=priority%2Cstatuspriority=1status=1%40pagesize=50%40startwith=0 -- Thanks 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/jnoller%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] Nab those release blockers!
On Mon, Jun 9, 2008 at 5:33 AM, Jesse Noller [EMAIL PROTECTED] 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 If you want to email what you have done to [EMAIL PROTECTED], we'd love to help! -- 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] Tuple pack/unpack and the definition of AST Assign nodes
In porting one of the old peephole optimizations to the new AST compiler I noticed something weird going on with the following code: a, b, c = 1, 2, 3 Now, as you would expect this gets parsed into an Assign node. That Assign node looks like the following: Assign.targets = [Tuple(Name(a), Name(b), Name(c))] Assign.value = Tuple(1, 2, 3) What's weird here is that Assign.targets is an asdl_seq ... why are we wrapping the names in a Tuple() node? Shouldn't it look something more like this: Assign.targets = [Name(a), Name(b), Name(c)] I understand that parsing the testlist might yield a tuple and it was thus easier to just use the tuple rather than unpack it into an asdl_seq ... but if this was the intention, then why is Assign.targets an expr* rather than a plain old expr? Cheers, Tom ___ 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: In porting one of the old peephole optimizations to the new AST compiler I noticed something weird going on with the following code: a, b, c = 1, 2, 3 Now, as you would expect this gets parsed into an Assign node. That Assign node looks like the following: Assign.targets = [Tuple(Name(a), Name(b), Name(c))] Assign.value = Tuple(1, 2, 3) What's weird here is that Assign.targets is an asdl_seq ... why are we wrapping the names in a Tuple() node? Shouldn't it look something more like this: Assign.targets = [Name(a), Name(b), Name(c)] I understand that parsing the testlist might yield a tuple and it was thus easier to just use the tuple rather than unpack it into an asdl_seq ... but if this was the intention, then why is Assign.targets an expr* rather than a plain old expr? 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. -- 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
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, string, 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. 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] Assignment to None
The problem is more general: what if a member (of some external object we're proxying one way or another) is named print (in Python 3), or class, or...? To allow foo.print or bar.class would require pretty big changes to Python's parser -- I have vague memories that the issue was discussed ages ago (possibly in conjunction with some early release of Jython) but never went anywhere much (including proposals to automatically append an underscore to such IDs in the proxying layer, etc etc). Maybe None in particular is enough of a special case (if it just happens to be hugely often used in dotNET libraries)? Alex On Mon, Jun 9, 2008 at 1:28 AM, Michael Foord [EMAIL PROTECTED] wrote: Steven D'Aprano wrote: On Mon, 9 Jun 2008 12:24:55 pm Curt Hagenlocher wrote: So, it's okay to setattr the attribute name None but not okay to set it directly? I suspect this is off-topic for python-dev, and would be better on comp.lang.python or similar, but for what it's worth, I consider having an attribute named 'None' bad practise, regardless of any runtime checks. But as part of Python's we're all consenting adults here philosophy, I wouldn't approve of expensive or extensive run-time checks specifically to prevent it. If you really have to name your attribute None, and are prepared to live with the consequences, then go ahead. FWIW Curt is asking because he is on the team responsible for implementing IronPython. In .NET you have several enumerations with members called None, for example 'Alignment.None'. It would be inconvenient for IronPython users if it enforced this particular syntax rule of Python's; that not only is assignment to None disallowed but that members named None are invalid syntax. The question is, what is the specification for Python. Is it that assignment to None is disallowed and the naming of members called None being invalid syntax is merely an artefact of the implementation of this, or does Python require this... Michael Foord In a similar fashion: class Parrot(object): ... pass ... p = Parrot() p.1 = 'spam' File stdin, line 1 p.1 ^ SyntaxError: invalid syntax setattr(p, '1', 'spam') ___ 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/aleaxit%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] Assignment to None
Alex Martelli wrote: The problem is more general: what if a member (of some external object we're proxying one way or another) is named print (in Python 3), or class, or...? To allow foo.print or bar.class would require pretty big changes to Python's parser -- I have vague memories that the issue was discussed ages ago (possibly in conjunction with some early release of Jython) but never went anywhere much (including proposals to automatically append an underscore to such IDs in the proxying layer, etc etc). Maybe None in particular is enough of a special case (if it just happens to be hugely often used in dotNET libraries)? 'None' as a member does occur particularly frequently in the .NET world. A halfway house might be to state (something like): Python as a language disallows you from having names the same as keywords or 'None'. An implementation restriction specific to CPython is that the same restriction also applies to member names. Alternative implementations are free to not implement this restriction, with the caveat that code using reserved member names directly will be invalid syntax for CPython. Although this appears to raise the spectre of code written for Jython or IronPython not being compatible with CPython, in reality if they are using Java or .NET objects then they are already incompatible with CPython (IronPython doesn't work by proxying .NET objects by the way - you work directly with them but the DLR 'catches' attribute look ups etc to add Python methods to basic types and do 'other magic' like wrapping Python functions as delegates). This at least enshrines the current IronPython behaviour with the veneer of respectability. Michael Foord Alex On Mon, Jun 9, 2008 at 1:28 AM, Michael Foord [EMAIL PROTECTED] wrote: Steven D'Aprano wrote: On Mon, 9 Jun 2008 12:24:55 pm Curt Hagenlocher wrote: So, it's okay to setattr the attribute name None but not okay to set it directly? I suspect this is off-topic for python-dev, and would be better on comp.lang.python or similar, but for what it's worth, I consider having an attribute named 'None' bad practise, regardless of any runtime checks. But as part of Python's we're all consenting adults here philosophy, I wouldn't approve of expensive or extensive run-time checks specifically to prevent it. If you really have to name your attribute None, and are prepared to live with the consequences, then go ahead. FWIW Curt is asking because he is on the team responsible for implementing IronPython. In .NET you have several enumerations with members called None, for example 'Alignment.None'. It would be inconvenient for IronPython users if it enforced this particular syntax rule of Python's; that not only is assignment to None disallowed but that members named None are invalid syntax. The question is, what is the specification for Python. Is it that assignment to None is disallowed and the naming of members called None being invalid syntax is merely an artefact of the implementation of this, or does Python require this... Michael Foord In a similar fashion: class Parrot(object): ... pass ... p = Parrot() p.1 = 'spam' File stdin, line 1 p.1 ^ SyntaxError: invalid syntax setattr(p, '1', 'spam') ___ 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/aleaxit%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] Assignment to None
At 4:46 PM +0100 6/9/08, Michael Foord wrote: Alex Martelli wrote: The problem is more general: what if a member (of some external object we're proxying one way or another) is named print (in Python 3), or class, or...? To allow foo.print or bar.class would require pretty big changes to Python's parser -- I have vague memories that the issue was discussed ages ago (possibly in conjunction with some early release of Jython) but never went anywhere much (including proposals to automatically append an underscore to such IDs in the proxying layer, etc etc). Maybe None in particular is enough of a special case (if it just happens to be hugely often used in dotNET libraries)? 'None' as a member does occur particularly frequently in the .NET world. A halfway house might be to state (something like): Python as a language disallows you from having names the same as keywords or 'None'. An implementation restriction specific to CPython is that the same restriction also applies to member names. Alternative implementations are free to not implement this restriction, with the caveat that code using reserved member names directly will be invalid syntax for CPython. ... Or perhaps CPython should just stop trying to detect this at compile time. Note that while assignment to .None is not allowed, setattr(foo, None, 1) then referencing .None is allowed. f.None = 1 SyntaxError: assignment to None f.None Traceback (most recent call last): File stdin, line 1, in ? AttributeError: 'Foo' object has no attribute 'None' setattr(f, 'None', 1) f.None 1 -- TonyN.:' mailto:[EMAIL PROTECTED] ' http://www.georgeanelson.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] Assignment to None
Tony Nelson wrote: At 4:46 PM +0100 6/9/08, Michael Foord wrote: Alex Martelli wrote: The problem is more general: what if a member (of some external object we're proxying one way or another) is named print (in Python 3), or class, or...? To allow foo.print or bar.class would require pretty big changes to Python's parser -- I have vague memories that the issue was discussed ages ago (possibly in conjunction with some early release of Jython) but never went anywhere much (including proposals to automatically append an underscore to such IDs in the proxying layer, etc etc). Maybe None in particular is enough of a special case (if it just happens to be hugely often used in dotNET libraries)? 'None' as a member does occur particularly frequently in the .NET world. A halfway house might be to state (something like): Python as a language disallows you from having names the same as keywords or 'None'. An implementation restriction specific to CPython is that the same restriction also applies to member names. Alternative implementations are free to not implement this restriction, with the caveat that code using reserved member names directly will be invalid syntax for CPython. ... Or perhaps CPython should just stop trying to detect this at compile time. Note that while assignment to .None is not allowed, setattr(foo, None, 1) then referencing .None is allowed. I'm +0 on this at the moment, but I can understand the desire for it. Maybe we should stop trying to check for this assignment on attributes? Currently there are separate checks for assignment to None: one for the foo.None = ... form, another for the None = ... form. Removing the check for the former looks like it would be a one-liner. 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] Obtaining short file path
If you want a short path name, you should use win32api.GetShortPathName().
Attempting to compute it yourself isn’t as straight forward as you think.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hartwell Bryan
Sent: 27 May 2008 08:00
To: python-dev@python.org
Subject: [Python-Dev] Obtaining short file path
Hi,
Purpose: obtaining the system (“short”) path from a full path
Background: File dialogs (visual studio) return a full path (e.g. f=“C:\this
path has spaces\thisfilenameislongerthan8char.txt”). If this value is provided
to Python, it will not recongize this as a file. In fact os.path.isfile(f)
doesn’t return false, it crashes. Likewise, when calling executables (from
Python) with files as arguments a short path is required. VB FileSystemObject
has the ShortPath method, while os.path and path (www.jorendorff.com) modules
do not (at least as far as my googling could determine). Why bother creating a
COM interface when you’re just going to pass as shell run-time arguments all
the values the server is better at computing?
System: Python 2.3; Windows XP
Sample Code:
import win32com.client
import time
import os,sys
import os.path
#-
def shortpath(x):
z=''
for y in x.split('\\'):
if len(y.split('.')[0])8:
if ('.' in y):
z=z+'\\'+y.split('.')[0][:6].upper()+'~1'+'.'+y.split('.')[1]
else:
z=z+'\\'+y[:6].upper()+'~1'
else:
z=z+'\\'+y
return z[1:]
#-
xlApp = win32com.client.Dispatch(Excel.Application)
xlBook = xlApp.ActiveWorkbook
savFile = str(sys.argv[1])
rawFile = str(xlBook.Sheets(Timestamp).TextBox2)
#print os.path.isfile(savFile)
r=shortpath(rawFile)
print r
try:
print os.path.isfile(r)
except:
print 'something rude'
time.sleep(7)
Notes: This code does not account for peer paths or files that share the first
8 characters (and file extension). I’m also aware that this is not the normal
means for submitting a “patch”, but in my job function I don’t see myself
regularly participating in python development (and I’m probably not savvy
enough) so the effort wasn’t worth it. However I still thought others might
benefit from what seems to be (to me) a fundamental path function. Do with it,
or ignore it, as you please.
Cheers,
Bryan Hartwell
This message is intended only for the use of the intended recipients, and it
may be privileged and confidential. If you are not the intended recipient, you
are hereby notified that any review, retransmission, conversion to hard copy,
copying, circulation or other use of this message is strictly prohibited. If
you are not the intended recipient, please notify me immediately by return
e-mail, and delete this message from your system.
___
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 Jun 9, 2008, at 17:12, Alex Martelli wrote: The problem is more general: what if a member (of some external object we're proxying one way or another) is named print (in Python 3), or class, or...? To allow foo.print or bar.class would require pretty big changes to Python's parser I simple solution to this would be to introduce syntax that allow you to quote identifiers that would otherwise be lexed as keywords. For instance C# uses a prefix '@' for such quoting, so you could write [EMAIL PROTECTED], [EMAIL PROTECTED] and [EMAIL PROTECTED] if you insist on using such identifiers. Too ugly for Python I guess. Regards, Gisle ___ 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
Tony Nelson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | At 4:46 PM +0100 6/9/08, Michael Foord wrote: | Or perhaps CPython should just stop trying to detect this at compile time. | Note that while assignment to .None is not allowed, setattr(foo, None, | 1) then referencing .None is allowed. | | f.None = 1 | SyntaxError: assignment to None | f.None | Traceback (most recent call last): | File stdin, line 1, in ? | AttributeError: 'Foo' object has no attribute 'None' | setattr(f, 'None', 1) | f.None | 1 I was a little surprised by this. ISTM that f.None should consistently work or not work both for getting and setting. The last result could be considered a bug rusulting from getting disabling depending on None not being set, but having a backdoor that does allow it to be set. I recently read someone (Guido?) saying that a language should start 'strict' because it is much easier to allow something new than disallow something old. Allowing 'None' and possibly other keywords as attributes will not break code (that does not depend on the exceptions). But I presume there was some thought that the restriction might prevent buggy code. At the global level, the subversion does not work: globals()['None'] = 'ha' None dir() ['None', '__builtins__', '__doc__', '__name__', '__package__'] globals()['None'] 'ha' 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] Assignment to None
At the global level, the subversion does not work: I think you are misinterpreting what you are seeing. When you refer to the global identifier None, the compiler just knows that it must be the NoneType singleton, and returns it as a constant, without doing any name lookup. So it isn't that assignment of the global None fails to be performed; instead, the compiler just ignores any global with the name None that might have been set. The compiler doesn't do the same thing for attributes, and rightfully so: it would surely be surprising if foo.None would yield the NoneType singleton for any arbitrary foo. Instead, the compiler generates a regular attribute, which then regularly finds the attribute in the object's dictionary if it is there. I was a little surprised by this. ISTM that f.None should consistently work or not work both for getting and setting. That will only happen when (if) None becomes a keywords: then foo.None will be a syntax error. You will still be able to put attributes named 'None' (or 'import' or 'if') into any object using getattr/setattr, or by direct access to __dict__. 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] Assignment to None
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). 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
[Python-Dev] asyncore patch
As we approach the 2.6 beta date, and after getting my updated public key pushed to the python.org servers, I would really like to get the asyncore/asynchat patch (with documentation) committed. Previously, we were waiting on documentation, which the last patch had, but which was 80 columns. That is now fixed. Neal had promised to commit if I got everything in order, but now that I have access, I can commit it. 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? What can I do to get these patch in and included with the beta? - 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] asyncore patch
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. :) -- 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
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 ___ 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
