[ python-Bugs-1742889 ] Pickling of exceptions broken
Bugs item #1742889, was opened at 2007-06-25 16:43 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742889&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: Pickling of exceptions broken Initial Comment: Exceptions with required initialization arguments can't be unpickled: >>> class E(Exception): ... def __init__(self, x): ... self.x = x ... >>> import pickle >>> e = E(1) >>> p = pickle.dumps(e, 1) >>> pickle.loads(p) Traceback (most recent call last): File "", line 1, in File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 1374, in loads return Unpickler(file).load() File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 858, in load dispatch[key](self) File "/usr/local/python/2.5.1/lib/python2.5/pickle.py", line 1133, in load_reduce value = func(*args) TypeError: __init__() takes exactly 2 arguments (1 given) This is because __reduce__ defined in exceptions.c returns the type and the args variable, which an exception subclass might not populate. Also, the reduce implementation doesn't properly serialize the message attribute. I assume that the need for a custom reduce is due to the micro-optimization to store arge and message in C slots. Is this really necessary? -- >Comment By: Ziga Seilnacht (zseil) Date: 2007-08-12 13:26 Message: Logged In: YES user_id=1326842 Originator: NO Jim, could you please take a look at the pathes in #1692335? See: http://www.python.org/sf/1692335 -- Comment By: Georg Brandl (gbrandl) Date: 2007-06-25 17:57 Message: Logged In: YES user_id=849994 Originator: NO No, I haven't anything written -- and this should be fixed anyway. -- Comment By: Jim Fulton (dcjim) Date: 2007-06-25 17:57 Message: Logged In: YES user_id=73023 Originator: YES I'll note that I think the right thing to do is to: - Take args and message out of the C struct. - inherit the default reduce behavior from object. -- Comment By: Jim Fulton (dcjim) Date: 2007-06-25 17:53 Message: Logged In: YES user_id=73023 Originator: YES I'm not aware of any such contract. Can you point to anything in writing? See for example: file:///home/jim/Documentation/Python-Docs-2.4.1/tut/node10.html#SECTION001050 which teaches people to create custom exceptions that: - don't set args ro message and - won't be unpicklable in Python 2.5. Also, as I mentioned, the reduce implementation doesn't preserve the message, so even if that was the contract, the contract is broken. -- Comment By: Georg Brandl (gbrandl) Date: 2007-06-25 17:26 Message: Logged In: YES user_id=849994 Originator: NO AFAIR we were told that filling args and message is part of the exception contract... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1742889&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770551 ] words able to decode but unable to encode in GB18030
Bugs item #1770551, was opened at 2007-08-09 10:34
Message generated for change (Comment added) made by perky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770551&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.5
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Z-flagship (zaex)
Assigned to: Hye-Shik Chang (perky)
Summary: words able to decode but unable to encode in GB18030
Initial Comment:
Here is a list of chinese characters that can be read from a file [in GB18030
encoding], but unable to encode to GB18030 encoding
detailed:
used codecs.open(r'file name', encoding='GB18030') to read the characters from
a file, and try to encode them word by word into GB18030 with
word.encode('GB18030'). The action caused an exception with 'illegal multibyte
sequence'
the attachment is also the list.
list:
䎬䎱䅟䌷䦟䦷䲠㧏㭎㘚㘎㱮䴔䴖䴗䦆㧟䙡䙌䴕䁖䎬䴙䥽䝼䞍䓖䲡䥇䦂䦅䴓㩳㧐㳠䲢䴘㖞䜣䥺䶮䜩䥺䲟䲣䦛䦶㑳㑇㥮㤘䏝䦃
--
>Comment By: Hye-Shik Chang (perky)
Date: 2007-08-13 00:18
Message:
Logged In: YES
user_id=55188
Originator: NO
The problem has been fixed about a week ago. (r56727-8)
It will be okay on the forthcoming Python releases. Thank you for
reporting!
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-08-10 12:35
Message:
Logged In: YES
user_id=33168
Originator: NO
This seems like a cjk problem. Hye-Shik, could you take a look?
--
Comment By: Z-flagship (zaex)
Date: 2007-08-09 10:37
Message:
Logged In: YES
user_id=1863611
Originator: YES
The Python is Python2.5 , my OS is windows XP professional sp2 version
2002
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770551&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772686 ] exec() doesn't take an open file
Bugs item #1772686, was opened at 2007-08-12 10:12
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=1772686&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: exec() doesn't take an open file
Initial Comment:
exec() is documented to take an open file. The error message also says it
takes one, however:
>>> exec(open('nn.py'))
Traceback (most recent call last):
File "", line 1, in
TypeError: exec() arg 1 must be a string, file, or code object, not
TextIOWrapper
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772686&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770416 ] Decimal.__int__ overflows for large values
Bugs item #1770416, was opened at 2007-08-08 20:43
Message generated for change (Comment added) made by marketdickinson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&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
Private: No
Submitted By: Jason G (aryx)
Assigned to: Facundo Batista (facundobatista)
Summary: Decimal.__int__ overflows for large values
Initial Comment:
This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__.
>>> from decimal import Decimal as D
>>> e = D("1e1234567890987654321")
>>> int(e)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/decimal.py", line 1501, in __int__
s = ''.join(map(str, self._int)) + '0'*self._exp
OverflowError: cannot fit 'long' into an index-sized integer
>>> e = D("1e1234567890")
>>> int(e)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/decimal.py", line 1501, in __int__
s = ''.join(map(str, self._int)) + '0'*self._exp
MemoryError
Also, for values that do work this is incredibly slow if they are still fairly
large.
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-08-12 17:57
Message:
Logged In: YES
user_id=703403
Originator: NO
Doesn't using hash(D.as_tuple()) break the principle that if two objects
compare equal then they should have equal hash?
An alternative to converting to long before hashing is to use the fact
that for the current hash implementation for long we have
hash(n) == hash(n % (2**32-1)) (except when n is a multiple of 2**32-1).
For a Decimal d that's integral, one should be
able to compute d % (2**32-1) very quickly: if d = c*10**e then just use
(c * pow(10, e, 2**32-1)) % (2**32-1), which should be acceptably fast even
when d = 123456789E999.
The only tricky bit is that on a 64-bit system all those 2**32-1 need to
be replaced by 2**64-1. Though now I come to think of it,
since 2**32-1 is a factor of 2**64-1 it would be enough just to do
everything modulo 2**64-1 even on a 32-bit system.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-08-09 17:37
Message:
Logged In: YES
user_id=849994
Originator: NO
Assigning to Facundo, he's actively working on decimal ATM.
--
Comment By: ajaksu (ajaksu2)
Date: 2007-08-09 17:21
Message:
Logged In: YES
user_id=1200609
Originator: NO
I see. Inheriting from Decimal and overloading __hash__ is a way to solve
your problem, but it's IMHO a shallow bug and worth reporting.
I just tried hash(D.as_tuple()) and it is blazing fast. I think that
unless the official line is "don't touch decimal.py until X", this change
to hashing would be useful and (AFAICT) harmless enough to fit in e.g.
2.5.2. To avoid incompatibilities, __hash__ could check for Overflow and
only use .as_tuple for values higher than the previous maximum (keeping,
unfortunately, __hash__ slow for values below).
Could the current status of Decimal be made a bit more clear? Are bug
reports/patches welcome? Is bugging Facundo or RHettinger welcome? :)
If getting __int__ a bit faster and able to convert sans huge strings is
desired, I've updated that old function (see below) and AFAIK it could be
used to replace Lib/decimal.py/Decimal.[__int__,__long__]. It gets about
ten times faster on best cases and is about as slow on worst cases (could
be much worse if "long(rint_part + rdec_part)/exponent" is a STUPID thing
to do, but seems easy to avoid). As the original __int__ optimizes
str(Decimal._int) and doesn't split/check for substrings, using the same
path should speed this up more. I can run the tests and benchmark it (next
month...) if there's interest.
def dec2long(number):
""" Convert decimal.Decimal to long (abridged, non-checking
version)"""
decimal_string = str(number)
if "e" in decimal_string:
radix, exponent = decimal_string.split("e")
elif "E" in decimal_string:
radix, exponent = decimal_string.split("E")
else:
radix, exponent = (decimal_string, 0)
if exponent:
exponent = int(exponent)
if "." in radix:
rint, rdec = radix.split(".")
radix_decimal_part_len = long(len(rdec))
if radix_decimal_part_len <= exponent:
radix_as_long = long(rint + rdec)
corrected_exponent = exponent - radix_decimal_part_len
result = radix_as_long * 10L** corrected_exponent
else:
result = long(rint + rdec) / exponent
else:
radix_as_long = long(radix)
result = radix
[ python-Bugs-1772686 ] exec() doesn't take an open file
Bugs item #1772686, was opened at 2007-08-12 10:12
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772686&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 3000
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: exec() doesn't take an open file
Initial Comment:
exec() is documented to take an open file. The error message also says it
takes one, however:
>>> exec(open('nn.py'))
Traceback (most recent call last):
File "", line 1, in
TypeError: exec() arg 1 must be a string, file, or code object, not
TextIOWrapper
--
>Comment By: Brett Cannon (bcannon)
Date: 2007-08-12 12:16
Message:
Logged In: YES
user_id=357491
Originator: NO
This is a duplicate of bug #1762972 which Guido and I have already
discussed how to deal with this.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772686&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770416 ] Decimal.__int__ overflows for large values
Bugs item #1770416, was opened at 2007-08-08 20:43
Message generated for change (Comment added) made by marketdickinson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&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
Private: No
Submitted By: Jason G (aryx)
Assigned to: Facundo Batista (facundobatista)
Summary: Decimal.__int__ overflows for large values
Initial Comment:
This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__.
>>> from decimal import Decimal as D
>>> e = D("1e1234567890987654321")
>>> int(e)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/decimal.py", line 1501, in __int__
s = ''.join(map(str, self._int)) + '0'*self._exp
OverflowError: cannot fit 'long' into an index-sized integer
>>> e = D("1e1234567890")
>>> int(e)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/decimal.py", line 1501, in __int__
s = ''.join(map(str, self._int)) + '0'*self._exp
MemoryError
Also, for values that do work this is incredibly slow if they are still fairly
large.
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-08-12 19:43
Message:
Logged In: YES
user_id=703403
Originator: NO
Mark Dickinson (marketdickinson) stupidly claimed that:
hash(n) == hash(n % (2**32-1))
It's not true. Sorry for the noise.
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-08-12 17:57
Message:
Logged In: YES
user_id=703403
Originator: NO
Doesn't using hash(D.as_tuple()) break the principle that if two objects
compare equal then they should have equal hash?
An alternative to converting to long before hashing is to use the fact
that for the current hash implementation for long we have
hash(n) == hash(n % (2**32-1)) (except when n is a multiple of 2**32-1).
For a Decimal d that's integral, one should be
able to compute d % (2**32-1) very quickly: if d = c*10**e then just use
(c * pow(10, e, 2**32-1)) % (2**32-1), which should be acceptably fast even
when d = 123456789E999.
The only tricky bit is that on a 64-bit system all those 2**32-1 need to
be replaced by 2**64-1. Though now I come to think of it,
since 2**32-1 is a factor of 2**64-1 it would be enough just to do
everything modulo 2**64-1 even on a 32-bit system.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-08-09 17:37
Message:
Logged In: YES
user_id=849994
Originator: NO
Assigning to Facundo, he's actively working on decimal ATM.
--
Comment By: ajaksu (ajaksu2)
Date: 2007-08-09 17:21
Message:
Logged In: YES
user_id=1200609
Originator: NO
I see. Inheriting from Decimal and overloading __hash__ is a way to solve
your problem, but it's IMHO a shallow bug and worth reporting.
I just tried hash(D.as_tuple()) and it is blazing fast. I think that
unless the official line is "don't touch decimal.py until X", this change
to hashing would be useful and (AFAICT) harmless enough to fit in e.g.
2.5.2. To avoid incompatibilities, __hash__ could check for Overflow and
only use .as_tuple for values higher than the previous maximum (keeping,
unfortunately, __hash__ slow for values below).
Could the current status of Decimal be made a bit more clear? Are bug
reports/patches welcome? Is bugging Facundo or RHettinger welcome? :)
If getting __int__ a bit faster and able to convert sans huge strings is
desired, I've updated that old function (see below) and AFAIK it could be
used to replace Lib/decimal.py/Decimal.[__int__,__long__]. It gets about
ten times faster on best cases and is about as slow on worst cases (could
be much worse if "long(rint_part + rdec_part)/exponent" is a STUPID thing
to do, but seems easy to avoid). As the original __int__ optimizes
str(Decimal._int) and doesn't split/check for substrings, using the same
path should speed this up more. I can run the tests and benchmark it (next
month...) if there's interest.
def dec2long(number):
""" Convert decimal.Decimal to long (abridged, non-checking
version)"""
decimal_string = str(number)
if "e" in decimal_string:
radix, exponent = decimal_string.split("e")
elif "E" in decimal_string:
radix, exponent = decimal_string.split("E")
else:
radix, exponent = (decimal_string, 0)
if exponent:
exponent = int(exponent)
if "." in radix:
rint, rdec = radix.split(".")
radix_decimal_part_len = long(len(rdec))
if radix_decimal_part_len <= exponent:
[ python-Bugs-1772788 ] chr(128) in u'only ascii' -> TypeError with misleading msg
Bugs item #1772788, was opened at 2007-08-13 01:54 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=1772788&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 Private: No Submitted By: Pekka Laukkanen (laukpe) Assigned to: Nobody/Anonymous (nobody) Summary: chr(128) in u'only ascii' -> TypeError with misleading msg Initial Comment: A test using in format "chr(x) in " raises a TypeError if "x" is in range 128-255 (i.e. non-ascii) and string is unicode. This happens even if the unicode string contains only ascii data as the example below demonstrates. Python 2.5.1 (r251:54863, May 2 2007, 16:56:35) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> chr(127) in 'hello' False >>> chr(128) in 'hello' False >>> chr(127) in u'hi' False >>> chr(128) in u'hi' Traceback (most recent call last): File "", line 1, in TypeError: 'in ' requires string as left operand This can cause pretty nasty and hard-to-debug bugs in code using "in " format if e.g. user provided data is converted to unicode internally. Most other string operations work nicely between normal and unicode strings and I'd say simply returning False in this situation would be ok too. Issuing a warning similarly as below might be a good idea also. >>> chr(128) == u'' __main__:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal Finally, the error message is somewhat misleading since the left operand is definitely a string. >>> type(chr(128)) A real life example of code where this problem exist is telnetlib. I'll submit a separate bug about it as that problem can obviously be fixed in the library itself. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772788&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772794 ] Using telnetlib fails with unicode strings containing only a
Bugs item #1772794, was opened at 2007-08-13 02:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772794&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
Private: No
Submitted By: Pekka Laukkanen (laukpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Using telnetlib fails with unicode strings containing only a
Initial Comment:
It is not possible to use unicode strings with telnetlib even if these strings
used only ascii characters. Example below demonstrates this.
Type "help", "copyright", "credits" or "license" for more information.
>>> import telnetlib
>>> telnetlib.Telnet().write(u'hi')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/telnetlib.py", line 289, in write
if IAC in buffer:
TypeError: 'in ' requires string as left operand
This problem is caused by bug #1772788 "chr(128) in u'only ascii' -> TypeError
with misleading msg". The relevant code is following and IAC is chr(255).
def write(self, buffer):
if IAC in buffer:
buffer = buffer.replace(IAC, IAC+IAC)
self.msg("send %r", buffer)
self.sock.sendall(buffer)
There are many pretty obvious ways to have a workaround for the issue. I
suggest something like follows assuming that accepting unicode data is ok in
general. If unicode is not ok then "pass" can be replaced with something like
"raise TypeError('Unicode data no accepted')" to at least have a better error
message.
def write(self, buffer):
try:
buffer = buffer.replace(IAC, IAC+IAC)
except UnicodeError:
pass
self.msg("send %r", buffer)
self.sock.sendall(buffer)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772794&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772794 ] Telnetlib dosn't accept unicode containing only ascii
Bugs item #1772794, was opened at 2007-08-13 02:17
Message generated for change (Settings changed) made by laukpe
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772794&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
Private: No
Submitted By: Pekka Laukkanen (laukpe)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Telnetlib dosn't accept unicode containing only ascii
Initial Comment:
It is not possible to use unicode strings with telnetlib even if these strings
used only ascii characters. Example below demonstrates this.
Type "help", "copyright", "credits" or "license" for more information.
>>> import telnetlib
>>> telnetlib.Telnet().write(u'hi')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/telnetlib.py", line 289, in write
if IAC in buffer:
TypeError: 'in ' requires string as left operand
This problem is caused by bug #1772788 "chr(128) in u'only ascii' -> TypeError
with misleading msg". The relevant code is following and IAC is chr(255).
def write(self, buffer):
if IAC in buffer:
buffer = buffer.replace(IAC, IAC+IAC)
self.msg("send %r", buffer)
self.sock.sendall(buffer)
There are many pretty obvious ways to have a workaround for the issue. I
suggest something like follows assuming that accepting unicode data is ok in
general. If unicode is not ok then "pass" can be replaced with something like
"raise TypeError('Unicode data no accepted')" to at least have a better error
message.
def write(self, buffer):
try:
buffer = buffer.replace(IAC, IAC+IAC)
except UnicodeError:
pass
self.msg("send %r", buffer)
self.sock.sendall(buffer)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772794&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772794 ] Telnetlib dosn't accept u'only ascii'
Bugs item #1772794, was opened at 2007-08-13 02:17
Message generated for change (Settings changed) made by laukpe
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772794&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
Private: No
Submitted By: Pekka Laukkanen (laukpe)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Telnetlib dosn't accept u'only ascii'
Initial Comment:
It is not possible to use unicode strings with telnetlib even if these strings
used only ascii characters. Example below demonstrates this.
Type "help", "copyright", "credits" or "license" for more information.
>>> import telnetlib
>>> telnetlib.Telnet().write(u'hi')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/telnetlib.py", line 289, in write
if IAC in buffer:
TypeError: 'in ' requires string as left operand
This problem is caused by bug #1772788 "chr(128) in u'only ascii' -> TypeError
with misleading msg". The relevant code is following and IAC is chr(255).
def write(self, buffer):
if IAC in buffer:
buffer = buffer.replace(IAC, IAC+IAC)
self.msg("send %r", buffer)
self.sock.sendall(buffer)
There are many pretty obvious ways to have a workaround for the issue. I
suggest something like follows assuming that accepting unicode data is ok in
general. If unicode is not ok then "pass" can be replaced with something like
"raise TypeError('Unicode data no accepted')" to at least have a better error
message.
def write(self, buffer):
try:
buffer = buffer.replace(IAC, IAC+IAC)
except UnicodeError:
pass
self.msg("send %r", buffer)
self.sock.sendall(buffer)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772794&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772481 ] urllib2 hangs with some documents.
Bugs item #1772481, was opened at 2007-08-12 06:52 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Creature (acreature) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 hangs with some documents. Initial Comment: While working on a web spider I encountered the following page that causes the read() call of a urllib2 response to fail. It uses 100% of the CPU and does not seem to ever return. I have this behaviour on Python 2.4.4, but several people on 2.5.1 have tried the code below and reported the same behaviour. By the way, the page it uses is a porn site, but please don't get hung up on that fact. This is a data processing issue, not a subject matter issue. This test case is attached as a file, but is also available at http://pastebin.com/d6f98618f . Please note that the user-agent masquerading is present to rule out any issues with the server returning different data to different clients; commenting out the line so Python sends the standard headers still results in the issue occuring. -- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-13 08:37 Message: Logged In: YES user_id=942711 Originator: NO Yes, I could verify the issue as well as the fix. Please submit a patch to patches or if someone with trunk access can make the change immediately. -- Comment By: Creature (acreature) Date: 2007-08-12 07:02 Message: Logged In: YES user_id=1407924 Originator: YES It seems that a fix to this issue is to change line 525 to add "or line == ''" on httplib.py in Python 2.4.4: # read and discard trailer up to the CRLF terminator ### note: we shouldn't have any trailers! while True: line = self.fp.readline() if line == '\r\n' or line == '': break I'm told that this is found on line 574 on Python 2.5. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772481&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-1728488 ] -q (quiet) option for python interpreter
Feature Requests item #1728488, was opened at 2007-05-30 20:44 Message generated for change (Comment added) made by wojdyr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1728488&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: None Priority: 5 Private: No Submitted By: Marcin Wojdyr (wojdyr) Assigned to: Nobody/Anonymous (nobody) Summary: -q (quiet) option for python interpreter Initial Comment: I'd like to suggest the new option for python: -q Do not print the version and copyright messages. These messages are also suppressed in non-interactive mode. Why: I often use python as a calculator, for a couple-lines calculations, and would prefer to avoid having printed these three lines. There is a similar option in e.g. gdb. AFAICS the implementation would require small changes in Modules/main.c, Misc/python.man and probably in other docs. If it would be accepted, I can do it. Marcin -- >Comment By: Marcin Wojdyr (wojdyr) Date: 2007-08-13 05:35 Message: Logged In: YES user_id=586843 Originator: YES -> patch 1772833 -- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-08-03 04:06 Message: Logged In: YES user_id=942711 Originator: NO +1 for this option. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-08-02 06:26 Message: Logged In: YES user_id=80475 Originator: NO +1 I think this would be nice. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1728488&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1558802 ] Tru64 make install failure
Bugs item #1558802, was opened at 2006-09-15 03:21 Message generated for change (Comment added) made by chris_laws You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558802&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: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Anthony Baxter (anthonybaxter) Summary: Tru64 make install failure Initial Comment: "make install" of Python 2.5c2 fails under Tru64 Unix V5.1. The failure is fixed by the simple patch below. I.e., simply remove two lines from Makefile.pre.in. Apparently the native make doesn't support comments where commands are expected. diff -r -u Python-2.5c2/Makefile.pre.in Python-2.5c2_cci/Makefile.pre.in --- Python-2.5c2/Makefile.pre.in2006-07-30 09:20:10.0 -0700 +++ Python-2.5c2_cci/Makefile.pre.in2006-09-14 10:17:12.0 -0700 @@ -850,8 +850,6 @@ $(INSTALL_DATA) Modules/Setup.config $(DESTDIR)$(LIBPL)/Setup.config $(INSTALL_SCRIPT) $(srcdir)/Modules/makesetup $(DESTDIR)$(LIBPL)/makesetup $(INSTALL_SCRIPT) $(srcdir)/install-sh $(DESTDIR)$(LIBPL)/install-sh - # Substitution happens here, as the completely-expanded BINDIR - # is not available in configure sed -e "s,@EXENAME@,$(BINDIR)/python$(VERSION)$(EXE)," < $(srcdir)/Misc/python-config.in >python-config $(INSTALL_SCRIPT) python-config $(DESTDIR)$(BINDIR)/python$(VERSION)-config rm python-config -- Comment By: chris_laws (chris_laws) Date: 2007-08-13 14:18 Message: Logged In: YES user_id=1866246 Originator: NO Not sure if this is appropriate here but it may at least indicate that the issue is affecting more than one user. I've just come across this bug and implementing the suggested patch fixed the issue for me. My company has a lot of DEC Alpha's (uname -a: OSF1 V4.0 1530 alpha) that we want to run Python on. It would be great if this simple fix was rolled into the main baseline in a future release. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-15 14:00 Message: Logged In: YES user_id=33168 Assigning to Anthony so he sees this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1558802&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770416 ] Decimal.__int__ overflows for large values
Bugs item #1770416, was opened at 2007-08-08 20:43
Message generated for change (Comment added) made by marketdickinson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&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
Private: No
Submitted By: Jason G (aryx)
Assigned to: Facundo Batista (facundobatista)
Summary: Decimal.__int__ overflows for large values
Initial Comment:
This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__.
>>> from decimal import Decimal as D
>>> e = D("1e1234567890987654321")
>>> int(e)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/decimal.py", line 1501, in __int__
s = ''.join(map(str, self._int)) + '0'*self._exp
OverflowError: cannot fit 'long' into an index-sized integer
>>> e = D("1e1234567890")
>>> int(e)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/decimal.py", line 1501, in __int__
s = ''.join(map(str, self._int)) + '0'*self._exp
MemoryError
Also, for values that do work this is incredibly slow if they are still fairly
large.
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-08-13 04:50
Message:
Logged In: YES
user_id=703403
Originator: NO
See patch #1772851
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-08-12 19:43
Message:
Logged In: YES
user_id=703403
Originator: NO
Mark Dickinson (marketdickinson) stupidly claimed that:
hash(n) == hash(n % (2**32-1))
It's not true. Sorry for the noise.
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-08-12 17:57
Message:
Logged In: YES
user_id=703403
Originator: NO
Doesn't using hash(D.as_tuple()) break the principle that if two objects
compare equal then they should have equal hash?
An alternative to converting to long before hashing is to use the fact
that for the current hash implementation for long we have
hash(n) == hash(n % (2**32-1)) (except when n is a multiple of 2**32-1).
For a Decimal d that's integral, one should be
able to compute d % (2**32-1) very quickly: if d = c*10**e then just use
(c * pow(10, e, 2**32-1)) % (2**32-1), which should be acceptably fast even
when d = 123456789E999.
The only tricky bit is that on a 64-bit system all those 2**32-1 need to
be replaced by 2**64-1. Though now I come to think of it,
since 2**32-1 is a factor of 2**64-1 it would be enough just to do
everything modulo 2**64-1 even on a 32-bit system.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-08-09 17:37
Message:
Logged In: YES
user_id=849994
Originator: NO
Assigning to Facundo, he's actively working on decimal ATM.
--
Comment By: ajaksu (ajaksu2)
Date: 2007-08-09 17:21
Message:
Logged In: YES
user_id=1200609
Originator: NO
I see. Inheriting from Decimal and overloading __hash__ is a way to solve
your problem, but it's IMHO a shallow bug and worth reporting.
I just tried hash(D.as_tuple()) and it is blazing fast. I think that
unless the official line is "don't touch decimal.py until X", this change
to hashing would be useful and (AFAICT) harmless enough to fit in e.g.
2.5.2. To avoid incompatibilities, __hash__ could check for Overflow and
only use .as_tuple for values higher than the previous maximum (keeping,
unfortunately, __hash__ slow for values below).
Could the current status of Decimal be made a bit more clear? Are bug
reports/patches welcome? Is bugging Facundo or RHettinger welcome? :)
If getting __int__ a bit faster and able to convert sans huge strings is
desired, I've updated that old function (see below) and AFAIK it could be
used to replace Lib/decimal.py/Decimal.[__int__,__long__]. It gets about
ten times faster on best cases and is about as slow on worst cases (could
be much worse if "long(rint_part + rdec_part)/exponent" is a STUPID thing
to do, but seems easy to avoid). As the original __int__ optimizes
str(Decimal._int) and doesn't split/check for substrings, using the same
path should speed this up more. I can run the tests and benchmark it (next
month...) if there's interest.
def dec2long(number):
""" Convert decimal.Decimal to long (abridged, non-checking
version)"""
decimal_string = str(number)
if "e" in decimal_string:
radix, exponent = decimal_string.split("e")
elif "E" in decimal_string:
radix, exponent = decimal_string.split("E")
else:
radix, exponent = (decimal_string, 0)
if exponent:
