Mailman 3 June 2008 - Python-Dev

Re: [Python-Dev] Have been sick, am behind on mail, let me know if there's anything urgent for me
by Benjamin Peterson 11 Jun '08

11 Jun '08

[just ccing python-dev] On Tue, Jun 10, 2008 at 10:17 PM, Benjamin Peterson <musiccomposition(a)gmail.com> wrote: > On Tue, Jun 10, 2008 at 10:08 PM, Guido van Rossum <guido(a)python.org> wrote: >> On Tue, Jun 10, 2008 at 7:19 PM, Benjamin Peterson >> <musiccomposition(a)gmail.com> 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."

1 0

Nab those release blockers!
by Benjamin Peterson 11 Jun '08

11 Jun '08

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=&%40… -- Thanks Benjamin Peterson "There's no place like 127.0.0.1."

4 7

Exception.__unicode__ and tp_unicode
by Simon Cross 11 Jun '08

11 Jun '08

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

2 2

pep8ity __future__
by Armin Ronacher 11 Jun '08

11 Jun '08

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

3 2

Stabilizing the C API of 2.6 and 3.0
by Christian Heimes 11 Jun '08

11 Jun '08

Hello! The first set of betas of Python 2.6 and 3.0 is fast apace. I like to grab the final chance and clean up the C API of 2.6 and 3.0. I know, I know, I brought up the topic two times in the past. But this time I mean it for real! :] Last time Guido said: --- I think it can actually be simplified. I think maintaining binary compatibility between 2.6 and earlier versions is hopeless anyway, so we might as well just rename PyString to PyBytes in 2.6 and 3.0, and have an extra set of macros so that code using PyString needs to be recompiled but not otherwise touched. E.g. typedef { ... } PyBytesObject; #define PyStringObject PyBytesObject ... PyString_Type; #define PyBytes_Type PyString_Type <etc> --- I like to follow Guido's advice and change the code as following: * replace PyBytes_ with PyByteArray_ * replace PyString with PyBytes_ * rename bytesobject.[ch] to bytearrayobject.[ch] * rename stringobject.[ch] to bytesobject.[ch] * add a new file stringobject.h which contains the aliases PyString_ -> PyBytes_ Christian

14 42

PEP 371 trunk implementation
by Jesse Noller 10 Jun '08

10 Jun '08

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

1 0

asyncore patch
by Josiah Carlson 10 Jun '08

10 Jun '08

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

6 9

Tuple pack/unpack and the definition of AST Assign nodes
by Thomas Lee 10 Jun '08

10 Jun '08

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

2 3

Obtaining short file path
by Hartwell Bryan 09 Jun '08

09 Jun '08

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.

4 3

GIL cpu usage problem, confirm me
by Pau Freixes 08 Jun '08

08 Jun '08

Hi List, Surly this is a recurring theme into python dev world, but I need your help for confirm if the follow image it's really http://www.milnou.net/~pfreixes/img/cpu_usage_gil_problem.png I'm writing a brief article for my blog and I need to make sure about the current problem with GIL and multi core environments, this picture try to explain with images the problem for scheduling multiple threads running python code of same interpreter into multiple cpu cores. Can anyone confirm to me this picture ? And if it's possible answer this two questions I will be happy :/ 1) When this situation it's produced into one core environment whats happens when thread library or os switch context into other python thread and this don't have a GIL ? 2) Exist some PEP or plans for modify this and run multiple thread python for same interpreter at current time ? for python 3000? Thanks and excuse for this break. -- Pau Freixes Linux GNU/User

3 2