Re: [Python-Dev] Get 2.5 changes in now, branch will be frozen soon
I'm sure everyone remembers the big ol' honking discussion on the change to
os.splitext; it sorta fizzled after Guido asked if people would accept a
pronouncement on the subject. I'm not anyone in the Python world, but felt
strongly enough on the particular subject to submit a patch (and later
revisions based upon the evolving conversation), but I think this should get
resolved one way or the other. If the existing "fix" goes in for 2.5.1, then
I'm going to withdraw said patch since I think it would end up doing more
harm then good to silently change the semantics of how the function treats
and defines extensions in one version only to do so again in another.
The options, from how I see it, are:
* The patch that Martin committed to fix the behavior such that
splitext('.cshrc') returned ('.cshrc', '') remains. This would silently
alter the behavior of a function whose tests have held the existing behavior
correct; but it would make the behavior more logical in many situations.
* The change gets simply reverted for now to return to the previous
behavior, to perhaps be addressed later. This would revert to the status quo
and its definition of 'extension' when it comes to files that have a leading
dot, which may not be long-term desirable but which would at least give time
for a plan and/or decision on the issue without a silent behavior
adjustment.
* The introduction of a keyword parameter to determine if the function
should treat that initial dot as the start of an extension or a hidden
filename. This would (IMHO) provide a migration path from the existing
behavior which is a bit odd to the new behavior which makes more sense,
while still allowing people to use whichever they choose to be appropriate
for their domain. The question is also open on the issue of warnings; there
was some sentiment that opposed a warning in this case (or in general)
With the latter, another question is what the default is now; and will it
change in the future.
I just wanted to offer a gentle prod to see if a decision can be made; if
any decision requires an adjustment to patches, tests and documentation, I'm
willing to do them. Whatever the decision ends up being.
On 3/29/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
This is a reminder that the 2.5 branch will be frozen early next week.
If there are changes you want to get into 2.5.1, they should be
checked in within a few days. Be conservative! There will be a
2.5.2, it's better to wait than to have to make a new release for one
rushed feature. If you don't believe, just wait until Anthony shows
up at your doorstep. :-)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Get 2.5 changes in now, branch will be frozen soon
"Stephen Hansen" <[EMAIL PROTECTED]> wrote: > I'm sure everyone remembers the big ol' honking discussion on the change to > os.splitext; it sorta fizzled after Guido asked if people would accept a > pronouncement on the subject. I'm not anyone in the Python world, but felt > strongly enough on the particular subject to submit a patch (and later > revisions based upon the evolving conversation), but I think this should get > resolved one way or the other. If the existing "fix" goes in for 2.5.1, then > I'm going to withdraw said patch since I think it would end up doing more > harm then good to silently change the semantics of how the function treats > and defines extensions in one version only to do so again in another. Anthony Baxter said that the patch wasn't making it into 2.5.1, and since he is the release manager, his word is just about as final as Guido's (at least regarding the releases he does). - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Get 2.5 changes in now, branch will be frozen soon
Anthony Baxter said that the patch wasn't making it into 2.5.1, and since he is the release manager, his word is just about as final as Guido's (at least regarding the releases he does). Ah, oops! Work got busy, and I must have missed that in the Endless Threads. Nevermind then. :) --S ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] proposed which.py replacement
Trent Mick has a module called which.py that might make a nice platform-independent replacement for python2.5/Tools/scripts/which.py. http://www.trentm.com/projects/which/ Why which.py? |which.py| is a small GNU-which replacement. It has the following features: * it is portable (Windows, Linux, Mac OS X, Un*x); * it understands PATHEXT and "App Paths" registration on Windows (i.e. it will find everything that |start| does from the command shell); * it can print all matches on the PATH; * it can note "near misses" on the PATH (e.g. files that match but may not, say, have execute permissions); and * it can be used as a Python module. I also would be happy to have this be a replacement for the |which.py| in the Python CVS tree at |dist/src/Tools/scripts/which.py| which is Unix-specific and not usable as a module; and perhaps for inclusion in the stdlib. -- Shane Geiger IT Director National Council on Economic Education [EMAIL PROTECTED] | 402-438-8958 | http://www.ncee.net Leading the Campaign for Economic and Financial Literacy begin:vcard fn:Shane Geiger n:Geiger;Shane org:National Council on Economic Education (NCEE) adr:Suite 215;;201 N. 8th Street;Lincoln;NE;68508;United States email;internet:[EMAIL PROTECTED] title:IT Director tel;work:402-438-8958 x-mozilla-html:FALSE url:http://www.ncee.net version:2.1 end:vcard ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] proposed which.py replacement
If you ask me, having it hosted by Trent is probably more helpful for its popularity than putting it in the Python source distro; the Tools directory is mostly a poorly-maintained collection of trivia I wrote many years ago that is now quietly gathering dust. (Not all of it, of course; there's some useful stuff there that I *didn't* write, which ended up there because it is either *used* by the distro (e.g. the compiler package support) or because the author needed a channel that guaranteed open source status (e.g. world and pynche). But Trent's which.py doesn't seem to fall in either category.) --Guido On 3/31/07, Shane Geiger <[EMAIL PROTECTED]> wrote: > > Trent Mick has a module called which.py that might make a nice > platform-independent replacement for python2.5/Tools/scripts/which.py. > > > > > http://www.trentm.com/projects/which/ > > > Why which.py? > > |which.py| is a small GNU-which replacement. It has the following features: > > * it is portable (Windows, Linux, Mac OS X, Un*x); > * it understands PATHEXT and "App Paths" registration on Windows > (i.e. it will find everything that |start| does from the command > shell); > * it can print all matches on the PATH; > * it can note "near misses" on the PATH (e.g. files that match but > may not, say, have execute permissions); and > * it can be used as a Python module. > > I also would be happy to have this be a replacement for the |which.py| > in the Python CVS tree at |dist/src/Tools/scripts/which.py| which is > Unix-specific and not usable as a module; and perhaps for inclusion in > the stdlib. > > > -- > Shane Geiger > IT Director > National Council on Economic Education > [EMAIL PROTECTED] | 402-438-8958 | http://www.ncee.net > > Leading the Campaign for Economic and Financial Literacy > > > ___ > Python-Dev mailing list > [email protected] > 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] BaseException pickle issue
Some subclasses of Exception are no longer pickleable in Python 2.5. An example: class A(Exception): def __init__(self, foo): self.foo = foo The key problem here is if you do not somehow set self.args to the correct arguments (via Exception.__init__ or setting self.args directly), you will get a TypeError when you try to unpickle it: TypeError: __init__() takes exactly 2 arguments (1 given) I do not think this is unusual. I found a few examples in Python's standard library that have this problem: subprocess.CalledProcessError HTMLParser.HTMLParseError httplib.UnknownProtocol, httplib.IncompleteRead, httplib.BadStatusLine optparse.OptParseError pickle._Stop and on and on... Does anyone have any thoughts about this? Is it a bug? I can imagine one could argue that exceptions should call the base __init__ method to properly set args, but there are so many exceptions out there that do not do this that it would be very difficult to track them all down. I removed the __reduce__ and __setstate__ methods from BaseException and everything seems to just work. Pickling/unpickling works for all protocols whether or not you set self.args. Is this an appropriate solution? I'm not sure what the motivation for having these methods is. -Eric ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Tracker Issues
ACTIVITY SUMMARY (03/25/07 - 04/01/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1647 open ( +3) / 8584 closed ( +2) / 10231 total ( +5) Average duration of open issues: 751 days. Median duration of open issues: 700 days. Open Issues Breakdown open 1647 ( +3) pending 0 ( +0) Issues Created Or Reopened (5) __ Buy Tramadol online 03/25/07 CLOSED http://bugs.python.org/issue1023created conor2k Testing bugs.python.org domain 03/26/07 CLOSED http://bugs.python.org/issue1024created izak Test issue 03/26/07 http://bugs.python.org/issue1025created loewis Test issue, to report@ 03/27/07 http://bugs.python.org/issue1026created forsberg base64.urlsafe_b64encode() shouldn't use the = character 03/28/07 http://bugs.python.org/issue1027created onlinestocktrading Issues Now Closed (2) _ Buy Tramadol online3 days http://bugs.python.org/issue1023amk Testing bugs.python.org domain 0 days http://bugs.python.org/issue1024izak ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Get 2.5 changes in now, branch will be frozen soon
[Stephen Hansen= > I just wanted to offer a gentle prod to see if a decision can be made; > if any decision requires an adjustment to patches, tests and documentation, > I'm willing to do them. We should get a pronouncement on this or else whatever goes out in Py2.5.1 becomes the de-facto decision and becomes much harder to change. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
