Re: [Python-Dev] range objects in 3.x
Am 24.09.2011 04:40, schrieb Guido van Rossum: > On Fri, Sep 23, 2011 at 7:13 PM, Steven D'Aprano wrote: http://code.activestate.com/recipes/577068-floating-point-range/ >>> >>> I notice that your examples carefully skirt around the rounding issues. >> >> I also carefully *didn't* claim that it made rounding issues disappear >> completely. I'll add a note clarifying that rounding still occurs and as a >> consequence results can be unexpected. > > I believe this API is fundamentally wrong for float ranges, even if > it's great for int ranges, and I will fight against adding it to the > stdlib in that form. > > Maybe we can come up with a better API, and e.g. specify begin and end > points and the number of subdivisions? E.g. frange(0.0, 2.1, 3) would > generate [0.0, 0.7, 1.4]. This is what numpy calls linspace: http://docs.scipy.org/doc/numpy/reference/generated/numpy.linspace.html numpy also has an "arange" that works with floats, but: """When using a non-integer step, such as 0.1, the results will often not be consistent. It is better to use linspace for these cases.""" Georg ___ 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] range objects in 3.x
On Fri, Sep 23, 2011 at 7:13 PM, Steven D'Aprano wrote: >>> http://code.activestate.com/recipes/577068-floating-point-range/ >> >> I notice that your examples carefully skirt around the rounding issues. > > I also carefully *didn't* claim that it made rounding issues disappear > completely. I'll add a note clarifying that rounding still occurs and as a > consequence results can be unexpected. I believe this API is fundamentally wrong for float ranges, even if it's great for int ranges, and I will fight against adding it to the stdlib in that form. Maybe we can come up with a better API, and e.g. specify begin and end points and the number of subdivisions? E.g. frange(0.0, 2.1, 3) would generate [0.0, 0.7, 1.4]. Or maybe it would even be better to use inclusive end points? OTOH if you consider extending the API to complex numbers, it might be better to specify an initial value, a step, and a count. So frange(0.0, 0.7, 3) to generate [0.0, 0.7, 1.4]. Probably it shouldn't be called frange then. -- --Guido van Rossum (python.org/~guido) ___ 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] range objects in 3.x
Guido van Rossum wrote: On Fri, Sep 23, 2011 at 6:36 PM, Steven D'Aprano wrote: Ethan Furman wrote: A question came up on StackOverflow about range objects and floating point numbers. I thought about writing an frange that did for floats what range does for ints, For what it's worth, here's mine: http://code.activestate.com/recipes/577068-floating-point-range/ I notice that your examples carefully skirt around the rounding issues. I also carefully *didn't* claim that it made rounding issues disappear completely. I'll add a note clarifying that rounding still occurs and as a consequence results can be unexpected. Thanks for taking the time to comment. -- Steven ___ 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] range objects in 3.x
On Fri, Sep 23, 2011 at 6:36 PM, Steven D'Aprano wrote: > Ethan Furman wrote: >> >> A question came up on StackOverflow about range objects and floating point >> numbers. I thought about writing an frange that did for floats what range >> does for ints, > > > For what it's worth, here's mine: > > http://code.activestate.com/recipes/577068-floating-point-range/ I notice that your examples carefully skirt around the rounding issues. Check out frange(0.0, 2.1, 0.7). -- --Guido van Rossum (python.org/~guido) ___ 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] range objects in 3.x
Ethan Furman wrote: A question came up on StackOverflow about range objects and floating point numbers. I thought about writing an frange that did for floats what range does for ints, For what it's worth, here's mine: http://code.activestate.com/recipes/577068-floating-point-range/ -- Steven ___ 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] Inconsistent script/console behaviour
On Fri, Sep 23, 2011 at 18:49, Terry Reedy wrote: > A interactive lisp interpreter can detect end-of-statement without a blank > line by matching a closing paren to the open paren that starts every > expression. Braces-loving programmers around the world are feverishly writing a PEP as we speak. ___ 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] Inconsistent script/console behaviour
On 9/23/2011 7:25 PM, anatoly techtonik wrote: Currently if you work in console and define a function and then immediately call it - it will fail with SyntaxError. For example, copy paste this completely valid Python script into console: def some(): print "XXX" some() There is an issue for that that was just closed by Eric. However, I'd like to know if there are people here that agree that if you paste a valid Python script into console - it should work without changes. For this kind of multi-line, multi-statemenmt pasting, open an IDLE edit window for tem.py (my name) or such, paste, run with F5. I have found that this works for me than direct pasting. A interactive lisp interpreter can detect end-of-statement without a blank line by matching a closing paren to the open paren that starts every expression. -- Terry Jan Reedy ___ 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] Inconsistent script/console behaviour
I agree that it should and it doesn't. I also recall that not having empty lines between function/class definitions can cause indentation errors when pasting to the console on my windows machine. --Yuval On Sep 23, 2011 7:26 PM, "anatoly techtonik" wrote: > Currently if you work in console and define a function and then > immediately call it - it will fail with SyntaxError. > For example, copy paste this completely valid Python script into console: > > def some(): > print "XXX" > some() > > There is an issue for that that was just closed by Eric. However, I'd > like to know if there are people here that agree that if you paste a > valid Python script into console - it should work without changes. > -- > anatoly t. > ___ > 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/ubershmekel%40gmail.com ___ 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] Inconsistent script/console behaviour
On Fri, Sep 23, 2011 at 4:25 PM, anatoly techtonik wrote: > Currently if you work in console and define a function and then > immediately call it - it will fail with SyntaxError. > For example, copy paste this completely valid Python script into console: > > def some(): > print "XXX" > some() > > There is an issue for that that was just closed by Eric. However, I'd > like to know if there are people here that agree that if you paste a > valid Python script into console - it should work without changes. You can't fix this without completely changing the way the interactive console treats blank lines. None that it's not just that a blank line is required after a function definition -- you also *can't* have a blank line *inside* a function definition. The interactive console is optimized for people entering code by typing, not by copying and pasting large gobs of text. If you think you can have it both, show us the code. -- --Guido van Rossum (python.org/~guido) ___ 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] Inconsistent script/console behaviour
Currently if you work in console and define a function and then immediately call it - it will fail with SyntaxError. For example, copy paste this completely valid Python script into console: def some(): print "XXX" some() There is an issue for that that was just closed by Eric. However, I'd like to know if there are people here that agree that if you paste a valid Python script into console - it should work without changes. -- anatoly t. ___ 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] range objects in 3.x
Ethan Furman wrote: The only reason I'm aware of at the moment is to prevent loss of functionality from 2.x range to 3.x range. Since 2.x range(...) is equivalent to 3.x list(range(...)), I don't see any loss of functionality there. Comparing range objects directly in 3.x is like comparing xrange objects in 2.x, and there the comparison was arbitrary -- it did *not* compare them like their corresponding lists: Python 2.7 (r27:82500, Oct 15 2010, 21:14:33) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> a = xrange(5) >>> b = xrange(5) >>> a > b True -- 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] range objects in 3.x
Martin v. Löwis wrote: Yes, I realize this is because range returned a list in 2.x. However, aren't __contains__, __getitem__, count, and index implemented in 3.x range because 2.x range returned lists? No, they are implemented because they are meaningful, and with an obvious meaning. "Is 30 in the range from 10 to 40?" is something that everybody will answer the same way. "What is the fifth element of the range from 10 to 40?" may not have such a universal meaning, but people familiar with the mathematical concept of an interval can readily guess the answer (except that they may wonder whether to start counting at 0 or 1). "Is the range from 5 to 100 larger than the range from 10 to 100?" is something that most people would answer as "yes" (I believe), yet py> range(5,100) > range(10,100) False Thanks, Martin! I can see where there could be many interpretations about the meaning of less-than and greater-than with regards to range. ~Ethan~ ___ 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] range objects in 3.x
> Yes, I realize this is because range returned a list in 2.x. However, > aren't __contains__, __getitem__, count, and index implemented in 3.x > range because 2.x range returned lists? No, they are implemented because they are meaningful, and with an obvious meaning. "Is 30 in the range from 10 to 40?" is something that everybody will answer the same way. "What is the fifth element of the range from 10 to 40?" may not have such a universal meaning, but people familiar with the mathematical concept of an interval can readily guess the answer (except that they may wonder whether to start counting at 0 or 1). "Is the range from 5 to 100 larger than the range from 10 to 100?" is something that most people would answer as "yes" (I believe), yet py> range(5,100) > range(10,100) False Regards, Martin ___ 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] range objects in 3.x
Le Fri, 23 Sep 2011 13:23:26 -0700, Ethan Furman a écrit : > > So the question becomes, Why does it implement the Sequence ABC? Because these operations are trivial to implement and it would be suboptimal to have to instantiate the full list to run them? ___ 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] range objects in 3.x
On Fri, Sep 23, 2011 at 1:23 PM, Ethan Furman wrote: > The only reason I'm aware of at the moment is to prevent loss of > functionality from 2.x range to 3.x range. > > I'm -0 with a decision to not have range be orderable; but I understand > there are bigger fish to fry. :) I don't believe there's a valid use case for ordering ranges. As for backwards compatibility, apparently nobody cares or we would've heard about it. > My original concern was that the comparison methods were there at all, but > looking around I see object has them, so it makes sense to me now. I had > thought I would have to implement them if I went ahead with an frange (for > floats). [...]> So the question becomes, Why does it implement the Sequence ABC? Because the > original range returned a list and those operations made sense? Because all operations on Sequence make sense: you can iterate over a range, it has a definite number of items, and so on; all other sequence operations can be derived from that easily (and in fact they almost all be done in O(1) time). -- --Guido van Rossum (python.org/~guido) ___ 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] range objects in 3.x
Benjamin Peterson wrote: 2011/9/23 Ethan Furman : Benjamin Peterson wrote: 2011/9/23 Ethan Furman : Follow-up question: since the original range returned lists, and comparisons do make sense for lists, should the new range also implement them? What would be the use-case? The only reason I'm aware of at the moment is to prevent loss of functionality from 2.x range to 3.x range. range comparisons in 2.x have no functionality. Python 2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. --> r1 = range(10) --> r2 = range(0, 20, 2) --> r3 = range(10) --> r1 == r3 True --> r1 < r2 True --> r3 > r2 False Yes, I realize this is because range returned a list in 2.x. However, aren't __contains__, __getitem__, count, and index implemented in 3.x range because 2.x range returned lists? ~Ethan~ ___ 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] range objects in 3.x
2011/9/23 Ethan Furman : > Benjamin Peterson wrote: >> >> 2011/9/23 Ethan Furman : > >>> >>> >>> Follow-up question: since the original range returned lists, and >>> comparisons >>> do make sense for lists, should the new range also implement them? >> >> What would be the use-case? > > The only reason I'm aware of at the moment is to prevent loss of > functionality from 2.x range to 3.x range. range comparisons in 2.x have no functionality. > >>> I note >>> that it does implement __contains__, __getitem__, count, and index in the >>> same way that list does. >> >> That's because it implements the Sequence ABC. > > So the question becomes, Why does it implement the Sequence ABC? Because the > original range returned a list and those operations made sense? I'm not sure what the history is. -- Regards, Benjamin ___ 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] range objects in 3.x
On 2011-09-23, at 20:23 , Guido van Rossum wrote: > Also, Ethan, I hope you're familiar with the reason why there is no > range() support for floats currently? (Briefly, things like range(0.0, > 0.8, step=0.1) could include or exclude the end point depending on > rounding, which makes for troublesome semantics.) On the other hand, there could be a range for Decimal could there not? ___ 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] range objects in 3.x
Benjamin Peterson wrote: 2011/9/23 Ethan Furman : >> Follow-up question: since the original range returned lists, and comparisons do make sense for lists, should the new range also implement them? What would be the use-case? The only reason I'm aware of at the moment is to prevent loss of functionality from 2.x range to 3.x range. I'm -0 with a decision to not have range be orderable; but I understand there are bigger fish to fry. :) My original concern was that the comparison methods were there at all, but looking around I see object has them, so it makes sense to me now. I had thought I would have to implement them if I went ahead with an frange (for floats). I note that it does implement __contains__, __getitem__, count, and index in the same way that list does. That's because it implements the Sequence ABC. So the question becomes, Why does it implement the Sequence ABC? Because the original range returned a list and those operations made sense? ~Ethan~ ___ 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] range objects in 3.x
Guido van Rossum wrote: Also, Ethan, I hope you're familiar with the reason why there is no range() support for floats currently? (Briefly, things like range(0.0, 0.8, step=0.1) could include or exclude the end point depending on rounding, which makes for troublesome semantics.) Good point, thanks for the reminder. ~Ethan~ ___ 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] range objects in 3.x
Also, Ethan, I hope you're familiar with the reason why there is no range() support for floats currently? (Briefly, things like range(0.0, 0.8, step=0.1) could include or exclude the end point depending on rounding, which makes for troublesome semantics.) On Fri, Sep 23, 2011 at 11:14 AM, Benjamin Peterson wrote: > 2011/9/23 Ethan Furman : >> A question came up on StackOverflow about range objects and floating point >> numbers. I thought about writing an frange that did for floats what range >> does for ints, so started examining the range class. I noticed it has >> __le__, __lt__, __eq__, __ne__, __ge__, and __gt__ methods. Some >> experiments show that xrange in 2.x does indeed implement those operations, >> but in 3.x range does not (TypeError: unorderable types: range() > range()). >> >> Was this intentional, or should I file a bug report? (I was unable to find >> anything in the What's New documents; also, I did not test in 3.0, just in >> 2.7, 3.1, 3.2.) > > That's simply a consequence of everything having comparisons defined > in 2.x. The comparison is essentially meaningless. > > > -- > Regards, > Benjamin > ___ > 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/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ 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] range objects in 3.x
2011/9/23 Ethan Furman : > A question came up on StackOverflow about range objects and floating point > numbers. I thought about writing an frange that did for floats what range > does for ints, so started examining the range class. I noticed it has > __le__, __lt__, __eq__, __ne__, __ge__, and __gt__ methods. Some > experiments show that xrange in 2.x does indeed implement those operations, > but in 3.x range does not (TypeError: unorderable types: range() > range()). > > Was this intentional, or should I file a bug report? (I was unable to find > anything in the What's New documents; also, I did not test in 3.0, just in > 2.7, 3.1, 3.2.) That's simply a consequence of everything having comparisons defined in 2.x. The comparison is essentially meaningless. -- Regards, Benjamin ___ 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] range objects in 3.x
A question came up on StackOverflow about range objects and floating point numbers. I thought about writing an frange that did for floats what range does for ints, so started examining the range class. I noticed it has __le__, __lt__, __eq__, __ne__, __ge__, and __gt__ methods. Some experiments show that xrange in 2.x does indeed implement those operations, but in 3.x range does not (TypeError: unorderable types: range() > range()). Was this intentional, or should I file a bug report? (I was unable to find anything in the What's New documents; also, I did not test in 3.0, just in 2.7, 3.1, 3.2.) ~Ethan~ ___ 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] [Python-checkins] cpython (3.2): Issue #7732: Don't open a directory as a file anymore while importing a
On 23/09/2011 20.11, Éric Araujo wrote: Hi Victor, diff --git a/Misc/NEWS b/Misc/NEWS --- a/Misc/NEWS +++ b/Misc/NEWS @@ -10,6 +10,10 @@ Core and Builtins - +- Issue #7732: Don't open a directory as a file anymore while importing a + module. Ignore the direcotry if its name matchs the module name (e.g. Typo: direcotry Typo: matchs ___ 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] [Python-checkins] cpython (3.2): Issue #7732: Don't open a directory as a file anymore while importing a
Hi Victor, > diff --git a/Misc/NEWS b/Misc/NEWS > --- a/Misc/NEWS > +++ b/Misc/NEWS > @@ -10,6 +10,10 @@ > Core and Builtins > - > > +- Issue #7732: Don't open a directory as a file anymore while importing a > + module. Ignore the direcotry if its name matchs the module name (e.g. Typo: direcotry ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2011-09-16 - 2011-09-23) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3030 (+11) closed 21788 (+31) total 24818 (+42) Open issues with patches: 1299 Issues opened (34) == #11686: Update of some email/ __all__ lists http://bugs.python.org/issue11686 reopened by r.david.murray #11780: email.encoders are broken http://bugs.python.org/issue11780 reopened by r.david.murray #12991: Python 64-bit build on HP Itanium - Executable built successfu http://bugs.python.org/issue12991 reopened by wah meng #12997: sqlite3: PRAGMA foreign_keys = ON doesn't work http://bugs.python.org/issue12997 opened by Mark.Bucciarelli #12998: Memory leak with CTypes Structure http://bugs.python.org/issue12998 opened by a01 #12999: _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED usage on Solaris http://bugs.python.org/issue12999 opened by neologix #13000: unhandled exception at install http://bugs.python.org/issue13000 opened by jorge.seifert #13001: test_socket.testRecvmsgTrunc failure on FreeBSD 7.2 buildbot http://bugs.python.org/issue13001 opened by neologix #13004: pprint: add option to truncate sequences http://bugs.python.org/issue13004 opened by terry.reedy #13008: syntax error when pasting valid snippet into console without e http://bugs.python.org/issue13008 opened by techtonik #13009: Remove documentation in distutils2 repo http://bugs.python.org/issue13009 opened by eric.araujo #13011: Frozen programs require the original build directory in order http://bugs.python.org/issue13011 opened by malcolmp #13012: Allow keyword argument in str.splitlines() http://bugs.python.org/issue13012 opened by mark.dickinson #13013: _ctypes.c: refleak http://bugs.python.org/issue13013 opened by Suman.Saha #13014: _ssl.c: refleak http://bugs.python.org/issue13014 opened by Suman.Saha #13015: _collectionsmodule.c: refleak http://bugs.python.org/issue13015 opened by Suman.Saha #13016: selectmodule.c: refleak http://bugs.python.org/issue13016 opened by Suman.Saha #13017: pyexpat.c: refleak http://bugs.python.org/issue13017 opened by Suman.Saha #13018: dictobject.c: refleak http://bugs.python.org/issue13018 opened by Suman.Saha #13019: bytearrayobject.c: refleak http://bugs.python.org/issue13019 opened by Suman.Saha #13020: structseq.c: refleak http://bugs.python.org/issue13020 opened by Suman.Saha #13023: argparse should allow displaying argument default values in ad http://bugs.python.org/issue13023 opened by denilsonsa #13024: cgitb uses stdout encoding http://bugs.python.org/issue13024 opened by haypo #13025: mimetypes should read the rule file using UTF-8, not the local http://bugs.python.org/issue13025 opened by haypo #13026: Dis module - documentation of MAKE_FUNCTION http://bugs.python.org/issue13026 opened by arno #13027: python 2.6.6 interpreter core dumps on modules command from he http://bugs.python.org/issue13027 opened by Balachandran.Sivakumar #13028: python wastes linux users time by checking for dylib on each d http://bugs.python.org/issue13028 opened by fzvqedi #13029: test_strptime fails on Windows 7 french http://bugs.python.org/issue13029 opened by haypo #13030: Be more generic when identifying the Windows main dir in insta http://bugs.python.org/issue13030 opened by sandro.tosi #13031: [PATCH] small speed-up for tarfile.py when unzipping tarballs http://bugs.python.org/issue13031 opened by jpeel #13032: h2py.py can fail with UnicodeDecodeError http://bugs.python.org/issue13032 opened by Arfrever #13033: recursive chown for shutils http://bugs.python.org/issue13033 opened by Low.Kian.Seong #13034: Python does not read Alternative Subject Names from SSL certif http://bugs.python.org/issue13034 opened by atrasatti #13035: "maintainer" value clear the "author" value when registering http://bugs.python.org/issue13035 opened by jab Most recent 15 issues with no replies (15) == #13035: "maintainer" value clear the "author" value when registering http://bugs.python.org/issue13035 #13034: Python does not read Alternative Subject Names from SSL certif http://bugs.python.org/issue13034 #13032: h2py.py can fail with UnicodeDecodeError http://bugs.python.org/issue13032 #13030: Be more generic when identifying the Windows main dir in insta http://bugs.python.org/issue13030 #13025: mimetypes should read the rule file using UTF-8, not the local http://bugs.python.org/issue13025 #13024: cgitb uses stdout encoding http://bugs.python.org/issue13024 #13023: argparse should allow displaying argument default values in ad http://bugs.python.org/issue13023 #13019: bytearrayobject.c: refleak http://bugs.python.org/issue13019 #13018: dictobject.c: refleak http://bugs.python.org/issue13018 #13017: pyexpat.c: refleak http://bugs.python.org/issue13017 #13016:
Re: [Python-Dev] genious hack in python
Hi! On Fri, Sep 23, 2011 at 11:12:53AM -0400, Martin Goudreau wrote: > Please check a very small > module i'v made for improving the debugger traceback. See the > pybettererror.py on sourceforge: > http://pybettererror.sourceforge.net/projet.html Why do this in sys.stderr and not by monkey-patching traceback.py, probably format_list and format_exception_only? Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] genious hack in python
Hello Dev Teem, Guido told me to send you this idea... Improving productivity is one of my Strength. Please check a very small module i'v made for improving the debugger traceback. See the pybettererror.py on sourceforge: http://pybettererror.sourceforge.net/projet.html It's hard to find something to complain about in python. This one was a too good idea to keep for myself. Thanks Martin Goudreau from Montreal ___ 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] [Python-checkins] cpython (2.7): Issue #12931: xmlrpclib now encodes Unicode URI to ISO-8859-1, instead of
Hi Victor,
> summary:
> Issue #12931: xmlrpclib now encodes Unicode URI to ISO-8859-1, instead of
> failing with a UnicodeDecodeError.
>
> diff --git a/Lib/test/test_xmlrpc.py b/Lib/test/test_xmlrpc.py
> --- a/Lib/test/test_xmlrpc.py
> +++ b/Lib/test/test_xmlrpc.py
> @@ -472,6 +472,9 @@
> # protocol error; provide additional information in test
> output
> self.fail("%s\n%s" % (e, getattr(e, "headers", "")))
>
> +def test_unicode_host(self):
> +server = xmlrpclib.ServerProxy(u"http://%s:%d/RPC2"%(ADDR, PORT))
Spaces around the modulo operator would have been nice here.
Readability counts :)
___
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
