[ python-Bugs-1446119 ] subprocess interpreted double quotation wrong on windows
Bugs item #1446119, was opened at 2006-03-09 04:26 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446119&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: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: simon (simonhang) >Assigned to: Peter à strand (astrand) Summary: subprocess interpreted double quotation wrong on windows Initial Comment: If we run below python command print subprocess.Popen([r'c:\test.bat', r'test"string:']).pid Actually c:\test.bat test\"string\" is executed. Module subprocess doesn't interpret double quotation mark right. Back slash shouldn't be added. I believe problem is in function subprocess.list2cmdline. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446119&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1446043 ] unicode('foo', '.utf99') does not raise LookupError
Bugs item #1446043, was opened at 2006-03-09 01:55
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&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
Submitted By: osvenskan (osvenskan)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode('foo', '.utf99') does not raise LookupError
Initial Comment:
A very minor inconsistency -- when I call unicode()
with an encoding that Python doesn't know about, it
usually returns a lookup error (e.g LookupError:
unknown encoding: utf99). But when the encoding begins
with a dot (ASCII 0x2e), Python instead gives a
ValueError: Empty module name. It is certainly correct
in raising an error, but it should raise a lookup
error, not a value error.
I've recreated this under Python 2.4.1/FreeBSD 6.0 and
2.3/OS X. See attachment for recreation steps.
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2006-03-09 09:12
Message:
Logged In: YES
user_id=89016
The problem is that after normalizing the encoding name a
module with this name is imported. Maybe
encodings/__init__.py:search_function should do:
if ".".join(filter(None, modname.split("."))) != modname:
return None
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1446043 ] unicode('foo', '.utf99') does not raise LookupError
Bugs item #1446043, was opened at 2006-03-09 00:55
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&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
Submitted By: osvenskan (osvenskan)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode('foo', '.utf99') does not raise LookupError
Initial Comment:
A very minor inconsistency -- when I call unicode()
with an encoding that Python doesn't know about, it
usually returns a lookup error (e.g LookupError:
unknown encoding: utf99). But when the encoding begins
with a dot (ASCII 0x2e), Python instead gives a
ValueError: Empty module name. It is certainly correct
in raising an error, but it should raise a lookup
error, not a value error.
I've recreated this under Python 2.4.1/FreeBSD 6.0 and
2.3/OS X. See attachment for recreation steps.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-09 08:16
Message:
Logged In: YES
user_id=849994
Is it possible for an encoding name to contain dots at all?
If not, this would do too:
if '.' in modname: continue
--
Comment By: Walter Dörwald (doerwalter)
Date: 2006-03-09 08:12
Message:
Logged In: YES
user_id=89016
The problem is that after normalizing the encoding name a
module with this name is imported. Maybe
encodings/__init__.py:search_function should do:
if ".".join(filter(None, modname.split("."))) != modname:
return None
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1443328 ] Pickle protocol 2 fails on private slots.
Bugs item #1443328, was opened at 2006-03-05 04:18 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1443328&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: Open Resolution: None Priority: 5 Submitted By: Daniele Varrazzo (dvarrazzo) >Assigned to: Tim Peters (tim_one) Summary: Pickle protocol 2 fails on private slots. Initial Comment: The pickling protocol 2 can manage new style objects defining __slots__ and without __dict__. Anyway it fails when one of the slots is "private". >>> class C1(object): __slots__ = ["__priv"] def __init__(self): self.__priv = 42 def get_priv(self): return self.__priv >>> C1().get_priv() 42 >>> import pickle >>> pickle.loads(pickle.dumps(C1(), 2)).get_priv() Traceback (most recent call last): File "", line 1, in -toplevel- pickle.loads(pickle.dumps(C1(), 2)).get_priv() File "", line 6, in get_priv return self.__priv AttributeError: _C1__priv of course redefining __getstate__ and __setstate__ bypasses the problem. the cPickle module shows the same issue. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-09 08:21 Message: Logged In: YES user_id=849994 Confirmed with pickle and cPickle here. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1443328&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1442874 ] handling comments with markupbase and HTMLParser
Bugs item #1442874, was opened at 2006-03-04 03:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442874&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: Fixed Priority: 3 Submitted By: Daniel (danielx_) Assigned to: Nobody/Anonymous (nobody) Summary: handling comments with markupbase and HTMLParser Initial Comment: If the following webpage is correct about the definition of a comment, HTMLParser.HTMLParser reports valid (albiet strange) comments as being erroenous: http://www.htmlhelp.com/reference/wilbur/misc/comment.html This site gives '' as an example of a valid html comment. See attachment for what happens at the console. A similar thing happens with other (pathalogical) form of comments. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-09 13:28 Message: Logged In: YES user_id=849994 Updated markupbase to cope with "" in rev. 42938. -- Comment By: Jim Jewett (jimjjewett) Date: 2006-03-06 20:41 Message: Logged In: YES user_id=764593 I recommend this as a wontfix. As the page itself notes, browsers generally got this wrong, and existing webpages rely on this buggy behavior. Even today, Opera is going back and forth on how right they can afford to be without breaking too many pages. The suggestion at the bottom of the page notes that if you keep your comments sane, you won't have problems on your own pages. Realistically, anything not following that rule (no embedded -- or >) is effectively buggy, and HTMLParser can only guess at the real intention. -- Comment By: Daniel (danielx_) Date: 2006-03-04 03:17 Message: Logged In: YES user_id=1383230 Sorry, I'm unfamiliar with the bug reporting system and my attachment doesn't seem to have attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442874&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1446043 ] unicode('foo', '.utf99') does not raise LookupError
Bugs item #1446043, was opened at 2006-03-08 19:55
Message generated for change (Comment added) made by osvenskan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&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
Submitted By: osvenskan (osvenskan)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode('foo', '.utf99') does not raise LookupError
Initial Comment:
A very minor inconsistency -- when I call unicode()
with an encoding that Python doesn't know about, it
usually returns a lookup error (e.g LookupError:
unknown encoding: utf99). But when the encoding begins
with a dot (ASCII 0x2e), Python instead gives a
ValueError: Empty module name. It is certainly correct
in raising an error, but it should raise a lookup
error, not a value error.
I've recreated this under Python 2.4.1/FreeBSD 6.0 and
2.3/OS X. See attachment for recreation steps.
--
>Comment By: osvenskan (osvenskan)
Date: 2006-03-09 10:04
Message:
Logged In: YES
user_id=1119995
There are encoding names that contain dots, such as
ANSI_X3.4-1968, ANSI_X3.4-1986 and ISO_646.IRV:1991 (as
reported by iconv). There are none in iconv's list that
begin with a dot.
Please note that the behavior of this function has been
discussed before in Python bugs 513666 and 960874. Apologies
for not referencing them in my original report.
Having stepped through the code, I understand how the
ValueError is getting generated. My frustration with this as
a programmer is that I want to write specific except clauses
for each possible exception that a method can raise, but
that's impractical if any exception is fair game on any
method. So I'm forced to use a catch-all except clause about
which the Python documentation says (wisely, IMHO), "Use
this with extreme caution, since it is easy to mask a real
programming error in this way!" While it is helpful to
document errors that a method is *likely* to raise, my code
needs to handle all possibilities, not just likely ones.
Perhaps the answer is just, "This is how Python works" and
if I feel it is a weakness in the language I need to take it
up on a different level.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-09 03:16
Message:
Logged In: YES
user_id=849994
Is it possible for an encoding name to contain dots at all?
If not, this would do too:
if '.' in modname: continue
--
Comment By: Walter Dörwald (doerwalter)
Date: 2006-03-09 03:12
Message:
Logged In: YES
user_id=89016
The problem is that after normalizing the encoding name a
module with this name is imported. Maybe
encodings/__init__.py:search_function should do:
if ".".join(filter(None, modname.split("."))) != modname:
return None
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1404859 ] friendly quit object
Feature Requests item #1404859, was opened at 2006-01-13 10:25 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1404859&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: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: friendly quit object Initial Comment: Today, there is no cross-platform way to quit. Today, typing quit returns a message that suggests the interpreter is willfully disobeying you. Instead, change the quit object to one whose __call__ will exit, and whose __str__ says something like """ quit() exits the interpreter, by calling this quit object. """ -- >Comment By: Jim Jewett (jimjjewett) Date: 2006-03-09 11:10 Message: Logged In: YES user_id=764593 This RFE would be answered by applying patch 1446372 -- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-13 10:26 Message: Logged In: YES user_id=764593 Rewording welcome; the point is that it should explain *why* it can't just exit immediately, unless it is explicitly called. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1404859&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1404859 ] friendly quit object
Feature Requests item #1404859, was opened at 2006-01-13 10:25 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1404859&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: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Georg Brandl (gbrandl) Summary: friendly quit object Initial Comment: Today, there is no cross-platform way to quit. Today, typing quit returns a message that suggests the interpreter is willfully disobeying you. Instead, change the quit object to one whose __call__ will exit, and whose __str__ says something like """ quit() exits the interpreter, by calling this quit object. """ -- >Comment By: Jim Jewett (jimjjewett) Date: 2006-03-09 11:11 Message: Logged In: YES user_id=764593 -- Comment By: Jim Jewett (jimjjewett) Date: 2006-03-09 11:10 Message: Logged In: YES user_id=764593 This RFE would be answered by applying patch 1446372 -- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-13 10:26 Message: Logged In: YES user_id=764593 Rewording welcome; the point is that it should explain *why* it can't just exit immediately, unless it is explicitly called. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1404859&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1446619 ] extended slice behavior inconsistent with docs
Bugs item #1446619, was opened at 2006-03-09 10:37
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=1446619&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: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: extended slice behavior inconsistent with docs
Initial Comment:
I don't know whether the behavior or the docs is wrong,
but the extended slice behavior does not match the
documentation. I found three places that talk about
extended slicing:
http://docs.python.org/ref/slicings.html
The semantics for a simple slicing are as follows... It
is not an error if i or j lie outside the range of
valid indexes (such items don't exist so they aren't
selected).
The semantics for an extended slicing are as follows...
http://docs.python.org/ref/types.html
Some sequences also support ``extended slicing'' with a
third ``step'' parameter: a[i:j:k] selects all items of
a with index x where x = i + n*k, n >= 0 and i <= x < j.
http://docs.python.org/lib/typesseq.html
s[i:j:k] slice of s from i to j with step k (3),(5)
...
(3) If i or j is negative, the index is relative to the
end of the string: len(s) + i or len(s) + j is
substituted. But note that -0 is still 0.
(5) The slice of s from i to j with step k is defined
as the sequence of items with index x = i + n*k such
that $0 \leq n < \frac{j-i}{k}$. In other words, the
indices are i, i+k, i+2*k, i+3*k and so on, stopping
when j is reached (but never including j). If i or j is
greater than len(s), use len(s). If i or j are omitted
then they become ``end'' values (which end depends on
the sign of k). Note, k cannot be zero.
Given those docs, consider this behavior:
>>> range(10)[10:0:-2]
[9, 7, 5, 3, 1]
By the Sequence Type Language Reference, [10:0:-2]
selects all items with index x where x = 10 + n*(-2), n
>= 0 and 10 <= x < 0. Since no such values of x exist,
I conclude the result should have been an empty list.
By the Sequence Type Library Reference, [10:0:-2]
selects all items with index x = 10 + n*(-2) such that
0 <= n < (0 - 10)/(-2) = 5. Thus I conclude that I
should get indices [10, 8, 6, 4, 2]. But this is also
wrong -- that would either have given me an IndexError,
if I stick to what's written for extended slicings, or
the list [8, 6, 4, 2] if I assume that the phrase "It
is not an error if i or j lie outside the range of
valid indexes" from the simple slicings section in the
Slicings Language Reference also applies to extended
slicings.
All the references I can find document this behavior
incorrectly. I suggest rewording all the sections to
say something like:
"""
To get the slice of s from i to j with step k, first
determine the bounds. If k is positive, and i or j is
greater than len(s), use len(s). If k is negative, and
i or j is greater than len(s)-1, use len(s)-1. Note, k
cannot be zero. If i or j are omitted then they become
``end'' values (which end depends on the sign of k).
The slice of s from i to j with step k is then defined
as the sequence of items with index x = i + n*k such
that 0 <= n < (j - i)/k. In other words, the indices
are i, i+k, i+2*k, i+3*k and so on, stopping when j is
reached (but never including j).
"""
The most important sentence above is "If k is negative,
and i or j is greater than len(s)-1, use len(s)-1."
Without this sentence, the documentation doesn't match
the behavior. The remainder of the rewording is to
make it clear that the bounds are adjusted *before* the
indices are calculated.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446619&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1446690 ] bug with xmlrpclib
Bugs item #1446690, was opened at 2006-03-09 19:22 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=1446690&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: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: varun bhansaly (varun_bhansaly) Assigned to: Nobody/Anonymous (nobody) Summary: bug with xmlrpclib Initial Comment: I am currently working on a project in which I am required to send some data from OpenOffice.org v2.0.(OOo) I have placed buttons on the spreadsheet, and a python script is to be invoked when the button is clicked. I am required to send the data in the spreadsheet to an app server, hence I am using XML-RPC to get this job done. The version of XML-RPC(xmlrpclib.py) I'm using is v1.36.2.1, The app server requires the connection to be authenticated, whereas the current xmlrpclib.py doesnot come with support for sending requests with basic authentication. In order to extend the capabilities of the xmlrpclib.py with http authentication, I have written code that provides necessary basic authentication.(class BasicAuthTransport in the attached file Project_saveFromOOoCalcAction.py) The actual connection and authentication details have been replaced for security reasons. When the button on the OOo spreadsheet is clicked, the script throws the following error. com.sun.star.uno.RuntimeExceptionexceptions.TypeError: request() got an unexpected keyword argument 'verbose', traceback follows File "usr/lib/python2.4/xmlrpclib.py", in line 1096, in __call__ return self.__send(self.__name,args) File "usr/lib/python2.4/xmlrpclib.py", in line 1383, in __request verbose=self.__verbose When I comment out the line 1383 of the above file, everything runs smoothly, this is a very trivial solution though,as this would require me to comment out the line 1383 of the above file n all the client machines in which the script has to executed. Hence I'm looking for a more viable solution. The files are attached along. Any help or advice in this regard shall be welcome. regards, -VB -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446690&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1404859 ] friendly quit object
Feature Requests item #1404859, was opened at 2006-01-13 15:25 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1404859&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Georg Brandl (gbrandl) Summary: friendly quit object Initial Comment: Today, there is no cross-platform way to quit. Today, typing quit returns a message that suggests the interpreter is willfully disobeying you. Instead, change the quit object to one whose __call__ will exit, and whose __str__ says something like """ quit() exits the interpreter, by calling this quit object. """ -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-09 23:25 Message: Logged In: YES user_id=849994 Patch 1446372 is now applied in rev. 42948. -- Comment By: Jim Jewett (jimjjewett) Date: 2006-03-09 16:11 Message: Logged In: YES user_id=764593 -- Comment By: Jim Jewett (jimjjewett) Date: 2006-03-09 16:10 Message: Logged In: YES user_id=764593 This RFE would be answered by applying patch 1446372 -- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-13 15:26 Message: Logged In: YES user_id=764593 Rewording welcome; the point is that it should explain *why* it can't just exit immediately, unless it is explicitly called. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1404859&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1442493 ] IDLE shell window gets very slow when displaying long lines
Bugs item #1442493, was opened at 2006-03-03 09:45 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442493&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Heiko Selber (drhok) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE shell window gets very slow when displaying long lines Initial Comment: I wrote a little python script that prints a large dictionary to stdout (simply using 'print mydictionary'). In fact, the type is irrelevant, what matters is that the resulting output had approx. 200,000 characters. The shell prints the dictionary into a single line, which causes the window to be almost non-responding, e.g. when I try to scroll the window. Even on a high-end PC it takes a minute or even longer to react to anything. I use Python 2.4.2 on Windows XP SP2. I am aware that it is not exactly wise to print such large objects, but I usually print return values to stdout when I debug a script, and I do not always expect an object to be that large. The average text editor handles such long lines much better. A quick workaround might be to break very long lines automagically (perhaps at around column 1000). PS: I already observed the bug some years ago. I think I even submitted it to python or idlefork a long time ago but I was unable to find it in the buglist. -- >Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-09 18:45 Message: Logged In: YES user_id=593130 I verified this with print 10*'a', also XP (home) sp2. The sluggishness continued after getting the prompt back and trying to do something simple, like 2+2, taking maybe 1/2 minute to print 4 and then the >>> prompt again. The sluggishness *also* continued after restarting the shell (^F6). This indicates that the problem is with the window, not with IDLE. Hope someone can try same on *nix system to see if general with TKinter or specific to Win systems. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442493&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1441408 ] svn head compiler fails to spot extended slicing
Bugs item #1441408, was opened at 2006-03-01 19:20
Message generated for change (Comment added) made by logistix
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441408&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: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Nobody/Anonymous (nobody)
Summary: svn head compiler fails to spot extended slicing
Initial Comment:
This is Python SVN HEAD:
>>> dis.dis(compile("x[::]", '', 'single'))
1 0 LOAD_NAME0 (x)
3 SLICE+0
4 PRINT_EXPR
5 LOAD_CONST 0 (None)
8 RETURN_VALUE
This is Python 2.4:
>>> dis.dis(compile("x[::]", '', 'single'))
1 0 LOAD_NAME0 (x)
3 LOAD_CONST 0 (None)
6 LOAD_CONST 0 (None)
9 LOAD_CONST 0 (None)
12 BUILD_SLICE 3
15 BINARY_SUBSCR
16 PRINT_EXPR
17 LOAD_CONST 0 (None)
20 RETURN_VALUE
--
Comment By: Grant Olson (logistix)
Date: 2006-03-09 18:22
Message:
Logged In: YES
user_id=699438
Patch 1446847 Posted.
--
Comment By: Grant Olson (logistix)
Date: 2006-03-05 17:33
Message:
Logged In: YES
user_id=699438
This only happens when you have implicit slice values.
x[1:2:3] works fine. I'm finishing up a patch and will post
to sf shortly.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441408&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1441486 ] yet another svn head compiler change
Bugs item #1441486, was opened at 2006-03-02 00:39 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441486&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: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: yet another svn head compiler change Initial Comment: This one seems stangely familiar: $ python2.4 Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> -2147483648 -2147483648 >>> $ ~/Source/python/build/python.exe Python 2.5a0 (trunk:42764M, Mar 1 2006, 18:21:57) [GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> -2147483648 -2147483648L -- Comment By: Grant Olson (logistix) Date: 2006-03-09 20:33 Message: Logged In: YES user_id=699438 Patch 1446922 posted. -- Comment By: Grant Olson (logistix) Date: 2006-03-06 17:47 Message: Logged In: YES user_id=699438 It looks like the parser is seeing this as unary minus applied to 2147483648 instead of the literal "-2147483648" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1441486&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1446619 ] extended slice behavior inconsistent with docs
Bugs item #1446619, was opened at 2006-03-09 11:37
Message generated for change (Comment added) made by logistix
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446619&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: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: extended slice behavior inconsistent with docs
Initial Comment:
I don't know whether the behavior or the docs is wrong,
but the extended slice behavior does not match the
documentation. I found three places that talk about
extended slicing:
http://docs.python.org/ref/slicings.html
The semantics for a simple slicing are as follows... It
is not an error if i or j lie outside the range of
valid indexes (such items don't exist so they aren't
selected).
The semantics for an extended slicing are as follows...
http://docs.python.org/ref/types.html
Some sequences also support ``extended slicing'' with a
third ``step'' parameter: a[i:j:k] selects all items of
a with index x where x = i + n*k, n >= 0 and i <= x < j.
http://docs.python.org/lib/typesseq.html
s[i:j:k] slice of s from i to j with step k (3),(5)
...
(3) If i or j is negative, the index is relative to the
end of the string: len(s) + i or len(s) + j is
substituted. But note that -0 is still 0.
(5) The slice of s from i to j with step k is defined
as the sequence of items with index x = i + n*k such
that $0 \leq n < \frac{j-i}{k}$. In other words, the
indices are i, i+k, i+2*k, i+3*k and so on, stopping
when j is reached (but never including j). If i or j is
greater than len(s), use len(s). If i or j are omitted
then they become ``end'' values (which end depends on
the sign of k). Note, k cannot be zero.
Given those docs, consider this behavior:
>>> range(10)[10:0:-2]
[9, 7, 5, 3, 1]
By the Sequence Type Language Reference, [10:0:-2]
selects all items with index x where x = 10 + n*(-2), n
>= 0 and 10 <= x < 0. Since no such values of x exist,
I conclude the result should have been an empty list.
By the Sequence Type Library Reference, [10:0:-2]
selects all items with index x = 10 + n*(-2) such that
0 <= n < (0 - 10)/(-2) = 5. Thus I conclude that I
should get indices [10, 8, 6, 4, 2]. But this is also
wrong -- that would either have given me an IndexError,
if I stick to what's written for extended slicings, or
the list [8, 6, 4, 2] if I assume that the phrase "It
is not an error if i or j lie outside the range of
valid indexes" from the simple slicings section in the
Slicings Language Reference also applies to extended
slicings.
All the references I can find document this behavior
incorrectly. I suggest rewording all the sections to
say something like:
"""
To get the slice of s from i to j with step k, first
determine the bounds. If k is positive, and i or j is
greater than len(s), use len(s). If k is negative, and
i or j is greater than len(s)-1, use len(s)-1. Note, k
cannot be zero. If i or j are omitted then they become
``end'' values (which end depends on the sign of k).
The slice of s from i to j with step k is then defined
as the sequence of items with index x = i + n*k such
that 0 <= n < (j - i)/k. In other words, the indices
are i, i+k, i+2*k, i+3*k and so on, stopping when j is
reached (but never including j).
"""
The most important sentence above is "If k is negative,
and i or j is greater than len(s)-1, use len(s)-1."
Without this sentence, the documentation doesn't match
the behavior. The remainder of the rewording is to
make it clear that the bounds are adjusted *before* the
indices are calculated.
--
Comment By: Grant Olson (logistix)
Date: 2006-03-09 20:42
Message:
Logged In: YES
user_id=699438
One problem in your analysis that range(10) returns the array
[0,1,2,3,4,5,6,7,8,9]
not:
[1,2,3,4,5,6,7,8,9,10]
The 10th element of the array holds the value 9. so when x
= 10 + (0*-2), you get 10. Then:
[0,1,2,3,4,5,6,7,8,9][10]
will return 9
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446619&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1446619 ] extended slice behavior inconsistent with docs
Bugs item #1446619, was opened at 2006-03-09 10:37
Message generated for change (Comment added) made by bediviere
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446619&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: None
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: extended slice behavior inconsistent with docs
Initial Comment:
I don't know whether the behavior or the docs is wrong,
but the extended slice behavior does not match the
documentation. I found three places that talk about
extended slicing:
http://docs.python.org/ref/slicings.html
The semantics for a simple slicing are as follows... It
is not an error if i or j lie outside the range of
valid indexes (such items don't exist so they aren't
selected).
The semantics for an extended slicing are as follows...
http://docs.python.org/ref/types.html
Some sequences also support ``extended slicing'' with a
third ``step'' parameter: a[i:j:k] selects all items of
a with index x where x = i + n*k, n >= 0 and i <= x < j.
http://docs.python.org/lib/typesseq.html
s[i:j:k] slice of s from i to j with step k (3),(5)
...
(3) If i or j is negative, the index is relative to the
end of the string: len(s) + i or len(s) + j is
substituted. But note that -0 is still 0.
(5) The slice of s from i to j with step k is defined
as the sequence of items with index x = i + n*k such
that $0 \leq n < \frac{j-i}{k}$. In other words, the
indices are i, i+k, i+2*k, i+3*k and so on, stopping
when j is reached (but never including j). If i or j is
greater than len(s), use len(s). If i or j are omitted
then they become ``end'' values (which end depends on
the sign of k). Note, k cannot be zero.
Given those docs, consider this behavior:
>>> range(10)[10:0:-2]
[9, 7, 5, 3, 1]
By the Sequence Type Language Reference, [10:0:-2]
selects all items with index x where x = 10 + n*(-2), n
>= 0 and 10 <= x < 0. Since no such values of x exist,
I conclude the result should have been an empty list.
By the Sequence Type Library Reference, [10:0:-2]
selects all items with index x = 10 + n*(-2) such that
0 <= n < (0 - 10)/(-2) = 5. Thus I conclude that I
should get indices [10, 8, 6, 4, 2]. But this is also
wrong -- that would either have given me an IndexError,
if I stick to what's written for extended slicings, or
the list [8, 6, 4, 2] if I assume that the phrase "It
is not an error if i or j lie outside the range of
valid indexes" from the simple slicings section in the
Slicings Language Reference also applies to extended
slicings.
All the references I can find document this behavior
incorrectly. I suggest rewording all the sections to
say something like:
"""
To get the slice of s from i to j with step k, first
determine the bounds. If k is positive, and i or j is
greater than len(s), use len(s). If k is negative, and
i or j is greater than len(s)-1, use len(s)-1. Note, k
cannot be zero. If i or j are omitted then they become
``end'' values (which end depends on the sign of k).
The slice of s from i to j with step k is then defined
as the sequence of items with index x = i + n*k such
that 0 <= n < (j - i)/k. In other words, the indices
are i, i+k, i+2*k, i+3*k and so on, stopping when j is
reached (but never including j).
"""
The most important sentence above is "If k is negative,
and i or j is greater than len(s)-1, use len(s)-1."
Without this sentence, the documentation doesn't match
the behavior. The remainder of the rewording is to
make it clear that the bounds are adjusted *before* the
indices are calculated.
--
>Comment By: Steven Bethard (bediviere)
Date: 2006-03-09 20:42
Message:
Logged In: YES
user_id=945502
logistix wrote:
> [0,1,2,3,4,5,6,7,8,9][10]
> will return 9
Huh? Python indexing starts from 0. Hence:
>>> range(10)[10]
Traceback (most recent call last):
File "", line 1, in ?
IndexError: list index out of range
>>> [0,1,2,3,4,5,6,7,8,9][10]
Traceback (most recent call last):
File "", line 1, in ?
IndexError: list index out of range
If I didn't understand your complaint, please explain it again.
--
Comment By: Grant Olson (logistix)
Date: 2006-03-09 19:42
Message:
Logged In: YES
user_id=699438
One problem in your analysis that range(10) returns the array
[0,1,2,3,4,5,6,7,8,9]
not:
[1,2,3,4,5,6,7,8,9,10]
The 10th element of the array holds the value 9. so when x
= 10 + (0*-2), you get 10. Then:
[0,1,2,3,4,5,6,7,8,9][10]
will return 9
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446619&group_i
[ python-Bugs-1445210 ] embedding Python causes memory leaks
Bugs item #1445210, was opened at 2006-03-08 10:20
Message generated for change (Comment added) made by andykt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1445210&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: None
Priority: 5
Submitted By: Andrew Trevorrow (andykt)
Assigned to: Nobody/Anonymous (nobody)
Summary: embedding Python causes memory leaks
Initial Comment:
[This bug has been submitted by others but for some reason it
has been marked Closed. I consider it to be an extremely serious
bug -- if I can't solve it I'm going to have to abandon Python as
my app's scripting language, even though I've fallen in love!]
I've added Python script support to my cross-platfom wxWidgets app
so that users can run .py scripts from within the app to automate the
GUI and do other fancy things. It all works very nicely, except for
one nasty problem: *every* time a script is run there is a memory leak,
usually small (about 10K) but sometimes massive (about 4MB in the
case of one rather complicated script).
The problem occurs on both Mac OS 10.3.9 and Windows 2000.
I'm using Python 2.3 on the Mac and 2.4.2 on Windows.
Every time the user runs a script, my app makes these calls:
(I've removed a lot of irrelevant stuff.)
Py_Initialize();
PyRun_SimpleString("execfile('foo.py')");
Py_Finalize();
It's definitely not a wxWidgets problem. In fact it's quite easy to
see the memory leak using a simple command-line program:
#include
#include
main(int argc, char *argv[])
{
int i;
for (i=0; i<1000; i++) {
Py_Initialize();
Py_Finalize();
printf(".");
if ((i+1) % 50 == 0) printf("\n");
}
}
Note that it doesn't even execute a script. If I run this program on
my Mac and watch its memory usage with Activity Monitor, I see a leak
of about 10K each time through the loop. Similar result on Windows.
Curiously, on both machines, the Py_Finalize() call takes longer and
longer to complete whatever it's doing. The above program takes a
few *minutes* to complete on my 400MHz Mac.
Andrew
--
>Comment By: Andrew Trevorrow (andykt)
Date: 2006-03-10 16:43
Message:
Logged In: YES
user_id=1281947
See http://evanjones.ca/python-memory.html for some
useful info. Apparently the Python memory allocator never
releases memory back to the OS! So if a complicated script
happens to consume 100MB of interpreter memory then
that amount is no longer available to the app in which
Python is embedded. Even worse, if a script has a
(Python) memory leak then there's nothing the app can
do about it. It would be great if wrapping each script
inside Py_Initialize/Py_Finalize could avoid all that.
There should be some way to tell Python "release all
the memory you've ever allocated and start again
with a clean slate".
--
Comment By: Andrew Trevorrow (andykt)
Date: 2006-03-08 20:50
Message:
Logged In: YES
user_id=1281947
Bloody hell -- sorry for the bad line breaks.
One day I'll figure out how to use sf properly!
--
Comment By: Andrew Trevorrow (andykt)
Date: 2006-03-08 20:46
Message:
Logged In: YES
user_id=1281947
> Why do you call Py_Initialize/Py_Finalize more than once?
How else do I tell Python to free up memory after each PyRun_SimpleString
call?
I want users to be able to run scripts many times from within my app.
If I just keep calling PyRun_SimpleString then my app will leak more and
more memory until it becomes unusable.
>From http://docs.python.org/api/embedding.html:
Sometimes, it is desirable to ``uninitialize'' Python. For instance, the
application may want to start over (make another call to Py_Initialize())
or the application is simply done with its use of Python and wants to free
all memory allocated by Python. This can be accomplished by calling
Py_Finalize().
That's exactly what I want to do. I want the interpreter to run a script
and then release all the resources used by that script. Unfortunately,
Py_Finalize does *not* restore memory usage to what it was before the
Py_Initialize call. I wouldn't mind if there was a one-off allocation
cost (the 1st time Py_Initialize is called), but my app is leaking more
memory *every* time a script is run!
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-03-08 19:32
Message:
Logged In: YES
user_id=33168
Why do you call Py_Initialize/Py_Finalize more than once?
Why not do something like this (I'm kinda mixing C and
Python for convenience):
/* startup */
Py_Initialize();
/* do whatever */
whil
[ python-Bugs-1447031 ] whatsnew 2.5: pep 353, python -m
Bugs item #1447031, was opened at 2006-03-09 23:44 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=1447031&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: None Status: Open Resolution: None Priority: 5 Submitted By: Gene Tani (gtani) Assigned to: Nobody/Anonymous (nobody) Summary: whatsnew 2.5: pep 353, python -m Initial Comment: http://docs.python.org/dev/whatsnew/whatsnew25.html I don't see mention of PEP 353 (indexing with ssize_t) or the python -m switch, as per: http://agiletesting.blogspot.com/2006/02/pycon-notes-part-2-guidos-keynote.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1447031&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
