[ python-Bugs-1431582 ] long path support in win32 part of os.listdir(posixmodule.c)
Bugs item #1431582, was opened at 2006-02-14 18:44 Message generated for change (Settings changed) made by fidoman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431582&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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Sergey Dorofeev (fidoman) >Assigned to: Martin v. Löwis (loewis) Summary: long path support in win32 part of os.listdir(posixmodule.c) Initial Comment: When passing path to os.listdir that is longer then MAX_PATH (what is supported in Windows API, http://msdn.microsoft.com/library/default.asp? url=/library/en-us/fileio/fs/naming_a_file.asp) the path is truncated at position MAX_PATH=260 and appended with "/*.*", so underlying Windows API function FindFirstFileW gets garbage on input: original path truncated, and symbol "/" is added, which may not be used as path separator in long path. I think posix_listdir should or raise error when getting extra long string, or pass it unchanged to underlying API. Affected code is in Modules\posixmodule.c, lines 1470- 1478 (Python 2.4.2). I think there is enough to change base when calculating size of allocated memory and copied block from fixed value of MAX_PATH to length of passed to function string. And use os.sep instead of "/", of course. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431582&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1432260 ] pydoc still doesn't handle lambda well
Bugs item #1432260, was opened at 2006-02-15 16:03 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=1432260&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: None Status: Open Resolution: None Priority: 5 Submitted By: William McVey (wamcvey) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc still doesn't handle lambda well Initial Comment: This is a duplicate of Bug ID 672578, but I could find no way for a 'normal user' to reopen a closed bug ticket. Pydoc doesn't currently handle functions and methods defined with lambda very well. Not only are names associated with a lambda defined function/method not indicated in the generated module and class definitions, but docstrings attached to the object generated by lambda are not integrated into the output. I've attached a sample program that illustrates the discrepency of handling methods defined with 'def' versus those that are handled with 'lambda'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432260&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1425127 ] os.remove OSError: [Errno 13] Permission denied
Bugs item #1425127, was opened at 2006-02-06 10:44
Message generated for change (Comment added) made by atila-cheops
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1425127&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.remove OSError: [Errno 13] Permission denied
Initial Comment:
When running the following program I get frequent
errors like this one
Exception in thread Thread-4:
Traceback (most recent call last):
File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
self.run()
File "os.remove.py", line 25, in run
os.remove(filename)
OSError: [Errno 13] Permission denied:
'c:\\docume~1\\joag\\locals~1\\temp\\tmpx91tkx'
When leaving out the touch statement(line 24) in the
loop of the class, I do not get any errors.
This is on Windows XP SP2 with python-2.4.2 (you should
have an exe touch somewhere in you path for this to
work) Can somebody shed any light on this please?
Thanks in advance
Joram Agten
--
>Comment By: cheops (atila-cheops)
Date: 2006-02-15 16:15
Message:
Logged In: YES
user_id=1276121
os.remove3.py
when using the os.write() function and os.close() function
to do the file writing, no problems are seen either.
so this seems to be a bug in the 'normal' file input output
functions under windows.
they don't seem to be thread safe in a way or another.
maybe the close() function returns too early?
--
Comment By: cheops (atila-cheops)
Date: 2006-02-15 15:50
Message:
Logged In: YES
user_id=1276121
further looking into the problem:
when using the win32api calls to write to the file, this
seems to work.
see os.remove_win.py
--
Comment By: cheops (atila-cheops)
Date: 2006-02-10 09:58
Message:
Logged In: YES
user_id=1276121
When running the same script, but now with the windows
remove function (cmd /c rm filename)
still problems occur, so maybe this is a windows problem
after all?
or does subprocess do things wrong?
--
Comment By: cheops (atila-cheops)
Date: 2006-02-07 11:32
Message:
Logged In: YES
user_id=1276121
for the subprocess.py I did the following in a few places
try:
_active.remove(self)
except:
pass
see also bug 1199282
https://sourceforge.net/tracker/index.php?func=detail&aid=1199282&group_id=5470&atid=105470
in my current script I circumvent the "Permission denied"
error in the following way:
removed = False
while not removed:
try:
os.remove(file)
except OSError, error:
logger.warning("could not remove file %s, %s"
%(file, error))
time.sleep(1)
else:
removed = True
I also have a virus scanner (Mcafee, corporate stuff), and
still get the same behaviour when disabling the virus scanner.
>My feel, after staring at filemon output, is that this is a
>problem in the Windows file I/O layer. NTFS queues the
>various operations, and calling an external process with
>stuff still in the queue messes up the request scheduling.
this seems strange to me, since every thread works with its
own temp files, and all requests are send one after another
to the file I/O layer
--
Comment By: Fredrik Lundh (effbot)
Date: 2006-02-07 07:59
Message:
Logged In: YES
user_id=38376
"Does it tell you more than _just_ that? It doesn't for me."
All requests against the file in question were issued by the
python process; there's no sign of virus checkers or other
external applications.
Also, whenever things failed, there were always multiple
requests for cmd.exe (caused by os.system) between the WRITE
request and the failing OPEN request.
My feel, after staring at filemon output, is that this is a
problem in the Windows file I/O layer. NTFS queues the
various operations, and calling an external process with
stuff still in the queue messes up the request scheduling.
--
Comment By: Tim Peters (tim_one)
Date: 2006-02-07 04:07
Message:
Logged In: YES
user_id=31435
[/F]
> Except that he's hitting the file system quite heavily,
Except that _without_ the call to touch(), he's hitting it
even more heavily, creating and destroying little files just
as fast as the OS can do it in each of 10 threads -- but
there aren't any errors then.
> and asyncronously.
What's asynch here? The OP's touch() function waits for the
spawned process to terminate, and the test driver doesn't
try to delete the file un
[ python-Bugs-1432343 ] Descript of file-object read() method is wrong.
Bugs item #1432343, was opened at 2006-02-15 17:49 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=1432343&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: Grant Edwards (grante) Assigned to: Nobody/Anonymous (nobody) Summary: Descript of file-object read() method is wrong. Initial Comment: There are two errors in the documentation of the file object's read() method found at http://www.python.org/doc/current/lib/bltin-file-objects.html#l2h-242 Suggested changes (unindented) are shown below interspersed with the current text with insertions noted by a '+' in the first column: Read at most size bytes from the file (less if the read hits EOF before obtaining size bytes). If the size argument is negative or omitted, read all data until EOF is reached. + Under some circumstances (e.g. system call aborted by + a signal) read() called with a negative or absent size + argument may return data before EOF is reached (even in + blocking mode). The bytes are returned as a string object. An empty string is returned when EOF is encountered immediately. (For certain files, like ttys, it makes sense to continue reading after an EOF is hit.) The last sentence above (the parenthetical one) is false for Linux/Unix. Once you hit EOF on a tty, it will return EOF forever until it's closed and re-opened. If the above sentence is true for other OSes, I suggest it be so qualified -- otherwise it should just be deleted. Note that this method may call the underlying C function fread() more than once in an effort to acquire as close to size bytes as possible. Also note that when in non-blocking mode, less data than what was requested may be returned, even if no size parameter was given. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432343&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1432343 ] Description of file-object read() method is wrong.
Bugs item #1432343, was opened at 2006-02-15 17:49 Message generated for change (Comment added) made by grante You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432343&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: Grant Edwards (grante) Assigned to: Nobody/Anonymous (nobody) >Summary: Description of file-object read() method is wrong. Initial Comment: There are two errors in the documentation of the file object's read() method found at http://www.python.org/doc/current/lib/bltin-file-objects.html#l2h-242 Suggested changes (unindented) are shown below interspersed with the current text with insertions noted by a '+' in the first column: Read at most size bytes from the file (less if the read hits EOF before obtaining size bytes). If the size argument is negative or omitted, read all data until EOF is reached. + Under some circumstances (e.g. system call aborted by + a signal) read() called with a negative or absent size + argument may return data before EOF is reached (even in + blocking mode). The bytes are returned as a string object. An empty string is returned when EOF is encountered immediately. (For certain files, like ttys, it makes sense to continue reading after an EOF is hit.) The last sentence above (the parenthetical one) is false for Linux/Unix. Once you hit EOF on a tty, it will return EOF forever until it's closed and re-opened. If the above sentence is true for other OSes, I suggest it be so qualified -- otherwise it should just be deleted. Note that this method may call the underlying C function fread() more than once in an effort to acquire as close to size bytes as possible. Also note that when in non-blocking mode, less data than what was requested may be returned, even if no size parameter was given. -- >Comment By: Grant Edwards (grante) Date: 2006-02-15 17:51 Message: Logged In: YES user_id=61937 Well, that didn't work very well. I really hate these web interfaces. I've attached the suggested changes as a text file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432343&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1432350 ] arrayobject should use PyObject_VAR_HEAD
Bugs item #1432350, was opened at 2006-02-15 13:16 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=1432350&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: arrayobject should use PyObject_VAR_HEAD Initial Comment: The only difference between PyObject_VAR_HEAD and PyObject_HEAD is that VAR_HEAD adds Py_ssize_t ob_size; This is also the first field that arrayobject adds; it would be clearer to just use PyObject_VAR_HEAD and take the field out of arrayobject's explicit declaration. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1432350&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-1432437 ] itertools.any and itertools.all
Feature Requests item #1432437, was opened at 2006-02-15 13:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432437&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: None Status: Open Resolution: None Priority: 5 Submitted By: paul cannon (paulcannon) Assigned to: Nobody/Anonymous (nobody) Summary: itertools.any and itertools.all Initial Comment: Just a couple very simple "shortcutting" functions that I find myself needing quite frequently. "reduce(operator.or_, foo, False)" is all right, but potentially does a lot more work. def any(i): """Returns true if any element from i is true.""" for element in i: if i: return True return False all() would also be nice: def all(i): """Returns true if all elements from i are true.""" for element in i: if not i: return False return True ..although it /could/ simply be built on any() as "not any(imap(operator.not_, i))". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432437&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-1432437 ] itertools.any and itertools.all
Feature Requests item #1432437, was opened at 2006-02-15 21:26 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432437&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: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: paul cannon (paulcannon) Assigned to: Nobody/Anonymous (nobody) Summary: itertools.any and itertools.all Initial Comment: Just a couple very simple "shortcutting" functions that I find myself needing quite frequently. "reduce(operator.or_, foo, False)" is all right, but potentially does a lot more work. def any(i): """Returns true if any element from i is true.""" for element in i: if i: return True return False all() would also be nice: def all(i): """Returns true if all elements from i are true.""" for element in i: if not i: return False return True ..although it /could/ simply be built on any() as "not any(imap(operator.not_, i))". -- >Comment By: Georg Brandl (birkenfeld) Date: 2006-02-15 21:44 Message: Logged In: YES user_id=1188172 These two happen to become builtins in 2.5. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1432437&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1431962 ] crash when using grid(row or column >9998)
Bugs item #1431962, was opened at 2006-02-15 07:28
Message generated for change (Comment added) made by cniekel
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431962&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: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Niekel (cniekel)
Assigned to: Martin v. Löwis (loewis)
Summary: crash when using grid(row or column >9998)
Initial Comment:
Hi,
The following crashes python with a coredump in linux,
and a 'send report'-message in windows:
from Tkinter import *
r = Tk()
l = Label(r, text='hello')
l.grid(row=1,column=1)
Amanjit Gill looked at the tk code and found in tkgrid.
c: if (slot < 0 || slot >= MAX_ELEMENT) { return
TCL_ERROR; }
(Where MAX_ELEMENT is 1)
It would be better (imho) if python would raise an
exception instead of crashing.
--
>Comment By: Chris Niekel (cniekel)
Date: 2006-02-16 07:39
Message:
Logged In: YES
user_id=106343
>From more discussion on the tkinter mailinglist, I
understood that the problem is in Tk, since a tcl script has
the same problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431962&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
