Mailman 3 April 2010 - Python-Dev

PyTuple_Parse*() and discontigious buffer
by Victor Stinner April 22, 2010

April 22, 2010

Hi, I opened issue #8215 about PyTuple_Parse*() outdated documentation. When I read the code, I found two functions: getbuffer() and convertbuffer(). getbuffer() checks that the buffer is contigious, whereas convertbuffer() doesn't. We can group formats by contigious check: - contigious buffer: s, y*, z*, w* - discontigious buffer: s#, y, z, t, w, w# I tried to test formats accepting discontigious buffer but I didn't found any function or library to test this. I'm not sure that functions using s#, y, z, t, w, w# format do really support discontigious buffer and it's just a bug in getargs.c. Do someone have information about that? Should it be fixed (only accept contigious buffer)? -- Victor Stinner http://www.haypocalc.com/

1 0

Reject bytearray filename in Python 3.2
by Victor Stinner April 22, 2010

April 22, 2010

Hi, About my work on unicode surrogates, I would like to reject bytearray filename, especially in the PyUnicode_FSConverter function. As explained in issue #8485, support bytearray requires to test the result type, acquire/release a lock, the API is more complex, etc. I don't know real world usecase of bytearray filename. The os.path module doesn't support it and no Python 3.0 or 3.1 user noticed that. Support of bytearray in not documentation in PyUnicode_FSConverter() comment (Include/unicodeobject.h). Martin Loewis, the author of PEP 383, created PyUnicode_FSConverter() and he agree to drop support of bytearray filename. But he asked me to ask on this mailing list if anyone would prefer to mark bytearray filename as deprecated in 3.2 and reject them in 3.3. I will be very sad if someone ask me to keep bytearray filename support in 3.2 because I opened a lot of issues about surrogates and I would make my work more diffcult :-( -- Victor Stinner http://www.haypocalc.com/

2 3

Re: [Python-Dev] Small suggestion re help(Exception)
by Rob Cliffe April 21, 2010

April 21, 2010

----- Original Message ----- From: "Aurélien Campeas" <aurelien.campeas(a)logilab.fr> To: "Rob Cliffe" <rob.cliffe(a)btinternet.com> Sent: Wednesday, April 21, 2010 5:25 PM Subject: Re: [Python-Dev] Small suggestion re help(Exception) > like in > >>>> ArithmeticError.__subclasses__() > [<type 'exceptions.FloatingPointError'>, <type > 'exceptions.OverflowError'>, <type 'exceptions.ZeroDivisionError'>] > > ? Yes, exactly like that. I wasn't aware of __subclasses__ (it doesn't appear in dir(ArithmeticError), for example), but if my suggestion were adopted, __subclasses__ would be just what is needed to implement it. Rob Cliffe > > Le mercredi 21 avril 2010 à 17:17 +0100, Rob Cliffe a écrit : >> help() on an Exception class lists the method resolution order >> (effectively the inheritance hierarchy). >> E.g. help(ArithmeticError) displays inter alia: >> >> Method resolution order: >> ArithmeticError >> StandardError >> Exception >> BaseException >> __builtin__.object >> >> Would it be possible for it also display the Python built-in >> SUBclasses of the class? E.g. in the same example something like: >> >> Built-in subclasses: >> FloatingPointError >> OverflowError >> ZeroDivisionError >> >> This may seem pointless to grizzled old Python veterans who (maybe) >> know the inheritance hierarchy backwards, but for those of us with >> less experience I think it would be helpful, e.g. >> (1) It would help to track down an Exception whose name you have >> forgotten. >> (2) It would sometimes be illuminating, e.g. LookupError might be a >> bit obscure at first, until you see that it is the superclass of the >> familiar IndexError and KeyError. >> >> Sorry, I'm not sure if I should send this sort of thing to >> Python-Ideas or Python-Dev, so please let me know gently which one I >> should (not) have sent it to. >> >> Best wishes >> Rob Cliffe >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev(a)python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/aurelien.campeas%40logila… > >

2 1

PEP 328, relative imports and Python 2.7
by Barry Warsaw April 21, 2010

April 21, 2010

While talking about Python 2.6 -> 2.7 transitions, the subject of relative and absolute imports has come up. PEP 328 states that absolute imports will be enabled by default in Python 2.7, however I cannot verify that this has actually happened. * Misc/NEWS doesn't mention it * What's New in Python 2.7 doesn't mention it either * My own limited testing on trunk indicates it hasn't happened Now, truth be told I only spent 15 minutes investigating this so I could certainly have missed something. Are absolute imports enabled by default in Python 2.7? If not, given that we're into beta, I don't think we can do it now, so I would suggest updating the PEP. If they have been enabled then we need to update NEWS and What's New. -Barry

3 4

argparse ambiguity handling
by Neal Becker April 21, 2010

April 21, 2010

I've noticed argparse ambiguity handling has changed a bit over last few revisions. I have cases where 1 valid input is a prefix of another: e.g.: '--string' '--string2' With the most recent 1.1, the behavior is: --string=hello is accepted, while: --strin=hello is marked as ambiguous. I'm OK with this, but just want to know if there is agreement that this is the behavior we want.

6 8

