Re: [Python-Dev] Proposal to revert r54204 (splitext change)
Patrick Maupin wrote: On 3/16/07, Steve Holden [EMAIL PROTECTED] wrote: [...] Then I can stop wasting everyone's time. Even though I am no fonder of code breakage than I was. Fortunately, for new code (at least for this particular change!), you don't have to worry about breakage. I'm sure this discussion has been so indelibly etched into your brain that you won't forget to check your filename management functions very carefully. Sorry, were you being sarcastic? I didn't realize that. Or am I prevaricating again? I don't know whether you are prevaricating again, but I can definitely confirm I wasn't being sarcastic. I don't think sarcasm helps in a discussion like this. I was just apologizing to the group for a rat hole I drew the thread down briefly before someone (Martin, I think) pointed out the incompleteness/incorrectness of my reply. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Blog of Note: http://holdenweb.blogspot.com See you at PyCon? http://us.pycon.org/TX2007 ___ 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] Proposal to revert r54204 (splitext change)
On Thu, Mar 15, 2007, Martin v. L??wis wrote: I'm not quite sure what it is, here. If it is that there be no incompatible changes in Python: this is not policy, and not even consensus. Instead, policy (as enforced by the release manager), and consensus is that bug fix releases (2.x.y) must not show incompatible behavior. For feature releases (2.x), incompatible behavior is acceptable (at least this is what I thought consensus is, but apparently I'm wrong). You are not wrong on one level, but you are wrong on another: if a change that may not be a bugfix gets any legitimate objections, the bar for the change becomes much higher, and that goes double or triple if the change will result in silent breakage of existing programs. If this discussion had occurred three years ago, I would be more inclined toward your position, but right now we have another outlet for silent incompatible changes: Python 3.0. I'm not opposed to extending the splitext API in 2.6 as one solution for this problem, but I still believe that pushing the change to 3.0 is best (assuming we make the change at all, because the people arguing against any change do have a point about Windows -- and in the end, Windows is the largest CONSUMER of Python programs). I do agree with the surprise expressed about your claim that extending the API isn't backward compatible -- the point is that any code using pre-2.6 splitext() API will work the same across 2.x regardless of whether the code is written after 2.6 is released. Of course anyone who uses the extended API is backward incompatible, but that's a much different kind of problem. Because this discussion has gone on so long, it seems to me that a micro-PEP would be good for summarizing. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ I disrespectfully agree. --SJM ___ 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] Py2.6 ideas
Sorry, forgot to include the output of doctest_driver.py --help. Here it is: -Edward Usage: doctest_driver.py [options] NAME ... Options: --version show program's version number and exit -h, --helpshow this help message and exit Actions (default=check): --check Verify the output of the doctest examples in the given files. -u, --updateUpdate the expected output for new or out-of- date doctest examples in the given files. In particular, find every example whose actual output does not match its expected output; and replace its expected output with its actual output. You will be asked to verify the changes before they are written back to the file; be sure to check them over carefully, to ensure that you don't accidentally create broken test cases. --debug Verify the output of the doctest examples in the given files. If any example fails, then enter the python debugger. Reporting: -v, --verbose Increase verbosity. -q, --quiet Decrease verbosity. -d, --udiff Display test failures using unified diffs. --cdiff Display test failures using context diffs. --ndiff Display test failures using ndiffs. Output Comparison: --ellipsis Allow ... to be used for ellipsis in the expected output. --normalize_whitespace Ignore whitespace differences between the expected output and the actual output. ___ 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] Py2.6 ideas
On Feb 15, 2007, at 2:59 PM, Raymond Hettinger wrote: * Enhance doctest with a method that computes updated doctest results. If the only change I make to a matrix suite is to add commas to long numbers in the matrix repr(), then it would be nice to have an automated way to update the matrix output on all the other test cases in the module. A while back I wrote up a command-line doctest driver that does this and more [1]. The output of doctest_driver.py --help is below; note in particular the --update and --debug options. I also wrote an emacs mode [2] that has support for running doctest putting the output (^c^c) or diffs (^c^d) in an output buffer; and for updating the output of selected examples (^c^r). I never really got around to doing official releases for either (although doctest-mode.el is part of the python-mode.el package). I could move some of this code into the doctest mode, if it seems appropriate; or I could just go ahead and release the driver and publicize it. -Edward [1] http://nltk.svn.sourceforge.net/viewvc/nltk/trunk/nltk/nltk_lite/ test/doctest_driver.py?view=markup [2] http://python-mode.svn.sourceforge.net/viewvc/*checkout*/python- mode/trunk/python-mode/doctest-mode.el?revision=424 ___ 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] Bug in inspect module
All,
I have a problem being reported (by Xen users) where inspect.stack() is
throwing IndexError. I think that this is a bug in inspect.py -- findsource
generally throws IOError when it can't find a particular source file, but in
the case where it finds a source file, but that file is shorter than expected,
then findsource throws IndexError, and this is propagated all the way out of
inspect.stack().
I'm not sure why inspect.py is finding source files that don't match the code
being executed -- it seems to be dependent upon the install environment,
because it's not affecting most people. That said, I think that it's
reasonable to cope with a too-short source file in the same way as we cope
with missing source files -- by throwing IOError from findsource and handling
that exception later.
Here's a patch.
Cheers,
Ewan Mellor, XenSource.
--- inspect.py.orig 2007-03-17 17:01:56.410399391 +
+++ inspect.py 2007-03-17 17:16:36.026005726 +
@@ -490,6 +490,8 @@
if not hasattr(object, 'co_firstlineno'):
raise IOError('could not find function definition')
lnum = object.co_firstlineno - 1
+if len(lines) - 1 lnum:
+raise IOError('source file is too short')
pat = re.compile(r'^(\s*def\s)|(.*(?!\w)lambda(:|\s))|^(\s*@)')
while lnum 0:
if pat.match(lines[lnum]): break
___
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] Rationale for NamedTemporaryFile?
I've just discovered the hard way that NamedTemporaryFile automatically deletes the file when you close it. That doesn't seem very useful to me, since surely the reason you're using NamedTemporaryFile instead of TemporaryFile is that you want to do something else with it afterwards? What's the rationale for this behaviour? -- Greg ___ 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] Bug in inspect module
On 3/17/07, Ewan Mellor [EMAIL PROTECTED] wrote: I have a problem being reported (by Xen users) where inspect.stack() is throwing IndexError. I think that this is a bug in inspect.py -- findsource generally throws IOError when it can't find a particular source file, but in the case where it finds a source file, but that file is shorter than expected, then findsource throws IndexError, and this is propagated all the way out of inspect.stack(). I'm not sure why inspect.py is finding source files that don't match the code being executed -- it seems to be dependent upon the install environment, because it's not affecting most people. That said, I think that it's reasonable to cope with a too-short source file in the same way as we cope with missing source files -- by throwing IOError from findsource and handling that exception later. FYI: this has been reported at least once before: see bug #1628987 (http://python.org/sf/1628987). The problem (in the bug report, at least) is that the source file changes between compilation and when findsource() is called, and findsource() picks up the modified version. Collin Winter ___ 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] Encouraging developers
On 8/03/2007, at 2:42 AM, Paul Moore wrote: On 06/03/07, Scott Dial [EMAIL PROTECTED] wrote: Sadly the sf tracker doesn't let you search for With comments by. The patch I was making reference to was 1410680. Someone else actually had wrote a patch that contained bugs and I corrected them. And with that, I was the last person to comment or review the patch in question. [...] On the other hand, what I've done is similar to what you did - comment on someone else's patch. It seems relevant to me that the original poster (Tony Meyer) hasn't felt strongly enough to respond on his own behalf to comments on his patch. No disrespect to Tony, but I'd argue that the implication is that the patch should be rejected because even the submitter doesn't care enough to respond to comments! There is a considerable difference between doesn't care enough, and has not had time to be able to (although in this specific case doesn't care enough is correct). I have submitted a very small (3?) number of patches, however, I suspect that my position is similar to others, so I offer an explanation in the hope that it adds value to this thread. I don't submit patches because I need the problem fixed in the Python distribution. I make the change locally, and either I am distributing a frozen application (almost always the case), which includes my local fix, or a workaround is made in the application source which means that the main Python distribution fix is unneeded (e.g. this is what I did with SpamBayes). The particular patch mentioned is one that uses code (more-or-less) from SpamBayes. SpamBayes has the code - it doesn't matter whether it's in the Python distribution or not. At the time I wrote the patch, there were (again) discussions on python-dev about what should be done to ConfigParser. I had some time free in those days, and, since I had some code that did more-or-less what Guido indicated was the best option, I contributed it (writing unittests, documentation, and commenting in the related tickets). To a certain extent, I considered that my work done. This was something I contributed because many people continually requested it, not something I felt a personal need to be added to the distribution (as above, that's not a need that I generally feel). I (much) later got email with patches, and then later email from Mark Hammond about the patch (IIRC Mark was looking at it and was thinking of fixing it up; I think I forwarded the email I got to him. OTOH, maybe he also sent me fixes - I'm too busy to trawl through email archives to figure it out). At the time, I hoped to fix up the errors and submit a revised patch, but my son was born a few weeks later and I never found the time. If the patch had been reviewed more quickly, then I probably would have found time to correct it - however, everyone else is busy to (if I felt strongly about it, then I would have reviewed 5 other patches, as I have in the past, and 'forced' more quick review, but I did not). For me, submitting a patch is mostly altruistic - if I do that then other people don't also have do the work I did, and hopefully other people do that as well, saving me work. It's not something I require, at all. This isn't something that is easy to make time for. ISTM that there is value in submitting a patch (including tests and documentation, and making appropriate comment in related patches), even if that is all that is done (i.e. no follow-up). If the value isn't there without that follow-up 'caring', then that is something that should be addressed to 'encourage developers'. Contributions don't only come from people hoping to be 'core' developers some day. Uncaringly-(with-apologies-to-uncle-timmy), Tony ___ 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] Rationale for NamedTemporaryFile?
On Sun, Mar 18, 2007 at 11:49:55AM +1200, Greg Ewing wrote: I've just discovered the hard way that NamedTemporaryFile automatically deletes the file when you close it. That doesn't seem very useful to me, since surely the reason you're using NamedTemporaryFile instead of TemporaryFile is that you want to do something else with it afterwards? What's the rationale for this behaviour? For both TemporaryFile and NamedTemporaryFile, the rationale is that temporary extends until the object is garbage collected. TemporaryFile is deleted immediately (to prevent other applications from modifying your temporary file). NamedTemporaryFile is inteded for use when you need access to the file by filename during the lifetime of the file. In either case, when the object goes, the file should too. Dustin ___ 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] Rewrite of cmath module?
The current cmath module has some significant numerical problems, particularly in the inverse trig and inverse hyperbolic trig functions. I've listed a few of these below, but for now I'll just note the following upsetting result: asin(-1e8) Traceback (most recent call last): File stdin, line 1, in module OverflowError: math range error (The true value is somewhere around -pi/2 +/- 19.1138j, which is hardly deserving of an overflow error.) I'm wondering whether anyone would be interested in a rewrite of the cmath module. I have a drop-in replacement written in pure Python, based largely on the formulas given by Kahan in his `Much Ado about Nothing's Sign Bit' article, which I believe eliminates the vast majority of the current numerical problems. Besides the numerical fixes, the only significant difference from the current behaviour is that the branch cuts for asinh have been moved. (The docs suggest that the current branch cuts for asinh should be regarded as buggy). I'm offering to translate this into C and add appropriate documentation and test cases, but I have a couple of questions before I start. (1) Is there actually any interest in fixing this module? I guess that the cmath module can't be used that much, otherwise these problems would have surfaced before. (2) (Disregard if the answer to question 1 is `No'.) What should be done about branch cuts? The value of a function on a branch cut is going to depend on signs of zeros, so it'll be pretty much impossible to make any guarantees about the behaviour. Even so, there are two approaches that seem feasible: (a) One can ensure that on a platform that happens to have IEEE-754 compliant hardware and a signed-zero-friendly math library, the complex functions `do the right thing': i.e., are continuous on both sides of each of the branch cuts, using the sign of zero on a branch cut to determine which side of the branch cut the user is interested in. Doing this portably in C89 involves some trickery, but it seems possible. For other platforms behaviour on the branch cuts would be undefined. Alternatively: (b) Force collapsing of all signed zeros to `positive' zero, so that the functions are continuous only on one side of the branch cuts, and the continuity is exactly as specified in the current documentation (though probably including the suggested changes for atan and atanh.) This is mostly what happens with the current implementation, though it's not clear to me whether that's by design or by accident. (c) Some other approach that I haven't considered. Which of these approaches is preferable? The Python module that I have currently does (a). (3) Is it worth trying to be consistent in exceptional cases? The current math module documentation notes that math.log(0) might produce -inf on one platform and raise ValueError on another, so being consistent about whether a non-representable result gives a NaN, an infinity or a Python exception seems as though it would be tricky. I should also note that I've made no effort to do the right thing when the argument to any of the functions contains a NaN or an infinity in either the real or imaginary part. Here are a few examples of the current cmath problems, on my machine (OS X 10.4.8/PowerPC). (*) As already mentioned in the docs, the current branch cuts for asinh are somewhat unconventional, and should probably be fixed. I believe that this is a fairly trivial fix. (*) asinh gives inaccurate answers in the portion of the complex plane between the current branch cuts, when the real part is large and negative. asinh(-1e7+0.9j) (-16.811242831518271+8.9158318101199366e-08j) asinh(-1e8+0.9j) (-19.113827924512311+0j) (The imaginary parts here should be approximately 8.e-8 and 8.e-9 respectively.) (*) asinh gives inaccurate results for small x: asinh(1e-12) (1.88900582091e-12+0j) asinh(1e-20) (4.4408920985006257e-16+0j) (asinh(x) ~ x - 1/6 x^3 + O(x^5) for small x, so the correct values are 1e-12 and 1e-20 to within machine precision.) (*) acos behaves badly for large reals: acos(1e7) 16.805431370234086j # true value ~ 16.811242831518262597j acos(1e8) Traceback (most recent call last): File stdin, line 1, in module OverflowError: math range error (*) tan and tanh overflow unnecessarily, even though tan(z) and tanh(z) should be representable for all representable complex arguments. tan(1000j) (nannanj) (Actual value: 1j, to within machine precision.) (*) log and sqrt overflow unnecessarily for arguments close to the limits of double precision: z = 1.4e308+1.4e308j sqrt(z) Traceback (most recent call last): File stdin, line 1, in module OverflowError: math range error log(z) (inf+0.78539816339744828j) (*) sqrt gives inaccurate answers for very small arguments (where the real and imaginary parts are denormalized numbers): z = .5e-323 + .5e-323j sqrt(z) (2.2227587494850775e-162+0j) (Correct value for sqrt(z) is close to 2.442109e-162 +
Re: [Python-Dev] Rewrite of cmath module?
On Sun, Mar 18, 2007, Mark Dickinson wrote: I'm wondering whether anyone would be interested in a rewrite of the cmath module. In theory, yes, but my observations of past discussions have been that they tend to founder on the issues of cross-platform support and long-term code maintenance. I have a drop-in replacement written in pure Python, based largely on the formulas given by Kahan in his `Much Ado about Nothing's Sign Bit' article, which I believe eliminates the vast majority of the current numerical problems. If nothing else, if you are willing to support this code, *PLEASE* upload it to the Cheese Shop. Public interest in such code makes it easier to sell back to the core. BTW, I noticed that your post was held for moderation, probably because you aren't subscribed to python-dev. If you want to participate in this discussion, subscribing makes that much easier. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Typing is cheap. Thinking is expensive. --Roy Smith ___ 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
