[ python-Bugs-1161031 ] Neverending warnings from asyncore
Bugs item #1161031, was opened at 2005-03-10 16:34 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 00:03 Message: Logged In: YES user_id=341410 Option 1 is not really an option in any case where a large number of connections are opened (so I don't believe should be the default). >From what I understand, certain methods are supposed to be overridden in a subclass if someone using a class wants different behavior. In this case, I believe you can perform either option 2 or 3 in your own code to avoid the thousands of logged lines; either by creating your own loop() function, or by creating a subclass of dispatcher and implementing a handle_expt() method that does as you desire. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1117601 ] os.path.exists returns false negatives in MAC environments.
Bugs item #1117601, was opened at 2005-02-06 16:57
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117601&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: Stephen Bennett (sbennett)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.exists returns false negatives in MAC environments.
Initial Comment:
In Mandatory Access Control environments (such as
SELinux), it's quite possible for stat to fail with
permission denied. In this case, os.path.exists will
return False incorrectly. The simple(ish) fix is to
check for an access denied error (which would indicate
present, but not readable) when using stat to check for
existence of files.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-05-31 00:09
Message:
Logged In: YES
user_id=341410
I believe Terry was curious about something like
os.path.exists("/etc/shadow/abc123") vs `ls -l
/etc/shadow/abc123`. If not, I know I am curious, and I
believe it may help with a corner case.
--
Comment By: Stephen Bennett (sbennett)
Date: 2005-02-16 14:46
Message:
Logged In: YES
user_id=817465
As far as I know (at least for SELinux), permission denied
on stat() always means that the file exists, but getattr
isn't allowed. As for a reproducible test case, probably the
simplest example is a vanilla Fedora Core 3 system with
SELinux enabled and strict policy. From a regular user
account, call os.path.exists("/etc/shadow"). It will return
False even though the file exists. For comparison, an `ls -l
/etc/shadow` from the command line will simply print
'Permission Denied'.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-02-16 12:26
Message:
Logged In: YES
user_id=593130
Does 'access denied' always mean 'present but not readable'
in every environment that gives such messages? I ask
because I have vague memories of wasting time trying to
get access to something that did not exist, because access
denied (or something like that) meant that I was denied
access even to info about whether it existed or not.
In any case, a reproducible example would help someone to
verify, fix, and write a test case for this if it is deemed to be
a fixable bug.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117601&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1161031 ] Neverending warnings from asyncore
Bugs item #1161031, was opened at 2005-03-11 13:34 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. -- >Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 19:15 Message: Logged In: YES user_id=552329 Yes this problem is easily solved by subclassing. However I firmly believe that it is a terrible default behaviour, and that it's likely to hit many asyncore users. A class shouldn't have to be subclassed to be usable (ignoring virtual classes and all that), and that really is the case here. The simplest solution would be to change the handler to not log the message. Or log the message once per socket or something. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 19:03 Message: Logged In: YES user_id=341410 Option 1 is not really an option in any case where a large number of connections are opened (so I don't believe should be the default). >From what I understand, certain methods are supposed to be overridden in a subclass if someone using a class wants different behavior. In this case, I believe you can perform either option 2 or 3 in your own code to avoid the thousands of logged lines; either by creating your own loop() function, or by creating a subclass of dispatcher and implementing a handle_expt() method that does as you desire. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1161031 ] Neverending warnings from asyncore
Bugs item #1161031, was opened at 2005-03-10 16:34 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 00:31 Message: Logged In: YES user_id=341410 I hate to point out the obvious, but dispatcher is wholly unusable without subclassing. How would you get data to/from a connection without replacing handle_read, handle_write? How do you handle the case when you want to connect to someone else or accept connections from someone else without overloading handle_connect or handle_accept? -- Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 00:15 Message: Logged In: YES user_id=552329 Yes this problem is easily solved by subclassing. However I firmly believe that it is a terrible default behaviour, and that it's likely to hit many asyncore users. A class shouldn't have to be subclassed to be usable (ignoring virtual classes and all that), and that really is the case here. The simplest solution would be to change the handler to not log the message. Or log the message once per socket or something. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 00:03 Message: Logged In: YES user_id=341410 Option 1 is not really an option in any case where a large number of connections are opened (so I don't believe should be the default). >From what I understand, certain methods are supposed to be overridden in a subclass if someone using a class wants different behavior. In this case, I believe you can perform either option 2 or 3 in your own code to avoid the thousands of logged lines; either by creating your own loop() function, or by creating a subclass of dispatcher and implementing a handle_expt() method that does as you desire. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1161031 ] Neverending warnings from asyncore
Bugs item #1161031, was opened at 2005-03-11 13:34 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. -- >Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 19:42 Message: Logged In: YES user_id=552329 dispatcher is not at all unusable without subclassing. You can get data with recv() and send it with send() etc. It can be treated as a thin wrapper around socket objects. Yes, you will want to subclass it to get more useful behaviour than you can get from a basic socket. I don't see that this means that you should be required to override the handle_expt() function, though. As much as possible a class should provide sensible methods, so that overriding is kept to a minimum. At the very least, this is a documentation error, since the documentation states: """ handle_expt( ) Called when there is out of band (OOB) data for a socket connection. This will almost never happen, as OOB is tenuously supported and rarely used. """ "Almost never" is completely wrong. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 19:31 Message: Logged In: YES user_id=341410 I hate to point out the obvious, but dispatcher is wholly unusable without subclassing. How would you get data to/from a connection without replacing handle_read, handle_write? How do you handle the case when you want to connect to someone else or accept connections from someone else without overloading handle_connect or handle_accept? -- Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 19:15 Message: Logged In: YES user_id=552329 Yes this problem is easily solved by subclassing. However I firmly believe that it is a terrible default behaviour, and that it's likely to hit many asyncore users. A class shouldn't have to be subclassed to be usable (ignoring virtual classes and all that), and that really is the case here. The simplest solution would be to change the handler to not log the message. Or log the message once per socket or something. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 19:03 Message: Logged In: YES user_id=341410 Option 1 is not really an option in any case where a large number of
[ python-Feature Requests-1209664 ] calling it revert is fine with me
Feature Requests item #1209664, was opened at 2005-05-27 07:36 Message generated for change (Comment added) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209664&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: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: calling it revert is fine with me Initial Comment: Calling it revert is fine with me. I don't want to get into an editor war thing, let's just say emacs is what I've always used; it's not a matter of any single "killer feature", it's a highly integrated system and I do everything in it (shell, news reader, email, syntax driven editing for N different languages, etc). I do use IDLE sometimes but comparing IDLE to Emacs is almost like comparing it to Eclipse. They're just light years apart. Btw re editor wars, I'm reminded of the T-shirt with a kid asking "Why are we running from the police, daddy?". The dad answers "Because we use emacs, son. They use vi". -- >Comment By: paul rubin (phr) Date: 2005-05-31 08:07 Message: Logged In: YES user_id=72053 I'm not sure what happened here. This is supposed to be a reply to kbk's question on item 1175686 which was a request for a "revert" function in IDLE. Somehow it got split off to a separate item. Yes, this should be merged with 1175686 and/or closed. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-30 01:49 Message: Logged In: YES user_id=80475 Please clarify what you're requesting. Is there some IDLE feature you want added or renamed. If this was just an editor rant, please close the RFE. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209664&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1205544 ] urllib has spurious print statement
Bugs item #1205544, was opened at 2005-05-20 12:26 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205544&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Stuart Wray (drcw) Assigned to: Nobody/Anonymous (nobody) Summary: urllib has spurious print statement Initial Comment: In Python 2.4.1, the procedure getproxies_environment() in urllib.py has a spurious print statement on line 1188: print proxies This was presumably used for testing, but not commented out. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 10:23 Message: Logged In: YES user_id=1188172 I can't find this line of code in urllib.py in the 2.4, 2.4.1, or 2.3.5 releases. Are you sure you didn't add it for testing? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1205544&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1211639 ] parser tells invalid syntax with correct code
Bugs item #1211639, was opened at 2005-05-31 00:36 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1211639&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 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: ntrunk (ntrunk) Assigned to: Nobody/Anonymous (nobody) Summary: parser tells invalid syntax with correct code Initial Comment: I work with python 2.4 on Win2000 Sp4. I wrote a simple game with 2 modules, importing one into the other. In the imported module I wrote in the first line the coding: iso-8859-15. Starting the script from the first module the parser shows 'invalid syntax'. By inserting *1* space in a comment line the script works fine! I reduced my scripts to the minimal lines, wich will reproduce the bug. (Actually the parser tells me, that the syntax error is in line 75 :-) Changing the coding to iso-8859-1 will making the bug dissapear. -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-05-31 10:51 Message: Logged In: YES user_id=89016 This is related to the new codec buffering code. It's a duplicate of bug #1175396 (and various others). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1211639&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-1209664 ] calling it revert is fine with me
Feature Requests item #1209664, was opened at 2005-05-27 02:36 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209664&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: Closed >Resolution: Invalid Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: calling it revert is fine with me Initial Comment: Calling it revert is fine with me. I don't want to get into an editor war thing, let's just say emacs is what I've always used; it's not a matter of any single "killer feature", it's a highly integrated system and I do everything in it (shell, news reader, email, syntax driven editing for N different languages, etc). I do use IDLE sometimes but comparing IDLE to Emacs is almost like comparing it to Eclipse. They're just light years apart. Btw re editor wars, I'm reminded of the T-shirt with a kid asking "Why are we running from the police, daddy?". The dad answers "Because we use emacs, son. They use vi". -- Comment By: paul rubin (phr) Date: 2005-05-31 03:07 Message: Logged In: YES user_id=72053 I'm not sure what happened here. This is supposed to be a reply to kbk's question on item 1175686 which was a request for a "revert" function in IDLE. Somehow it got split off to a separate item. Yes, this should be merged with 1175686 and/or closed. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-29 20:49 Message: Logged In: YES user_id=80475 Please clarify what you're requesting. Is there some IDLE feature you want added or renamed. If this was just an editor rant, please close the RFE. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1209664&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1210832 ] An error in Python Tutorial
Bugs item #1210832, was opened at 2005-05-29 17:28 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210832&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Gene (godhand) Assigned to: Nobody/Anonymous (nobody) Summary: An error in Python Tutorial Initial Comment: In section 4.4, the program should be written as follow to get the correct result: -- for n in range(2, 10): for x in range(2, n): if n % x == 0: print n, 'equals', x, '*', n/x break if x == n-1: print n, 'is a prime number' -- besides, the line "2 is a prime number" should not appear in the result output. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 11:31 Message: Logged In: YES user_id=1188172 As for 2 being prime, Josiah is right. As for your change to the code, it is equivalent to the one in the tutorial. Besides, the sample code is there to demonstrate the else clause on for/while loops, so maybe you should look into this? Closing as Invalid. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 08:22 Message: Logged In: YES user_id=341410 The indentation on your proposed code addition was lost during your post, re-post so that it is understandable. Further, from mathworld.com: "A prime number (or prime integer, often simply called a ''prime'' for short) is a positive integer p > 1 that has no positive integer divisors other than 1 and p itself. (More concisely, a prime number p is a positive integer having exactly one positive divisor other than 1.)" That is to say, 2 is prime, so should appear in the result output, and it seems to me that the code provided in tutorial section 4.4 is correct. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210832&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1209880 ] doc bug in Lock.acquire
Bugs item #1209880, was opened at 2005-05-27 16:04
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209880&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: Chris Perkins (cperkins)
Assigned to: Nobody/Anonymous (nobody)
Summary: doc bug in Lock.acquire
Initial Comment:
The docs for the acquire method in both the thread and
threading modules are incorrect. They describe an old
(insane) version that returned None when called with no
argument. It appears that acquire is now sane, and
always returns True or False.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-05-31 11:33
Message:
Logged In: YES
user_id=1188172
It certainly seems that there is a code path in Lock.acquire
that can return None, as the following excerpt from
Modules/threadmodule.c shows:
static PyObject *
lock_PyThread_acquire_lock(lockobject *self, PyObject *args)
{
int i = 1;
if (!PyArg_ParseTuple(args, "|i:acquire", &i))
return NULL;
Py_BEGIN_ALLOW_THREADS
i = PyThread_acquire_lock(self->lock_lock, i);
Py_END_ALLOW_THREADS
if (args == NULL) {
Py_INCREF(Py_None);
return Py_None;
}
else
return PyBool_FromLong((long)i);
}
Nevertheless, a_lock.acquire() still returns true.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209880&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1210832 ] An error in Python Tutorial
Bugs item #1210832, was opened at 2005-05-29 10:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210832&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Gene (godhand) Assigned to: Nobody/Anonymous (nobody) Summary: An error in Python Tutorial Initial Comment: In section 4.4, the program should be written as follow to get the correct result: -- for n in range(2, 10): for x in range(2, n): if n % x == 0: print n, 'equals', x, '*', n/x break if x == n-1: print n, 'is a prime number' -- besides, the line "2 is a prime number" should not appear in the result output. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-31 04:36 Message: Logged In: YES user_id=80475 The code and output in the tutorial is correct. Also, it fulfills its purpose as an example of "else" and "break" statements in a for-loop. The OP's code contains an error. It produces: NameError: name 'x' is not defined -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 04:31 Message: Logged In: YES user_id=1188172 As for 2 being prime, Josiah is right. As for your change to the code, it is equivalent to the one in the tutorial. Besides, the sample code is there to demonstrate the else clause on for/while loops, so maybe you should look into this? Closing as Invalid. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 01:22 Message: Logged In: YES user_id=341410 The indentation on your proposed code addition was lost during your post, re-post so that it is understandable. Further, from mathworld.com: "A prime number (or prime integer, often simply called a ''prime'' for short) is a positive integer p > 1 that has no positive integer divisors other than 1 and p itself. (More concisely, a prime number p is a positive integer having exactly one positive divisor other than 1.)" That is to say, 2 is prime, so should appear in the result output, and it seems to me that the code provided in tutorial section 4.4 is correct. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1210832&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1193180 ] Strange os.path.exists() results with invalid chars
Bugs item #1193180, was opened at 2005-05-01 01:13
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniele Varrazzo (dvarrazzo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Strange os.path.exists() results with invalid chars
Initial Comment:
Hi,
when there are invalid chars in a filename, os.path.exists
() behaves oddly, returning True.
The bug appears on win32 system, not on unix ones.
Thus is probably related to some weird windows api call
and doesn't maybe worth fixing.
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import os
>>> f = file("a_b", "w")
>>> f.close()
>>> os.listdir(".")
['a_b']
>>> os.path.exists("a>> os.path.exists("a>b")
True
And, even more strange...
>>> os.path.exists("a<")
True
>>> os.path.exists("a>")
False
Better answers would have been:
* False
* raise ValueError
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-05-31 11:56
Message:
Logged In: YES
user_id=1188172
I think Python just uses the Win32 system call, so there
isn't much Python can do about it.
--
Comment By: engelbert gruber (grubert)
Date: 2005-05-23 08:52
Message:
Logged In: YES
user_id=147070
testing with perl: print -e "a<"; returns True/1 too
--
Comment By: Jarek Zgoda (zgoda)
Date: 2005-05-02 14:04
Message:
Logged In: YES
user_id=9
Same for Python 2.3.5.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193180&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1209447 ] os.path.join() fails if 2nd arg is a UNC path
Bugs item #1209447, was opened at 2005-05-26 22:45
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209447&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.join() fails if 2nd arg is a UNC path
Initial Comment:
os.path.join('c:', r'\server\share') returns
c:\server\share rather than \server\share.
Interestingly os.path.join('c:a', r'\server\share')
returns r'\server\share'. IMHO, r'\server\share'
should be returned in all cases.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-05-31 12:25
Message:
Logged In: YES
user_id=1188172
This is a difficult issue, since as far as I recall Windows
allows two or more backslashes in a row in the middle of
normal paths.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209447&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1209411 ] divmod documentation shd reference // not /
Bugs item #1209411, was opened at 2005-05-26 21:47 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209411&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: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: divmod documentation shd reference // not / Initial Comment: At http://docs.python.org/lib/typesnumeric.html we find: divmod(x, y) the pair (x / y, x % y) (3)(4) This should be: divmod(x, y) the pair (x // y, x % y) (3)(4) At http://docs.python.org/lib/built-in-funcs.html#built-in-funcs we find: divmod( a, b) For plain and long integers, the result is the same as (a / b, a % b). This should be: For plain and long integers, the result is the same as (a // b, a % b). Alternatively there could be a reference to "from __future__ import division" but the proposed change is cleaner and will last. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 12:27 Message: Logged In: YES user_id=1188172 Agreed. This should be changed in the documentation before it becomes wrong in Py3k ;) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209411&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202395 ] Description of string.lstrip() needs improvement
Bugs item #1202395, was opened at 2005-05-15 12:50 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: Description of string.lstrip() needs improvement Initial Comment: In http://docs.python.org/lib/string-methods.html, under lstrip(), it says, "chars must be a string; the characters in the string will be stripped from the beginning of the string this method is called on". It would be clearer if it said: "chars must be a string; the characters in the string constitute a set of characters to be stripped from the beginning of the string this method is called on". Similarly for rstrip() and strip(). There was a recent posting to comp.lang.python where it appears that the poster thought the argument to lstrip() was a leading string to be removed, not a set of characters. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-31 05:27 Message: Logged In: YES user_id=80475 Okay, fixed. Thanks for the report. -- Comment By: liturgist (liturgist) Date: 2005-05-23 11:03 Message: Logged In: YES user_id=197677 It would also be helpful to note the definition of "whitespace" in each of the strip() methods. It appears to be defined in strip() as being identical to string.whitespace. However, I do not see a built-in whitespace for strings. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 20:18 Message: Logged In: YES user_id=593130 Over the years, several people have tripped over this and posted to c.l.p., so I think the existing text is unclear enough to arguably qualify as a buglet. In response to the same posting, I had the same thought of clarifying that the 'string' defines a set, so I support this suggestion or something similar ;-) and thank you for submitting it. -- Comment By: Roy Smith (roysmith) Date: 2005-05-15 12:55 Message: Logged In: YES user_id=390499 I notice bug #1196824 (recently submitted and closed as "not a bug") relates to the same issue. It seems more than one person has gotten confused by this :-) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202395&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1209411 ] divmod documentation shd reference // not /
Bugs item #1209411, was opened at 2005-05-26 14:47 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209411&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: divmod documentation shd reference // not / Initial Comment: At http://docs.python.org/lib/typesnumeric.html we find: divmod(x, y) the pair (x / y, x % y) (3)(4) This should be: divmod(x, y) the pair (x // y, x % y) (3)(4) At http://docs.python.org/lib/built-in-funcs.html#built-in-funcs we find: divmod( a, b) For plain and long integers, the result is the same as (a / b, a % b). This should be: For plain and long integers, the result is the same as (a // b, a % b). Alternatively there could be a reference to "from __future__ import division" but the proposed change is cleaner and will last. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-31 06:04 Message: Logged In: YES user_id=80475 Fixed. Thanks for the report. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 05:27 Message: Logged In: YES user_id=1188172 Agreed. This should be changed in the documentation before it becomes wrong in Py3k ;) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1209411&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-691733 ] Let assign to as raise SyntaxWarning as well
Bugs item #691733, was opened at 2003-02-23 18:08 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=691733&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 2.5 Status: Open Resolution: None Priority: 2 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Let assign to as raise SyntaxWarning as well Initial Comment: according to the Python Language Reference Manual: > In some future version of Python, the identifiers > as and None will both become keywords. Hence, it seems natural to me to raise a SyntaxWarning when assigning to either of these. However, the current Python implementation doesn't: 103 >>> None="foo":1: SyntaxWarning: assignment to None 104 >>> as="foo" 105 >>> For consistency and cleanliness, assignment to 'as' should raise a SyntaxWarning as well. Currently, it's possible to not know it'll be a keyword and use it as a variable; people shouldn't, so a SyntaxWarning would be good. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 13:23 Message: Logged In: YES user_id=1188172 This may be too late if as becomes a keyword in the new with/do/whatever-statement... -- Comment By: Gerrit Holl (gerrit) Date: 2003-02-23 18:21 Message: Logged In: YES user_id=13298 I'm not sure whether this should be considered as a feature. I'd call it a minor wart... I'm also not sure about the category, is this 'Python interpreter core' or am I right with 'parser/compiler'? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=691733&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-757365 ] FutureWarning: %u/%o/%x/%X of negative int will return a sig
Bugs item #757365, was opened at 2003-06-19 18:35 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757365&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Duncan Grant (duncangrantuk) Assigned to: Nobody/Anonymous (nobody) Summary: FutureWarning: %u/%o/%x/%X of negative int will return a sig Initial Comment: printf style formatting: "FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up" The library reference clearly states that these are UNSIGNED representations, so the Futurewarning must be spurious! Please tell me you don't really intend to break this in 2.4 In 20+ yrs of low level bit-twiddling I have never ever wanted a signed hexadecimal. The idea of a signed hex or octal is just plain stupid. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 13:30 Message: Logged In: YES user_id=1188172 Now that this has already been "broken", the bug can be closed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757365&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-750328 ] Pickle fails to restore new-style class instance in a cycle
Bugs item #750328, was opened at 2003-06-06 23:13 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750328&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: Type/class unification Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: Pickle fails to restore new-style class instance in a cycle Initial Comment: Here is code to demonstrate the problem. All asserts succeed except the last, showing that pickle and cPickle both handle a "classic" cycle correctly, but only cPickle handles new-style cycles correctly. It would appear that the problem is that the pure-Python pickle isn't putting the object into its 'memo' until *after* the object's state has been pickled. Thus, the identity is not preserved on unpickling. This may be true for other object types that use __reduce__, but I have not verified this. import pickle, cPickle class X: pass x = X() x.x = x x2 = cPickle.loads(cPickle.dumps(x)) assert x2.x is x2 x2 = pickle.loads(pickle.dumps(x)) assert x2.x is x2 class Y(object): pass y = Y() y.y = y y2 = cPickle.loads(cPickle.dumps(y)) assert y2.y is y2 # this fails y2 = pickle.loads(pickle.dumps(y)) assert y2.y is y2 -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 13:34 Message: Logged In: YES user_id=1188172 Runs fine in Py2.4.1 too, so should it be considered fixed? -- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 05:00 Message: Logged In: YES user_id=80475 Another datapoint: This above script runs fine in Py2.3b2. -- Comment By: Steven Taschuk (staschuk) Date: 2003-06-08 22:23 Message: Logged In: YES user_id=666873 Compare bug 702858, which observes the same behaviour for copy.deepcopy. The common parts of pickle and copy really ought to be merged. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750328&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-763007 ] dl module not installed with 2.2.3
Bugs item #763007, was opened at 2003-06-30 07:08 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763007&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: Build Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mike Messmore (salmo) Assigned to: Nobody/Anonymous (nobody) Summary: dl module not installed with 2.2.3 Initial Comment: I'm running Redhat 7.3 on an older PII. I was attemping to try out the python bindings for gstreamer when I discovered my build of python 2.2.3 was lacking the 'dl' module. I've installed RPMS built from the SRPMS available on the python.org site (with the non-redhat9 spec file). Looking around I have not found a reason for this, nor a way to go about fixing it, so I assume it is a bug. Whenever I try to run a gst-python example I get an ImportError stating the the dl module does not exist, as well as when I try to run test_dl.py in my /usr/lib/python2.2/test/ directory. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 13:36 Message: Logged In: YES user_id=1188172 Is this still an issue? The group is Python 2.2.3, so should it be considered out of date? -- Comment By: Mike Messmore (salmo) Date: 2003-07-01 07:31 Message: Logged In: YES user_id=121084 >From the output it seems to never try to compile dlmodule.c. I ran 'rpm --rebuild python2-2.2.3-1.src.rpm 2&>1 >python_build.txt' and grepped the resulting text for dlmodule.c and only found it placing the file in the build directory. It found dlfcn.h fine. If you need me to I can attach the python_build.txt file here, but I can't find any visable errors in the building process. By the way, feel free to let me know at any point if I'm doing something retarded. -- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 17:22 Message: Logged In: YES user_id=33168 What is the error when building dlmodule.c? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763007&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-772176 ] digraphs on komment lines / xlib
Bugs item #772176, was opened at 2003-07-16 11:24 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772176&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: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Gregory Eckersley (daddio_2) Assigned to: Nobody/Anonymous (nobody) Summary: digraphs on komment lines / xlib Initial Comment: Python 2.3 falls over if it encounters non-ascii characters on comment lines. These occur with digraphs and non English names. e.g. This simple program #!/usr/bin/python print 'This program does nothing' # Aber eine Kommentarzeile l�uft nicht! # The " � " causes trouble # This causes Xlib to stop working causes the following output sys:1: DeprecationWarning: Non-ASCII character '\xe4' in file /nglob/g/bat/digraph.py on line 6, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details This program does nothing Some libraries (such as python-xlib 2.2 ) cause this problem. The line parser ought ignore all comment content whether ascii or not. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 13:41 Message: Logged In: YES user_id=1188172 This should already have been closed. As it is related to python-xlib, marking as "3rd Party". -- Comment By: Gregory Eckersley (daddio_2) Date: 2003-07-21 02:37 Message: Logged In: YES user_id=823572 I understand & agree with your comments. I did not include the exact version since it , as you say, seems to be an undesirable (in this case) consequence of the PEP. Please consider this bug report closed, and I'll follow it up in the short term with xlib, and in the longer term with the PEP after looking at whether there is a simple and systematic way of handling this. -- Comment By: Terry J. Reedy (tjreedy) Date: 2003-07-20 22:46 Message: Logged In: YES user_id=593130 1. Python 2.3 has not been released yet. Please indicate exact versions on bug reports. Including the system and OS often helps too. 2. The reported behavior is intentional and not a bug. See Reference Manual 2. Lexical analysis: "Python uses the 7-bit ASCII character set" and the referenced PEP 0263. Please close this report. 3. If a standard library module were to generate this warning, that would be a bug that should be reported here. If a third-party library does so, get a version updated for 2.3 or request that the authors make one. 4. If you want to discuss intended behavior, post to comp.lang.python. While your request about ignoring comments is superficially reasonable, the PEP seems to indicate that encoding is dealt with, and the warning issued, *before* any actual parsing, which is to say, before the parser knows what is a comment and what is not. Detecting comments is not trivial since '#' within a string does not start a comment. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772176&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1058786 ] r'\10' as replacement pattern loops in compilation
Bugs item #1058786, was opened at 2004-11-02 13:39 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058786&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nick Maclaren (nmm1) Assigned to: Gustavo Niemeyer (niemeyer) Summary: r'\10' as replacement pattern loops in compilation Initial Comment: The following program loops under at least Solaris 9 on SPARC and Linux (kernel 2.6) in x86. From tracebacks, it seems to be in the internal compilation of the pattern r'\10'. from re import compile line = "" pat = compile(12 * r'(\d+)') ltarget = float(pat.sub(r'\10',line)) print ltarget -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 13:45 Message: Logged In: YES user_id=1188172 Setting group to Python 2.3. If there won't be a 2.3.6 in the future, it can be closed. -- Comment By: Nick Maclaren (nmm1) Date: 2004-11-02 14:28 Message: Logged In: YES user_id=652073 I have also checked, and it is fixed. From my point of view, it isn't worth backporting, as I can upgrade and don't mind using a beta version. -- Comment By: Michael Hudson (mwh) Date: 2004-11-02 14:07 Message: Logged In: YES user_id=6656 It does seem to be fixed in 2.4, but not in 2.3(.3, anyway). I know some of the re changes for 2.4 are fairly large, so I don't know whether the fix is a backport candidate for 2.3.5. Gustavo might know. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-11-02 14:07 Message: Logged In: YES user_id=469548 I get the following on Python 2.4/Linux 2.6.8, so it does seem to be fixed: >>> from re import compile >>> line = "" >>> pat = compile(12 * r'(\d+)') >>> ltarget = float(pat.sub(r'\10',line)) Traceback (most recent call last): File "", line 1, in ? ValueError: empty string for float() -- Comment By: Fredrik Lundh (effbot) Date: 2004-11-02 14:00 Message: Logged In: YES user_id=38376 If you need a workaround for 2.2, use a sub callback: http://effbot.org/zone/re-sub.htm#callbacks -- Comment By: Fredrik Lundh (effbot) Date: 2004-11-02 13:58 Message: Logged In: YES user_id=38376 Cannot check this right now, but I'm 99% sure that this has been fixed in 2.4. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1058786&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1117601 ] os.path.exists returns false negatives in MAC environments.
Bugs item #1117601, was opened at 2005-02-07 00:57
Message generated for change (Comment added) made by sbennett
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117601&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: Stephen Bennett (sbennett)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.exists returns false negatives in MAC environments.
Initial Comment:
In Mandatory Access Control environments (such as
SELinux), it's quite possible for stat to fail with
permission denied. In this case, os.path.exists will
return False incorrectly. The simple(ish) fix is to
check for an access denied error (which would indicate
present, but not readable) when using stat to check for
existence of files.
--
>Comment By: Stephen Bennett (sbennett)
Date: 2005-05-31 12:56
Message:
Logged In: YES
user_id=817465
In the case of /etc/shadow/abc123, the stat will fail with
"Not a directory". However, attempting to stat /root/abc123
as a limited account will return permission denied unless
you have the search permission to the parent directory.
However, this is an issue with regular Unix permissions too
-- try to stat() a file that's inside a directory with 000
permissions.
One possible way around this is to attempt to get a listing
of the parent dir if the stat fails with permission denied
-- if it succeeds then the file exists but can't be statted;
if it fails then (at least for the purposes of the library
functions) if doesn't.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-05-31 07:09
Message:
Logged In: YES
user_id=341410
I believe Terry was curious about something like
os.path.exists("/etc/shadow/abc123") vs `ls -l
/etc/shadow/abc123`. If not, I know I am curious, and I
believe it may help with a corner case.
--
Comment By: Stephen Bennett (sbennett)
Date: 2005-02-16 22:46
Message:
Logged In: YES
user_id=817465
As far as I know (at least for SELinux), permission denied
on stat() always means that the file exists, but getattr
isn't allowed. As for a reproducible test case, probably the
simplest example is a vanilla Fedora Core 3 system with
SELinux enabled and strict policy. From a regular user
account, call os.path.exists("/etc/shadow"). It will return
False even though the file exists. For comparison, an `ls -l
/etc/shadow` from the command line will simply print
'Permission Denied'.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-02-16 20:26
Message:
Logged In: YES
user_id=593130
Does 'access denied' always mean 'present but not readable'
in every environment that gives such messages? I ask
because I have vague memories of wasting time trying to
get access to something that did not exist, because access
denied (or something like that) meant that I was denied
access even to info about whether it existed or not.
In any case, a reproducible example would help someone to
verify, fix, and write a test case for this if it is deemed to be
a fixable bug.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117601&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-834351 ] Mouse wheel crashes program
Bugs item #834351, was opened at 2003-11-02 01:37
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834351&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: Gary Richardson (garyrxx)
Assigned to: Martin v. Löwis (loewis)
Summary: Mouse wheel crashes program
Initial Comment:
The following program (by Michael Peuser) crashes as
soon as the mouse wheel is moved. See my post to
c.l.p. on Oct 29.
Gary Richardson
#-
from Tkinter import *
def _onMouseWheel(event):
print event
root = Tk()
root.bind('',_onMouseWheel)
root.mainloop()
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-05-31 15:11
Message:
Logged In: YES
user_id=1188172
Bumping, as it is still the same with 2.4 on my box.
--
Comment By: nikolaus heger (orthorim)
Date: 2005-05-12 16:41
Message:
Logged In: YES
user_id=933256
sdati, thanks for this workaround. it's awesome. i am now
happily mouse-wheeling :)
I did make a small improvement to it so it works for all
MouseWheel type events. Instead of
if sequence == "":
i say
if type(sequence) == str and
sequence.__contains__("MouseWheel"):
This way, all permutations of mouse events are covered, e.g.
""
--
Comment By: Steve Davis (sdati)
Date: 2005-02-08 03:40
Message:
Logged In: YES
user_id=1214285
I have determined the root cause of this problem. It actually does lie in
Tk, but is only revealed by Python Tkinter because of the way Python
deals with events.
>From Tk source -- tkWinX.c:
case WM_MOUSEWHEEL:
...
event.xany.send_event = -1
...
This line causes Tk to call TkpGetString() when ExpandPercents() is
called with '%A' (which is done by Python for ALL events, including
). This, in turn, causes segmentation fault because
event.xkey.trans_chars and event.xkey.nbytes are not initialized.
So, the workaround from the Python side is pretty ugly, but I have
tested it and verified that it works. There is probably a better way, but
this was the obvious solution to me, since I have never needed to look at
the Tkinter interface before:
In Tkinter.py, define a new _subst_format and _subst_format_str:
_subst_format_workaround = ('%#', '%b', '%f', '%h', '%k',
'%s', '%t', '%w', '%x', '%y',
'%D', '%E', '%K', '%N', '%W', '%T', '%X', '%Y', '%D')
_subst_format_str_workaround = " ".join(_subst_format_workaround)
Note that '%A' entry in _subst_format is replaced with '%D' entry in
_subst_format_workaround.
Now, in Misc._bind(),
if sequence == "":
cmd = ('%sif {"[%s %s]" == "break"} break\n'
%
(add and '+' or '',
funcid, self._subst_format_str_workaround))
else:
cmd = ('%sif {"[%s %s]" == "break"} break\n'
%
(add and '+' or '',
funcid, self._subst_format_str))
I am submitting this bug to Tcl/Tk maintainers to request that they fix
(Project: Tk Toolkit Request ID 1118340), but in the meantime (and for
all older versions of Tk), it seems like a workaround in the Tkinter code
might be appropriate.
--
Comment By: John Speno (corvus)
Date: 2005-01-04 16:40
Message:
Logged In: YES
user_id=2138
I wasn't able to reproduce this in pure Tcl/Tk (under Wish). No surprise
there. In wish, I used this:
toplevel .top
bind .top {puts 'foo'}
And mouse wheeling in the Toplevel widget made a bunch of 'foo's appear in
the wish console without crashing.
HTH.
--
Comment By: John Speno (corvus)
Date: 2005-01-04 16:02
Message:
Logged In: YES
user_id=2138
Me too. Python 2.3.4 with Tcl/Tk 8.4.9. Crash on Scroll Wheeling in WinXP
SP 1. (users report it happening in SP 2 also).
I'll try to make this happen in pure Tcl/Tk rather than Tkinter too.
--
Comment By: John Fouhy (johnfouhy)
Date: 2004-10-26 06:13
Message:
Logged In: YES
user_id=1084032
I can reproduce this bug. I am running Python 2.3.4 on
WinXP SP2.
tk84.dll is version 8.4.3; tcl84.dll is also 8.4.3.
The mousewheel works correctly with a Tkinter.Text object
with no additional bindings.
--
Comment By: Jon Ashley (ash101)
Date: 2003-12-04 18:02
Message:
Logged In: YES
user_id=923903
Happens for me too, on Win2K with python 2.3.2. The fault is
in TCL84.DLL at an offs
[ python-Bugs-1212077 ] itertools.groupby ungraceful, un-Pythonic
Bugs item #1212077, was opened at 2005-05-31 10:34 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=1212077&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: itertools.groupby ungraceful, un-Pythonic Initial Comment: The sharing of the result iterator by itertools.groupby leads to strange, arguably un-Pythonic behavior. For example, suppose we have a list of pairs that we're about to turn into a dict and we want to check first for duplicate keys. We might do something like this >>> [ (k,list(v)) for (k, v) in groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0]) ] [(1, [(1, 2), (1, 3)]), (2, [(2, 3)]), (3, [(3, 5)])] >>> [ (k,list(v)) for (k, v) in list(groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0])) ] [(1, []), (2, []), (3, [(3, 5)])] >>> [ (k,list(v)) for (k, v) in groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0]) if len(list(v)) > 1 ] [(1, [])] The first result looks good, but the second two silently produce what appear to be bizarre results. The second is understandable (sort of) if you know that the result iterator is shared, and the third I don't get at all. This silent failure seems very Perlish. At a minimum, if use is made of the "expired" result iterator, an exception should be thrown. This is a wonderfully useful function and ideally, there should be a version of groupby that behaves as a naive user would expect. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212077&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-1212091 ] sets needs an 'arbitrary element' method
Feature Requests item #1212091, was opened at 2005-05-31 10:54 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=1212091&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: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: sets needs an 'arbitrary element' method Initial Comment: It would be nice to have an "arbitrary element" method that would return some arbitrary element of a non-empty set (throwing an exception if the set is empty). Something like this >>> s = sets.Set([1,2,3]) >>> print s.element() 2 AFAIK, the current alternative would be to do something like this >>> print list(s)[0] which is somewhat expensive and unreadable. It'd be fine if the operator returned the same or a different element each time. Perhaps it'd be useful if it returned the same element each time for frozen sets. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&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-1212091 ] sets needs an 'arbitrary element' method
Feature Requests item #1212091, was opened at 2005-05-31 17:54 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&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: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: sets needs an 'arbitrary element' method Initial Comment: It would be nice to have an "arbitrary element" method that would return some arbitrary element of a non-empty set (throwing an exception if the set is empty). Something like this >>> s = sets.Set([1,2,3]) >>> print s.element() 2 AFAIK, the current alternative would be to do something like this >>> print list(s)[0] which is somewhat expensive and unreadable. It'd be fine if the operator returned the same or a different element each time. Perhaps it'd be useful if it returned the same element each time for frozen sets. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 17:59 Message: Logged In: YES user_id=1188172 For mutable sets, I think that pop() is better suited. Do you have a use case of your proposal with frozensets? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1212077 ] itertools.groupby ungraceful, un-Pythonic
Bugs item #1212077, was opened at 2005-05-31 10:34 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212077&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: itertools.groupby ungraceful, un-Pythonic Initial Comment: The sharing of the result iterator by itertools.groupby leads to strange, arguably un-Pythonic behavior. For example, suppose we have a list of pairs that we're about to turn into a dict and we want to check first for duplicate keys. We might do something like this >>> [ (k,list(v)) for (k, v) in groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0]) ] [(1, [(1, 2), (1, 3)]), (2, [(2, 3)]), (3, [(3, 5)])] >>> [ (k,list(v)) for (k, v) in list(groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0])) ] [(1, []), (2, []), (3, [(3, 5)])] >>> [ (k,list(v)) for (k, v) in groupby([(1,2), (1,3), (2,3), (3,5)], lambda x: x[0]) if len(list(v)) > 1 ] [(1, [])] The first result looks good, but the second two silently produce what appear to be bizarre results. The second is understandable (sort of) if you know that the result iterator is shared, and the third I don't get at all. This silent failure seems very Perlish. At a minimum, if use is made of the "expired" result iterator, an exception should be thrown. This is a wonderfully useful function and ideally, there should be a version of groupby that behaves as a naive user would expect. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-31 11:16 Message: Logged In: YES user_id=80475 Sorry, this is more of a rant than a bug report. The tool is functioning as designed and documented. The various design options were discussed on python-dev and this was what was settled on as the most useful, general purpose tool (eminently practical, but not idiotproof). Like other itertools, it can be used in a straight-forward manner or be used to write cryptic, mysterious code. In general, if you can't follow your own code (in situatations such as the above), a good first step is to unroll the list comprehension into a regular for-loop as that tends to make the assumptions and control flow more visible. Also, it can be taken as a hint that the itertool is not being used as intended. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212077&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-1212091 ] sets needs an 'arbitrary element' method
Feature Requests item #1212091, was opened at 2005-05-31 10:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&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: Mike Coleman (mkc) Assigned to: Nobody/Anonymous (nobody) Summary: sets needs an 'arbitrary element' method Initial Comment: It would be nice to have an "arbitrary element" method that would return some arbitrary element of a non-empty set (throwing an exception if the set is empty). Something like this >>> s = sets.Set([1,2,3]) >>> print s.element() 2 AFAIK, the current alternative would be to do something like this >>> print list(s)[0] which is somewhat expensive and unreadable. It'd be fine if the operator returned the same or a different element each time. Perhaps it'd be useful if it returned the same element each time for frozen sets. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-05-31 11:54 Message: Logged In: YES user_id=80475 I had looked at putting in a choose() method but there were a shortage of use cases that were not better served by pop() or by iteration. Will leave this open as the request may yet prove its worth. To do so, I would need to see examples of practical code where choose() is a better choice than existing alternatives. For the record, here were some of the lines of thinking about choose(). * Given that any element could be returned, it was logical to return the first encountered. That led to the odd situation where the method would return the same value on every call (unless followed by a set mutation) making the method useless in a loop. * If needed, an efficient alternative is available: iter(s).next(). And here is a more readable, encapsulated version that a programmer could dash off in seconds: def choose(s, default=None): for elem in s: return elem return default * I had looked at a few textbook algorithms that were expressed in terms of choose(). Without exception, their Python code was better expressed using pop(), In a couple of cases, the pop() needed to be followed by an add() if the item was to be left in the set. Those two cases all had other set mutations occuring on each iteration (otherwise, the pop/add pair would always get the same element). -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 10:59 Message: Logged In: YES user_id=1188172 For mutable sets, I think that pop() is better suited. Do you have a use case of your proposal with frozensets? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212091&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-1212169 ] Prepending Text
Feature Requests item #1212169, was opened at 2005-05-31 11:59 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=1212169&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: Aaron Elbaz (flamesrock) Assigned to: Nobody/Anonymous (nobody) Summary: Prepending Text Initial Comment: Perhaps this has already been considered, but I have an idea that would make neat addition to python: Appending a string to another string can be done with += or .join(), but currently, there is no elegant way to prepend to a string. How about something like- string.prepend(list.pop(0) ? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212169&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-1212169 ] Prepending Text
Feature Requests item #1212169, was opened at 2005-05-31 19:59 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212169&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: Aaron Elbaz (flamesrock) Assigned to: Nobody/Anonymous (nobody) Summary: Prepending Text Initial Comment: Perhaps this has already been considered, but I have an idea that would make neat addition to python: Appending a string to another string can be done with += or .join(), but currently, there is no elegant way to prepend to a string. How about something like- string.prepend(list.pop(0) ? -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 20:48 Message: Logged In: YES user_id=1188172 -0. What's wrong with >>> string = something + string Also, the above conveys the notion that this is an expensive operation (when done multiple times, e.g. in a loop) better than a str method. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1212169&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1212195 ] str.lower() to have an IMPORTANT NOTE or it's for magicians
Bugs item #1212195, was opened at 2005-05-31 21:56
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=1212195&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: Nikos Kouremenos (nkour)
Assigned to: Nobody/Anonymous (nobody)
Summary: str.lower() to have an IMPORTANT NOTE or it's for magicians
Initial Comment:
lower() {maybe others} should mention that if used with
string object [not unicode object] it's likely the that
encoding will change unde some locales [eg pl_PL makes
it from utf8 to latin2]!!
or this hsould be put in the beginning of the doc in
str as a general WARNING/NOTE:
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212195&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1212223 ] anydbm and 'n' flag
Bugs item #1212223, was opened at 2005-05-31 12:32 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=1212223&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: Jack Moffitt (jackiem) Assigned to: Nobody/Anonymous (nobody) Summary: anydbm and 'n' flag Initial Comment: When a 0 length file exists and anydbm is asked to create a new database with that file name via the anydbm.open(fn, 'n') call, the call fails as whichdb detection fails. whichdb should not be invoked with the 'n' flag, since the purpose of this flag is to always create a database, not only if it is missing. This bug prevents creating a secure temporary file with mkstemp and then uisng that file to open a database. The workaround is to unlink the file then call open, but this is leaving a small hole. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212223&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1161031 ] Neverending warnings from asyncore
Bugs item #1161031, was opened at 2005-03-10 16:34 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Neverending warnings from asyncore Initial Comment: Changes in asyncore from 2.3 to 2.4 mean that asyncore.poll() now passes all the sockets in the map to select.select() to be checked for errors, which is probably a good thing. If an error occurs, then handle_expt() is called, which by default logs the error. asyncore.dispatcher creates nonblocking sockets. When connect_ex() is called on a nonblocking socket, it will probably return EWOULDBLOCK (connecting takes time), which may mean the connection is successful, or may not (asyncore dispatcher keeps going assuming all is well). If the connection is not successful, and then asyncore.loop() is called, then select.select() will indicate that there is an error with the socket (can't connect) and the error will be logged. The trouble is that asyncore.loop then keeps going, and will log this error again. My not-that-fast system here gets about 10,000 logged messages per second with a single socket in the asyncore map. There are ways to avoid this: (1) if the socket is blocking when connect()ing (and then nonblocking afterwards) an error is raised if the connect fails. (2) Before calling asyncore.loop(), the caller can run through all the sockets, checking that they are ok. (3) handle_expt() can be overridden with a function that repairs or removes the socket from the map (etc) However, I'm not convinced that this is good behavior for asyncore to have, by default. On Windows, select.select() will only indicate an error when trying to connect (nonblocking) or if SO_OOBINLINE is disabled, but this may not be the case (i.e. errors can occur at other times) with other platforms, right? Unless the error is temporary, asyncore will by default start streaming (extremely fast) a lot of "warning: unhandled exception" (not very helpful an error message, either) messages. Even if the error only lasts a minute, that could easily result in 10,000 warnings being logged. Do any of the python developers agree that this is a flaw? I'm happy to work up a patch for whatever the desired solution is, if so. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-31 12:34 Message: Logged In: YES user_id=341410 You seem to be unwilling to subclass asyncore.dispatcher to extend its functionality, and the only reason you have given as to why you are unwilling is "As much as possible a class should provide sensible methods, so that overriding is kept to a minimum." (I personally subclass dispatcher and its async_chat derivative qutie often) Now, in the case of the other standard socket server and client framework in the Python standard library, namely the SocketServer module and its derivatives, you will find extending the functionality of those classes is via subclassing and overriding methods as necessary. To me, when two 'competing' methods of generating socket servers and clients in the standard library offer the same method of extension of their base functionality, then perhaps that is what should be done. The fact that basically all of the standard library is subclassable (some C modules are exceptions to the rule, but should be fixed in Python 2.5), including types in the base language, further suggests to me that subclassing is the standard mechanism for extending the functionality of a class, regardless of its usefulness in its base state. In regards to the documentation, it seems to be that whenever an object has an error, the handle_expt() method is called (in spending two minutes reading the source). Whether or not those errors are rare, perhaps debatable (I've not seen any in years), but it seems to be application-specific as to what behavior the socket should have in the case of an error (you may want to close, I may want to report the error and reconnect, etc.). -- Comment By: Tony Meyer (anadelonbrin) Date: 2005-05-31 00:42 Message: Logged In: YES user_id=552329 dispatcher is not at all unusable without subclassing. You can get data with recv() and send it with send() etc. It can be treated as a thin wrapper around socket objects. Yes, you will want to subclass it to get more useful behaviour than you can get from a basic socket. I don't see that this means that you should be required to override the handle_expt() function, thou
[ python-Bugs-860515 ] fileinput does not use universal input
Bugs item #860515, was opened at 2003-12-15 20:11 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860515&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: fileinput does not use universal input Initial Comment: In Python 2.3.0 the fileinput module does not appear to use universal line ending mode for reading files. I found this using MacPython 2.3 (via the binary installer) but looking at the module it appears to be vanilla code. I confess I didn't see where the files were opened, so I cannot suggest a fix. Sample code: import fileinput for line in fileinput.input(): print line[0:20] try this with text files that have some other platform's line endings. For me, it works on MacOS X for files with unix line endings, but fails if the file(s) have Mac line endings. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-05-31 23:42 Message: Logged In: YES user_id=1188172 See patch #1212287. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=860515&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1212223 ] anydbm and 'n' flag
Bugs item #1212223, was opened at 2005-05-31 19:32 Message generated for change (Settings changed) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212223&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: Wont Fix Priority: 5 Submitted By: Jack Moffitt (jackiem) Assigned to: Nobody/Anonymous (nobody) Summary: anydbm and 'n' flag Initial Comment: When a 0 length file exists and anydbm is asked to create a new database with that file name via the anydbm.open(fn, 'n') call, the call fails as whichdb detection fails. whichdb should not be invoked with the 'n' flag, since the purpose of this flag is to always create a database, not only if it is missing. This bug prevents creating a secure temporary file with mkstemp and then uisng that file to open a database. The workaround is to unlink the file then call open, but this is leaving a small hole. -- >Comment By: Sean Reifschneider (jafo) Date: 2005-06-01 03:00 Message: Logged In: YES user_id=81797 I'm torn as to what should happen here. In the documentation, it says that in the event that the file exists, the whichdb module will be used to determine the type of the database. In the case of an unrecognised database format, that function returns the empty string, and anydbm raises that as an exception. On the other hand, the documentation says that if "n" is passed a new database will always be created, which in this case it definitely is not. I'd be reluctant to change anydbm.open(), since the reason for anydbm to exist is that it determines the database type of an existing file, and in the case that it doesn't understand the database type it says so. One could imagine a "textdb" type being added later where an empty file would be a valid, empty, textdb file, but a change to anydbm here could lead to problems in the future. The real solution, I would propose, is that in the event that you're trying to create a temporary database, call mkstemp, then call "anydbm._defaultmod.open" on the resulting file name, for example. Call the module directly instead of relying on anydbm. I'm inclined to close this as Wont Fix, please re-open if you think the assessment is wrong. Sean -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212223&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1212411 ] Incorrect result for regular expression - "|(hello)|(world)"
Bugs item #1212411, was opened at 2005-06-01 05:13
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=1212411&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Vijay Kumar (karamana)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Incorrect result for regular expression - "|(hello)|(world)"
Initial Comment:
The regular expression "|hello|world" incorrectly gives a
match, owing to the starting '|'. Below is a sample
program which highlights this. The correct result
behavior is to return None:
If the leading '|' is removed then the result is correct.
-
import re
m = re.search("|hello|world","This is a simple sentence")
print m
m2 = re.search("hello|world","This is a simple sentence")
print m2
output ---
<_sre.SRE_Match object at 0x00B71F70>
None
--
The first one is incorrect. Should have returned a None.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212411&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1212411 ] Incorrect result for regular expression - "|(hello)|(world)"
Bugs item #1212411, was opened at 2005-06-01 01:13
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212411&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Regular Expressions
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Vijay Kumar (karamana)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: Incorrect result for regular expression - "|(hello)|(world)"
Initial Comment:
The regular expression "|hello|world" incorrectly gives a
match, owing to the starting '|'. Below is a sample
program which highlights this. The correct result
behavior is to return None:
If the leading '|' is removed then the result is correct.
-
import re
m = re.search("|hello|world","This is a simple sentence")
print m
m2 = re.search("hello|world","This is a simple sentence")
print m2
output ---
<_sre.SRE_Match object at 0x00B71F70>
None
--
The first one is incorrect. Should have returned a None.
--
>Comment By: Tim Peters (tim_one)
Date: 2005-06-01 01:19
Message:
Logged In: YES
user_id=31435
I expect you'll find that, e.g., Perl does the same thing:
a "missing" alternative is treated as an empty string, and an
empty string always matches. What basis do you have for
claiming it should not match (beyond just repeating that it
should not )?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1212411&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
