[ python-Bugs-1370380 ] asynchat.async_chat.push() function doesnt say when failed
Bugs item #1370380, was opened at 2005-11-30 22:18 Message generated for change (Comment added) made by jjdmol You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&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: Jan David Mol (jjdmol) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat.async_chat.push() function doesnt say when failed Initial Comment: suppose you have a socket handled by your asynchat.async_chat class and want to send a message (call push()). push() calls initiate_send(), which can call handle_error() if an error occurs. however, once handle_error() returns, the control is passed back to push(), which has no return value thus cannot signal the success or failure to the code that did the push(). i.e. if we have code like foo() s.push(data) bar() the following is executed in case of an error: foo() s.push(data) s.handle_error() bar() this created an obscure bug, as the bar() assumed the send() always succeeds, and also cannot check directly by the result of push() if it did. this creates the false illusion push() can never fail. to avoid this, handle_error() can set a flag, which can be checked after the push(). however, this is an ugly hack of course. PS: send() can easily fail. suppose we're reading from 2 sockets: A and B, and send messages to both when data is read from either one. if B gets disconnected and A has data ready, both will be in the set of readible sockets returned by select(). if A's data is handled before B's, and A sends a message to B, this will cause the send to fail as B is disconnected. your app wont know B failed, because this is processed after the data from A is processed. -- >Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 09:18 Message: Logged In: YES user_id=516066 Push() sending data may indeed be the source of the problems here. There should be no problems with delaying the write until the next select() will tell the socket is writable. My current work around is indeed subclassing as you describe. However, it seemed that such a thing would be exactly that: a work around in order to obtain expected behaviour. So a suggestion: push() should either not try to send, or should communicate back to its caller when an error occurs. Having an error handler set an error code to check is so 80s, but that could be just me :) Maybe push() not sending is the nicer of the two solutions. There is little reason why it can't wait till the next select() call returns the socket as writable. If nothing is changed, the documentation should contain that handle_error() can be triggered even though one is only adding stuff to a FIFO buffer (or so the description of push() makes it seem). Reading the docs doesn't prepare you for the control flow as I first described. In all the other handle_error invocations, handle_error() isn't called from within your code unless you raise exceptions in your part of the handle_read/write/accept/connect code. Even in asyncore, send() gives you an exception instead, creating an inconsistency with asynchat's push(), as both can fail. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-14 07:16 Message: Logged In: YES user_id=341410 Not a bug. The control for deciding how to handle an error in a connection is defined by the instance method handle_error(). If you would like custom error handling in your instances, perhaps you should subclass async_chat... import asynchat class MyAsyncChat(asynchat.async_chat): error = 0 def handle_error(self): self.error = 1 asynchat.async_chat.handle_error(self) def push(self, data): self.error = 0 asynchat.async_chat.push(self, data) return self.error Also, the fact that async_chat.push() ends up trying to send data, is, in my opinion, a misfeature in implementation. Under certain circumstances it can increase data throughput, but it removes the standard asyncore.loop/poll() from the control flow. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1370380 ] asynchat.async_chat.push() function doesnt say when failed
Bugs item #1370380, was opened at 2005-11-30 13:18 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&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: Jan David Mol (jjdmol) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat.async_chat.push() function doesnt say when failed Initial Comment: suppose you have a socket handled by your asynchat.async_chat class and want to send a message (call push()). push() calls initiate_send(), which can call handle_error() if an error occurs. however, once handle_error() returns, the control is passed back to push(), which has no return value thus cannot signal the success or failure to the code that did the push(). i.e. if we have code like foo() s.push(data) bar() the following is executed in case of an error: foo() s.push(data) s.handle_error() bar() this created an obscure bug, as the bar() assumed the send() always succeeds, and also cannot check directly by the result of push() if it did. this creates the false illusion push() can never fail. to avoid this, handle_error() can set a flag, which can be checked after the push(). however, this is an ugly hack of course. PS: send() can easily fail. suppose we're reading from 2 sockets: A and B, and send messages to both when data is read from either one. if B gets disconnected and A has data ready, both will be in the set of readible sockets returned by select(). if A's data is handled before B's, and A sends a message to B, this will cause the send to fail as B is disconnected. your app wont know B failed, because this is processed after the data from A is processed. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 00:32 Message: Logged In: YES user_id=341410 Here's a subclass that doesn't send on push... class MyAsyncChat(asynchat.async_chat): def push (self, data): self.producer_fifo.push (simple_producer (data)) That's it. And according to my reading of asynchat and asyncore, while actually trying to send data during a push() may trigger the handle_error() method to be called, by default, the handle_error() method logs the error and closes the socket. Errors don't seem to propagate out of push(). -- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 00:18 Message: Logged In: YES user_id=516066 Push() sending data may indeed be the source of the problems here. There should be no problems with delaying the write until the next select() will tell the socket is writable. My current work around is indeed subclassing as you describe. However, it seemed that such a thing would be exactly that: a work around in order to obtain expected behaviour. So a suggestion: push() should either not try to send, or should communicate back to its caller when an error occurs. Having an error handler set an error code to check is so 80s, but that could be just me :) Maybe push() not sending is the nicer of the two solutions. There is little reason why it can't wait till the next select() call returns the socket as writable. If nothing is changed, the documentation should contain that handle_error() can be triggered even though one is only adding stuff to a FIFO buffer (or so the description of push() makes it seem). Reading the docs doesn't prepare you for the control flow as I first described. In all the other handle_error invocations, handle_error() isn't called from within your code unless you raise exceptions in your part of the handle_read/write/accept/connect code. Even in asyncore, send() gives you an exception instead, creating an inconsistency with asynchat's push(), as both can fail. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-13 22:16 Message: Logged In: YES user_id=341410 Not a bug. The control for deciding how to handle an error in a connection is defined by the instance method handle_error(). If you would like custom error handling in your instances, perhaps you should subclass async_chat... import asynchat class MyAsyncChat(asynchat.async_chat): error = 0 def handle_error(self): self.error = 1 asynchat.async_chat.handle_error(self) def push(self, data): self.error = 0 asynchat.async_chat.push(self, data) return self.error Also, the fact that async_chat.push() ends up trying to send data, is, in my opinion, a misfeature in implementation. Under certain circumstances it can increase data throughput, but it removes the standard
[ python-Bugs-1361643 ] textwrap.dedent() expands tabs
Bugs item #1361643, was opened at 2005-11-19 20:02
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&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: 6
Submitted By: Steven Bethard (bediviere)
Assigned to: Greg Ward (gward)
Summary: textwrap.dedent() expands tabs
Initial Comment:
I'm not sure whether this is a documentation bug or a
code bug, but textwrap.dedent() expands tabs (and
AFAICT doesn't give the user any way of stopping this):
py> def test():
... x = ('abcdefgh\n'
... 'ijklmnop\n')
... y = textwrap.dedent('''... abcdefgh
... ijklmnop
... ''')
... return x, y
...
py> test()
('abcd\tefgh\nijkl\tmnop\n', 'abcdefgh\nijkl
mnop\n')
Looking at the code, I can see the culprit is the first
line:
lines = text.expandtabs().split('\n')
If this is the intended behavior, I think the first
sentence in the documentation[1] should be replaced with:
"""
Replace all tabs in string with spaces as per
str.expandtabs() and then remove any whitespace that
can be uniformly removed from the left of every line in
text.
"""
and (I guess this part is an RFE) textwrap.dedent()
should gain an optional expandtabs= keyword argument to
disable this behavior.
If it's not the intended behavior, I'd love to see that
.expandtabs() call removed.
[1]http://docs.python.org/lib/module-textwrap.html
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-15 09:45
Message:
Logged In: YES
user_id=1188172
Looks good!
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-11-20 07:04
Message:
Logged In: YES
user_id=80475
Suggested code:
import re as _re
_emptylines_with_spaces = _re.compile('(?m)^[ \t]+$')
_prefixes_on_nonempty_lines = _re.compile('(?m)(^[
\t]*)(?:[^ \t\n]+)')
def dedent(text):
text = _emptylines_with_spaces.sub('', text)
prefixes = _prefixes_on_nonempty_lines.findall(text)
margin = min(prefixes or [''])
if margin:
text = _re.sub('(?m)^' + margin, '', text)
return text
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-11-20 05:52
Message:
Logged In: YES
user_id=80475
After more thought, I think the expandtabs() is a bug since
it expands content tabs as well as margin tabs:
>>> textwrap.dedent('\tABC\t\tDEF')
'ABC DEF'
This is especially problematic given that dedent() has to
guess at the tab size.
If this gets fixed, I recommend using regular expressions as
a way to indentify common margin prefixes on non-empty
lines. This will also mixes of spaces and tabs without
altering content with embedded tabs and without making
assumptions about the tab size. Also, it ought to run
somewhat faster.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-11-19 21:18
Message:
Logged In: YES
user_id=80475
FWIW, the tab expansion would be more useful if the default
tabsize could be changed.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1378755 ] logging : fileConfig does not check existance of the file
Bugs item #1378755, was opened at 2005-12-12 14:24
Message generated for change (Comment added) made by vsajip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&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: Didrik Pinte (dpinte)
Assigned to: Vinay Sajip (vsajip)
Summary: logging : fileConfig does not check existance of the file
Initial Comment:
Hi,
The fileConfig method from the logging.config module
does not check for the existance of the config file
before trying to load it.
Worst, if the file does not exist, the exception is
totally unrelated to the file.
Example :
[EMAIL PROTECTED]:~/$ python
Python 2.3.5 (#2, Nov 20 2005, 16:40:39)
[GCC 4.0.3 2005 (prerelease) (Debian 4.0.2-4)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> from logging import config
>>> config.fileConfig('')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.3/logging/config.py", line 68,
in fileConfig
flist = cp.get("formatters", "keys")
File "/usr/lib/python2.3/ConfigParser.py", line 505,
in get
raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'formatters'
It is really important that the exception is correctly
reported.
In fact, the problem seems to be here :
/usr/lib/python2.3/ConfigParser.py, line 258
for filename in filenames:
try:
fp = open(filename)
except IOError:
continue
self._read(fp, filename)
The documentation of the read method says "Files that
cannot be opened are silently ignored;".
The behaviour of logging.config.fileConfig is highly
related to the user actions. He must be informed of the
fact that the logging system have not opened its file.
I will provide a very basic path :
File /usr/lib/python2.3/logging/config.py, line 61
-
import os
if not (os.path.file(fname)):
raise IOError('Provided filename is not existing')
-
Didrik
--
>Comment By: Vinay Sajip (vsajip)
Date: 2005-12-15 09:00
Message:
Logged In: YES
user_id=308438
I don't believe this is a logging bug. The logging code
defers to ConfigParser, and it is the responsibility of
ConfigParser to raise exceptions with appropriate messages.
Clearly, you could also pass an existing file with an
invalid format - the logging config code does not try to do
error recovery in these cases, but lets the exceptions
propagate up to calling code. Doing otherwise would amount
to defensive programming which I do not believe justified in
this case.
Please consider logging an issue against ConfigParser. After
all, a change there would benefit more than just the logging
package.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-15 05:58
Message:
Logged In: YES
user_id=33168
Vinay, any comments?
--
Comment By: Didrik Pinte (dpinte)
Date: 2005-12-12 14:27
Message:
Logged In: YES
user_id=970259
Oups, the patch should be the following :
File /usr/lib/python2.3/logging/config.py, line 61
-
import os
if not (os.path.isfile(fname)):
raise IOError('Provided filename is not existing')
--
Comment By: Didrik Pinte (dpinte)
Date: 2005-12-12 14:25
Message:
Logged In: YES
user_id=970259
i've reported it for Python 2.4 but I reproduced it on
Python 2.3.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1367814 ] loogger module locks
Bugs item #1367814, was opened at 2005-11-27 23:31 Message generated for change (Settings changed) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367814&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: Chris Fuller (cfuller) Assigned to: Nobody/Anonymous (nobody) Summary: loogger module locks Initial Comment: I have an application that uses the logger functionality, and the RotatingFileHandler class. If my application is running, and another instance is launched, it fails at the rollover step. I don't want multiple instances running at once, so this is fine, and even general, since the rollover must occur if an instance is already running. Rather than checking for a generic I/O error, however, I'd like to use some sort of locking mechanism that is less opaque. The locking provided won't work, since it is blocking only: the application deadlocks if one ias runnning already. Why doesn't it work like a normal Lock() instance and take a blocking parameter? I could use locking via the portalocker module from the python cookbook (hmm, portable file locking would be a nice thing to have in the standard library, the logger module already does it anyway!) but I can't find anyway to access the file descriptor! Sure, I could workaround that. I could create a RotatingFileHandler instance, roll over, close it, open the file, pass it to StreamHandler, but python is way more elegant than that. For now, I'll just trap the rollover. Still very cool stuff! -- >Comment By: Vinay Sajip (vsajip) Date: 2005-12-15 09:06 Message: Logged In: YES user_id=308438 Closing, as this does not appear to be a bug report. Thanks for your comments. My advice (if you have multiple processes logging to the same file) is to add a separate logging process (or perhaps a thread in one of the processes) which receives logging events from a socket and logs to files. This way, there is no contention for the file. See http://docs.python.org/lib/network-logging.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367814&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1370380 ] asynchat.async_chat.push() function doesnt say when failed
Bugs item #1370380, was opened at 2005-11-30 22:18 Message generated for change (Comment added) made by jjdmol You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&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: Jan David Mol (jjdmol) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat.async_chat.push() function doesnt say when failed Initial Comment: suppose you have a socket handled by your asynchat.async_chat class and want to send a message (call push()). push() calls initiate_send(), which can call handle_error() if an error occurs. however, once handle_error() returns, the control is passed back to push(), which has no return value thus cannot signal the success or failure to the code that did the push(). i.e. if we have code like foo() s.push(data) bar() the following is executed in case of an error: foo() s.push(data) s.handle_error() bar() this created an obscure bug, as the bar() assumed the send() always succeeds, and also cannot check directly by the result of push() if it did. this creates the false illusion push() can never fail. to avoid this, handle_error() can set a flag, which can be checked after the push(). however, this is an ugly hack of course. PS: send() can easily fail. suppose we're reading from 2 sockets: A and B, and send messages to both when data is read from either one. if B gets disconnected and A has data ready, both will be in the set of readible sockets returned by select(). if A's data is handled before B's, and A sends a message to B, this will cause the send to fail as B is disconnected. your app wont know B failed, because this is processed after the data from A is processed. -- >Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 10:15 Message: Logged In: YES user_id=516066 Oh I fully agree that its easy to write a workaround. And that the error doesn't propagate out of push(). It's just the question whether this is desired behaviour and expected behaviour after reading the documentation? If not, either the code or documentation ought to be modified. Right now, you wouldn't tell from the docs that push() will try to send data (and thus fail, which is the only moment handle_error() can occur in the middle your code if you catch exceptions yourself). This creates all sorts of obscure behaviour: class MyAsyncProtocol(asynchat.async_chat): def handle_connect(self): self.foo = some_value_I_calculate self.push( "hello!" ) class MyLoggingAsyncProcotol(MyAsyncProtocol): def handle_connect(self): MyAsyncProtocol.handle_connect(self) print "Connection established with foo value %d" % self.foo def handle_error(self): print "Connection lost" Could produce the following output: Connection lost Connection established with foo value 42 I wouldnt expect this from the documentation: push() adds data to the output buffer, but the docs dont say or imply it can fail and thus trigger handle_error (). A simple solution would be to put all push()es at the end of the function so that no more code is executed except maybe handle_error(). But as the example above shows, this is not always possible. Another solution would be one of your workarounds. If only the docs would be adapted, it would still bother me to have to do the above for any but the most trivial of applications. But once the docs warns me for this behaviour, I at least know it from the start :) So, do you feel docs/code should be changed, and if so, which one? -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 09:32 Message: Logged In: YES user_id=341410 Here's a subclass that doesn't send on push... class MyAsyncChat(asynchat.async_chat): def push (self, data): self.producer_fifo.push (simple_producer (data)) That's it. And according to my reading of asynchat and asyncore, while actually trying to send data during a push() may trigger the handle_error() method to be called, by default, the handle_error() method logs the error and closes the socket. Errors don't seem to propagate out of push(). -- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 09:18 Message: Logged In: YES user_id=516066 Push() sending data may indeed be the source of the problems here. There should be no problems with delaying the write until the next select() will tell the socket is writable. My current work around is indeed subclassing as you describe. However, it seemed that such a thing would be exactly that: a work around in order to obtain expected behaviour.
[ python-Bugs-1370380 ] asynchat.async_chat.push() function doesnt say when failed
Bugs item #1370380, was opened at 2005-11-30 13:18 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&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: Jan David Mol (jjdmol) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat.async_chat.push() function doesnt say when failed Initial Comment: suppose you have a socket handled by your asynchat.async_chat class and want to send a message (call push()). push() calls initiate_send(), which can call handle_error() if an error occurs. however, once handle_error() returns, the control is passed back to push(), which has no return value thus cannot signal the success or failure to the code that did the push(). i.e. if we have code like foo() s.push(data) bar() the following is executed in case of an error: foo() s.push(data) s.handle_error() bar() this created an obscure bug, as the bar() assumed the send() always succeeds, and also cannot check directly by the result of push() if it did. this creates the false illusion push() can never fail. to avoid this, handle_error() can set a flag, which can be checked after the push(). however, this is an ugly hack of course. PS: send() can easily fail. suppose we're reading from 2 sockets: A and B, and send messages to both when data is read from either one. if B gets disconnected and A has data ready, both will be in the set of readible sockets returned by select(). if A's data is handled before B's, and A sends a message to B, this will cause the send to fail as B is disconnected. your app wont know B failed, because this is processed after the data from A is processed. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 01:38 Message: Logged In: YES user_id=341410 If anything should be changed, I would say the docs. Though I disagree with the send during a call to push(), for most users, it makes sense, and convincing the current maintainer that removing the send on push for the sake of async purity would be difficulty (practicality beats purity). I believe that adding a note which reads something like the following would be sufficient. "The default push() implementation calls the underlying socket send() (to increase data throughput in many situations), and upon error, will call handle_error(). This may cause unexpected behavior if push() is used within a subclassed handle_connect()." -- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 01:15 Message: Logged In: YES user_id=516066 Oh I fully agree that its easy to write a workaround. And that the error doesn't propagate out of push(). It's just the question whether this is desired behaviour and expected behaviour after reading the documentation? If not, either the code or documentation ought to be modified. Right now, you wouldn't tell from the docs that push() will try to send data (and thus fail, which is the only moment handle_error() can occur in the middle your code if you catch exceptions yourself). This creates all sorts of obscure behaviour: class MyAsyncProtocol(asynchat.async_chat): def handle_connect(self): self.foo = some_value_I_calculate self.push( "hello!" ) class MyLoggingAsyncProcotol(MyAsyncProtocol): def handle_connect(self): MyAsyncProtocol.handle_connect(self) print "Connection established with foo value %d" % self.foo def handle_error(self): print "Connection lost" Could produce the following output: Connection lost Connection established with foo value 42 I wouldnt expect this from the documentation: push() adds data to the output buffer, but the docs dont say or imply it can fail and thus trigger handle_error (). A simple solution would be to put all push()es at the end of the function so that no more code is executed except maybe handle_error(). But as the example above shows, this is not always possible. Another solution would be one of your workarounds. If only the docs would be adapted, it would still bother me to have to do the above for any but the most trivial of applications. But once the docs warns me for this behaviour, I at least know it from the start :) So, do you feel docs/code should be changed, and if so, which one? -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 00:32 Message: Logged In: YES user_id=341410 Here's a subclass that doesn't send on push... class MyAsyncChat(asynchat.async_chat): def push (self, data): self.producer_fifo.push (simple_producer (data))
[ python-Bugs-1370380 ] asynchat.async_chat.push() function doesnt say when failed
Bugs item #1370380, was opened at 2005-11-30 22:18 Message generated for change (Comment added) made by jjdmol You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&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: Open Resolution: None Priority: 5 Submitted By: Jan David Mol (jjdmol) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat.async_chat.push() function doesnt say when failed Initial Comment: suppose you have a socket handled by your asynchat.async_chat class and want to send a message (call push()). push() calls initiate_send(), which can call handle_error() if an error occurs. however, once handle_error() returns, the control is passed back to push(), which has no return value thus cannot signal the success or failure to the code that did the push(). i.e. if we have code like foo() s.push(data) bar() the following is executed in case of an error: foo() s.push(data) s.handle_error() bar() this created an obscure bug, as the bar() assumed the send() always succeeds, and also cannot check directly by the result of push() if it did. this creates the false illusion push() can never fail. to avoid this, handle_error() can set a flag, which can be checked after the push(). however, this is an ugly hack of course. PS: send() can easily fail. suppose we're reading from 2 sockets: A and B, and send messages to both when data is read from either one. if B gets disconnected and A has data ready, both will be in the set of readible sockets returned by select(). if A's data is handled before B's, and A sends a message to B, this will cause the send to fail as B is disconnected. your app wont know B failed, because this is processed after the data from A is processed. -- >Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 11:14 Message: Logged In: YES user_id=516066 Ok thanks. The example with handle_connect() is just one out of many btw: in general, don't run code after push() which uses or assumes data which handle_error() cleans up. There are indeed cases in which initiate_send() in a push() is practical. Aside from throughput issues, sending heartbeat messages or streaming data from another thread using a timer doesn't work without initiate_send, because the data wouldn't be sent until select() in the main thread feels like returning. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 10:38 Message: Logged In: YES user_id=341410 If anything should be changed, I would say the docs. Though I disagree with the send during a call to push(), for most users, it makes sense, and convincing the current maintainer that removing the send on push for the sake of async purity would be difficulty (practicality beats purity). I believe that adding a note which reads something like the following would be sufficient. "The default push() implementation calls the underlying socket send() (to increase data throughput in many situations), and upon error, will call handle_error(). This may cause unexpected behavior if push() is used within a subclassed handle_connect()." -- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 10:15 Message: Logged In: YES user_id=516066 Oh I fully agree that its easy to write a workaround. And that the error doesn't propagate out of push(). It's just the question whether this is desired behaviour and expected behaviour after reading the documentation? If not, either the code or documentation ought to be modified. Right now, you wouldn't tell from the docs that push() will try to send data (and thus fail, which is the only moment handle_error() can occur in the middle your code if you catch exceptions yourself). This creates all sorts of obscure behaviour: class MyAsyncProtocol(asynchat.async_chat): def handle_connect(self): self.foo = some_value_I_calculate self.push( "hello!" ) class MyLoggingAsyncProcotol(MyAsyncProtocol): def handle_connect(self): MyAsyncProtocol.handle_connect(self) print "Connection established with foo value %d" % self.foo def handle_error(self): print "Connection lost" Could produce the following output: Connection lost Connection established with foo value 42 I wouldnt expect this from the documentation: push() adds data to the output buffer, but the docs dont say or imply it can fail and thus trigger handle_error (). A simple solution would be to put all push()es at the end of the function so that no more code is executed except maybe handle_error(). But as the example above shows, this is not always possible. Another solution would be one of
[ python-Bugs-212558 ] dictionary lookup does not check exceptions
Bugs item #212558, was opened at 2000-08-23 14:24
Message generated for change (Comment added) made by arigo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=212558&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Closed
Resolution: Fixed
Priority: 9
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: dictionary lookup does not check exceptions
Initial Comment:
class BadDictKey:
def __hash__(self):
return hash(self.__class__)
def __cmp__(self, other):
if isinstance(other, self.__class__):
print "raising error"
raise RuntimeError, "gotcha"
return other
The dict lookup code does not check for hash or cmp functions raising an
exception. This can lead to a variety of bogus behavior; e.g. the uncaught
exception is noticed and raised for the next line.
>>> d = {}
>>> x1 = BadDictKey()
>>> x2 = BadDictKey()
>>> d[x1] = 1
>>> d[x2] = 2
raising error
>>> print d.keys()
Traceback (most recent call last):
File "/tmp/dicterr.py", line 8, in __cmp__
raise RuntimeError, "gotcha"
RuntimeError: gotcha
--
>Comment By: Armin Rigo (arigo)
Date: 2005-12-15 10:24
Message:
Logged In: YES
user_id=4771
For future reference, the patch number is actually #401277.
--
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-08-31 19:05
Message:
Fixed by patch #101277, checked in as dictobject.c revision 2.63.
--
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-08-24 16:56
Message:
See patch #101277 for a proposed fix & discussion.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=212558&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1370380 ] asynchat.async_chat.push() function doesnt say when failed
Bugs item #1370380, was opened at 2005-11-30 13:18 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&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: Open Resolution: None Priority: 5 Submitted By: Jan David Mol (jjdmol) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat.async_chat.push() function doesnt say when failed Initial Comment: suppose you have a socket handled by your asynchat.async_chat class and want to send a message (call push()). push() calls initiate_send(), which can call handle_error() if an error occurs. however, once handle_error() returns, the control is passed back to push(), which has no return value thus cannot signal the success or failure to the code that did the push(). i.e. if we have code like foo() s.push(data) bar() the following is executed in case of an error: foo() s.push(data) s.handle_error() bar() this created an obscure bug, as the bar() assumed the send() always succeeds, and also cannot check directly by the result of push() if it did. this creates the false illusion push() can never fail. to avoid this, handle_error() can set a flag, which can be checked after the push(). however, this is an ugly hack of course. PS: send() can easily fail. suppose we're reading from 2 sockets: A and B, and send messages to both when data is read from either one. if B gets disconnected and A has data ready, both will be in the set of readible sockets returned by select(). if A's data is handled before B's, and A sends a message to B, this will cause the send to fail as B is disconnected. your app wont know B failed, because this is processed after the data from A is processed. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 02:36 Message: Logged In: YES user_id=341410 Manipulating the same socket in two threads is a fool's business. If you want to force select to return, you should have a shorter timeout for select, or a loopback socket in which both ends are in the same process, where you can send some data, which causes the select to be triggered for a read event. -- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 02:14 Message: Logged In: YES user_id=516066 Ok thanks. The example with handle_connect() is just one out of many btw: in general, don't run code after push() which uses or assumes data which handle_error() cleans up. There are indeed cases in which initiate_send() in a push() is practical. Aside from throughput issues, sending heartbeat messages or streaming data from another thread using a timer doesn't work without initiate_send, because the data wouldn't be sent until select() in the main thread feels like returning. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 01:38 Message: Logged In: YES user_id=341410 If anything should be changed, I would say the docs. Though I disagree with the send during a call to push(), for most users, it makes sense, and convincing the current maintainer that removing the send on push for the sake of async purity would be difficulty (practicality beats purity). I believe that adding a note which reads something like the following would be sufficient. "The default push() implementation calls the underlying socket send() (to increase data throughput in many situations), and upon error, will call handle_error(). This may cause unexpected behavior if push() is used within a subclassed handle_connect()." -- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 01:15 Message: Logged In: YES user_id=516066 Oh I fully agree that its easy to write a workaround. And that the error doesn't propagate out of push(). It's just the question whether this is desired behaviour and expected behaviour after reading the documentation? If not, either the code or documentation ought to be modified. Right now, you wouldn't tell from the docs that push() will try to send data (and thus fail, which is the only moment handle_error() can occur in the middle your code if you catch exceptions yourself). This creates all sorts of obscure behaviour: class MyAsyncProtocol(asynchat.async_chat): def handle_connect(self): self.foo = some_value_I_calculate self.push( "hello!" ) class MyLoggingAsyncProcotol(MyAsyncProtocol): def handle_connect(self): MyAsyncProtocol.handle_connect(self) print "Connection established with foo value %d" % self.foo def handle_error(self): print "Connection lost"
[ python-Bugs-1381476 ] csv.reader endless loop
Bugs item #1381476, was opened at 2005-12-15 11:04
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=1381476&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: Christian Harms (wwwingman)
Assigned to: Nobody/Anonymous (nobody)
Summary: csv.reader endless loop
Initial Comment:
Hi,
the csv.reader produce a endless loop, ifan parsing
Error is in the last line of the CSV-File. If you put
an "\r" in the last line, cvs.Error is raised and
StopIteration will lost.
import csv, StringIO
fp = StringIO.StringIO("line1\nline2\rerror")
reader = csv.reader(fp)
while 1:
try:
print reader.next()
except csv.Error:
print "Error"
except StopIteration:
break
Die Problem is in python 2.3 AND python 2.4. Other
version are not checked.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381476&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1370380 ] async_chat.push() can trigger handle_error(). undocumented.
Bugs item #1370380, was opened at 2005-11-30 22:18 Message generated for change (Settings changed) made by jjdmol You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&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: Open Resolution: None Priority: 5 Submitted By: Jan David Mol (jjdmol) Assigned to: Nobody/Anonymous (nobody) >Summary: async_chat.push() can trigger handle_error(). undocumented. Initial Comment: suppose you have a socket handled by your asynchat.async_chat class and want to send a message (call push()). push() calls initiate_send(), which can call handle_error() if an error occurs. however, once handle_error() returns, the control is passed back to push(), which has no return value thus cannot signal the success or failure to the code that did the push(). i.e. if we have code like foo() s.push(data) bar() the following is executed in case of an error: foo() s.push(data) s.handle_error() bar() this created an obscure bug, as the bar() assumed the send() always succeeds, and also cannot check directly by the result of push() if it did. this creates the false illusion push() can never fail. to avoid this, handle_error() can set a flag, which can be checked after the push(). however, this is an ugly hack of course. PS: send() can easily fail. suppose we're reading from 2 sockets: A and B, and send messages to both when data is read from either one. if B gets disconnected and A has data ready, both will be in the set of readible sockets returned by select(). if A's data is handled before B's, and A sends a message to B, this will cause the send to fail as B is disconnected. your app wont know B failed, because this is processed after the data from A is processed. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 11:36 Message: Logged In: YES user_id=341410 Manipulating the same socket in two threads is a fool's business. If you want to force select to return, you should have a shorter timeout for select, or a loopback socket in which both ends are in the same process, where you can send some data, which causes the select to be triggered for a read event. -- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 11:14 Message: Logged In: YES user_id=516066 Ok thanks. The example with handle_connect() is just one out of many btw: in general, don't run code after push() which uses or assumes data which handle_error() cleans up. There are indeed cases in which initiate_send() in a push() is practical. Aside from throughput issues, sending heartbeat messages or streaming data from another thread using a timer doesn't work without initiate_send, because the data wouldn't be sent until select() in the main thread feels like returning. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-15 10:38 Message: Logged In: YES user_id=341410 If anything should be changed, I would say the docs. Though I disagree with the send during a call to push(), for most users, it makes sense, and convincing the current maintainer that removing the send on push for the sake of async purity would be difficulty (practicality beats purity). I believe that adding a note which reads something like the following would be sufficient. "The default push() implementation calls the underlying socket send() (to increase data throughput in many situations), and upon error, will call handle_error(). This may cause unexpected behavior if push() is used within a subclassed handle_connect()." -- Comment By: Jan David Mol (jjdmol) Date: 2005-12-15 10:15 Message: Logged In: YES user_id=516066 Oh I fully agree that its easy to write a workaround. And that the error doesn't propagate out of push(). It's just the question whether this is desired behaviour and expected behaviour after reading the documentation? If not, either the code or documentation ought to be modified. Right now, you wouldn't tell from the docs that push() will try to send data (and thus fail, which is the only moment handle_error() can occur in the middle your code if you catch exceptions yourself). This creates all sorts of obscure behaviour: class MyAsyncProtocol(asynchat.async_chat): def handle_connect(self): self.foo = some_value_I_calculate self.push( "hello!" ) class MyLoggingAsyncProcotol(MyAsyncProtocol): def handle_connect(self): MyAsyncProtocol.handle_connect(self) print "Connection established with foo value %d" % self.foo def handle_error(self): print "Connection lost" Co
[ python-Bugs-1381717 ] mode 't' not documented as posssible mode for file built-in
Bugs item #1381717, was opened at 2005-12-15 17:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381717&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: Simo Salminen (ssalmine) Assigned to: Nobody/Anonymous (nobody) Summary: mode 't' not documented as posssible mode for file built-in Initial Comment: At http://docs.python.org/lib/built-in-funcs.html, 'file' function parameter 'mode' accepts 't' (for text mode). This is not documented. It is mentioned in file object description (http://docs.python.org/lib/bltin-file-objects.html). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381717&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1381717 ] mode 't' not documented as posssible mode for file built-in
Bugs item #1381717, was opened at 2005-12-15 10:37
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381717&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: Simo Salminen (ssalmine)
Assigned to: Nobody/Anonymous (nobody)
Summary: mode 't' not documented as posssible mode for file built-in
Initial Comment:
At http://docs.python.org/lib/built-in-funcs.html,
'file' function parameter 'mode' accepts 't' (for text
mode).
This is not documented. It is mentioned in file object
description
(http://docs.python.org/lib/bltin-file-objects.html).
--
>Comment By: Tim Peters (tim_one)
Date: 2005-12-15 11:08
Message:
Logged In: YES
user_id=31435
This is more involved than you might like. In general,
open(path, mode) passes the mode string to the platform C
library's file-opening function, and using anything other
than standard C mode letters ("w", "b", "r", "a", "+") is
platform-dependent. "t" is not a standard C mode letter, so
whether it has any meaning, and exactly what it means if it
_does_ mean something, depends entirely on the platform C
library.
Using "t" to force text mode is a Microsoft-specific
gimmick, so if "t" is documented at all, it should be
plastered with warnings about its platform-specific nature.
Even on a Microsoft platform, "t" is basically silly: text
mode is the default mode (C defines this) -- it's what you
get if you don't pass "b". The only reason Microsoft
supports "t" is because MS has _another_ non-standard option
to tell its C runtime to use binary mode by default, and if
you use that non-standard option then you also need to use
the non-standard "t" mode letter to force a file to open in
text mode.
In short, the docs should change to spell out what the
standard C modes are, and note that at the cost of
portability you can also pass whichever non-standard mode
extensions your platform happens to support.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381717&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1381939 ] cElementTree only supports a few encodings
Bugs item #1381939, was opened at 2005-12-15 22:15 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=1381939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: cElementTree only supports a few encodings Initial Comment: The cElementTree driver only supports a small number of XML encodings compared to ElementTree (and other pyexpat-based tools). This would be nice if this was fixed before 2.5 final. In the meantime, a workaround can be found here: http://effbot.org/zone/celementtree-encoding.htm -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381939&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1381717 ] mode 't' not documented as posssible mode for file built-in
Bugs item #1381717, was opened at 2005-12-15 16:37
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381717&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: Simo Salminen (ssalmine)
Assigned to: Nobody/Anonymous (nobody)
Summary: mode 't' not documented as posssible mode for file built-in
Initial Comment:
At http://docs.python.org/lib/built-in-funcs.html,
'file' function parameter 'mode' accepts 't' (for text
mode).
This is not documented. It is mentioned in file object
description
(http://docs.python.org/lib/bltin-file-objects.html).
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-15 22:36
Message:
Logged In: YES
user_id=1188172
I removed the reference to "t" from the docs of file.seek()
in rev 41703,41704.
--
Comment By: Tim Peters (tim_one)
Date: 2005-12-15 17:08
Message:
Logged In: YES
user_id=31435
This is more involved than you might like. In general,
open(path, mode) passes the mode string to the platform C
library's file-opening function, and using anything other
than standard C mode letters ("w", "b", "r", "a", "+") is
platform-dependent. "t" is not a standard C mode letter, so
whether it has any meaning, and exactly what it means if it
_does_ mean something, depends entirely on the platform C
library.
Using "t" to force text mode is a Microsoft-specific
gimmick, so if "t" is documented at all, it should be
plastered with warnings about its platform-specific nature.
Even on a Microsoft platform, "t" is basically silly: text
mode is the default mode (C defines this) -- it's what you
get if you don't pass "b". The only reason Microsoft
supports "t" is because MS has _another_ non-standard option
to tell its C runtime to use binary mode by default, and if
you use that non-standard option then you also need to use
the non-standard "t" mode letter to force a file to open in
text mode.
In short, the docs should change to spell out what the
standard C modes are, and note that at the cost of
portability you can also pass whichever non-standard mode
extensions your platform happens to support.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381717&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1379994 ] "unicode_escape" and "raw_unicode_escape" encoding is broken
Bugs item #1379994, was opened at 2005-12-14 01:47
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Mc Mahon (markmcmahon)
Assigned to: M.-A. Lemburg (lemburg)
Summary: "unicode_escape" and "raw_unicode_escape" encoding is broken
Initial Comment:
In Python 2.4.2 and Python 2.4.1 (Windows XP)
>>> "\t\t".encode("string_escape")
'\t\\t'
>>> "\t\t".encode("unicode_escape")
'\t\t'
>>> "\t\t".encode("raw_unicode_escape")
'\t\t'
>>> u"\t\t".encode("unicode_escape")
'\t\t'
>>> u"\t\t".encode("raw_unicode_escape")
'\t\t'
I would have expected all to produce the same result.
Also round-tripping with the encoding doesn't seem to work:
>>> "\t\t".encode('string_escape').decode('string_escape')
'\t\t'
>>>
u"\t\t".encode('unicode_escape').decode('unicode_escape')
u'\t\t'
Thanks
Mark
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-15 22:39
Message:
Logged In: YES
user_id=1188172
Patch looks good.
--
Comment By: Hye-Shik Chang (perky)
Date: 2005-12-14 02:41
Message:
Logged In: YES
user_id=55188
Attached a patch. It looks like a simple typo. :)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&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-1379573 ] python executable optionally should search script on PATH
Feature Requests item #1379573, was opened at 2005-12-13 16:13 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&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: Christoph Conrad (cconrad) Assigned to: Nobody/Anonymous (nobody) Summary: python executable optionally should search script on PATH Initial Comment: I've seen that with perl - parameter -S means search script on path. Very helpful. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 22:40 Message: Logged In: YES user_id=1188172 I don't know... if the script is in the PATH, isn't it normally executable too? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1379393 ] StreamReader.readline doesn't advance on decode errors
Bugs item #1379393, was opened at 2005-12-13 11:35 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379393&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: Matthew Mueller (donut) >Assigned to: Walter Dörwald (doerwalter) Summary: StreamReader.readline doesn't advance on decode errors Initial Comment: In previous versions of python, when there was a unicode decode error, StreamReader.readline() would advance to the next line. In the current version(2.4.2 and trunk), it doesn't. Testing under Linux AMD64 (Ubuntu 5.10) Attaching an example script. In python2.3 it prints: hi~ hi error: 'utf8' codec can't decode byte 0x80 in position 2: unexpected code byte error: 'utf8' codec can't decode byte 0x81 in position 2: unexpected code byte all done In python2.4 and trunk it prints: hi~ hi error: 'utf8' codec can't decode byte 0x80 in position 0: unexpected code byte error: 'utf8' codec can't decode byte 0x80 in position 0: unexpected code byte error: 'utf8' codec can't decode byte 0x80 in position 0: unexpected code byte [repeats forever] Maybe this isn't actually supposed to work (the docs don't mention what should happen with strict error checking..), but it would be nice, given the alternatives: 1. use errors='replace' and then search the result for the replacement character. (ick) 2. define a custom error handler similar to ignore or replace, that also sets some flag. (slightly less ick, but more work.) -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 22:42 Message: Logged In: YES user_id=1188172 I don't know what should be correct. Walter? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379393&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1378455 ] a problem of urllib using open_local_file
Bugs item #1378455, was opened at 2005-12-12 03:10 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378455&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Weongyo Jeong (weongyo) Assigned to: Nobody/Anonymous (nobody) Summary: a problem of urllib using open_local_file Initial Comment: Hello. I'm sorry for my short english. I'm using python 2.4 on my windows system. But I have a problem. see below: >3->3--- Traceback (most recent call last): File "main.py", line 57, in uploadproc UNNAMED_toplev.main (self.liststore.get_value (iter, i)) File "C:\Work\unnamed\UNNAMED_toplev.py", line 59, in main toplev_main (doc, TARGET_FILE) File "C:\Work\unnamed\UNNAMED_toplev.py", line 51, in toplev_main doc.documentElement.appendChild (UNNAMED_filehash.GetSHA1Info (doc, filepath )) File "C:\Work\unnamed\UNNAMED_filehash.py", line 19, in GetSHA1Info file = urllib.urlopen (filepath) File "C:\Python24\lib\urllib.py", line 77, in urlopen return opener.open(url) File "C:\Python24\lib\urllib.py", line 185, in open return getattr(self, name)(url) File "C:\Python24\lib\urllib.py", line 421, in open_file return self.open_local_file(url) File "C:\Python24\lib\urllib.py", line 435, in open_local_file raise IOError(e.errno, e.strerror, e.filename) IOError: [Errno 2] No such file or directory: '\C:\pse_signature.psr' >3->3--- i made a simple GUI program with pygtk and do drag and drop a file from windows file explorer. It printed "file:///C:/pse_signature.psr" which is a type of "text/uri-list". But urllib can't process it. Is it a problem of urllib? I read a article which reported a same problem with my case in python 2.2. that "file:///C:/pse_signature.psr" string made by windows. not me. why this problem don't be fixed? are there any reasons? thanks for reading. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 22:59 Message: Logged In: YES user_id=1188172 Fixed in r41705,41706. Thanks for the report! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378455&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-1379573 ] python executable optionally should search script on PATH
Feature Requests item #1379573, was opened at 2005-12-13 16:13 Message generated for change (Comment added) made by cconrad You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&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: Christoph Conrad (cconrad) Assigned to: Nobody/Anonymous (nobody) Summary: python executable optionally should search script on PATH Initial Comment: I've seen that with perl - parameter -S means search script on path. Very helpful. -- >Comment By: Christoph Conrad (cconrad) Date: 2005-12-15 23:00 Message: Logged In: YES user_id=21338 i meant the windows operating system. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 22:40 Message: Logged In: YES user_id=1188172 I don't know... if the script is in the PATH, isn't it normally executable too? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1379573&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1378455 ] a problem of urllib using open_local_file
Bugs item #1378455, was opened at 2005-12-12 03:10 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378455&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: Closed Resolution: Fixed Priority: 5 Submitted By: Weongyo Jeong (weongyo) Assigned to: Nobody/Anonymous (nobody) Summary: a problem of urllib using open_local_file Initial Comment: Hello. I'm sorry for my short english. I'm using python 2.4 on my windows system. But I have a problem. see below: >3->3--- Traceback (most recent call last): File "main.py", line 57, in uploadproc UNNAMED_toplev.main (self.liststore.get_value (iter, i)) File "C:\Work\unnamed\UNNAMED_toplev.py", line 59, in main toplev_main (doc, TARGET_FILE) File "C:\Work\unnamed\UNNAMED_toplev.py", line 51, in toplev_main doc.documentElement.appendChild (UNNAMED_filehash.GetSHA1Info (doc, filepath )) File "C:\Work\unnamed\UNNAMED_filehash.py", line 19, in GetSHA1Info file = urllib.urlopen (filepath) File "C:\Python24\lib\urllib.py", line 77, in urlopen return opener.open(url) File "C:\Python24\lib\urllib.py", line 185, in open return getattr(self, name)(url) File "C:\Python24\lib\urllib.py", line 421, in open_file return self.open_local_file(url) File "C:\Python24\lib\urllib.py", line 435, in open_local_file raise IOError(e.errno, e.strerror, e.filename) IOError: [Errno 2] No such file or directory: '\C:\pse_signature.psr' >3->3--- i made a simple GUI program with pygtk and do drag and drop a file from windows file explorer. It printed "file:///C:/pse_signature.psr" which is a type of "text/uri-list". But urllib can't process it. Is it a problem of urllib? I read a article which reported a same problem with my case in python 2.2. that "file:///C:/pse_signature.psr" string made by windows. not me. why this problem don't be fixed? are there any reasons? thanks for reading. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 23:00 Message: Logged In: YES user_id=1188172 I should add that the problem was not in urllib itself, but nturl2path. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-15 22:59 Message: Logged In: YES user_id=1188172 Fixed in r41705,41706. Thanks for the report! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378455&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1163401 ] uncaught AttributeError deep in urllib
Bugs item #1163401, was opened at 2005-03-15 01:39
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163401&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: K Lars Lohn (lohnk)
Assigned to: Nobody/Anonymous (nobody)
Summary: uncaught AttributeError deep in urllib
Initial Comment:
Python 2.4 and Python 2.3.4 running under Suse 9.2
We're getting an AttributeError exception "AttributeError: 'NoneType' object
has no attribute 'read'" within a very simple call to urllib.urlopen.
This was discovered while working on Sentry 2, the new mirror integrity checker
for the Mozilla project. We try to touch hundreds of URLs to make sure that
the files are present on each of the mirrors. One particular URL kills the
call to urllib.urlopen:
http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe
This file probably does not exist on the mirror, however, in other cases of bad
URLs, we get much more graceful failures when we try to read from the object
returned by urllib.urlopen.
>>> import urllib
>>> urlReader =
>>> urllib.urlopen("http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe";)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.4/urllib.py", line 77, in urlopen
return opener.open(url)
File "/usr/local/lib/python2.4/urllib.py", line 180, in open
return getattr(self, name)(url)
File "/usr/local/lib/python2.4/urllib.py", line 305, in open_http
return self.http_error(url, fp, errcode, errmsg, headers)
File "/usr/local/lib/python2.4/urllib.py", line 322, in http_error
return self.http_error_default(url, fp, errcode, errmsg, headers)
File "/usr/local/lib/python2.4/urllib.py", line 550, in http_error_default
return addinfourl(fp, headers, "http:" + url)
File "/usr/local/lib/python2.4/urllib.py", line 836, in __init__
addbase.__init__(self, fp)
File "/usr/local/lib/python2.4/urllib.py", line 786, in __init__
self.read = self.fp.read
AttributeError: 'NoneType' object has no attribute 'read'
The attached file is a three line scipt that demos the problem.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-15 23:10
Message:
Logged In: YES
user_id=1188172
Duplicate of #767111.
--
Comment By: Roy Smith (roysmith)
Date: 2005-04-02 23:44
Message:
Logged In: YES
user_id=390499
Wow, this is bizarre. I just spend some time tracking down exactly this
same bug and was just about to enter it when I saw this entry. For what
it's worth, I can reliably reproduce this exception when fetching a URL from
a deliberately broken server (well, at least I think it's broken; have to
double-check the HTTP spec to be sure this isn't actually allowed) which
produces headers but no body:
(This is on Mac OSX-10.3.8, Python-2.3.4)
---
Roy-Smiths-Computer:bug$ cat server.py
#!/usr/bin/env python
from BaseHTTPServer import *
class NullHandler (BaseHTTPRequestHandler):
def do_GET (self):
self.send_response (100)
self.end_headers ()
server = HTTPServer (('', 8000), NullHandler)
server.handle_request()
--
Roy-Smiths-Computer:bug$ cat client.py
#!/usr/bin/env python
import urllib
urllib.urlopen ('http://127.0.0.1:8000')
-
Roy-Smiths-Computer:bug$ ./client.py
Traceback (most recent call last):
File "./client.py", line 5, in ?
urllib.urlopen ('http://127.0.0.1:8000')
File "/usr/local/lib/python2.3/urllib.py", line 76, in urlopen
return opener.open(url)
File "/usr/local/lib/python2.3/urllib.py", line 181, in open
return getattr(self, name)(url)
File "/usr/local/lib/python2.3/urllib.py", line 306, in open_http
return self.http_error(url, fp, errcode, errmsg, headers)
File "/usr/local/lib/python2.3/urllib.py", line 323, in http_error
return self.http_error_default(url, fp, errcode, errmsg, headers)
File "/usr/local/lib/python2.3/urllib.py", line 551, in http_error_default
return addinfourl(fp, headers, "http:" + url)
File "/usr/local/lib/python2.3/urllib.py", line 837, in __init__
addbase.__init__(self, fp)
File "/usr/local/lib/python2.3/urllib.py", line 787, in __init__
self.read = self.fp.read
AttributeError: 'NoneType' object has no attribute 'read'
-
I'll give urllib2 a try and see how that works.
[ python-Bugs-767111 ] AttributeError thrown by urllib.open_http
Bugs item #767111, was opened at 2003-07-07 14:52
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&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: 6
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: AttributeError thrown by urllib.open_http
Initial Comment:
In 2.3b2, looks like an error condition isn't being picked up
on line 300 or 301 of urllib.py.
The code that triggered this traceback was simply:
url = urllib.urlopen(action, data)
Traceback (most recent call last):
File "autospamrep.py", line 170, in ?
current_page = handle_spamcop_page(current_page)
File "autospamrep.py", line 140, in handle_spamcop_page
url = urllib.urlopen(action, data)
File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 78, in urlopen
return opener.open(url, data)
File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 183, in open
return getattr(self, name)(url, data)
File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 308, in open_http
return self.http_error(url, fp, errcode, errmsg, headers,
data)
File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 323, in http_error
return self.http_error_default(url, fp, errcode, errmsg,
headers)
File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 551, in http_error_default
return addinfourl(fp, headers, "http:" + url)
File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 837, in __init__
addbase.__init__(self, fp)
File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 787, in __init__
self.read = self.fp.read
AttributeError: 'NoneType' object has no attribute 'read'
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-15 23:11
Message:
Logged In: YES
user_id=1188172
Further information can be found in #1163401 which has been
closed as a duplicate.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2005-01-07 13:39
Message:
Logged In: YES
user_id=11375
No, not at this point in time. Unassigning (or, if this bug
is on the radar for 2.3.5/2.4.1, I can find time to work on it).
-
--
Comment By: A.M. Kuchling (akuchling)
Date: 2005-01-07 13:39
Message:
Logged In: YES
user_id=11375
No, not at this point in time. Unassigning (or, if this bug
is on the radar for 2.3.5/2.4.1, I can find time to work on it).
-
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-07 02:37
Message:
Logged In: YES
user_id=80475
Andrew, are you still working on this one?
--
Comment By: Rob Probin (robzed)
Date: 2004-03-19 00:43
Message:
Logged In: YES
user_id=1000470
The file pointer (fp) is None (inside urllib) from httplib. This appears to
be caused by a BadStatusLine exception in getreply() (line1016 httplib).
This sets self.file to self._conn.sock.makefile('rb', 0) then does a
self.close() which sets self.file to None.
Being new to this peice of code, I'm not sure whether it's urllib assuming
the file isn't going to be closed, or the BadStatusLine exception clearing
the file. Certainly it looks like the error -1 is not being trapped by
open_http() in urllib upon calling h.getreply() and assuming that the file
still exists even in an error condition?
It maybe a coincidence but it appears to occur more when a web browser
on the same machine is refreshing.
Regards
Rob
--
Comment By: Rob Probin (robzed)
Date: 2004-03-17 23:24
Message:
Logged In: YES
user_id=1000470
"""
This comment is program to reproduce the problem. Sorry it's not an
attachment - as a relative Sourceforge newbie I have no idea how to
attach to an existing bug. More notes available via email if required -
including all local variables for each function from post mortem.
As said before, seems to be fp = None. Although the exception is caused
by the 'self.read = self.fp.read', it looks like 'fp = h.getfile()' inside
open_http()
This is repeatable, but you may have to run this more than once.
(Apologies to noaa.gov).
*** PLEASE: Run only where absolutely necessary for reproduction of
bug!!! ***
"""
""" Attribute Error test ca
[ python-Bugs-1381939 ] cElementTree only supports a few encodings
Bugs item #1381939, was opened at 2005-12-15 22:15 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381939&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Fredrik Lundh (effbot) Summary: cElementTree only supports a few encodings Initial Comment: The cElementTree driver only supports a small number of XML encodings compared to ElementTree (and other pyexpat-based tools). This would be nice if this was fixed before 2.5 final. In the meantime, a workaround can be found here: http://effbot.org/zone/celementtree-encoding.htm -- >Comment By: Fredrik Lundh (effbot) Date: 2005-12-16 00:07 Message: Logged In: YES user_id=38376 I've attached the relevant patch from CET 1.0.5 (in progress) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381939&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1382096 ] MacRoman Encoding Bug (OHM vs. OMEGA)
Bugs item #1382096, was opened at 2005-12-16 02:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382096&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Sean B. Palmer (seanbpalmer)
Assigned to: M.-A. Lemburg (lemburg)
Summary: MacRoman Encoding Bug (OHM vs. OMEGA)
Initial Comment:
The file encodings/mac_roman.py in Python 2.4.1
contains the following incorrect character definition
on line 96:
0x00bd: 0x2126, # OHM SIGN
This should read:
0x00bd: 0x03A9, # GREEK CAPITAL LETTER OMEGA
Presumably this bug occurred due to a misreading, given
that OHM and OMEGA having the same glyph. Evidence that
the OMEGA interpretation is correct:
0xBD 0x03A9 # GREEK CAPITAL LETTER OMEGA
-http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT
Further evidence can be found by Googling for MacRoman
tables. This bug means that, for example, the following
code gives a UnicodeEncodeError when it shouldn't do:
>>> u'\u03a9'.encode('macroman')
For a workaround, I've been using the following code:
>>> import codecs
>>> from encodings import mac_roman
>>> mac_roman.decoding_map[0xBD] = 0x03A9
>>> mac_roman.encoding_map =
codecs.make_encoding_map(mac_roman.decoding_map)
And then, to use the example above:
>>> u'\u03a9'.encode('macroman')
'\xbd'
>>>
Thanks,
--
Sean B. Palmer
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382096&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1382213 ] Tutorial section 9.5.1 ignores MRO for new-style classes
Bugs item #1382213, was opened at 2005-12-16 18:08
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=1382213&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: Open
Resolution: None
Priority: 5
Submitted By: GaryD (gazzadee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tutorial section 9.5.1 ignores MRO for new-style classes
Initial Comment:
Section 9.5.1 ("Multiple Inheritance") of the tutorial
(as viewed on http://www.python.org/doc/2.4.2/tut/)
discusses the Method Resolution Order (MRO) for classes
with multiple inheritance.
However, the 2nd paragraph incorrectly states that "The
only rule necessary to explain the semantics is the
resolution rule used for class attribute references.
This is depth-first, left-to-right". Whilst this is
true for old-style classes, new-style classes use a
different MRO (as documented elsewhere - eg.
http://www.python.org/2.3/mro.html)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382213&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1382213 ] Tutorial section 9.5.1 ignores MRO for new-style classes
Bugs item #1382213, was opened at 2005-12-16 02:08
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382213&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: Open
Resolution: None
Priority: 5
Submitted By: GaryD (gazzadee)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Tutorial section 9.5.1 ignores MRO for new-style classes
Initial Comment:
Section 9.5.1 ("Multiple Inheritance") of the tutorial
(as viewed on http://www.python.org/doc/2.4.2/tut/)
discusses the Method Resolution Order (MRO) for classes
with multiple inheritance.
However, the 2nd paragraph incorrectly states that "The
only rule necessary to explain the semantics is the
resolution rule used for class attribute references.
This is depth-first, left-to-right". Whilst this is
true for old-style classes, new-style classes use a
different MRO (as documented elsewhere - eg.
http://www.python.org/2.3/mro.html)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382213&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
