[ python-Feature Requests-1326277 ] itertools.count wraps around after maxint
Feature Requests item #1326277, was opened at 2005-10-13 18:27 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&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: None 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: Raymond Hettinger (rhettinger) Date: 2005-10-14 02:12 Message: Logged In: YES user_id=80475 It's not a bug -- it is the documented behavior. The simple work-around is to roll your own generators: def count(n): while 1: yield n n += 1 def enumerate(iterable): c = 0 for elem in iterable: yield (c, elem) c += 1 Will look at possibly enhancing this for Py2.5. -- Comment By: paul rubin (phr) Date: 2005-10-14 00: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 00: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 18: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=355470&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 01:38 Message generated for change (Settings changed) made by rhettinger 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: Raymond Hettinger (rhettinger) 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
[ python-Bugs-1325071 ] "as" keyword sometimes highlighted in strings
Bugs item #1325071, was opened at 2005-10-12 12:45 Message generated for change (Comment added) made by rhettinger 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. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-14 02:20 Message: Logged In: YES user_id=80475 It is better to have fast and simple syntax highlighting which does not special-case literals. IOW, I prefer the status quo -- it would be a loss to have the highlighting code get mired down with parser logic. -- 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-1325611 ] Curses,h
Bugs item #1325611, was opened at 2005-10-13 18:04 Message generated for change (Comment added) made by kbob_ru 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 -- Comment By: kbob_ru (kbob_ru) Date: 2005-10-14 20:46 Message: Logged In: YES user_id=1347065 What's operating system?? -- 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-1325611 ] Curses,h
Bugs item #1325611, was opened at 2005-10-13 05:04 Message generated for change (Comment added) made by rbrenner 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 -- >Comment By: hafnium (rbrenner) Date: 2005-10-14 08:05 Message: Logged In: YES user_id=1361127 OS = FreeBSD 4.4 -- Comment By: kbob_ru (kbob_ru) Date: 2005-10-14 07:46 Message: Logged In: YES user_id=1347065 What's operating system?? -- 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-1325611 ] Curses,h
Bugs item #1325611, was opened at 2005-10-13 19:04 Message generated for change (Comment added) made by perky 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: Closed >Resolution: Invalid 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: Hye-Shik Chang (perky) Date: 2005-10-14 22:13 Message: Logged In: YES user_id=55188 It's a FreeBSD bug. Please use up-to-date ports. See: http://www.freshports.org/lang/python/[EMAIL PROTECTED] -- Comment By: hafnium (rbrenner) Date: 2005-10-14 22:05 Message: Logged In: YES user_id=1361127 OS = FreeBSD 4.4 -- Comment By: kbob_ru (kbob_ru) Date: 2005-10-14 21:46 Message: Logged In: YES user_id=1347065 What's operating system?? -- 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-1325611 ] Curses,h
Bugs item #1325611, was opened at 2005-10-13 05:04 Message generated for change (Comment added) made by rbrenner 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 -- >Comment By: hafnium (rbrenner) Date: 2005-10-14 09:16 Message: Logged In: YES user_id=1361127 Thanks -- Comment By: Hye-Shik Chang (perky) Date: 2005-10-14 08:13 Message: Logged In: YES user_id=55188 It's a FreeBSD bug. Please use up-to-date ports. See: http://www.freshports.org/lang/python/[EMAIL PROTECTED] -- Comment By: hafnium (rbrenner) Date: 2005-10-14 08:05 Message: Logged In: YES user_id=1361127 OS = FreeBSD 4.4 -- Comment By: kbob_ru (kbob_ru) Date: 2005-10-14 07:46 Message: Logged In: YES user_id=1347065 What's operating system?? -- 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-Feature Requests-1326830 ] python scratchpad
Feature Requests item #1326830, was opened at 2005-10-14 14:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1326830&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: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: python scratchpad
Initial Comment:
Lots of times I want to use Idle sort of like a
Mathematica notebook but for Python. That is, I want
to enter some code and interactively run it, edit it,
run it some more, etc. Then, at the end, I typically
don't want to save it. It's like doing a calculation
on scratch paper and throwing away the paper after
finding the answer.
It's a bit of a pain to have to explicitly save such
code in a file, going through the whole file dialog,
after launching to a Python editor window. Most word
processors will generate an automatic filename like
"Untitled", or "Untitled-1", "Untitled-2", etc., if
"Untitled" already exists. That makes the dialog a bit
more streamlined.
It would be nice if this type of operation were easier
in IDLE. I'm not sure of the exact best way. Here are
some:
1) Have a default filename ("Untitled-.py" for
example) that saves to the user's home dir, or
home/.idle, or maybe some configurable place. User
could click to confirm (that's probably the easiest) or
IDLE could display some kind of message (preferable)
that doesn't need user interaction. IDLE has no status
bar right now so maybe it would need one in order to
display such a message conveniently.
I guess the message could be displayed in the Python
shell (by sending an appropriate print statement to the
subprocess) if the user saves by hitting F5 to run the
program.
2) (this is perhaps questionable) The default place to
save the file could be in /tmp. On hitting F5, the
Python shell would print a message noting that the file
was only in /tmp and hadn't been saved anyplace permanent.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1326830&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 15:56 Message generated for change (Comment added) made by rhettinger 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: Closed >Resolution: Invalid 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 -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-14 09:41 Message: Logged In: YES user_id=80475 Try this: p = [lambda t, n=n: t**n for n in range(6)] -- 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-1326841 ] SIGALRM alarm signal kills interpreter
Bugs item #1326841, was opened at 2005-10-14 14:48 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=1326841&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: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: SIGALRM alarm signal kills interpreter Initial Comment: This may be similar to #210641. Example (Python 2.4.1, Fedora Core 4 GNU/Linux): sh-3.00$ python Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import signal >>> signal.alarm(1) # 1 second passes... 0 >>> Alarm clock sh-3.00$ # python has exited Doing the same thing in IDLE results in the subprocess restarting. IMO the correct behavior would be to raise an exception that the outer shell would catch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1326841&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-1326277 ] itertools.count wraps around after maxint
Feature Requests 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=355470&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: None 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 15:11 Message: Logged In: YES user_id=72053 You're right, the docs do describe that behavior of itertools.count (someone on clpy thought otherwise, IIRC). I don't see anything in http://docs.python.org/lib/built-in-funcs.html about what enumerate does. It looks my p3-750 can enumerate about 400k iterations of itertools.repeat(None) per second, so it can reach maxint in about 1.5 hours, but I don't feel like running it that long to see what happens. At minimum, enumerate's doc should be updated to say what it does. I suppose it's a matter of opinion but I'd take the view that both of these wraparounds (assuming enumerate wraps around) are bugs even if they're documented bugs. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-14 07:12 Message: Logged In: YES user_id=80475 It's not a bug -- it is the documented behavior. The simple work-around is to roll your own generators: def count(n): while 1: yield n n += 1 def enumerate(iterable): c = 0 for elem in iterable: yield (c, elem) c += 1 Will look at possibly enhancing this for Py2.5. -- 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=355470&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 01:38 Message generated for change (Comment added) made by rhettinger 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: Tim Peters (tim_one) 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. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-14 09:37 Message: Logged In: YES user_id=80475 Tim, do you have any thoughts on this? I'm unclear on whether this is a bug in set(), in copy_reg, in pickle, or even a bug at all. setobject.c implements pickling via a __reduce__() method. -- 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
[ python-Bugs-1325611 ] Curses,h
Bugs item #1325611, was opened at 2005-10-13 12:04 Message generated for change (Comment added) made by birkenfeld 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: Closed >Resolution: Invalid 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-14 18:59 Message: Logged In: YES user_id=1188172 Closing again. -- Comment By: hafnium (rbrenner) Date: 2005-10-14 16:16 Message: Logged In: YES user_id=1361127 Thanks -- Comment By: Hye-Shik Chang (perky) Date: 2005-10-14 15:13 Message: Logged In: YES user_id=55188 It's a FreeBSD bug. Please use up-to-date ports. See: http://www.freshports.org/lang/python/[EMAIL PROTECTED] -- Comment By: hafnium (rbrenner) Date: 2005-10-14 15:05 Message: Logged In: YES user_id=1361127 OS = FreeBSD 4.4 -- Comment By: kbob_ru (kbob_ru) Date: 2005-10-14 14:46 Message: Logged In: YES user_id=1347065 What's operating system?? -- 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-1327110 ] wrong TypeError traceback in generator expressions
Bugs item #1327110, was opened at 2005-10-14 16:25
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=1327110&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Yusuke Shinyama (euske)
Assigned to: Nobody/Anonymous (nobody)
Summary: wrong TypeError traceback in generator expressions
Initial Comment:
In the following session, the TypeError traceback of '
'.join( foo(i) for i in range(10) ) is wrong. The cause
is not because of being a generator, but of its
manually created exception.
--
Python 2.4.2 (#1, Oct 14 2005, 16:08:57)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> def foo(x): raise TypeError('foo!')
...
>>> def bar(x): raise ValueError('bar!')
...
>>> ' '.join( foo(i) for i in range(10) )
Traceback (most recent call last):
File "", line 1, in ?
TypeError: sequence expected, generator found
>>> ' '.join( bar(i) for i in range(10) )
Traceback (most recent call last):
File "", line 1, in ?
File "", line 1, in
File "", line 1, in bar
ValueError: bar!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327110&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1327110 ] wrong TypeError traceback in generator expressions
Bugs item #1327110, was opened at 2005-10-14 15:25
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327110&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.4
Status: Open
Resolution: None
>Priority: 1
Submitted By: Yusuke Shinyama (euske)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: wrong TypeError traceback in generator expressions
Initial Comment:
In the following session, the TypeError traceback of '
'.join( foo(i) for i in range(10) ) is wrong. The cause
is not because of being a generator, but of its
manually created exception.
--
Python 2.4.2 (#1, Oct 14 2005, 16:08:57)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> def foo(x): raise TypeError('foo!')
...
>>> def bar(x): raise ValueError('bar!')
...
>>> ' '.join( foo(i) for i in range(10) )
Traceback (most recent call last):
File "", line 1, in ?
TypeError: sequence expected, generator found
>>> ' '.join( bar(i) for i in range(10) )
Traceback (most recent call last):
File "", line 1, in ?
File "", line 1, in
File "", line 1, in bar
ValueError: bar!
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-14 15:57
Message:
Logged In: YES
user_id=80475
This isn't an error -- it was a design decision. It is not
unusual to have a situation arise in Python where a high
level routine competes with a low level routine over which
is in the best position to provide the most useful error
message. The low level routine typically knows the
proximate cause. The high level routine typically knows
what the user was trying to do.
In the case of str.join(), the high level routine usually
makes the most informative error message; however, it is
sometimes off the mark.
Will revisit the design decision to see if it should be
changed. Lowering the priority because the code is working
as designed, the error type is correct, and it is not clear
that any change is warranted.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327110&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1327233 ] title() uppercases latin1 strings after accented letters
Bugs item #1327233, was opened at 2005-10-14 21: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=1327233&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: Humberto Diógenes (virtualspirit) Assigned to: Nobody/Anonymous (nobody) Summary: title() uppercases latin1 strings after accented letters Initial Comment: When using latin1, the title() method of strings considers accented letters as word separators. The same thing doesn't happen with unicode strings: >>> print u'diógenes'.title() Diógenes >>> print 'diógenes'.title() DióGenes I'm using Python 2.4.2 on Ubuntu Breezy with 'utf-8' as default encoding. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327233&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1327233 ] title() uppercases latin1 strings after accented letters
Bugs item #1327233, was opened at 2005-10-14 21:08 Message generated for change (Settings changed) made by virtualspirit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327233&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: 1 Submitted By: Humberto Diógenes (virtualspirit) Assigned to: Nobody/Anonymous (nobody) Summary: title() uppercases latin1 strings after accented letters Initial Comment: When using latin1, the title() method of strings considers accented letters as word separators. The same thing doesn't happen with unicode strings: >>> print u'diógenes'.title() Diógenes >>> print 'diógenes'.title() DióGenes I'm using Python 2.4.2 on Ubuntu Breezy with 'utf-8' as default encoding. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327233&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1327233 ] title() uppercases latin1 strings after accented letters
Bugs item #1327233, was opened at 2005-10-15 09:08 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327233&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.4 >Status: Closed >Resolution: Invalid Priority: 1 Submitted By: Humberto Diógenes (virtualspirit) Assigned to: Nobody/Anonymous (nobody) Summary: title() uppercases latin1 strings after accented letters Initial Comment: When using latin1, the title() method of strings considers accented letters as word separators. The same thing doesn't happen with unicode strings: >>> print u'diógenes'.title() Diógenes >>> print 'diógenes'.title() DióGenes I'm using Python 2.4.2 on Ubuntu Breezy with 'utf-8' as default encoding. -- >Comment By: Hye-Shik Chang (perky) Date: 2005-10-15 11:55 Message: Logged In: YES user_id=55188 String methods are locale-dependent. You should set locale LC_CTYPE) to use such methods. >>> print 'diógenes'.title() DióGenes >>> import locale >>> locale.setlocale(locale.LC_ALL, '') 'fr_FR.ISO8859-1' >>> print 'diógenes'.title() Diógenes And, string manipulation methods only works for single byte character encodings. So the usage will not work for UTF-8 or others. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327233&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
