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
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 :-(
----- 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
> [<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.
> 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:
>> 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:
>> 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
>> (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
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
* 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.
I've noticed argparse ambiguity handling has changed a bit over last few
I have cases where 1 valid input is a prefix of another:
With the most recent 1.1, the behavior is:
is accepted, while:
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.
help() on an Exception class lists the method resolution order (effectively the inheritance hierarchy).
E.g. help(ArithmeticError) displays inter alia:
Method resolution order:
Would it be possible for it also display the Python built-in SUBclasses of the class? E.g. in the same example something like:
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.
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).
(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
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
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
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
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
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?
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
Am I wrong in that assumption, or is this a bug in the latest versions?
I've got agreement in principle for one of our decommissioned
servers to be repurposed as a Python buildbot. My idea would
be to set it up as a Windows 2003 R2 server, at least partly
because we don't seem to have any Windows server buildbots
and it's a platform I'm especially interested in.
Does anyone suggest that a different configuration would be
preferable? Thanks to the PSF MSDN license I can pretty much
choose whatever I want. I believe Brian Curtin's looking at
the possibility of a Win2k8 box which is one reason why I
steered away from that. Also because my box -- whenever they
hand it over -- will be relatively old.