[ python-Bugs-1695718 ] PEP 302 broken
Bugs item #1695718, was opened at 2007-04-06 12:32 Message generated for change (Comment added) made by philipdumont You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695718&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Closed Resolution: Wont Fix Priority: 6 Private: No Submitted By: phil (philipdumont) Assigned to: Georg Brandl (gbrandl) Summary: PEP 302 broken Initial Comment: The product I'm working on uses a PEP 302 importer hook. It's a home-grown ltihooks clone. (We don't use ltihooks because it's GPLed, and we don't want to be.) Our importer worked on 2.4.3, is broken on 2.5.0. What's broken is that if the hook's find_module() method returns None for a given module name, say 'spam', then that is supposed to cause the import machinery to fall back on the regular unhooked import behavior -- that is, find 'spam.py' (or 'spam.pyc', 'spam.pyo') in the directory in question. This used to be what happened, but no longer. Tracing through the code, the problem seems to be occurring due to the 'continue' at line 1289 (in the 2.5 tarball) of Python/import.c. Slogging through SVN (aside: this would have been easier if your ViewSVN supported annotate/blame -- any chance you could add that?), it appears that the offending continue statement was added in revision 46372, whose checkin comment claims that it was done for performance reasons. I'm all for performance improvements, but not at the expense of breakage. Attached is a tarball with some files that reproduce the problem. (The LibtoolImporter.py file is a stripped-down toy version of what we are really using.) Unwind the tarball, cd to the directory, and run script.py. Here's what I get: shell prompt> pwd /home/phil/pep302_bug shell prompt> ls -CF eggs.la LibtoolImporter.py script.py* spam.py shell prompt> python2.4.3 script.py .la file(s) found in /home/phil/pep302_bug, LibtoolImporter will be used. LibtoolImporter.find_module() couldn't find spam.la or spammodule.la in /home/phil/pep302_bug. Returning None. This is *supposed* to cause a fallback to the default import code looking for spam.py in /home/phil/pep302_bug module spam loaded shell prompt> python2.5 script.py .la file(s) found in /home/phil/pep302_bug, LibtoolImporter will be used. LibtoolImporter.find_module() couldn't find spam.la or spammodule.la in /home/phil/pep302_bug. Returning None. This is *supposed* to cause a fallback to the default import code looking for spam.py in /home/phil/pep302_bug Traceback (most recent call last): File "script.py", line 4, in import spam ImportError: No module named spam shell prompt> -- >Comment By: phil (philipdumont) Date: 2007-04-09 09:40 Message: Logged In: YES user_id=1364034 Originator: YES Ok. I concede that I misread the PEP. And I won't dispute the NO CHANGE resolution. But before I drop it entirely, I wish to make one more comment. >From PEP 302: "The hooks proposed in this PEP...would allow the __import__-based tools to get rid of most of their import.c emulation code." This implementation change causes hooks that handle directories containing both custom modules and "normal" modules to have to do some of that import.c emulation. Which is what I guess I will do. -- Comment By: Georg Brandl (gbrandl) Date: 2007-04-08 08:58 Message: Logged In: YES user_id=849994 Originator: NO You're correct, Brett. I found the implicit fallback at the Iceland sprint and we decided to change that in 2.5: http://mail.python.org/pipermail/python-dev/2006-May/065174.html PEP 302 has even been edited to say: [...] Note that if the callable returns an importer object for a specific sys.path entry, the builtin import machinery will not be invoked to handle that entry any longer, even if the importer object later fails to find a specific module. Closing as "Won't fix", if more need for discussion arises, please take this to python-dev. -- Comment By: Brett Cannon (bcannon) Date: 2007-04-08 00:55 Message: Logged In: YES user_id=357491 Originator: NO I don't agree with this interpretation of PEP 302 for this instance. If you read the PEP there is no explicit mention that if an importer for an entry on sys.path fails that it falls back on the default import behaviour. The only mention of using the default behaviour is if a value of None is stored in sys.path_importer_cache (which also occurs when no entry on sys.path_hooks returns a usable importer). In my interpretation of PEP 302 (and how I implemented it for my pure Python import implementation), if an
[ python-Bugs-1615275 ] tempile.TemporaryFile differences between linux and windows
Bugs item #1615275, was opened at 2006-12-13 16:20
Message generated for change (Comment added) made by draghuram
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1615275&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: hirzel (hirzel)
Assigned to: Nobody/Anonymous (nobody)
Summary: tempile.TemporaryFile differences between linux and windows
Initial Comment:
This bug came up when trying to write a numpy array to a
tempfile.TemporaryFile() using the numpy 'tofile' method on windows using
python 2.4.
with a numpy array 'a', and a TemporaryFile 'f',
on windows:
>>> a.tofile(f)
throws an IOError, where on Linux it does not.
On windows, you must use a.tofile(f.file)
The cause of this difference is that in windows, tempfile.TemporaryFile()
returns that has a 'file' attribute of ,
whereas in linux tempfile.TemporaryFile() returns and there is no
'file' attribute.
Ideally, the windows version would align with linux, and the module
documentation and TemporaryFile() would return a . If this is not
possible, it seems like the linux version and docs should be changed to match
the windows version to align cross-platform behavior. At least, that seems to
be the shared opinion of this thread from the mailing list: numpy-discussion.
http://www.mail-archive.com/numpy-discussion@scipy.org/msg00271.html
To my knowledge, while platform differences in tempfile have been reported in
the past, this one has not.
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-04-09 10:16
Message:
Logged In: YES
user_id=984087
Originator: NO
I posted in python-dev about this bug asking if TemporaryFile() can also
return a wrapper on all platforms but immediately realized that always
returning a wrapper instead of a file object would break any existing code
that depends on the return value being a file object. There were no other
comments from any one on the dev list either. I think the best bet is to
update the document with the following details.
1) "NamedTemporaryFile" returns a file-like object. The actual file object
can be accessed with "file" member of the returned instance.
2) "TemporaryFile" on windows is same as "NamedTemporaryFile".
3) cross-platform code that needs access to file object (such as
array.tofile) should check for the return object type and behave
accordingly.
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-03-29 14:36
Message:
Logged In: YES
user_id=984087
Originator: NO
After looking at tempfile.py, the reason for the difference in behaviour
is clear. On windows, "TemporaryFile" is an alias for "NamedTemporaryFile".
NamedTemporaryFile() returns a wrapper instance with file-like interface
but which is not actually a file. This is not a problem when file
operations like "write" and "close" are used directly. But array.tofile()
explicitly checks for file type object and hence fails with
NamedTemporaryFile(). Same is the reason for numpy failure as reported by
OP (I haven't explicitly analyzed numpy failure but gleaned this info from
the discussion thread in the initial post).
Even though the reason is clear, I think the end result is a bit
unsatisfactory. array.tofile() (and numpy's tofile()) need to pass
different parameters depending on the platform. One possible solution is
for "TemporaryFile" to return a wrapper as well. Then, tofile() can be
called with TemporaryFile().file on all platforms.
--
Comment By: Raghuram Devarakonda (draghuram)
Date: 2007-03-28 10:43
Message:
Logged In: YES
user_id=984087
Originator: NO
I used the following code to reproduce the problem on windows XP.
--
import array
import tempfile
testarray = array.array('B')
testarray.fromstring("\x00\x00\x00")
f = tempfile.TemporaryFile()
testarray.tofile(f)
---
This works fine on linux but on windows, it gives the following error:
-
Traceback (most recent call last):
File "c:\rags\tofile.py", line 7, in
testarray.tofile(f)
TypeError: arg must be open file
-
Changing "f" to "f.file" seems to work, though, as explained in the
initial post. So this may be the same problem as OP reported even though I
am getting TypeError and he mentioned IOError.
I tested with 2.4 and 2.5 as I don't know how to set up python development
environment on windows (yet). I will see if I can set that up first before
working on the "fix".
Raghu.
--
You can respond by visiting:
https://
[ python-Bugs-1685000 ] asyncore DoS vulnerability
Bugs item #1685000, was opened at 2007-03-21 02:15 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1685000&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 9 Private: No Submitted By: billiejoex (billiejoex) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore DoS vulnerability Initial Comment: DoS asyncore vulnerability asyncore, independently if used with select() or poll(), suffers a DoS-type vulnerability when a high number of simultaneous connections to handle simultaneously is reached. The number of maximum connections is system-dependent as well as the type of error raised. I attached two simple Proof of Concept scripts demonstrating such bug. If you want to try the behaviours listed below run the attached "asyncore_server.py" and "asyncore_client.py" scripts on your local workstation. On my Windows XP system (Python 2.5), independently if asyncore has been used to develop a server or a client, the error is raised by select() inside asyncore's "poll" function when 512 (socket_map's elements) simultaneous connections are reached. Here's the traceback I get: [...] connections: 510 connections: 511 connections: 512 Traceback (most recent call last): File "C:\scripts\asyncore_server.py", line 38, in asyncore.loop() File "C:\Python25\lib\asyncore.py", line 191, in loop poll_fun(timeout, map) File "C:\Python25\lib\asyncore.py", line 121, in poll r, w, e = select.select(r, w, e, timeout) ValueError: too many file descriptors in select() On my Linux Ubuntu 6.10 (kernel 2.6.17-10, Python 2.5) different type of errors are raised depending on the application (client or server). In an asyncore-based client the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'connect' method of 'dispatcher' class: [...] connections: 1018 connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_client.py", line 31, in File "asyncore.py", line 191, in loop File "asyncore.py", line 138, in poll File "asyncore.py", line 80, in write File "asyncore.py", line 76, in write File "asyncore.py", line 395, in handle_write_event File "asyncore_client.py", line 24, in handle_connect File "asyncore_client.py", line 9, in __init__ File "asyncore.py", line 257, in create_socket File "socket.py", line 156, in __init__ socket.error: (24, 'Too many open files') On an asyncore-based server the error is raised by socket module (dispatcher's "self.socket" attribute) inside 'accept' method of 'dispatcher' class: [...] connections: 1019 connections: 1020 connections: 1021 Traceback (most recent call last): File "asyncore_server.py", line 38, in File "asyncore.py", line 191, in loop File "asyncore.py", line 132, in poll File "asyncore.py", line 72, in read File "asyncore.py", line 68, in read File "asyncore.py", line 384, in handle_read_event File "asyncore_server.py", line 16, in handle_accept File "asyncore.py", line 321, in accept File "socket.py", line 170, in accept socket.error: (24, 'Too many open files') -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-04-09 09:13 Message: Logged In: YES user_id=341410 Originator: NO Assign the "bug" to me, I'm the maintainer for asyncore/asynchat. With that said, since a user needs to override asyncore.dispatcher.handle_accept() anyways, which necessarily needs to call asyncore.dispatcher.accept(), the subclass is free to check the number of sockets in its socket map before creating a new instance of whatever subclass of asyncore.dispatcher the user has written. Also, the number of file handles that select can handle on Windows is a compile-time constant, and has nothing to do with the actual number of open file handles. Take and run the following source file on Windows and see how the total number of open sockets can be significantly larger than the number of sockets passed to select(): import socket import asyncore import random class new_map(dict): def items(self): r = [(i,j) for i,j in dict.items(self) if not random.randrange(4) and j != h] r.append((h._fileno, h)) print len(r), len(asyncore.socket_map) return r asyncore.socket_map = new_map() class listener(asyncore.dispatcher): def handle_accept(self): x = self.accept() if x: conn, addr = x connection(conn) class connection(asyncore.dispatcher): def writable(self): 0 def handle_connect(self): pass if __name__ == '__main__': h = listener() h.create_socket(socket.AF_INET, socket.SOC
[ python-Bugs-1695948 ] logging.handlers.SocketHandler.makeSocket() blocks app
Bugs item #1695948, was opened at 2007-04-07 06:22 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695948&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: jtdeng (jtdeng) Assigned to: Vinay Sajip (vsajip) Summary: logging.handlers.SocketHandler.makeSocket() blocks app Initial Comment: Python Version: === Any Python Version OS Platform: Debian Linux 2.6.8-2-386 #1 Tue Aug 16 12:46:35 UTC 2005 i686 GNU/Linux Windows XP SP2 Problem: Member function makeSocket() of logging.handlers.SocketHandler creates a socket with no default timeout, and this may block the app on Linux. def makeSocket(self): """ A factory method which allows subclasses to define the precise type of socket they want. """ s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((self.host, self.port)) return s if the log receiver on the destination host is not running, the log sender will block the app on socket.connect(), but on windows, socket.connect() will return immediately. So I propose to provide a default timeout value for makeSocket() like below: def makeSocket(self, timeout=1): """ A factory method which allows subclasses to define the precise type of socket they want. """ s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(timeout) s.connect((self.host, self.port)) return s -- >Comment By: Vinay Sajip (vsajip) Date: 2007-04-09 16:18 Message: Logged In: YES user_id=308438 Originator: NO Change (not exactly as above) checked into SVN trunk. New functionality, so not backported. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-04-09 05:56 Message: Logged In: YES user_id=33168 Originator: NO Vinay, could you take a look? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695948&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1695718 ] PEP 302 broken
Bugs item #1695718, was opened at 2007-04-06 09:32 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1695718&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Closed Resolution: Wont Fix Priority: 6 Private: No Submitted By: phil (philipdumont) Assigned to: Georg Brandl (gbrandl) Summary: PEP 302 broken Initial Comment: The product I'm working on uses a PEP 302 importer hook. It's a home-grown ltihooks clone. (We don't use ltihooks because it's GPLed, and we don't want to be.) Our importer worked on 2.4.3, is broken on 2.5.0. What's broken is that if the hook's find_module() method returns None for a given module name, say 'spam', then that is supposed to cause the import machinery to fall back on the regular unhooked import behavior -- that is, find 'spam.py' (or 'spam.pyc', 'spam.pyo') in the directory in question. This used to be what happened, but no longer. Tracing through the code, the problem seems to be occurring due to the 'continue' at line 1289 (in the 2.5 tarball) of Python/import.c. Slogging through SVN (aside: this would have been easier if your ViewSVN supported annotate/blame -- any chance you could add that?), it appears that the offending continue statement was added in revision 46372, whose checkin comment claims that it was done for performance reasons. I'm all for performance improvements, but not at the expense of breakage. Attached is a tarball with some files that reproduce the problem. (The LibtoolImporter.py file is a stripped-down toy version of what we are really using.) Unwind the tarball, cd to the directory, and run script.py. Here's what I get: shell prompt> pwd /home/phil/pep302_bug shell prompt> ls -CF eggs.la LibtoolImporter.py script.py* spam.py shell prompt> python2.4.3 script.py .la file(s) found in /home/phil/pep302_bug, LibtoolImporter will be used. LibtoolImporter.find_module() couldn't find spam.la or spammodule.la in /home/phil/pep302_bug. Returning None. This is *supposed* to cause a fallback to the default import code looking for spam.py in /home/phil/pep302_bug module spam loaded shell prompt> python2.5 script.py .la file(s) found in /home/phil/pep302_bug, LibtoolImporter will be used. LibtoolImporter.find_module() couldn't find spam.la or spammodule.la in /home/phil/pep302_bug. Returning None. This is *supposed* to cause a fallback to the default import code looking for spam.py in /home/phil/pep302_bug Traceback (most recent call last): File "script.py", line 4, in import spam ImportError: No module named spam shell prompt> -- >Comment By: Brett Cannon (bcannon) Date: 2007-04-09 10:42 Message: Logged In: YES user_id=357491 Originator: NO I am planning to work on the import machinery in general for this year so hopefully things will improve. -- Comment By: phil (philipdumont) Date: 2007-04-09 06:40 Message: Logged In: YES user_id=1364034 Originator: YES Ok. I concede that I misread the PEP. And I won't dispute the NO CHANGE resolution. But before I drop it entirely, I wish to make one more comment. >From PEP 302: "The hooks proposed in this PEP...would allow the __import__-based tools to get rid of most of their import.c emulation code." This implementation change causes hooks that handle directories containing both custom modules and "normal" modules to have to do some of that import.c emulation. Which is what I guess I will do. -- Comment By: Georg Brandl (gbrandl) Date: 2007-04-08 05:58 Message: Logged In: YES user_id=849994 Originator: NO You're correct, Brett. I found the implicit fallback at the Iceland sprint and we decided to change that in 2.5: http://mail.python.org/pipermail/python-dev/2006-May/065174.html PEP 302 has even been edited to say: [...] Note that if the callable returns an importer object for a specific sys.path entry, the builtin import machinery will not be invoked to handle that entry any longer, even if the importer object later fails to find a specific module. Closing as "Won't fix", if more need for discussion arises, please take this to python-dev. -- Comment By: Brett Cannon (bcannon) Date: 2007-04-07 21:55 Message: Logged In: YES user_id=357491 Originator: NO I don't agree with this interpretation of PEP 302 for this instance. If you read the PEP there is no explicit mention that if an importer for an entry on sys.path fails that it falls back on the default import behaviour. The on
[ python-Bugs-1697169 ] package.pth file name not used as described.
Bugs item #1697169, was opened at 2007-04-09 14:58 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=1697169&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 Private: No Submitted By: cfk (carlfk) Assigned to: Nobody/Anonymous (nobody) Summary: package.pth file name not used as described. Initial Comment: "...whose name has the form package.pth" http://www.python.org/doc/lib/module-site.html as far as I can tell, that is incorrect. the .pth file can be named anything - only the name of the dir listed in it is used as a package/module name. It is implemented in site.py : def addpackage(sitedir, name, known_paths): fullname = os.path.join(sitedir, name) f = open(fullname, "rU") for line in f: dir, dircase = makepath(sitedir, line) if not dircase in known_paths and os.path.exists(dir): sys.path.append(dir) Notice name is not added to sys.path. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697169&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1697175 ] winreg module for cygwin?
Bugs item #1697175, was opened at 2007-04-09 20:06 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=1697175&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: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: winreg module for cygwin? Initial Comment: Please make the winreg module work on cygwin. Nowadays cygwin has a /proc/registry file system, which might provide an easy way to do it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697175&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1697215 ] execute
"execute sitedir if it starts with 'import'" doesn'
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-SourceForge-Tracker-unixname: python
X-SourceForge-Tracker-trackerid: 105470
X-SourceForge-Tracker-itemid: 1697215
X-SourceForge-Tracker-itemstatus: Open
X-SourceForge-Tracker-itemassignee: nobody
X-SourceForge-Tracker-itemupdate-reason: Tracker Item Submitted
X-SourceForge-Tracker-itemupdate-username: Item Submitter
Bugs item #1697215, was opened at 2007-04-09 16:23
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=1697215&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
Private: No
Submitted By: cfk (carlfk)
Assigned to: Nobody/Anonymous (nobody)
Summary: execute
"execute sitedir if it starts with 'import'" doesn'
Initial Comment:
docstring says "execute sitedir" - but that isn't what gets executed.
suggested:
"""Add a new path to known_paths by combining sitedir and 'name'
or execute lines in name.pth that start with 'import'"""
site.py
def addpackage(sitedir, name, known_paths):
"""Add a new path to known_paths by combining sitedir and 'name' or execute
sitedir if it starts with 'import'"""
fullname = os.path.join(sitedir, name)
f = open(fullname, "rU")
for line in f:
if line.startswith("import"):
exec line
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697215&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1697248 ] Property with -> annotation triggers assert
Bugs item #1697248, was opened at 2007-04-09 19:05 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=1697248&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: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: Property with -> annotation triggers assert Initial Comment: Example: # x.py class C: @property def p(self) -> int: return 0 $ ./python -E x.py python: ../Python/ast.c:724: ast_for_arguments: Assertion `((n)->n_type) == 263 || ((n)->n_type) == 267' failed. Aborted $ Removing "@property" or "-> int" from the example avoids the problem. Adding argument annotations inside the argument list doesn't trigger it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1697248&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681974 ] mkdtemp fails on Windows if username has non-ASCII character
Bugs item #1681974, was opened at 2007-03-16 12:03 Message generated for change (Comment added) made by niemisto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681974&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Markus Niemist� (niemisto) Assigned to: Nobody/Anonymous (nobody) Summary: mkdtemp fails on Windows if username has non-ASCII character Initial Comment: mkdtemp fails miserably on Windows if Windows user name has any non-ASCII characters, like ä or ö, in it. mkdtemp throws an encoding error. This seems to be because the default temp dir in Windows is "c:\documents and settings\\local settings\temp". Now if the user name has non-ASCII characters ASCII decoder cannot handle it and creating temp directories won't work. As a work around I have used the following code: tempdir = unicode(tempfile.gettempdir(), 'mbcs') mkdtemp(suffix='foo', dir=tempdir) This applies for both Python 2.4 and Python 2.5. -- >Comment By: Markus Niemist� (niemisto) Date: 2007-04-10 09:48 Message: Logged In: YES user_id=459586 Originator: YES Here is traceback. Sorry it took so long. Traceback (most recent call last): File "c:\util\home\xxx\xxx.py", line 350, in OnOpen dir = tempfile.mkdtemp(prefix=u'test') File "C:\python24\lib\tempfile.py", line 326, in mkdtemp file = _os.path.join(dir, prefix + name + suffix) File "c:\python24\lib\ntpath.py", line 102, in join path += "\\" + b UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 12: ordinal not in range(128) -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 13:42 Message: Logged In: YES user_id=849994 Originator: NO Could you indicate where exactly what error is raised? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681974&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
