[ python-Bugs-1325491 ] binary code made by freeze results "unknown encoding"
Bugs item #1325491, was opened at 2005-10-13 16:45
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=1325491&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: Demos and Tools
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: greatPython (samsjang)
Assigned to: Nobody/Anonymous (nobody)
Summary: binary code made by freeze results "unknown encoding"
Initial Comment:
One of my python code is like the following.
** mysrc.py **
str = 'I love Python'
print str.encode('UTF-8')
** **
this code runs well in python shell. But binary made by
freeze.py results the following.
Traceback (most recent call last):
File "/home/samy/src/mysrc.py", line 2, in ?
print str.encode('UTF-8')
LookupError: unknown encoding: UTF-8
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1325491&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1325491 ] binary code made by freeze results "unknown encoding"
Bugs item #1325491, was opened at 2005-10-13 16:45
Message generated for change (Settings changed) made by perky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1325491&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: Demos and Tools
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: greatPython (samsjang)
Assigned to: Nobody/Anonymous (nobody)
Summary: binary code made by freeze results "unknown encoding"
Initial Comment:
One of my python code is like the following.
** mysrc.py **
str = 'I love Python'
print str.encode('UTF-8')
** **
this code runs well in python shell. But binary made by
freeze.py results the following.
Traceback (most recent call last):
File "/home/samy/src/mysrc.py", line 2, in ?
print str.encode('UTF-8')
LookupError: unknown encoding: UTF-8
--
>Comment By: Hye-Shik Chang (perky)
Date: 2005-10-13 18:45
Message:
Logged In: YES
user_id=55188
It's not a bug. You should force freeze to include
"encoding" package.
See http://www.google.com/search?q=freeze+%22unknown+encoding%22
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1325491&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1325611 ] Curses,h
Bugs item #1325611, was opened at 2005-10-13 05: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=1325611&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: hafnium (rbrenner) Assigned to: Nobody/Anonymous (nobody) Summary: Curses,h Initial Comment: Please advise whether I can proceed with the build after encountering the following: >From ./configure: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## thanks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1325611&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1325903 ] Curses,h
Bugs item #1325903, was opened at 2005-10-13 10:01 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=1325903&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: hafnium (rbrenner) Assigned to: Nobody/Anonymous (nobody) Summary: Curses,h Initial Comment: Please advise whether I can proceed with the build after encountering the following: >From ./configure: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## thanks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1325903&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1325903 ] Curses,h
Bugs item #1325903, was opened at 2005-10-13 17:01 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1325903&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: hafnium (rbrenner) Assigned to: Nobody/Anonymous (nobody) Summary: Curses,h Initial Comment: Please advise whether I can proceed with the build after encountering the following: >From ./configure: checking curses.h usability... no checking curses.h presence... yes configure: WARNING: curses.h: present but cannot be compiled configure: WARNING: curses.h: check for missing prerequisite headers? configure: WARNING: curses.h: see the Autoconf documentation configure: WARNING: curses.h: section "Present But Cannot Be Compiled" configure: WARNING: curses.h: proceeding with the preprocessor's result configure: WARNING: curses.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to http://www.python.org/python-bugs ## configure: WARNING: ## ## thanks -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-10-13 18:03 Message: Logged In: YES user_id=1188172 Duplicate of #1325611. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1325903&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1326077 ] traceback.py formats SyntaxError differently
Bugs item #1326077, was opened at 2005-10-13 18:28 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=1326077&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: Neil Schemenauer (nascheme) Assigned to: Nobody/Anonymous (nobody) Summary: traceback.py formats SyntaxError differently Initial Comment: I ran into this bug while working on the AST compiler. The new compiler sets the "lineno" and "filename" attributes of SyntaxErrors in more cases than the old. The problem is that the traceback.py module formats SyntaxError exceptions differently than pythonrun.c does. Attached is a small testcase. Notice that traceback.py uses str() to generate the exception line and that it includes the file and lineno in parenthesis. This difference confuses doctest.py. I guess the parse_syntax_error() logic needs to be reproduced in traceback.py. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326077&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1326195 ] odd behaviour when making lists of lambda forms
Bugs item #1326195, was opened at 2005-10-13 22:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326195&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Johan Hidding (jhidding) Assigned to: Nobody/Anonymous (nobody) Summary: odd behaviour when making lists of lambda forms Initial Comment: Hi, I don't know if this is really a bug, but it is odd. I tried to make a list of lambda forms like in the following example, but the functions thus created don't really do what I expect. ** Python 2.3.5 (#2, Jun 19 2005, 13:28:00) [GCC 3.3.6 (Debian 1:3.3.6-6)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> p = [lambda t: t**n for n in range(6)] >>> p[0](2) 32 >>> p [ at 0xb7cece64>, at 0xb7cf10d4>, at 0xb7cf1b1c>, at 0xb7cf1b54>, at 0xb7cf1b8c>, at 0xb7cf1bc4>] >>> p[1](2) 32 >>> p[1](5) 3125 While: >>> q = [lambda t: 1, lambda t: t, lambda t: t**2, lambda t: t**3, lambda t: t**4] >>> q[0](4) 1 >>> q[1](4) 4 >>> q[2](4) 16 *** I tried creating the list using a for loop, but it shows the same weird behaviour. Also any attempt to put the lambda form in an object didn't give a cure. say: Wrap(lambda x: x**2) creates a callable object storing the lambda form as a data member. >>> j = [Wrap(lambda t: t**n) for n in range(5)] >>> j[0](1) 1 >>> j[0](3) 81 >>> j[0](5) 625 Both Python 2.3 and 2.4 show this behaviour. Am I completely overlooking something, or...? kind regards, Johan Hidding Groningen, the Netherlands -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326195&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1326277 ] itertools.count wraps around after maxint
Bugs item #1326277, was opened at 2005-10-13 23:27 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=1326277&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: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: itertools.count wraps around after maxint Initial Comment: See below. This goes against the notion of int/long unification and can cause weird unexpected behavior, almost like a buffer overflow. It should promote to a long at the appropriate time, or that's not feasible, then raise an exception, don't wrap around silently. Xrange is also not so great about this. It at least raises an exception if you give it too large an endpoint, but promoting to long would be better. Steven D'Aprano and others on clpy pointed this out. >>> from itertools import count >>> b=2**31 - 3 >>> c = count(b) >>> for i in range(5): ...print c.next() ... 2147483645 2147483646 2147483647 -2147483648 -2147483647 >>> -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326277&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1326277 ] itertools.count wraps around after maxint
Bugs item #1326277, was opened at 2005-10-13 23:27 Message generated for change (Comment added) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326277&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: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: itertools.count wraps around after maxint Initial Comment: See below. This goes against the notion of int/long unification and can cause weird unexpected behavior, almost like a buffer overflow. It should promote to a long at the appropriate time, or that's not feasible, then raise an exception, don't wrap around silently. Xrange is also not so great about this. It at least raises an exception if you give it too large an endpoint, but promoting to long would be better. Steven D'Aprano and others on clpy pointed this out. >>> from itertools import count >>> b=2**31 - 3 >>> c = count(b) >>> for i in range(5): ...print c.next() ... 2147483645 2147483646 2147483647 -2147483648 -2147483647 >>> -- >Comment By: paul rubin (phr) Date: 2005-10-13 23:29 Message: Logged In: YES user_id=72053 I forgot to say, the test example is Python 2.4.1 on linux. I don't know if 2.4.2 has a fix. I don't see anything about it in the database. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326277&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1208304 ] urllib2's urlopen() method causes a memory leak
Bugs item #1208304, was opened at 2005-05-25 05:20
Message generated for change (Comment added) made by holdenweb
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1208304&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: Open
Resolution: None
Priority: 5
Submitted By: Petr Toman (manekcz)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2's urlopen() method causes a memory leak
Initial Comment:
It seems that the urlopen(url) methd of the urllib2 module
leaves some undestroyable objects in memory.
Please try the following code:
==
if __name__ == '__main__':
import urllib2
a = urllib2.urlopen('http://www.google.com')
del a # or a = None or del(a)
# check memory on memory leaks
import gc
gc.set_debug(gc.DEBUG_SAVEALL)
gc.collect()
for it in gc.garbage:
print it
==
In our code, we're using lots of urlopens in a loop and
the number of unreachable objects grows beyond all
limits :) We also tried a.close() but it didn't help.
You can also try the following:
==
def print_unreachable_len():
# check memory on memory leaks
import gc
gc.set_debug(gc.DEBUG_SAVEALL)
gc.collect()
unreachableL = []
for it in gc.garbage:
unreachableL.append(it)
return len(str(unreachableL))
if __name__ == '__main__':
print "at the beginning", print_unreachable_len()
import urllib2
print "after import of urllib2", print_unreachable_len()
a = urllib2.urlopen('http://www.google.com')
print 'after urllib2.urlopen', print_unreachable_len()
del a
print 'after del', print_unreachable_len()
==
We're using WindowsXP with latest patches, Python 2.4
(ActivePython 2.4 Build 243 (ActiveState Corp.) based on
Python 2.4 (#60, Nov 30 2004, 09:34:21) [MSC v.1310
32 bit (Intel)] on win32).
--
Comment By: Steve Holden (holdenweb)
Date: 2005-10-14 00:13
Message:
Logged In: YES
user_id=88157
The Windows 2.4.1 build doesn't show this error, but the
Cygwin 2.4.1 build does still have uncollectable objects
after a urllib2.urlopen(), so there may be a platform
dependency here. No 2.4.2 on Cygwin yet, so nothing
conclusive as lsof isn't available.
--
Comment By: Brian Wellington (bwelling)
Date: 2005-08-15 14:13
Message:
Logged In: YES
user_id=63197
The real problem we were seeing wasn't the memory leak, it
was a file descriptor leak. Leaking references within the
interpreter is bad, but the garbage collector will
eventually notice that the system is out of memory and clean
them. Leaking file descriptors is much worse, as gc won't
be triggered when the process has reached it's limit, and
the process will start failing with "Too many file descriptors".
To easily show this problem, run the following from an
interactive python interpreter:
import urllib2
f = urllib2.urlopen('http://www.google.com')
f.close()
and from another window, run "lsof -p ".
It should show a TCP socket in CLOSE_WAIT, which means the
file descriptor is still open. I'm seeing weirdness on
Fedora Core 4 today that I didn't see last week where after
a few seconds, the file descriptor is listed as "can't
identify protocol" instead of TCP, but that's not too
relevant, since it's still open.
Repeating the urllib2.urlopen()/close() pairs of statements
in the interpreter will cause more fds to be leaked, which
can also be seen by lsof.
--
Comment By: Sean Reifschneider (jafo)
Date: 2005-08-12 18:30
Message:
Logged In: YES
user_id=81797
I've just tried it again using the current CVS version as
well as the version installed with Fedora Core 4, and in
both cases I was able to run over 100,000 retrievals of
http://127.0.0.1/test.html and http://127.0.0.1/google.html.
test.html is just "it works" and google.html was generated
with "wget -O google.html http://google.com/";.
I was able to reproduce this before, but now am not. My
urllib2.py includes the r.recv=r.read line. I have upgraded
from FC3 to FC4, could this be something related to an OS or
library interaction? I was going to try to confirm the last
message, but now I can't reproduce the failure.
--
Comment By: Brian Wellington (bwelling)
Date: 2005-08-11 22:22
Message:
Logged In: YES
user_id=63197
We just ran into this same problem, and worked around it by
simply removing the 'r.recv = r.read' line in urllib2.py,
and creating a recv alias to the read function in
HTTPResponse ('recv = read' in the class).
Not sure if this is the best solution, but it seems to wor
[ python-Bugs-1326406 ] pdb breaks programs which import from __main__
Bugs item #1326406, was opened at 2005-10-13 21:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326406&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: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: pdb breaks programs which import from __main__ Initial Comment: The following example illustrates the problem: bagira:~/python/dist/src/Lib> cat tt/xx hello=None import yy print "in xx:yy imported" bagira:~/python/dist/src/Lib> cat tt/yy.py from __main__ import hello print "in yy: yy imported " this works by itself: bagira:~/python/dist/src/Lib> ../python tt/xx in yy: yy imported in xx:yy imported But breaks under pdb bagira:~/python/dist/src/Lib> ../python -m pdb tt/xx > /home/ilya/python/dist/src/Lib/tt/xx(1)?() -> hello=None (Pdb) c Traceback (most recent call last): File "/home/ilya/python/dist/src/Lib/pdb.py", line 1057, in main pdb._runscript(mainpyfile) File "/home/ilya/python/dist/src/Lib/pdb.py", line 982, in _runscript self.run(statement, globals=globals_, locals=locals_) File "/home/ilya/python/dist/src/Lib/bdb.py", line 367, in run exec cmd in globals, locals File "", line 1, in ? File "tt/xx", line 2, in ? import yy File "/home/ilya/python/dist/src/Lib/tt/yy.py", line 1, in ? from __main__ import hello ImportError: cannot import name hello Uncaught exception. Entering post mortem debugging Running 'cont' or 'step' will restart the program > /home/ilya/python/dist/src/Lib/tt/yy.py(1)?() -> from __main__ import hello -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326406&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1326277 ] itertools.count wraps around after maxint
Bugs item #1326277, was opened at 2005-10-13 16:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326277&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: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) >Assigned to: Raymond Hettinger (rhettinger) Summary: itertools.count wraps around after maxint Initial Comment: See below. This goes against the notion of int/long unification and can cause weird unexpected behavior, almost like a buffer overflow. It should promote to a long at the appropriate time, or that's not feasible, then raise an exception, don't wrap around silently. Xrange is also not so great about this. It at least raises an exception if you give it too large an endpoint, but promoting to long would be better. Steven D'Aprano and others on clpy pointed this out. >>> from itertools import count >>> b=2**31 - 3 >>> c = count(b) >>> for i in range(5): ...print c.next() ... 2147483645 2147483646 2147483647 -2147483648 -2147483647 >>> -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-13 22:18 Message: Logged In: YES user_id=33168 I agree something should be done. Raymond, which behaviour would you prefer? I can implement if you want (just let me know and assign back to me). BTW, I don't have the same problem. I need to set b = 2**63 - 3 :-) (using current CVS). -- Comment By: paul rubin (phr) Date: 2005-10-13 16:29 Message: Logged In: YES user_id=72053 I forgot to say, the test example is Python 2.4.1 on linux. I don't know if 2.4.2 has a fix. I don't see anything about it in the database. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326277&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1325071 ] "as" keyword sometimes highlighted in strings
Bugs item #1325071, was opened at 2005-10-12 10:45 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1325071&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: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Artur de Sousa Rocha (adsr) >Assigned to: Kurt B. Kaiser (kbk) Summary: "as" keyword sometimes highlighted in strings Initial Comment: IDLE sometimes highlights the "as" keyword inside strings. See the docstring to the get_redir() function in the attached script. IDLE 1.1.2, Python 2.4.2, but I've seen it in older versions too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1325071&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1326277 ] itertools.count wraps around after maxint
Bugs item #1326277, was opened at 2005-10-13 23:27 Message generated for change (Comment added) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326277&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: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: itertools.count wraps around after maxint Initial Comment: See below. This goes against the notion of int/long unification and can cause weird unexpected behavior, almost like a buffer overflow. It should promote to a long at the appropriate time, or that's not feasible, then raise an exception, don't wrap around silently. Xrange is also not so great about this. It at least raises an exception if you give it too large an endpoint, but promoting to long would be better. Steven D'Aprano and others on clpy pointed this out. >>> from itertools import count >>> b=2**31 - 3 >>> c = count(b) >>> for i in range(5): ...print c.next() ... 2147483645 2147483646 2147483647 -2147483648 -2147483647 >>> -- >Comment By: paul rubin (phr) Date: 2005-10-14 05:53 Message: Logged In: YES user_id=72053 If both fixes are feasible then promoting to long is definitely the correct one. Raising an exception is just a kludge to at least not do something horrible silently. However, on a fast 32 bit machine, counting past 2**31 or something is quite realistic. A web server might send out that many packets in a few days or weeks. It shouldn't crash or go crazy after running for a long time and overflowing maxint. It occurs to me, the enumerate iterator should also be checked and fixed if needed. It, too, can overflow maxint if counting something like a network stream. Maybe there are some more iterators besides these, which need the same attention. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-14 05:18 Message: Logged In: YES user_id=33168 I agree something should be done. Raymond, which behaviour would you prefer? I can implement if you want (just let me know and assign back to me). BTW, I don't have the same problem. I need to set b = 2**63 - 3 :-) (using current CVS). -- Comment By: paul rubin (phr) Date: 2005-10-13 23:29 Message: Logged In: YES user_id=72053 I forgot to say, the test example is Python 2.4.1 on linux. I don't know if 2.4.2 has a fix. I don't see anything about it in the database. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326277&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1326448 ] set.__getstate__ is not overriden
Bugs item #1326448, was opened at 2005-10-14 06:38 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=1326448&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.4 Status: Open Resolution: None Priority: 5 Submitted By: George Sakkis (gsakkis) Assigned to: Nobody/Anonymous (nobody) Summary: set.__getstate__ is not overriden Initial Comment: >>> import pickle >>> class Foo(set): ... def __getstate__(self): assert False >>> pickle.dumps(Foo()) # doesn't raise AssertionError The same happens with frozenset. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326448&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