Small suggestion re help(Exception)
by Rob Cliffe April 21, 2010

April 21, 2010

help() on an Exception class lists the method resolution order (effectively the inheritance hierarchy). E.g. help(ArithmeticError) displays inter alia: Method resolution order: ArithmeticError StandardError Exception BaseException __builtin__.object Would it be possible for it also display the Python built-in SUBclasses of the class? E.g. in the same example something like: Built-in subclasses: FloatingPointError OverflowError ZeroDivisionError This may seem pointless to grizzled old Python veterans who (maybe) know the inheritance hierarchy backwards, but for those of us with less experience I think it would be helpful, e.g. (1) It would help to track down an Exception whose name you have forgotten. (2) It would sometimes be illuminating, e.g. LookupError might be a bit obscure at first, until you see that it is the superclass of the familiar IndexError and KeyError. Sorry, I'm not sure if I should send this sort of thing to Python-Ideas or Python-Dev, so please let me know gently which one I should (not) have sent it to. Best wishes Rob Cliffe

2 1

Email addresses for new committers for python-committers
by Brett Cannon April 21, 2010

April 21, 2010

If you are a committer and are NOT subscribed to the python-committers mailing list (I believe this at least includes Giampaolo, JP, and Brian), then please either reply to this email with your preferred email address or let me know directly (the former is preferred so Georg or Eric can beat me to the subscription if I take too long).

4 3

jean-claude elias
by Robert Hancock April 21, 2010

April 21, 2010

http://www.aricciafestaecultura.it/home.php

1 0

Python 2.7b1 and argparse's version action
by Tobias Herp April 21, 2010

April 21, 2010

Hi, all, (I don't know whether the first attempt to post this went through; I could'nt find it, so I retry. My apologies for any inconvenience...) I noticed that Python 2.7 beta 1 now contains the argparse module, which might be a good thing. The code has been cleaned up, too, compared to the current version 1.1. But there is still one issue with argparse; to tell the story from the beginning: The ArgumentParser class uses uses '-v' as a default short option for the 'tell me the program version' facility. Since this is commonly used for verbosity, and the vast majority of *X commandline tools use '-V' instead (if they bother to accompany '--version' with a short option at all). Therefore I submitted an issue report at <http://code.google.com/p/argparse/issues/detail?id=43>. To put it short: *Argparse should simply do this like optparse does already.* I.e., use '--version', '--help' and '-h' by default, but not '-v'. Subsequently I spent a hard time arguing. (Perhaps it was somewhat distracting that I proposed a way of postponing the creation of the help and version options and to provide them with the short options which are left unused e.g. for hosts (database clients), human readability (ls, du, etc.) or verbosity; Steven had stated it might break backward compatibility if the '-v' option string for version output would be dropped which might be relied on by other programs which parse the output. IMO, however, anyone should be beaten who relies on '-v' giving the version while '--version' has been present all the time. The Zen of Python, 2nd aphorism: "Explicit is better than implicit") What happened was the following: Completely unnecessarily, the 'version' constructor argument is now deprecated. This fact doesn't solve any problem I can think of; the only effect is to make programming more cumbersome, and it is /one more/ difference to optparse. The 'version' argument is a perfectly reasonable way to provide a script with a simple version information feature. Of course, it should only define the '--version' argument; it *must not* define '-v' for this purpose, since this is commonly used for verbosity, and '-V' is widely used to accompany '--version'. I have lots of scripts which use optparse, and every single one uses the version argument. I consider this a matter of good style. The deprecation of the 'version' argument press-gangs people to replace it by parser.add_argument('--version', action='version', version='<the version>', # the only common part help="show program's version number and exit") in every single script (which violates the DRY principle, by the way). Of course, if a more fancy version information is needed, e.g. reporting the versions of all imported modules, it is perfectly possible to just omit the version argument during creation and build a special 'version' action. No deprecation warnings are needed for this. *Before Python 2.7 reaches productivity stage*, IMNSHO the following changes should be applied to argparse.py: - removal of the deprecation warnings - removal of the default usage of '-v' with the version information facility This is a very simple thing to do; I'd happily provide a patch. (The only complicated task might be to make the unit tests reflect the change; but for a start, 7 lines of the test_main function could be dropped.) Just for the records, this is what optparse does: - it defines -h and --help for the help (unless suppressed) - it defines --version for the version (if version argument given) This is how it should be (regarding the version, at least). This is how the vast majority of *x tools looks like. No reason to change this behaviour. What do you think? -- Cheers, Tobias

16 42

Binary Compatibility Issue with Python v2.6.5 and v3.1.2
by Phil Thompson April 20, 2010

April 20, 2010

When I build my C++ extension on Windows (specifically PyQt with MinGW) against Python v2.6.5 it fails to run under v2.6.4. The same problem exists when building against v3.1.2 and running under v3.1.1. The error message is... ImportError: DLL load failed: The specified procedure could not be found. ...though I don't know what the procedure is. When built against v2.6.4 it runs fine under all v2.6.x. When built under v3.1.1 it runs fine under all v3.1.x. I had always assumed that an extension built with vX.Y.Z would always run under vX.Y.Z-1. Am I wrong in that assumption, or is this a bug in the latest versions? Thanks, Phil

4 6