[ python-Feature Requests-1449496 ] Python should use 3GB Address Space on Windows
Feature Requests item #1449496, was opened at 2006-03-14 12:04 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=1449496&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Gfeller (gfe) Assigned to: Nobody/Anonymous (nobody) Summary: Python should use 3GB Address Space on Windows Initial Comment: Python runs fine using a 3GB address space on 32bit Windows. To take advantage of this feature, Python should be linked using the /LARGEADDRESSAWARE flag of the linker. For details, please refer to: http://msdn.microsoft.com/library/en- us/memory/base/4gt_ram_tuning.asp As most Windows users just use pre-built executables, this would be a worthwhile change. Best regards, Martin Gfeller -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1449496&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1443504 ] locale.getpreferredencoding() dies when setlocale fails
Bugs item #1443504, was opened at 2006-03-05 08:50 Message generated for change (Settings changed) made by catherinedevlin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1443504&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: 3 Submitted By: Catherine Devlin (catherinedevlin) Assigned to: Nobody/Anonymous (nobody) Summary: locale.getpreferredencoding() dies when setlocale fails Initial Comment: I'm on Ubuntu 5.10, with Python 2.4.2-0ubuntu2, and when I open a terminal window and run python, I get >>> import locale >>> locale.getpreferredencoding() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/locale.py", line 417, in getpreferredencoding setlocale(LC_CTYPE, "") File "/usr/lib/python2.4/locale.py", line 381, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting However, if I su - root - or even su right back to my own account (catherine) ! - then everything works. This is of concern (to me, anyway) because this error crashes bzr. I chose "Esperanto" as my language when setting up Ubuntu. (No, I wasn't trying to be funny - I really do speak Esperanto!) That may be why I found the problem, but I don't think this is simply a problem with flawed Esperanto support in Ubuntu - because the routine works after su is used, and because locale.nl_langinfo(CODESET) works fine (please read on). Anyway, within locale.getpreferredencoding(), line 417 - setlocale(LC_CTYPE, "") - seems to be the problem... >>> locale.setlocale(locale.LC_CTYPE) 'C' >>> locale.setlocale(locale.LC_CTYPE, "") Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/locale.py", line 381, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting >>> locale.setlocale(locale.LC_CTYPE, None) 'C' This makes me wonder if setlocale(LC_TYPE, "") is really so very necessary. It seems to be there to prep for the nl_langinfo call, but it doesn't actually seem strictly necessary for that call to work. >>> locale.nl_langinfo(locale.CODESET) 'ANSI_X3.4-1968' ... I get that result whether before or after calling setlocale, and I get it under any account (including root, where setlocale does not raise an exception). Thus, as far as I can tell, it isn't really necessary to set setlocale(LC_CTYPE, "") or die trying, and accepting the nl_langinfo result without a successful setlocale(LC_CTYPE, "") would be preferable to raising an unhandled exception. I suggest that setlocale(LC_TYPE, "") be enclosed in a try block. try: setlocale(LC_CTYPE, "") except: None Since I don't really understand what it's doing in the first place, I don't know if this is really a good patch. Thanks! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1443504&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1450019 ] Build of readline fails
Bugs item #1450019, was opened at 2006-03-14 18: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=1450019&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Sydney Weidman (weidmans) Assigned to: Nobody/Anonymous (nobody) Summary: Build of readline fails Initial Comment: I was attempting to compile Python-2.3.5 under Fedora Core 4: Python 2.3.5 (#14, Mar 14 2006, 17:57:17) [GCC 4.0.2 20051125 (Red Hat 4.0.2-8)] on linux2 and needed it to have readline support No matter how I compiled it, the readline module was never built, and of course readline functionality did not work. I tried ./configure --with-readline=/usr and a couple of other configure options that I thought would help, but nothing worked. Finally, I tried: make Modules/readline which gave the error: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -L/home/sweidman/Applications/Python-2.3.5 Modules/readline.c -o Modules/readline Modules/readline.c:96: error: static declaration of âhistory_lengthâ follows non-static declaration /usr/include/readline/history.h:242: error: previous declaration of âhistory_lengthâ was here make: *** [Modules/readline] Error 1 So without knowing what I was really doing, I commented out the definition of history_length at Modules/readline.c:96 After making that change, Python-2.3.5 compiled and ran fine with readline support working; i.e. "import readline" gave no errors and the arrow keys bring back the last command. So is this a bug or a quirk on my platform or something else I'm doing wrong? Thanks for the great software!! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1450019&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-931877 ] Segfault in object_reduce_ex
Bugs item #931877, was opened at 2004-04-08 13:46
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=931877&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: Tim Peters (tim_one)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault in object_reduce_ex
Initial Comment:
Shane Hathaway bumped into this, unbounded recursion
in typeobject.c's object_reduce_ex(). This occurs in
Python 2.3.3 and current CVS.
Assigned to Guido, to ponder whether object_reduce_ex
is doing what it should; if it is (which seems likely to
me), I suppose we need to inject a recursion counter to
prevent the segfault.
The failing case is short, but I'll attach it (temp99.py) to
avoid SF line mangling. While the test uses pickle, same
symptom if it's changed to use cPickle instead.
Jim Fulton's analysis:
"""
This is a very clever infinite loop. The proxy doesn't
actually proxy, but it does manage to confuse reduce
about what's going on.
reduce tries to figure out if it has been overridden by
asking whether the class's reduce is the same as
object.__reduce__. It doesn't expect to be lied to
about the class. Things wouldn't have been so bad if
the proxy had proxied __reduce__ as well as __class__.
"""
The priority hasn't been bumped, because "the real
code" from which this was whittled down wasn't doing
what it needed to do anyway, and the recursion went
away when the real code was repaired.
--
>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-03-15 00:05
Message:
Logged In: YES
user_id=6380
Unassigning. I need to concentrate on Python 3000.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 16:58
Message:
Logged In: YES
user_id=1188172
Still crashing with 2.5...
--
Comment By: Nathan Srebro (nati)
Date: 2004-11-29 20:26
Message:
Logged In: YES
user_id=63133
This infinite recursion also occurs in another place, that
got me stumped for a couple of days when old code that
worked with Python 2.2 stopped working. If __class__ is not
fidgeted with (as in original bug report), but a descriptor
returns a custom reduce for the class, but not for its
objects, reduce enters an infinite loop on the object:
"""
class descriptor_for_reduce(object):
def __get__(self,obj,tp=None):
if obj is not None: return
super(ASpecialClass,obj).__reduce__
return self.reducer
def reducer(self,proto=None):
return "VerySpecial"
class ASpecialClass(object):
__reduce__ = descriptor_for_reduce()
copy.copy(ASpecialClass())
"""
ASpecialClass().__reduce__ is object.__reduce__, which is
implemented by typeobject.c:object_reduce_ex. This function
(that doesn't know if its called as the __reduce__ or the
__reduce_ex__ method) tries to detect if the object's
__reduce__ is overridden. It does so by checking if the
object's class's __reduce__ is overridden, and in fact it
is. It then assumes that the object's __reduce__ is
overridden, and calls it. But the object's __reduce__ is
the same function, causing the infinite loop.
If __reduce_ex__ is used instead of __reduce__, the problem
goes away, ASpecialClass().__reduce_ex__() return the usual
tuple, and ASpecialClass.__reduce_ex__() return
"VerySpecial". But when __reduce__ is overridden,
ASpecialClass().__reduce__() enters an infinite loop.
I believe this is a legitimate example that should behave
just as when __reduce_ex__ is overridden. The example
doesn't lie about __class__, and it is certainly legitimate
for define a property that behaves differently for the class
and for its objects.
Where did this come up and why would I ever care about a
class's __reduce__? The __reduce__ attribute of a class is
never used by (the standard) pickle or copy, since
save_global() is called instead. However, I have a custom
pickler, implemented as a subclass of pickle.Pickler, which
falls back on the class's __reduce__ when save_global()
fails. This way, I can pickle certain classes that are
created at run-time (and can be easily recreated, e.g. from
their bases and dictionaries).
--
Comment By: Tim Peters (tim_one)
Date: 2004-04-08 13:51
Message:
Logged In: YES
user_id=31435
Hmm! The temp99.py download link doesn't work for me.
Here's the content in case it doesn't work for others either:
"""
import cPickle as pickle
from pickle import dumps
class SimpleItem:
def __reduce__(self):
return (self.__class__, None, {})
cla
