[ python-Bugs-489256 ] Lib/profile.doc should be updated
Bugs item #489256, was opened at 2001-12-05 06:51 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: Lib/profile.doc should be updated Initial Comment: What's Lib/profile.doc doing there? Is it still needed? Why is it in Lib, anyway? (it seems very old - is it still up to date after all the hackery? doesn't seem so) -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-10 10:07 Message: Logged In: YES user_id=469548 I just checked and there was no information in profile.doc that wasn't in the library reference, so I've removed it now. I've also replaced help() along the lines of what you suggested. Just one more question: could we remove the "How Is This Profiler Different From The Old Profiler?" subsection from the library reference? It's hardly relevant, considering that the Old Profiler was last seen in Python 1.1 (!). -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-10 04:07 Message: Logged In: YES user_id=3066 Removing profile.doc sounds fine to me. The only thing that really needs to be done prior to removal is to make sure all the (still current) information in profile.doc is represented in the library documentation. The help() function should probably be replaced with something that refers the user to the library documentation, rather than removing the function. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 02:27 Message: Logged In: YES user_id=469548 I would like to go ahead with removing profile.doc and the help() function from profile.py for Python 2.5. They're not really all that helpful, they're in an unexpected place, and they're undocumented. I'll remove them if there are no objections within some weeks. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 07:08 Message: Logged In: YES user_id=3066 profile.doc is used as the help file for profile.py, and is read by an external pager (sloppily) using the profile.help() function. Either the document should be updated and the help() function should be more intelligent about the pager, or... ...the document and the help() function should be removed. This is a possibility since help() is not documented. profile.doc should be updated for Python 2.2; other changes will need to wait for Python 2.3. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1099324 ] Optik OptionParse important undocumented option
Bugs item #1099324, was opened at 2005-01-10 04:17 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=1099324&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ncouture (nicolas_couture) Assigned to: Nobody/Anonymous (nobody) Summary: Optik OptionParse important undocumented option Initial Comment: the add_help_option variable is undocumented in Python's Library Reference, tho it can be figured by reading the optparse module, I think it would be usefull to document it on http://docs.python.org/lib/optparse-generating-help.html. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099324&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1097597 ] SimpleHTTPServer sends wrong Content-Length header
Bugs item #1097597, was opened at 2005-01-07 03:34
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097597&group_id=5470
>Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David Schachter (razmatazz)
>Assigned to: Johannes Gijsbers (jlgijsbers)
Summary: SimpleHTTPServer sends wrong Content-Length header
Initial Comment:
On Microsoft Windows, text files use \r\n for newline.
The SimpleHTTPServer class's "send_head()" method opens
files with "r" or "rb" mode depending on the MIME type.
Files opened in "r" mode will have \r\n -> \n
translation performed automatically, so the stream of
bytes sent to the client will be smaller than the size
of the file on disk.
Unfortunately, the send_head() method sets the
Content-Length header using the file size on disk,
without compensating for the \r\n -> \n translation.
I remedied this on my copy thusly:
if mode == "r":
content = f.read()
contentLength = str(len(content))
f.seek(0)
else:
contentLength = str(os.fstat(f.fileno())[6])
self.send_header("Content-Length", contentLength)
This may not be as inefficient as it seems: the entire
file was going to be read in anyway for the newline
translation.
Hmmm. The code could be slightly simpler:
if mode == "r":
contentLength = len(f.read())
f.seek(0)
else:
contentLength = os.fstat(f.fileno())[6]
self.send_header("Content-Length",
str(contentLength))
The documentation for SimpleHTTPServer in Python 2.3.4
for Windows says:
A 'Content-type:' with the guessed content type is
output, and then a blank line, signifying end of
headers, and then the contents of the file. The file
is always opened in binary mode.
Actually, after Content-type, the Content-Length header
is sent.
It would probably be nice if "Content-Length" was
"Content-length" or if "Content-type" was
"Content-Type", for consistency. The latter is probably
best, per RFC 2016.
By the way, clients weren't caching the files I sent. I
added another line after the Content-Length handling:
self.send_header("Expires", "Fri, 31 Dec 2100
12:00:00 GMT")
This is egregiously wrong in the general case and just
fine in my case.
--
>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-01-10 10:29
Message:
Logged In: YES
user_id=469548
Okay, fixed on maint24 and HEAD by applying patch 839496.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-01-10 01:49
Message:
Logged In: YES
user_id=129426
http://sourceforge.net/support/tracker.php?aid=839496 is a
better url because it has been moved.
I've added a comment to my patch, because I'm now quite sure
it is good after all.
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-01-09 18:18
Message:
Logged In: YES
user_id=469548
http://python.org/sf/839496 has a patch for this, but the
submitter isn't sure whetther it's correct. Maybe one of you
could take a look at it?
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-01-09 10:26
Message:
Logged In: YES
user_id=341410
Would it be wrong to open all files with a mode of 'rb',
regardless of file type?
While I don't know MIME embeddings all that well, I do have
experience with email and that most codecs that use MIME
embeddings (like base 64, 85, 95, etc.) are \r, \n and \r\n
agnostic..
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097597&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1099363 ] refman doesn't know about universal newlines
Bugs item #1099363, was opened at 2005-01-10 11:33 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=1099363&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: refman doesn't know about universal newlines Initial Comment: The reference manual (in ref/ref2.tex) still talks about the various different end-of-line conventions, but as Python reads source code with universal newlines this is no longer relevant. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099363&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1099364 ] raw_input() displays wrong unicode prompt
Bugs item #1099364, was opened at 2005-01-10 11:33
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=1099364&group_id=5470
Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Petr Prikryl (prikryl)
Assigned to: Nobody/Anonymous (nobody)
Summary: raw_input() displays wrong unicode prompt
Initial Comment:
I have observed a problem when running
Python 2.4, Windows version (python-2.4.msi)
and using raw_input() with unicode prompt
string in a console program (ran in the DOS window).
I do use the following sitecustomize.py file to set
the default encoding in the English Windows 2000 Server:
sitecustomize.py
=
import sys
sys.setdefaultencoding('cp1250')
=
test.py
=
# -*- coding: cp1250 -*-
s = u'string with accented letters (different than this)'
print s# OK
val = raw_input(s)# s displayed differently (wrong)
=
See the test.png
(captured from screen) and the test.py for the
used string -- inside the attached zip file.
The "type test.py" (result visible on the captured
screen) displays the string
definition also wrongly, because the DOS window
uses different encoding than cp1250. The print
command prints the string correctly, converting
the internal unicode string to the encoding that
the is defined by the output environment. However,
the raw_input() probably does convert the unicode
string to the cp1250 and does not do the same
(more clever) thing that the print does.
I did not use the unicode in older Python (2.3.4),
so I do not know what was the behaviour earlier.
Could you confirm the bug? Sorry if the bug
is well known.
Petr
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099364&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1098990 ] codec readline() splits lines apart
Bugs item #1098990, was opened at 2005-01-09 17:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098990&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: codec readline() splits lines apart Initial Comment: It seems that the fix for bug 1076985 (Incorrect behaviour of StreamReader.readline leads to crash) has introduced a new bug. using current cvs Python on Linux, I observe faulty behavior of the readline() method on file-like objects returned from the codecs module. See the attached example.txt. The readline() breaks certain lines in half. It only happens when a certain encoding is used, so regular file objects behave as expected. Also, readlines() works fine. -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-01-10 12:15 Message: Logged In: YES user_id=89016 The problem is that the first readline() reads more than the first line, returns the first line and puts back the rest for the next read. The next call to readline() discovers that there is already data there and doesn't call read() again. I'm working on a patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098990&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1098990 ] codec readline() splits lines apart
Bugs item #1098990, was opened at 2005-01-09 17:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098990&group_id=5470 Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: codec readline() splits lines apart Initial Comment: It seems that the fix for bug 1076985 (Incorrect behaviour of StreamReader.readline leads to crash) has introduced a new bug. using current cvs Python on Linux, I observe faulty behavior of the readline() method on file-like objects returned from the codecs module. See the attached example.txt. The readline() breaks certain lines in half. It only happens when a certain encoding is used, so regular file objects behave as expected. Also, readlines() works fine. -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-01-10 13:26 Message: Logged In: YES user_id=89016 Checked in as: Lib/codecs.py 1.37 Lib/test/test_codecs.py 1.18 Lib/codecs.py 1.35.2.2 Lib/test/test_codecs.py 1.15.2.2 Thanks for the report! -- Comment By: Walter Dörwald (doerwalter) Date: 2005-01-10 12:15 Message: Logged In: YES user_id=89016 The problem is that the first readline() reads more than the first line, returns the first line and puts back the rest for the next read. The next call to readline() discovers that there is already data there and doesn't call read() again. I'm working on a patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098990&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1099324 ] Optik OptionParse important undocumented option
Bugs item #1099324, was opened at 2005-01-10 04:17 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099324&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ncouture (nicolas_couture) >Assigned to: Greg Ward (gward) Summary: Optik OptionParse important undocumented option Initial Comment: the add_help_option variable is undocumented in Python's Library Reference, tho it can be figured by reading the optparse module, I think it would be usefull to document it on http://docs.python.org/lib/optparse-generating-help.html. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099324&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1095821 ] The doc for DictProxy is missing
Bugs item #1095821, was opened at 2005-01-04 10:42 Message generated for change (Comment added) made by greg_ball You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095821&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: The doc for DictProxy is missing Initial Comment: The types module has an entry for DictProxy. I am unable to find any documentation. -- Comment By: Gregory H. Ball (greg_ball) Date: 2005-01-10 07:32 Message: Logged In: YES user_id=11365 Currently the library reference contains minimal information on internal objects; here's the entire text of the relevant section: """ 2.3.10.10 Internal Objects See the Python Reference Manual for this information. It describes stack frame objects, traceback objects, and slice objects. """ Perhaps cell and dictproxy types should be added to the language reference manual. On the other hand, it isn't clear to me that absolute completeness is desirable. Any language or application has some undocumented features; the fact that they are not documented is a signal to the user that their use is not supported and they may go away without warning in future versions. -- Comment By: Colin J. Williams (cjwhrh) Date: 2005-01-09 21:09 Message: Logged In: YES user_id=285587 I suggest that it would be better to indicate the purpose and usage of both CellType in the Library Reference. If one is to keep it under the pillow, it should be complete and uptodate. Colin W. -- Comment By: Gregory H. Ball (greg_ball) Date: 2005-01-09 11:48 Message: Logged In: YES user_id=11365 DictProxy is an implementation detail, perhaps it should have been left out of types. I notice there is no CellType in there. (you can obtain this type like so:) >>> type((lambda x: lambda: x)(1).func_closure[0]) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095821&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1099516 ] tempfile files not types.FileType
Bugs item #1099516, was opened at 2005-01-10 16:29 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=1099516&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Frans van Nieuwenhoven (vannieuwenhoven) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile files not types.FileType Initial Comment: a temporary file created with the tempfile module is not recognized as a types.FileType testcase: import types import tempfile # this will return False (I think it should return True) isinstance(tempfile.TemporaryFile(), types.FileType) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099516&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1099324 ] Optik OptionParse important undocumented option
Bugs item #1099324, was opened at 2005-01-10 10:17 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099324&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ncouture (nicolas_couture) Assigned to: Greg Ward (gward) Summary: Optik OptionParse important undocumented option Initial Comment: the add_help_option variable is undocumented in Python's Library Reference, tho it can be figured by reading the optparse module, I think it would be usefull to document it on http://docs.python.org/lib/optparse-generating-help.html. -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-10 21:57 Message: Logged In: YES user_id=469548 This should probably be addressed by fixing http://python.org/sf/993601. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099324&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1099746 ] copy.deepcopy barfs when copying a class derived from dict
Bugs item #1099746, was opened at 2005-01-10 21:28
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=1099746&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Doug Winter (winjer)
Assigned to: Nobody/Anonymous (nobody)
Summary: copy.deepcopy barfs when copying a class derived from dict
Initial Comment:
I've got a class:
class odict(dict):
def __init__(self, d={}):
self._keys = d.keys()
dict.__init__(self, d)
def __setitem__(self, key, item):
dict.__setitem__(self, key, item)
if key not in self._keys:
self._keys.append(key)
...
When I copy.deepcopy one of these it blows up in
__setitem__ with an AttributeError on _keys, because
__setitem__ is called without __init__ ever having been
called. Presumably this thing looks and smells like a
dictionary, so deepcopy thinks it is one.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1099746&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1098985 ] set objects cannot be marshalled
Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) >Assigned to: Guido van Rossum (gvanrossum) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 19:17 Message: Logged In: YES user_id=80475 Guido, what to you think about the OP's request? The need does not arise for pyc files and pickling takes care of general persistance needs. Is there something to be gained? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1098985 ] set objects cannot be marshalled
Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 Category: Python Library >Group: Python 2.5 Status: Open Resolution: None >Priority: 4 Submitted By: Gregory H. Ball (greg_ball) >Assigned to: Raymond Hettinger (rhettinger) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-01-10 19:25 Message: Logged In: YES user_id=6380 As the OP says, it would be nice. Let's see if he or someone else wants it bad enough to submit a patch. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 19:17 Message: Logged In: YES user_id=80475 Guido, what to you think about the OP's request? The need does not arise for pyc files and pickling takes care of general persistance needs. Is there something to be gained? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-809254 ] imp.find_module doesn't work in /tmp
Bugs item #809254, was opened at 2003-09-19 13:44
Message generated for change (Comment added) made by vng1
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809254&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Victor T. Ng (vng1)
Assigned to: Nobody/Anonymous (nobody)
Summary: imp.find_module doesn't work in /tmp
Initial Comment:
I'm running OSX 10.2.6 and the imp module seems to
have a parsing error when I pass it the directory "/"
bash$ cd /tmp
bash$ touch __init__.py
bash$ python
Python 2.3 (#2, Jul 30 2003, 11:45:28)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or
"license" for more
information.
>>> import imp
>>> imp.find_module("tmp",['/'])
Traceback (most recent call last):
File "", line 1, in ?
ImportError: No module named tmp
>>> imp.find_module("tmp",['//'])
(None, '//tmp', ('', '', 5))
I'm not sure why, but I seem to need a double slash in the
directory name.
--
>Comment By: Victor T. Ng (vng1)
Date: 2005-01-11 00:29
Message:
Logged In: YES
user_id=679596
lima:~ buildbox$ cd /tmp
lima:/tmp buildbox$ touch __init__.py
lima:/tmp buildbox$ python
Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> import imp
>>> imp.find_module("tmp", ['/'])
Traceback (most recent call last):
File "", line 1, in ?
ImportError: No module named tmp
>>>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809254&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-809254 ] imp.find_module doesn't work in /tmp
Bugs item #809254, was opened at 2003-09-19 13:44
Message generated for change (Comment added) made by vng1
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809254&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Victor T. Ng (vng1)
Assigned to: Nobody/Anonymous (nobody)
Summary: imp.find_module doesn't work in /tmp
Initial Comment:
I'm running OSX 10.2.6 and the imp module seems to
have a parsing error when I pass it the directory "/"
bash$ cd /tmp
bash$ touch __init__.py
bash$ python
Python 2.3 (#2, Jul 30 2003, 11:45:28)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or
"license" for more
information.
>>> import imp
>>> imp.find_module("tmp",['/'])
Traceback (most recent call last):
File "", line 1, in ?
ImportError: No module named tmp
>>> imp.find_module("tmp",['//'])
(None, '//tmp', ('', '', 5))
I'm not sure why, but I seem to need a double slash in the
directory name.
--
>Comment By: Victor T. Ng (vng1)
Date: 2005-01-11 00:31
Message:
Logged In: YES
user_id=679596
Affects both Python 2.3 and Python 2.4 on OSX:
Python 2.4 (#1, Dec 25 2004, 15:45:34)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> import imp
>>> imp.find_module('tmp', ['/'])
Traceback (most recent call last):
File "", line 1, in ?
ImportError: No module named tmp
>>>
--
Comment By: Victor T. Ng (vng1)
Date: 2005-01-11 00:29
Message:
Logged In: YES
user_id=679596
lima:~ buildbox$ cd /tmp
lima:/tmp buildbox$ touch __init__.py
lima:/tmp buildbox$ python
Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> import imp
>>> imp.find_module("tmp", ['/'])
Traceback (most recent call last):
File "", line 1, in ?
ImportError: No module named tmp
>>>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809254&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-809254 ] imp.find_module doesn't work in /tmp
Bugs item #809254, was opened at 2003-09-19 13:44
Message generated for change (Comment added) made by vng1
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809254&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Victor T. Ng (vng1)
Assigned to: Nobody/Anonymous (nobody)
Summary: imp.find_module doesn't work in /tmp
Initial Comment:
I'm running OSX 10.2.6 and the imp module seems to
have a parsing error when I pass it the directory "/"
bash$ cd /tmp
bash$ touch __init__.py
bash$ python
Python 2.3 (#2, Jul 30 2003, 11:45:28)
[GCC 3.1 20020420 (prerelease)] on darwin
Type "help", "copyright", "credits" or
"license" for more
information.
>>> import imp
>>> imp.find_module("tmp",['/'])
Traceback (most recent call last):
File "", line 1, in ?
ImportError: No module named tmp
>>> imp.find_module("tmp",['//'])
(None, '//tmp', ('', '', 5))
I'm not sure why, but I seem to need a double slash in the
directory name.
--
>Comment By: Victor T. Ng (vng1)
Date: 2005-01-11 00:32
Message:
Logged In: YES
user_id=679596
No problems under Python 2.4 on Linux:
Python 2.4 (#3, Dec 29 2004, 10:03:34)
[GCC 3.3.4 (Debian 1:3.3.4-13)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import imp
>>> imp.find_module('tmp',['/'])
(None, '/tmp', ('', '', 5))
>>>
--
Comment By: Victor T. Ng (vng1)
Date: 2005-01-11 00:31
Message:
Logged In: YES
user_id=679596
Affects both Python 2.3 and Python 2.4 on OSX:
Python 2.4 (#1, Dec 25 2004, 15:45:34)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> import imp
>>> imp.find_module('tmp', ['/'])
Traceback (most recent call last):
File "", line 1, in ?
ImportError: No module named tmp
>>>
--
Comment By: Victor T. Ng (vng1)
Date: 2005-01-11 00:29
Message:
Logged In: YES
user_id=679596
lima:~ buildbox$ cd /tmp
lima:/tmp buildbox$ touch __init__.py
lima:/tmp buildbox$ python
Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> import imp
>>> imp.find_module("tmp", ['/'])
Traceback (most recent call last):
File "", line 1, in ?
ImportError: No module named tmp
>>>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809254&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1098985 ] set objects cannot be marshalled
Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 4 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Raymond Hettinger (rhettinger) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. -- >Comment By: Tim Peters (tim_one) Date: 2005-01-10 20:51 Message: Logged In: YES user_id=31435 Just noting that some people prefer to use marshal instead of pickle because unmarshaling can't end up executing arbitrary user-defined code (but unpickling can, via arbitrary module importing and arbitrary construction of objects of user- defined classes). That's really not one of marshal's goals, though, so "would be nice" is as strong as it gets. -- Comment By: Guido van Rossum (gvanrossum) Date: 2005-01-10 19:25 Message: Logged In: YES user_id=6380 As the OP says, it would be nice. Let's see if he or someone else wants it bad enough to submit a patch. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 19:17 Message: Logged In: YES user_id=80475 Guido, what to you think about the OP's request? The need does not arise for pyc files and pickling takes care of general persistance needs. Is there something to be gained? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1098985 ] set objects cannot be marshalled
Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 4 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Raymond Hettinger (rhettinger) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 22:03 Message: Logged In: YES user_id=80475 Then let things be nice for all. See Python marshal.c 1.81. -- Comment By: Tim Peters (tim_one) Date: 2005-01-10 20:51 Message: Logged In: YES user_id=31435 Just noting that some people prefer to use marshal instead of pickle because unmarshaling can't end up executing arbitrary user-defined code (but unpickling can, via arbitrary module importing and arbitrary construction of objects of user- defined classes). That's really not one of marshal's goals, though, so "would be nice" is as strong as it gets. -- Comment By: Guido van Rossum (gvanrossum) Date: 2005-01-10 19:25 Message: Logged In: YES user_id=6380 As the OP says, it would be nice. Let's see if he or someone else wants it bad enough to submit a patch. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 19:17 Message: Logged In: YES user_id=80475 Guido, what to you think about the OP's request? The need does not arise for pyc files and pickling takes care of general persistance needs. Is there something to be gained? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-645594 ] for lin in file: file.tell() tells wrong
Bugs item #645594, was opened at 2002-11-29 06:13
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645594&group_id=5470
Category: Documentation
Group: Python 2.2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Dmitry Vasiliev (hdima)
Assigned to: Nobody/Anonymous (nobody)
Summary: for lin in file: file.tell() tells wrong
Initial Comment:
Consider following piece of code:
f = file("test.txt", "rb")
pos = f.tell()
for line in f:
print "%u: '%s'" % (pos, line)
pos = f.tell()
During the code execution we have following result:
0 'Line 1'
63 'Line 2'
63 'Line 3'
...
63 'Line 9'
However, following piece of code works fine:
f = file("test.txt", "rb")
while True:
pos = f.tell()
line = f.readline()
if line == "":
break
print "%u: '%s'" % (pos, line)
It prints:
0 'Line 1'
7 'Line 2'
14 'Line 3'
...
56 'Line 9'
It seems a file iterator makes file.tell() to tell
positions of some internal blocks used by the iterator.
--
>Comment By: Facundo Batista (facundobatista)
Date: 2005-01-11 00:15
Message:
Logged In: YES
user_id=752496
Closing it, check bug 1036626 for rationale.
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-11-07 16:29
Message:
Logged In: YES
user_id=469548
Closed accoding to rationale in #1036626.
--
Comment By: Brett Cannon (bcannon)
Date: 2003-05-22 01:09
Message:
Logged In: YES
user_id=357491
As suggested by Just and Dimtry I am reclassifying this as a doc bug.
--
Comment By: Dmitry Vasiliev (hdima)
Date: 2003-01-08 07:17
Message:
Logged In: YES
user_id=388573
I agree. Unfortunately a small patch doesn't work here. :-(
But I suggest to recategorize it as a documentation bug.
--
Comment By: Just van Rossum (jvr)
Date: 2003-01-05 18:25
Message:
Logged In: YES
user_id=92689
This bug is very similar to #524804, which was closed as
"won't fix". Unless it's recategorized as a documentation
bug, I suggest to close this one as a duplicate.
--
Comment By: Dmitry Vasiliev (hdima)
Date: 2002-12-04 08:24
Message:
Logged In: YES
user_id=388573
File.next() uses readahead buffer (8192 bytes for now).
Calling file.seek() drops the buffer, but other operations
don't. I think it's possible for file.tell() to return right
result (I'll try to make a patch). But all these quirks
should be documented.
--
Comment By: Jack Jansen (jackjansen)
Date: 2002-11-29 19:07
Message:
Logged In: YES
user_id=45365
Actually, all file operations behave the same (well, all: I tried one:
readline():-): they behave as if the whole file has been read. I.e.
file.readline() within a "for line in file" will return an empty
string.
If a file iterator behaves as if it has read the complete file at once on
instantiation (never mind what it actually does: if it *behaves* as if this
happens) I think this should just be documented and that's it.
--
Comment By: Tim Peters (tim_one)
Date: 2002-11-29 13:57
Message:
Logged In: YES
user_id=31435
Possibly. Maybe something fancier could be done too, to
give "expected" results. although I don't know how to
approach that on Windows for text-mode files (byte
arithmetic on seek/tell results doesn't work at all for
those). I'd take it to Python-Dev.
--
Comment By: Martin v. Löwis (loewis)
Date: 2002-11-29 13:01
Message:
Logged In: YES
user_id=21627
Shouldn't tell raise an exception then?
--
Comment By: Tim Peters (tim_one)
Date: 2002-11-29 12:42
Message:
Logged In: YES
user_id=31435
"for x in file" does do its own chunking under the covers, for
speed, and seek() and tell() are indeed not to be used on a
file being iterated over in this way.
--
Comment By: Dmitry Vasiliev (hdima)
Date: 2002-11-29 11:46
Message:
Logged In: YES
user_id=388573
I'll try to dig in.
--
Comment By: Martin v. Löwis (loewis)
Date: 2002-11-29 11:30
Message:
Logged In: YES
user_id=21627
Would you like to investigate this further? There is no need
to, but if you find a solution and a patch, there is a better
chance that this is fixed before 2.3.
-
[ python-Bugs-654783 ] doctest and exception messages
Bugs item #654783, was opened at 2002-12-16 16:23 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Aahz (aahz) Assigned to: Aahz (aahz) Summary: doctest and exception messages Initial Comment: doctest should include information something like this: doctest docstrings should not rely on the text of internal Python exceptions. Notice the way factorial() uses its own error messages with the standard Python exceptions. The internal messages can change even in bugfix releases (as in 2.2.1 to 2.2.2). -- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:30 Message: Logged In: YES user_id=752496 What should change Aahz in the docs? Not clear to me... -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:30 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-23 19:01 Message: Logged In: YES user_id=3066 Tim sent this back to Aahz, so I'm assigning it to him as a reminder. ;-) -- Comment By: Tim Peters (tim_one) Date: 2003-04-25 16:08 Message: Logged In: YES user_id=31435 Back to Aahz. I don't mind if you change this -- edit the docs and check it in. -- Comment By: Tim Peters (tim_one) Date: 2002-12-16 20:39 Message: Logged In: YES user_id=31435 It could, but it shouldn't: error msgs in docs that don't match reality are also an insult to users. doctest should grow some sort of option here, though, as its uses outgrew its original purposes. -- Comment By: Neil Schemenauer (nascheme) Date: 2002-12-16 19:01 Message: Logged In: YES user_id=35752 Couldn't doctest be modified so that it only compares the exception name only? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654783&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-666700 ] os.popen+() can take string list and bypass shell.
Bugs item #666700, was opened at 2003-01-12 13:45 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dani (asqui) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen+() can take string list and bypass shell. Initial Comment: After being somewhat dumbfounded by the fact that there is no easy way to securely give user input as parameters to an external utility (because of the fact that os.popen*() runs things in the shell), I was happy to find that (os | popen2).popen[234]() will accept either a string as the command and execute it within a shell, or a string list which is executed directly. This does not apply to os.popen(), however popen2.popen[234]() all use this piece of code to execute the command in the child process: /usr/lib/python2.2/popen2.py def _run_child(self, cmd): if isinstance(cmd, types.StringTypes): cmd = ['/bin/sh', '-c', cmd] for i in range(3, MAXFD): try: os.close(i) except: pass try: os.execvp(cmd[0], cmd) finally: os._exit(1) Meaning that unless cmd is a string it will be run directly, outside of any shell. This appears to be the case for os.popen[234]() as well as popen2.popen*() -- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:34 Message: Logged In: YES user_id=752496 Should this be fixed in 2.4? Now we have the "subprocess" module. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:34 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-23 19:34 Message: Logged In: YES user_id=99508 Can I second that the documentation should definitely be updated to reflect this possibility, even if it's only available on *nix-like systems? This is something that many other languages in the same realm as Python (Perl, PHP, etc.) support and document, and I can't see any good reason why we *shouldn't* document a more secure way to give data to external programs. -- Comment By: Bernhard Herzog (bernhard) Date: 2003-08-05 13:04 Message: Logged In: YES user_id=2369 Given that the command as list of strings feature only works on Unix-like systems, ISTM it should perhaps only be documented for the PopenN classes. Maybe the documentation for the functions should state that on unix they accept lists of strings, though. -- Comment By: Dani (asqui) Date: 2003-01-12 13:49 Message: Logged In: YES user_id=569758 (The punch line which I omitted was that this fact is not documented anywhere.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-672035 ] Py_Main() does not perform to spec
Bugs item #672035, was opened at 2003-01-21 17:42 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672035&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: Fixed Priority: 5 Submitted By: Douglas Napoleone (derivin) Assigned to: Nobody/Anonymous (nobody) Summary: Py_Main() does not perform to spec Initial Comment: I consider this a code bug, not a documentation issue as the documentation is the behavior we want. >From http://www.python.org/doc/current/api/veryhigh.html#l2h- 47 : int Py_Main(int argc, char **argv) The main program for the standard interpreter. This is made available for programs which embed Python. The argc and argv parameters should be prepared exactly as those which are passed to a C program's main() function. It is important to note that the argument list may be modified (but the contents of the strings pointed to by the argument list are not). The return value will be the integer passed to the sys.exit() function, 1 if the interpreter exits due to an exception, or 2 if the parameter list does not represent a valid Python command line. I have checked the code for 2.2, 2.2.1, 2.2.2, and r2.3al In all cases the code will call exit(2) in C when an improper commandline is given instead of returning 2. ALL exit() calls should be removed from this module. The return value should be passed to exit or returned from main() by the caller of Py_Main() and NOT from within this call. python.c's main() would not need to be changed as it already does this. -- >Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:48 Message: Logged In: YES user_id=752496 Effectively closing it. -- Comment By: Douglas Napoleone (derivin) Date: 2003-04-21 15:33 Message: Logged In: YES user_id=541557 Patch was applied, just closing -- Comment By: Douglas Napoleone (derivin) Date: 2003-01-21 17:50 Message: Logged In: YES user_id=541557 The max recursion limit problem in the re module is well-known. Until this limitation in the implementation is removed, to work around it check http://www.python.org/dev/doc/devel/lib/module-re.html http://python/org/sf/493252 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672035&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-672035 ] Py_Main() does not perform to spec
Bugs item #672035, was opened at 2003-01-21 17:42 Message generated for change (Settings changed) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672035&group_id=5470 Category: Extension Modules Group: Python 2.2.2 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Douglas Napoleone (derivin) Assigned to: Nobody/Anonymous (nobody) Summary: Py_Main() does not perform to spec Initial Comment: I consider this a code bug, not a documentation issue as the documentation is the behavior we want. >From http://www.python.org/doc/current/api/veryhigh.html#l2h- 47 : int Py_Main(int argc, char **argv) The main program for the standard interpreter. This is made available for programs which embed Python. The argc and argv parameters should be prepared exactly as those which are passed to a C program's main() function. It is important to note that the argument list may be modified (but the contents of the strings pointed to by the argument list are not). The return value will be the integer passed to the sys.exit() function, 1 if the interpreter exits due to an exception, or 2 if the parameter list does not represent a valid Python command line. I have checked the code for 2.2, 2.2.1, 2.2.2, and r2.3al In all cases the code will call exit(2) in C when an improper commandline is given instead of returning 2. ALL exit() calls should be removed from this module. The return value should be passed to exit or returned from main() by the caller of Py_Main() and NOT from within this call. python.c's main() would not need to be changed as it already does this. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:48 Message: Logged In: YES user_id=752496 Effectively closing it. -- Comment By: Douglas Napoleone (derivin) Date: 2003-04-21 15:33 Message: Logged In: YES user_id=541557 Patch was applied, just closing -- Comment By: Douglas Napoleone (derivin) Date: 2003-01-21 17:50 Message: Logged In: YES user_id=541557 The max recursion limit problem in the re module is well-known. Until this limitation in the implementation is removed, to work around it check http://www.python.org/dev/doc/devel/lib/module-re.html http://python/org/sf/493252 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672035&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-676346 ] String formatting operation Unicode problem.
Bugs item #676346, was opened at 2003-01-28 17:59
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676346&group_id=5470
Category: Unicode
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 3
Submitted By: David M. Grimes (dmgrime)
Assigned to: M.-A. Lemburg (lemburg)
Summary: String formatting operation Unicode problem.
Initial Comment:
When performing a string formatting operation using %s
and a unicode argument, the argument evaluation is
performed more than once. In certain environments (see
example) this leads to excessive calls.
It seems Python-2.2.2:Objects/stringobject.c:3394 is
where PyObject_GetItem is used (for dictionary-like
formatting args). Later, at :3509, there is a"goto
unicode" when a string argument is actually unicode.
At this point, everything resets and we do it all over
again in PyUnicode_Format.
There is an underlying assumption that the cost of the
call to PyObject_GetItem is very low (since we're going
to do them all again for unicode). We've got a
Python-based templating system which uses a very simple
Mix-In class to facilitate flexible page generation.
At the core is a simple __getitem__ implementation
which maps calls to getattr():
class mixin:
def __getitem__(self, name):
print '%r::__getitem__(%s)' % (self, name)
hook = getattr(self, name)
if callable(hook):
return hook()
else:
return hook
Obviously, the print is diagnostic. So, this basic
mechanism allows one to write hierarchical templates
filling in content found in "%()s" escapes with
functions returning strings. It has worked extremely
well for us.
BUT, we recently did some XML-based work which
uncovered this strange unicode behaviour. Given the
following classes:
class w1u(mixin):
v1 = u'v1'
class w2u(mixin):
def v2(self):
return '%(v1)s' % w1u()
class w3u(mixin):
def v3(self):
return '%(v2)s' % w2u()
class w1(mixin):
v1 = 'v1'
class w2(mixin):
def v2(self):
return '%(v1)s' % w1()
class w3(mixin):
def v3(self):
return '%(v2)s' % w2()
And test case:
print 'All string:'
print '%(v3)s' % w3()
print
print 'Unicode injected at w1u:'
print '%(v3)s' % w3u()
print
As we can see, the only difference between the w{1,2,3}
and w{1,2,3}u classes is that w1u defines v1 as unicode
where w1 uses a "normal" string.
What we see is the string-based one shows 3 calls, as
expected:
All string:
<__main__.w3 instance at 0x8150524>::__getitem__(v3)
<__main__.w2 instance at 0x814effc>::__getitem__(v2)
<__main__.w1 instance at 0x814f024>::__getitem__(v1)
v1
But the unicode causes a tree-like recursion:
Unicode injected at w1u:
<__main__.w3u instance at 0x8150524>::__getitem__(v3)
<__main__.w2u instance at 0x814effc>::__getitem__(v2)
<__main__.w1u instance at 0x814f024>::__getitem__(v1)
<__main__.w1u instance at 0x814f024>::__getitem__(v1)
<__main__.w2u instance at 0x814effc>::__getitem__(v2)
<__main__.w1u instance at 0x814f024>::__getitem__(v1)
<__main__.w1u instance at 0x814f024>::__getitem__(v1)
<__main__.w3u instance at 0x8150524>::__getitem__(v3)
<__main__.w2u instance at 0x814effc>::__getitem__(v2)
<__main__.w1u instance at 0x814f024>::__getitem__(v1)
<__main__.w1u instance at 0x814f024>::__getitem__(v1)
<__main__.w2u instance at 0x814effc>::__getitem__(v2)
<__main__.w1u instance at 0x814f024>::__getitem__(v1)
<__main__.w1u instance at 0x814f024>::__getitem__(v1)
v1
I'm sure this isn't a "common" use of the string
formatting mechanism, but it seems that evaluating the
arguments multiple times could be a bad thing. It
certainly is for us 8^)
We're running this on a RedHat 7.3/8.0 setup, not that
it appears to matter (from looking in stringojbect.c).
Also appears to still be a problem in 2.3a1.
Any comments? Help? Questions?
--
Comment By: Facundo Batista (facundobatista)
Date: 2005-01-11 00:54
Message:
Logged In: YES
user_id=752496
Please, could you verify if this problem persists in Python 2.3.4
or 2.4?
If yes, in which version? Can you provide a test case?
If the problem is solved, from which version?
Note that if you fail to answer in one month, I'll close this bug
as "Won't fix".
Thank you!
.Facundo
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2003-01-28 19:23
Message:
Logged In: YES
user_id=38388
I don't see how you can avoid fetching the Unicode
argument a second time without restructuring the
formatting code altogether.
If you know that your arguments can be Unicode, you
should start with a Unicode formatting string to begin
with. That's faster and doesn't involve a fallback
solution.
If you still want to see this fixed, I'd suggest to submit
a patch.
---
[ python-Bugs-680379 ] Incorrect permissions set in lib-dynload.
Bugs item #680379, was opened at 2003-02-04 15:24 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680379&group_id=5470 Category: Distutils Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Arcady Genkin (antipode) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect permissions set in lib-dynload. Initial Comment: I have seen a number of bugs on this issue, but all of them seem dot be marked as "closed" for some reason. This has been the case in every release since Python 2.1 and is still the case in 2.2.2. When istalling Python by typing "make install" (with umask set to 022) everything is installed with correct permissions, *except* for the stuff in the lib-dynload directory, where the files are installed with mode 700 (should be of 755). Thanks. -- Arcady Genkin -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:58 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680379&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-687297 ] Profilier hooked into SystemExit
Bugs item #687297, was opened at 2003-02-15 22:41 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687297&group_id=5470 Category: Demos and Tools Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dylan Shell (dshell) Assigned to: Nobody/Anonymous (nobody) Summary: Profilier hooked into SystemExit Initial Comment: I've been attempting to profile code that uses the PyOpenGL bindings. Essentially I've got a program with that calls glutMainLoop - which is said to never return. The problem is that since this really envokes some C code that calls "exit" the profiler does not catch a "SystemExit" exception, because this is never thrown. If there was a way to get the profiler to dump state on demand, I could do this in an "onExit" event handler, and then restart python with the pstats module to have a look-see. Alternatively the profiler could use some OS provided exit handler - or something simliar. Also, running the main loop in a thread does not seem to work (the video memory used by GLUT) is corrupted. So, this isn't a fair test on which to profile. I suspect that the ability to dump profile stats to disk could also be useful for other folks. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 01:08 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! .Facundo -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687297&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
