[ python-Bugs-1692695 ] webbrowser module cannot open the right URL
Bugs item #1692695, was opened at 2007-04-02 08:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1692695&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pan Yongzhi (fossilet) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser module cannot open the right URL Initial Comment: My python version is: tux 0 ~ $ ipython Python 2.5 (release25-maint, Mar 29 2007, 11:14:31) Type "copyright", "credits" or "license" for more information. I use the example given at http://docs.python.org/lib/module-webbrowser.html : In [1]: import webbrowser In [2]: url = 'http://www.python.org' In [3]: webbrowser.open_new_tab(url + '/doc') The location bar of firefox shows: file:///home/tux/%22http://www.python.org/doc%22 and firefox cannot open the URL. This problem also occurs with local dir URLs. webbrowser.open also has this problem. In python 2.4.4 things are OK. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1692695&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1692695 ] webbrowser module cannot open the right URL
Bugs item #1692695, was opened at 2007-04-02 07:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1692695&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Pan Yongzhi (fossilet) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser module cannot open the right URL Initial Comment: My python version is: tux 0 ~ $ ipython Python 2.5 (release25-maint, Mar 29 2007, 11:14:31) Type "copyright", "credits" or "license" for more information. I use the example given at http://docs.python.org/lib/module-webbrowser.html : In [1]: import webbrowser In [2]: url = 'http://www.python.org' In [3]: webbrowser.open_new_tab(url + '/doc') The location bar of firefox shows: file:///home/tux/%22http://www.python.org/doc%22 and firefox cannot open the URL. This problem also occurs with local dir URLs. webbrowser.open also has this problem. In python 2.4.4 things are OK. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-04-02 07:46 Message: Logged In: YES user_id=849994 Originator: NO This should be fixed in 2.5.1 which comes out in a few days. If not, please reopen. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1692695&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1693050 ] \w not helpful for non-Roman scripts
Bugs item #1693050, was opened at 2007-04-02 09:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693050&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: nlmiles (nathanlmiles)
Assigned to: M.-A. Lemburg (lemburg)
Summary: \w not helpful for non-Roman scripts
Initial Comment:
When I try to use r"\w+(?u)" to find words in a unicode Devanagari text bad
things happen. Words get chopped into small pieces. I think this is likely
because vowel signs such as 093e are not considered to match \w.
I think that if you wish \w to be useful for Indic
scipts \w will need to be exanded to unclude unicode character categories Mc,
Mn, Me.
I am using Python 2.4.4 on Windows XP SP2.
I ran the following script to see the characters which I think ought to match
\w but don't
import re
import unicodedata
text = ""
for i in range(0x901,0x939): text += unichr(i)
for i in range(0x93c,0x93d): text += unichr(i)
for i in range(0x93e,0x94d): text += unichr(i)
for i in range(0x950,0x954): text += unichr(i)
for i in range(0x958,0x963): text += unichr(i)
parts = re.findall("\W(?u)", text)
for ch in parts:
print "%04x" % ord(ch), unicodedata.category(ch)
The odd character here is 0904. Its categorization seems to imply that you are
using the uncode 3.0 database but perhaps later versions of Python are using
the current 5.0 database.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693050&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1686386 ] Python SEGFAULT on invalid superclass access
Bugs item #1686386, was opened at 2007-03-22 17:00 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686386&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: toxik (ludvig.ericson) Assigned to: Nobody/Anonymous (nobody) Summary: Python SEGFAULT on invalid superclass access Initial Comment: When one uses a class that has derived BaseException in one way or another and uses an invalid super() and calls a function upon that object, Python dies with SIGSEGV. Reproduce code: >>> class X(BaseException): ... def __init__(self): ... super(X, self).__init__(self) ... >>> X() Segmentation fault I could reproduce this on two different Python 2.5 installations. This is as much as I could get from gdb: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211660624 (LWP 30234)] 0xb7ea601c in _PyObject_GC_Malloc () from /usr/lib/libpython2.5.so.1.0 (gdb) bt #0 0xb7ea601c in _PyObject_GC_Malloc () from /usr/lib/libpython2.5.so.1.0 #1 0xb7ea613b in _PyObject_GC_NewVar () from /usr/lib/libpython2.5.so.1.0 #2 0xb7e4abe4 in PyTuple_New () from /usr/lib/libpython2.5.so.1.0 #3 0xb7e4b48d in ?? () from /usr/lib/libpython2.5.so.1.0 #4 0x0001 in ?? () #5 0x in ?? () -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-22 17:37 Message: Logged In: YES user_id=849994 Originator: NO This is not new in 2.5. That is does not work with super() in 2.4 is because in 2.4 exceptions are old-style classes. Look at this: >>> class X(Exception): ... def __init__(self): ... Exception.__init__(self, self) ... >>> x=X() >>> str(x) [1]4396 segmentation fault python2.4 The problem is that str(x) calls str(x) etc. -- Comment By: toxik (ludvig.ericson) Date: 2007-03-22 17:09 Message: Logged In: YES user_id=1373326 Originator: YES It might be added that this works (throws an exception) in python 2.4 (though, BaseException does not exist there): TypeError: super() argument 1 must be type, not classobj -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1686386&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1693050 ] \w not helpful for non-Roman scripts
Bugs item #1693050, was opened at 2007-04-02 17:27
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693050&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: nlmiles (nathanlmiles)
>Assigned to: Nobody/Anonymous (nobody)
Summary: \w not helpful for non-Roman scripts
Initial Comment:
When I try to use r"\w+(?u)" to find words in a unicode Devanagari text bad
things happen. Words get chopped into small pieces. I think this is likely
because vowel signs such as 093e are not considered to match \w.
I think that if you wish \w to be useful for Indic
scipts \w will need to be exanded to unclude unicode character categories Mc,
Mn, Me.
I am using Python 2.4.4 on Windows XP SP2.
I ran the following script to see the characters which I think ought to match
\w but don't
import re
import unicodedata
text = ""
for i in range(0x901,0x939): text += unichr(i)
for i in range(0x93c,0x93d): text += unichr(i)
for i in range(0x93e,0x94d): text += unichr(i)
for i in range(0x950,0x954): text += unichr(i)
for i in range(0x958,0x963): text += unichr(i)
parts = re.findall("\W(?u)", text)
for ch in parts:
print "%04x" % ord(ch), unicodedata.category(ch)
The odd character here is 0904. Its categorization seems to imply that you are
using the uncode 3.0 database but perhaps later versions of Python are using
the current 5.0 database.
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2007-04-02 17:38
Message:
Logged In: YES
user_id=38388
Originator: NO
Python 2.4 is using Unicode 3.2. Python 2.5 ships with Unicode 4.1.
We're likely to ship Unicode 5.x with Python 2.6 or a later release.
Regarding the char classes: I don't think Mc, Mn and Me should be
considered parts of a word. Those are marks which usually separate words.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693050&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1693079 ] Can't save empty array in shelve
Bugs item #1693079, was opened at 2007-04-02 18:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693079&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IWL (iwl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't save empty array in shelve
Initial Comment:
iwl wrote:
> I've tryed to save some data containing empty arrays (array('f')) in a
> shelve.
> It looks like the shelve has some problems with empty arrays, get
> allways:
> TypeError: ("'NoneType' object is not iterable", ,
> ('f', None))-
> Messages when dealing with the readed back shelve.
> Seems like I have to avoid empty arrays in a shelve.
That seems to be a bug in the underlying pickling mechanism:
>>> from array import array
>>> from cPickle import loads, dumps
>>> loads(dumps(array("f", [1])))
array('f', [1.0])
>>> loads(dumps(array("f")))
Traceback (most recent call last):
File "", line 1, in
TypeError: ("'NoneType' object is not iterable", , ('f',
None))
Please submit a bug report.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693079&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1693079 ] Can't save empty array in shelve
Bugs item #1693079, was opened at 2007-04-02 11:19
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693079&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: IWL (iwl)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Can't save empty array in shelve
Initial Comment:
iwl wrote:
> I've tryed to save some data containing empty arrays (array('f')) in a
> shelve.
> It looks like the shelve has some problems with empty arrays, get
> allways:
> TypeError: ("'NoneType' object is not iterable", ,
> ('f', None))-
> Messages when dealing with the readed back shelve.
> Seems like I have to avoid empty arrays in a shelve.
That seems to be a bug in the underlying pickling mechanism:
>>> from array import array
>>> from cPickle import loads, dumps
>>> loads(dumps(array("f", [1])))
array('f', [1.0])
>>> loads(dumps(array("f")))
Traceback (most recent call last):
File "", line 1, in
TypeError: ("'NoneType' object is not iterable", , ('f',
None))
Please submit a bug report.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693079&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1693079 ] Can't save empty array in shelve
Bugs item #1693079, was opened at 2007-04-02 11:19
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693079&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: IWL (iwl)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Can't save empty array in shelve
Initial Comment:
iwl wrote:
> I've tryed to save some data containing empty arrays (array('f')) in a
> shelve.
> It looks like the shelve has some problems with empty arrays, get
> allways:
> TypeError: ("'NoneType' object is not iterable", ,
> ('f', None))-
> Messages when dealing with the readed back shelve.
> Seems like I have to avoid empty arrays in a shelve.
That seems to be a bug in the underlying pickling mechanism:
>>> from array import array
>>> from cPickle import loads, dumps
>>> loads(dumps(array("f", [1])))
array('f', [1.0])
>>> loads(dumps(array("f")))
Traceback (most recent call last):
File "", line 1, in
TypeError: ("'NoneType' object is not iterable", , ('f',
None))
Please submit a bug report.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-02 12:29
Message:
Logged In: YES
user_id=80475
Originator: NO
Fixed. See versions 54657 and 54658.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1693079&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results
Bugs item #1678380, was opened at 2007-03-11 12:16
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Mark Dickinson (marketdickinson)
>Assigned to: Alex Martelli (aleax)
Summary: 0.0 and -0.0 identified, with surprising results
Initial Comment:
The identification of -0.0 and 0.0 in scripts leads to some surprising
results. In particular, code that behaves one way in the interpreter can
behave differently in a script. For example:
Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import atan2;
>>> x = -0.
>>> y = 0.
>>> print atan2(y, -1.)
3.14159265359
But:
>>> exec("from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)")
-3.14159265359
A simpler example:
>>> x, y = -0., 0.
>>> x, y
(-0.0, -0.0)
>>> id(x) == id(y)
True
But:
>>> x = -0.
>>> y = 0.
>>> x, y
(-0.0, 0.0)
This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-02 14:02
Message:
Logged In: YES
user_id=80475
Originator: NO
The distinction between +0.0 and -0.0 was important to Tim for get the
branch cuts to work correctly. That was the reason for the special-casing
in earlier versions in pre-ast versions of compile.c and in the peephole
optimizer.
Alex's patch looks correct. It should go into Py2.5.1.
--
Comment By: Alex Martelli (aleax)
Date: 2007-03-12 09:57
Message:
Logged In: YES
user_id=60314
Originator: NO
and yet, peephole.c does specialcase -0 (with a comment and all!-)
avoiding constant-folding optimization for it -- making things work fine in
Python 2.4.x for high enough x -- it's just that peephole.c's efforts are
defeated by a similar optimization applied without specialcase checking in
ast.c in Python 2.5. This is inconsistent: it makes no sense to take SOME
of the precautions needed to avoid an issue but not ALL of them, since this
makes the issue appear anyway, so those precautions that ARE taken are
there for no purpose (except a miniscule slowdown and enlargement of the
interpreter:-). Either we save those few lines of code in peephole.c or
add the few lines to ast.c that I suggest in my patch 1678668 -- the
current situation makes no sense.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-03-12 04:04
Message:
Logged In: YES
user_id=21627
Originator: NO
I also expressed myself badly. I not only meant that programs should not
rely on +0 and -0 being different things across platforms, but that they
should also not rely on them being either always different or always the
same in a single program. If Python would randomly chose to interpret +0 as
-0, or would do so for every third occurence, I still couldn't see a
problem.
--
Comment By: Alex Martelli (aleax)
Date: 2007-03-11 20:54
Message:
Logged In: YES
user_id=60314
Originator: NO
Oops,sorry, I meant patch 1678668 (copy-and-pasted the wrong ID:-).
Alex
--
Comment By: Alex Martelli (aleax)
Date: 2007-03-11 20:51
Message:
Logged In: YES
user_id=60314
Originator: NO
Also see my patch 1678380 which fixes this bug (and checks for it in a new
unittest).
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-03-11 20:15
Message:
Logged In: YES
user_id=703403
Originator: YES
I expressed myself badly. I apologise. This really isn't about +0. and
-0.
being different, or not. I'm perfectly comfortable with the idea that +0.
and -0. may or may not be distinguishable on any given platform.
The surprise is the other way around: two *identical* calls to atan(0.,
-1.)
(or to repr(0.) for that matter) give *different* results, depending
solely
on whether a -0. literal has appeared earlier on in the code unit being
compiled.
So if the first float zero literal encountered in a source file just
happens to be a
-0. rather than a 0., the meaning of str(0.) later on suddenly becomes
"-0.0"
rather than "0.0". I'd like to be able to rely on str(0.) meaning "0.0"
without
having to worry about whether there might be a -0. literal appearing in
some
faraway and otherwise completely irrelevant portion of the file.
---
[ python-Bugs-1678380 ] 0.0 and -0.0 identified, with surprising results
Bugs item #1678380, was opened at 2007-03-11 12:16
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1678380&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
>Priority: 6
Private: No
Submitted By: Mark Dickinson (marketdickinson)
Assigned to: Alex Martelli (aleax)
Summary: 0.0 and -0.0 identified, with surprising results
Initial Comment:
The identification of -0.0 and 0.0 in scripts leads to some surprising
results. In particular, code that behaves one way in the interpreter can
behave differently in a script. For example:
Python 2.6a0 (trunk:54183M, Mar 6 2007, 20:16:00)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import atan2;
>>> x = -0.
>>> y = 0.
>>> print atan2(y, -1.)
3.14159265359
But:
>>> exec("from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)")
-3.14159265359
A simpler example:
>>> x, y = -0., 0.
>>> x, y
(-0.0, -0.0)
>>> id(x) == id(y)
True
But:
>>> x = -0.
>>> y = 0.
>>> x, y
(-0.0, 0.0)
This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-02 14:02
Message:
Logged In: YES
user_id=80475
Originator: NO
The distinction between +0.0 and -0.0 was important to Tim for get the
branch cuts to work correctly. That was the reason for the special-casing
in earlier versions in pre-ast versions of compile.c and in the peephole
optimizer.
Alex's patch looks correct. It should go into Py2.5.1.
--
Comment By: Alex Martelli (aleax)
Date: 2007-03-12 09:57
Message:
Logged In: YES
user_id=60314
Originator: NO
and yet, peephole.c does specialcase -0 (with a comment and all!-)
avoiding constant-folding optimization for it -- making things work fine in
Python 2.4.x for high enough x -- it's just that peephole.c's efforts are
defeated by a similar optimization applied without specialcase checking in
ast.c in Python 2.5. This is inconsistent: it makes no sense to take SOME
of the precautions needed to avoid an issue but not ALL of them, since this
makes the issue appear anyway, so those precautions that ARE taken are
there for no purpose (except a miniscule slowdown and enlargement of the
interpreter:-). Either we save those few lines of code in peephole.c or
add the few lines to ast.c that I suggest in my patch 1678668 -- the
current situation makes no sense.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-03-12 04:04
Message:
Logged In: YES
user_id=21627
Originator: NO
I also expressed myself badly. I not only meant that programs should not
rely on +0 and -0 being different things across platforms, but that they
should also not rely on them being either always different or always the
same in a single program. If Python would randomly chose to interpret +0 as
-0, or would do so for every third occurence, I still couldn't see a
problem.
--
Comment By: Alex Martelli (aleax)
Date: 2007-03-11 20:54
Message:
Logged In: YES
user_id=60314
Originator: NO
Oops,sorry, I meant patch 1678668 (copy-and-pasted the wrong ID:-).
Alex
--
Comment By: Alex Martelli (aleax)
Date: 2007-03-11 20:51
Message:
Logged In: YES
user_id=60314
Originator: NO
Also see my patch 1678380 which fixes this bug (and checks for it in a new
unittest).
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-03-11 20:15
Message:
Logged In: YES
user_id=703403
Originator: YES
I expressed myself badly. I apologise. This really isn't about +0. and
-0.
being different, or not. I'm perfectly comfortable with the idea that +0.
and -0. may or may not be distinguishable on any given platform.
The surprise is the other way around: two *identical* calls to atan(0.,
-1.)
(or to repr(0.) for that matter) give *different* results, depending
solely
on whether a -0. literal has appeared earlier on in the code unit being
compiled.
So if the first float zero literal encountered in a source file just
happens to be a
-0. rather than a 0., the meaning of str(0.) later on suddenly becomes
"-0.0"
rather than "0.0". I'd like to be able to rely on str(0.) meaning "0.0"
without
having to worry about whether there might be a -0. literal appearing in
some
faraway and otherwise completely irrelevant portion of the file.
--
[ python-Bugs-1671137 ] slice obj with no start index is 0 instead of None sometimes
Bugs item #1671137, was opened at 2007-02-28 13:58
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671137&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.6
Status: Open
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: Mike Verdone (jyzude)
Assigned to: Nobody/Anonymous (nobody)
Summary: slice obj with no start index is 0 instead of None sometimes
Initial Comment:
Slice objects returned by the slice ":42" return different slice objects
depending on whether the entire slice operation is simple or extended. This bit
of code explains it best:
class SliceBug:
def __getitem__(self, sliceArg):
print sliceArg
s = SliceBug()
s[:42]
s[:42,]
s[:42] produces slice(0, 42, None)
s[:42,] produces (slice(None, 42, None),)
Note that this bug only occurs on classes that do no inherit from object ("old
style" classes). If you change the class to make it inherit from "object" both
slices have None as their start index. Oddly enough in Python 3000 it still
only happens on "old style" classes even though supposedly they are the same as
new style classes. I have also reproduced the bug in Python 2.6, 2.4, 2.3, and
2.2. Seems to be a long standing bug/feature.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-02 14:11
Message:
Logged In: YES
user_id=80475
Originator: NO
Fixing this small inconsistency has very little upside but runs the risk
of breaking code that has been running fine for years. I think we should
punt. If you agree, please close this bug report.
--
Comment By: Mike Verdone (jyzude)
Date: 2007-02-28 14:04
Message:
Logged In: YES
user_id=584997
Originator: YES
Correction! This is fixed in Python 3000. I just have too many windows
open and too many branches checked out.
File Added: slicebug.py
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671137&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1691411 ] Duplicate "preferences" menu item/Tk Aqua 8.4.14
Bugs item #1691411, was opened at 2007-03-30 11:12
Message generated for change (Comment added) made by wordtech
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1691411&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kevin Walzer (wordtech)
Assigned to: Nobody/Anonymous (nobody)
Summary: Duplicate "preferences" menu item/Tk Aqua 8.4.14
Initial Comment:
Version 8.4.14 of Tcl/Tk Aqua (for OS X) hard-codes a "Preferences" item in
the Apple menu. As a result, IDLE now has two "Preferences" items--the active
one that is coded by default, and an inactive item that is hard-coded by Tk.
The way to work around this is to check the version of Tk that is present, in
this fashion:
tkversion=Tkinter.Tk().tk.eval('info patchlevel')
If it is 8.4.14 or greater, then you should bind IDLE's "preferences" dialog to
the hard-coded menu item in Tk (and remove the "preferences" menu entry that
comes with IDLE). It can be done in this fashion:
Tkinter.Tk().createcommand('::tk::mac::ShowPreferences',
IDLEpreferencesfunction) ##substitute the correction function name here
If tkversion <= '8.4.13', leave things as they are.
I have tried to put together a patch for this, but I'm not sure where the
correct place to add this code is. I've looked at Bindings.py and
macosxSupport.py, but it doesn't work as expected (in macosxSupport.py, it
simply ignores the code; in Bindings.py, it removes IDLE's preferences item,
but doesn't activate the hard-coded one). So I'm leaving this to someone with a
greater knowledge of IDLE's internal structure to apply.
--
>Comment By: Kevin Walzer (wordtech)
Date: 2007-04-02 17:17
Message:
Logged In: YES
user_id=794827
Originator: YES
Patch # 1693258 submitted April 2, 2007 to address this problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1691411&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1647541 ] SystemError with re.match(array)
Bugs item #1647541, was opened at 2007-01-29 19:04
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647541&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
>Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 4
Private: No
Submitted By: Armin Rigo (arigo)
Assigned to: Armin Rigo (arigo)
Summary: SystemError with re.match(array)
Initial Comment:
An small issue which I guess is to be found in
the implementation of the buffer interface
for zero-length arrays:
>>> a = array.array("c")
>>> r = re.compile("bla")
>>> r.match(a)
SystemError: error return without exception set
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-02 17:54
Message:
Logged In: YES
user_id=80475
Originator: NO
Fixed in versions 54662 and 54663.
Now returns a buffer of length zero other than NULL.
--
Comment By: Armin Rigo (arigo)
Date: 2007-01-30 08:37
Message:
Logged In: YES
user_id=4771
Originator: YES
It seems to me that an empty array should be
equivalent to an empty string. Accessing it as a
buffer should return a buffer of length 0, not
raise ValueError.
In all cases, the fix in _sre.c is sensible.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-30 00:21
Message:
Logged In: YES
user_id=33168
Originator: NO
Armin, what do you think of the attached patch?
File Added: empty-array.diff
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1647541&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds
Bugs item #1683368, was opened at 2007-03-18 22:32 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-02 18:12 Message: Logged In: YES user_id=80475 Originator: NO FWIW, this change will be somewhat pervasive and will affect anything inheriting object.__init__ including immutable builtins (like tuple, float, and frozenset) as well as user-defined new-style classes that do not define their own __init__ method (perhaps using new instead). Here are the warnings being thrown-off by the current test suite: /py26/Lib/test/test_array.py:731: DeprecationWarning: object.__init__() takes no parameters array.array.__init__(self, 'c', s) /py26/Lib/copy_reg.py:51: DeprecationWarning: object.__init__() takes no parameters base.__init__(obj, state) /py26/Lib/test/test_descr.py:2308: DeprecationWarning: object.__init__() takes no parameters float.__init__(self, value) -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-23 00:01 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54539. The committed version issues warnings rather than errors when both methods are overridden, to avoid too much breakage. The string.py change was necessary to avoid spurious warnings (with no module/lineno!) and breakage of test_subprocess.py. Something fishy's going on -- is string.Template() used by the warnings module or by site.py??? I'm leaving this bug open but changing the category to Py3k so remind me it needs to be merged and then changed there. -- Comment By: Adam Olsen (rhamphoryncus) Date: 2007-03-21 23:46 Message: Logged In: YES user_id=12364 Originator: NO >> I think it would also help if calling a method via super() didn't allow >> positional arguments. > > That's absurd, *except* for __init__(), where it could make sense > depending on the style of cooperation used. But not enough to enforce this > in the language; in Py3k you will be able to enforce this on a per-class > basis. The vast majority of "positional" arguments can also be given via name. The rare exceptions (primarily C functions) may not cooperate well anyway, so you're trading a relatively obscure limitation for better error detection. Perhaps not that important though, since it could be taught as bad style unless absolutely needed. >> Having two mixins with the same method name and >> without a common parent class is just not sane. > > Right. This is a cornerstone of cooperative multiple inheritance that > sometimes seems to be forgotten; there is a big difference between defining > a method and extending a method, and only extending methods can make super > calls. > > The __init__ case is an exception, because there's no requirement that a > subclass have a signature compatible with the superclass (if you don't get > this, read up on constructors in C++ or Java). I understand the desire for it to be an exception, I fail to see how it actually is one. The namespace/signature conflicts exist just the same. The only way I can see to handle incompatible signatures is to add a flag that says "I am the *ONLY* class allowed to subclass X" (triggering an error if violated), have super() entirely bypass it, and then call X.__init__() directly. Even that doesn't handle X's superclasses being subclassed more than once, and it looks pretty complicated/obscure anyway. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-21 23:28 Message: Logged In: YES user_id=6380 Originator: NO > I think
[ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds
Bugs item #1683368, was opened at 2007-03-18 23:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 3000 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-04-02 19:55 Message: Logged In: YES user_id=6380 Originator: NO That's one way of looking at it. You could also say that it found two legitimate problems: - since array doesn't define __init__() there's no point in calling it - similarly, float doesn't define __init__() The copy_reg warning is more subtle, and needs a work-around. I've checked in all three fixes. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-02 19:12 Message: Logged In: YES user_id=80475 Originator: NO FWIW, this change will be somewhat pervasive and will affect anything inheriting object.__init__ including immutable builtins (like tuple, float, and frozenset) as well as user-defined new-style classes that do not define their own __init__ method (perhaps using new instead). Here are the warnings being thrown-off by the current test suite: /py26/Lib/test/test_array.py:731: DeprecationWarning: object.__init__() takes no parameters array.array.__init__(self, 'c', s) /py26/Lib/copy_reg.py:51: DeprecationWarning: object.__init__() takes no parameters base.__init__(obj, state) /py26/Lib/test/test_descr.py:2308: DeprecationWarning: object.__init__() takes no parameters float.__init__(self, value) -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-23 01:01 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54539. The committed version issues warnings rather than errors when both methods are overridden, to avoid too much breakage. The string.py change was necessary to avoid spurious warnings (with no module/lineno!) and breakage of test_subprocess.py. Something fishy's going on -- is string.Template() used by the warnings module or by site.py??? I'm leaving this bug open but changing the category to Py3k so remind me it needs to be merged and then changed there. -- Comment By: Adam Olsen (rhamphoryncus) Date: 2007-03-22 00:46 Message: Logged In: YES user_id=12364 Originator: NO >> I think it would also help if calling a method via super() didn't allow >> positional arguments. > > That's absurd, *except* for __init__(), where it could make sense > depending on the style of cooperation used. But not enough to enforce this > in the language; in Py3k you will be able to enforce this on a per-class > basis. The vast majority of "positional" arguments can also be given via name. The rare exceptions (primarily C functions) may not cooperate well anyway, so you're trading a relatively obscure limitation for better error detection. Perhaps not that important though, since it could be taught as bad style unless absolutely needed. >> Having two mixins with the same method name and >> without a common parent class is just not sane. > > Right. This is a cornerstone of cooperative multiple inheritance that > sometimes seems to be forgotten; there is a big difference between defining > a method and extending a method, and only extending methods can make super > calls. > > The __init__ case is an exception, because there's no requirement that a > subclass have a signature compatible with the superclass (if you don't get > this, read up on constructors in C++ or Java). I understand the desire for it to be an exception, I fail to see how it actually is one. The namespace/signature conflicts exist just the same. The only way I can see to handle incompatible signatures is to
[ python-Bugs-1602378 ] Incorrect docs for bisect_left
Bugs item #1602378, was opened at 2006-11-24 12:07 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1602378&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 4 Private: No Submitted By: Daniel Eloff (eloff) Assigned to: Raymond Hettinger (rhettinger) Summary: Incorrect docs for bisect_left Initial Comment: Quote: Return the index where to insert item x in list a, assuming a is sorted. The return value i is such that all e in a[:i] have e < x, and all e in a[i:] have e >= x. So if x already appears in the list, i points just before the leftmost x already there. The last sentence is incorrect, and it contradicts what comes earlier. Not knowing which is correct, I had to test it in the shell. >>> from bisect import * >>> l = [1,2,3,3,3,4,5] >>> bisect_left(l,3) 2 >>> l[2:] [3, 3, 3, 4, 5] It should be changed to read "i points at the leftmost x already there" -Dan -- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-02 19:02 Message: Logged In: YES user_id=80475 Originator: NO Fixed. See versions 54665 and 64666. -- Comment By: Daniel Eloff (eloff) Date: 2006-12-03 17:39 Message: Logged In: YES user_id=730918 Originator: YES That makes more sense, but if that's explained anywhere it was hidden away where I've never discovered it. I would be in favor of you're suggested fix to the line in question. -Dan -- Comment By: Tim Peters (tim_one) Date: 2006-11-24 14:16 Message: Logged In: YES user_id=31435 Originator: NO The docs are written from the POV that indices in Python point /between/ array elements, which is the easiest way to understand slices, and that there are n+1 non-negative indices that "make obvious sense" in slices of a sequence with n elements: index 0 points "just before" element a[0], and index n "just after" element a[n-1], while for 0 < i < n-1, index i points "just before" element [i] /and/ "just after" element a[i-1]. This is also the sanest way to understand the return value of the bisect functions, which again can return n+1 values given a sequence with n elements. That said, I agree the docs are cryptic if you don't understand that first. I'm not sure this is the best place to explain it. The specific line in question could be "repaired" by saying a[i] is the leftmost x already there, identifying one of the n elements instead of one of the n+1 sequence positions. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1602378&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1382213 ] Tutorial section 9.5.1 ignores MRO for new-style classes
Bugs item #1382213, was opened at 2005-12-16 02:08
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382213&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: GaryD (gazzadee)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Tutorial section 9.5.1 ignores MRO for new-style classes
Initial Comment:
Section 9.5.1 ("Multiple Inheritance") of the tutorial
(as viewed on http://www.python.org/doc/2.4.2/tut/)
discusses the Method Resolution Order (MRO) for classes
with multiple inheritance.
However, the 2nd paragraph incorrectly states that "The
only rule necessary to explain the semantics is the
resolution rule used for class attribute references.
This is depth-first, left-to-right". Whilst this is
true for old-style classes, new-style classes use a
different MRO (as documented elsewhere - eg.
http://www.python.org/2.3/mro.html)
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-02 20:40
Message:
Logged In: YES
user_id=80475
Originator: NO
Fixed. See versions 54667 and 54668.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382213&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1683316 ] select.select() injecting spurious text in stdout
Bugs item #1683316, was opened at 2007-03-18 17:34 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683316&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Peter Williams (peter_ono) Assigned to: Nobody/Anonymous (nobody) Summary: select.select() injecting spurious text in stdout Initial Comment: I'm using a function (see attachment) similar to that described on Page 386 (Section 9.12) of the Python Cookbook (Second Edition) to capture the stdout and stderr streams of programs run with popen2.Popen3. This involves using select.select() to detect the availability of data on the two streams. Sometimes, what looks like a debugging message: "EXCEPTION IN SAFE SELECT 9\n" gets injected into the stdout stream. As far as I can tell this has only started occuring after updating to version 2.4.4. No exception occurs and the string just silently appears in stdout. Apart from the bogus text in stdout everything seems to be working correctly and I'm able to work around the problem by looking for the string and removing whenever it occurs. It looks to me like a debugging message that somebody forgot to remove. -- >Comment By: SourceForge Robot (sf-robot) Date: 2007-04-02 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 02:12 Message: Logged In: YES user_id=849994 Originator: NO I can find no occurrence of the message or parts of it in the current 2.5 or 2.6 branches. Please make sure that it is Python that emits that message. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683316&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
