[ python-Bugs-1575746 ] typo: section 2.1 -> property
Bugs item #1575746, was opened at 2006-10-12 09:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575746&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Antoine De Groote (grootea) Assigned to: Nobody/Anonymous (nobody) Summary: typo: section 2.1 -> property Initial Comment: http://docs.python.org/lib/built-in-funcs.html The property function paragraph (version 2.5) includes the following snippet class C(object): def __init__(self): self.__x = None def getx(self): return self._x def setx(self, value): self._x = value def delx(self): del self._x x = property(getx, setx, delx, "I'm the 'x' property.") On line 2, __x is initialized. Some think this should be _x. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575746&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1575746 ] typo: section 2.1 -> property
Bugs item #1575746, was opened at 2006-10-12 07:22 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575746&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Antoine De Groote (grootea) >Assigned to: Georg Brandl (gbrandl) Summary: typo: section 2.1 -> property Initial Comment: http://docs.python.org/lib/built-in-funcs.html The property function paragraph (version 2.5) includes the following snippet class C(object): def __init__(self): self.__x = None def getx(self): return self._x def setx(self, value): self._x = value def delx(self): del self._x x = property(getx, setx, delx, "I'm the 'x' property.") On line 2, __x is initialized. Some think this should be _x. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 07:38 Message: Logged In: YES user_id=849994 Thanks for the report, fixed in rev. 52293, 52294 (2.5). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575746&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-813342 ] -Qnew switch doesn't work
Bugs item #813342, was opened at 2003-09-26 23:18 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813342&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: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Gregor Lingl (glingl) >Assigned to: Georg Brandl (gbrandl) Summary: -Qnew switch doesn't work Initial Comment: When starting IDLE 1.0 with Python's -Qnew option new division ist *not* in action! (Whereas this worked well with IDLE 0.8 and Python 2.2) Exception: new division works, when additionally the -n switch of IDLE is used (no subprocesses). -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 07:57 Message: Logged In: YES user_id=849994 Fixed in rev. 52295, 52296 (2.5). -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 06:25 Message: Logged In: YES user_id=33168 This is still a problem in 2.5 (CVS). -- Comment By: Gregor Lingl (glingl) Date: 2003-09-28 22:12 Message: Logged In: YES user_id=505031 Sorry, adding turtle.py was an error (wrong bug-thread, see bug 812986) Gregor -- Comment By: Gregor Lingl (glingl) Date: 2003-09-28 22:05 Message: Logged In: YES user_id=505031 Oh! Here is the file mentioned above, Gregor -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813342&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565919 ] sets missing from standard types list in ref
Bugs item #1565919, was opened at 2006-09-26 18:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565919&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Georg Brandl (gbrandl) >Assigned to: Georg Brandl (gbrandl) Summary: sets missing from standard types list in ref Initial Comment: Sets (and frozensets) are missing from http://docs.python.org/ref/types.html. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 08:23 Message: Logged In: YES user_id=849994 Fixed in rev. 52297, 52298 (2.5). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565919&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1086642 ] Compile of _socket fails on 2.4
Bugs item #1086642, was opened at 2004-12-16 19:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&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: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: "_SS_ALIGNSIZE" redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 08:44 Message: Logged In: YES user_id=849994 Is anyone going to do something about this, without a specific report? Anyway, lowering priority. -- Comment By: Andrew McNabb (amcnabb) Date: 2006-09-19 21:42 Message: Logged In: YES user_id=1234027 When I use the native IRIX cc to compile socketmodule.c in Python 2.5, I get: cc -OPT:Olimit=0 -DNDEBUG -O -I. -I/auto/fsc/awm27/bzr/Python-2.5/./Include -I/fsc/awm27/i nclude -I./Include -I. -I/usr/local/include -I/auto/fsc/awm27/bzr/Python-2.5/Include -I/au to/fsc/awm27/bzr/Python-2.5 -c /auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.c -o bu ild/temp.irix64-6.5-2.5/auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.o cc-1047 cc: WARNING File = /usr/include/sys/param.h, Line = 372 Macro "MAX" (declared at line 77 of "/auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.c") has an incompatible redefinition. #define MAX(a,b) (((a)>(b))?(a):(b)) ^ When I commented out the macro definition in socketmodule.c, I was able to get it to compile (with the IRIX compiler). It seems to me that --without-gcc should be the default for IRIX until the gcc problem gets fixed because ./configure is currently automatically choosing gcc as the compiler when both are available. And I'm really not sure why the "#undef MAX" didn't happen. Anyway, I hope this is helpful for someone. -- Comment By: Andrew McNabb (amcnabb) Date: 2006-09-19 21:26 Message: Logged In: YES user_id=1234027 I'm having this same problem with Python 2.5. I checked, and "/usr/lib/libmpc.a" is present. I've only tried with gcc, and I'm getting the exact same errors as above. -- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date:
[ python-Bugs-1565468 ] Install on WinXP always goes to C:\
Bugs item #1565468, was opened at 2006-09-26 03:05 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565468&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 Submitted By: Wayne Pierce (piercew) >Assigned to: Martin v. Löwis (loewis) Summary: Install on WinXP always goes to C:\ Initial Comment: When I install Python on WinXP it always goes go C:\ even though I select C:\Python . This happens when Python is installed for just me or for all users on a system. The system is running WinXP SP 2 and the account installing has enough rights to install applications. An install log has been attached. -- Comment By: Wayne Pierce (piercew) Date: 2006-09-26 09:10 Message: Logged In: YES user_id=4553 Since I cannot attach a file to a bug report I have placed the python.log file at http://shalofin.googlepages.com/python.log -- Comment By: Wayne Pierce (piercew) Date: 2006-09-26 03:40 Message: Logged In: YES user_id=4553 I am unable to attach a file. Every time a file is attached I receive a 'page cannot be found' error message. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565468&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-1555501 ] Please include pliblist for all plattforms
Feature Requests item #101, was opened at 2006-09-09 20:07 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=101&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Guido Guenther (guidog) Assigned to: Nobody/Anonymous (nobody) Summary: Please include pliblist for all plattforms Initial Comment: Hi, plistlib which is currently under ./Lib/plat-mac/plistlib.py is usefull on other platforms too (e.g. in apples calendar server which runs on OS X and Linux). Could this be moved to Lib/ for 2.5 so that other platforms can benefit from it too? Cheers, -- Guido -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 09:05 Message: Logged In: YES user_id=849994 Currently, there is no documentation for plistlib. Would you be willing to help writing one? -- Comment By: Guido Guenther (guidog) Date: 2006-09-17 20:27 Message: Logged In: YES user_id=696207 That's sad since it looks unproblematic. Please add it to 2.6 then. Thanks a lot, -- Guido -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-17 19:27 Message: Logged In: YES user_id=580910 this is too late for 2.5. Adding it to the general library could be done for 2.6. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=101&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1565129 ] make plistlib.py available in every install
Bugs item #1565129, was opened at 2006-09-25 14:28 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565129&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.6 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: make plistlib.py available in every install Initial Comment: [requested in http://bugs.debian.org/386738] plistlib which is currently under ./Lib/plat-mac/plistlib.py is usefull on other platforms too it's e.g. needed for packaging calendar-server -- Apple's calendar server The module could be packaged separately, but should better be used from the standard library. -- Comment By: �iga Seilnacht (zseil) Date: 2006-09-25 15:42 Message: Logged In: YES user_id=1326842 This is a duplicate of bug #779460: http://www.python.org/sf/779460 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1565129&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-1555501 ] Please include pliblist for all plattforms
Feature Requests item #101, was opened at 2006-09-09 22:07 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=101&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.6 Status: Open Resolution: None Priority: 5 Submitted By: Guido Guenther (guidog) Assigned to: Nobody/Anonymous (nobody) Summary: Please include pliblist for all plattforms Initial Comment: Hi, plistlib which is currently under ./Lib/plat-mac/plistlib.py is usefull on other platforms too (e.g. in apples calendar server which runs on OS X and Linux). Could this be moved to Lib/ for 2.5 so that other platforms can benefit from it too? Cheers, -- Guido -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-12 11:08 Message: Logged In: YES user_id=580910 As an aside: adding plistlib to the standard library seems to be a good idea. I've discussed this with Jack Jansen and Bob Ippolito and they agree. The only thing that's missing at the moment is documentation. -- Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 11:05 Message: Logged In: YES user_id=849994 Currently, there is no documentation for plistlib. Would you be willing to help writing one? -- Comment By: Guido Guenther (guidog) Date: 2006-09-17 22:27 Message: Logged In: YES user_id=696207 That's sad since it looks unproblematic. Please add it to 2.6 then. Thanks a lot, -- Guido -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-09-17 21:27 Message: Logged In: YES user_id=580910 this is too late for 2.5. Adding it to the general library could be done for 2.6. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=101&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1550524 ] inspect module and class startlineno
Bugs item #1550524, was opened at 2006-09-01 13:26 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550524&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Ali Gholami Rudi (aligrudi) >Assigned to: Georg Brandl (gbrandl) Summary: inspect module and class startlineno Initial Comment: Inspect module fails to find the correct starting line number of a class. :: import inspect def a_func(): class AClass(object): pass class AClass(object): pass print inspect.findsource(AClass)[1] # the result should have been 7, but it is 4 After reading `inspect` module I realized that for classes it does a simple RE search to find their definition location. Apart from that I think python does not seem to fully support classes with the same name in one module (nested classes that are defined in other functions or classes). That is a `ClassType` only holds its module and its name and that is hardly enough for runtime analysis of objects. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 09:21 Message: Logged In: YES user_id=849994 Added a better find heuristics in rev. 52299, 52300 (2.5). (More can't be done) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550524&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1549574 ] Pdb parser bug
Bugs item #1549574, was opened at 2006-08-30 20:46
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549574&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pdb parser bug
Initial Comment:
>>> import pdb
>>> pdb.set_trace()
--Return--
> (1)()->None
(Pdb) p ";;"
*** SyntaxError: SyntaxError('EOL while scanning
single-quoted string', ('', 1, 1, '"'))
*** SyntaxError: EOL while scanning single-quoted
string (, line 1)
Still present in trunk:51513M
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 09:23
Message:
Logged In: YES
user_id=849994
It's documented, and it can be worked around. So I'm closing
this as Won't Fix. If you want to have a more elaborate
splitting, please submit a feature request.
--
Comment By: Ilya Sandler (isandler)
Date: 2006-09-04 21:42
Message:
Logged In: YES
user_id=971153
For the record, this behaviour is explicitly documented in
pdb docs.
from:
http://www.python.org/doc/current/lib/debugger-commands.html
"""Multiple commands may be entered on a single line,
separated by ";;" No intelligence is applied to
separating the commands; the input is split at the first
";;" pair, even if it is in the middle of a quoted string."""
So should this be considered a bug?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549574&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1575803 ] Missing notice on environment setting LD_LIBRARY_PATH
Bugs item #1575803, was opened at 2006-10-12 11:42 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=1575803&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Anastasios Hatzis (ahatzis) Assigned to: Nobody/Anonymous (nobody) Summary: Missing notice on environment setting LD_LIBRARY_PATH Initial Comment: Probably it would be a good idea to provide Linux noobs like me a short notice in the README that LD_LIBRARY_PATH needs to be set. It was time-consuming to find out what caused problems with my installation although the build process went fine. I don't know if this is really only necessary if Python is built from source with the "--enable-shared" option. If yes, a short notice in this paragraph would be fine: Building a shared libpython --- Starting with Python 2.3, the majority of the interpreter can be built into a shared library, which can then be used by the interpreter executable, and by applications embedding Python. To enable this feature, configure with --enable-shared. If you enable this feature, the same object files will be used to create a static library. In particular, the static library will contain object files using position-independent code (PIC) on platforms where PIC flags are needed for the shared library. Otherwise, if the setting is necessary whether "--enable-shared" is turned on or off, a good place would be right after the "make install" explanations. Again, this is a Linux rookie issue. But if I want to install the most recent Python version I can't take any ready-to-use RPM, so I have to build from sources and will run into these problems the first time. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575803&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1548891 ] shlex (or perhaps cStringIO) and unicode strings
Bugs item #1548891, was opened at 2006-08-29 21:16 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548891&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Erwin S. Andreasen (drylock) >Assigned to: Georg Brandl (gbrandl) Summary: shlex (or perhaps cStringIO) and unicode strings Initial Comment: Python 2.5c1 (r25c1:51305, Aug 19 2006, 18:23:29) [GCC 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)] on linux2 (Also seen in 2.4) shlex.split do not like unicode strings: >>> shlex.split(u"foo") ['f\x00\x00\x00o\x00\x00\x00o\x00\x00\x00'] The shlex code IMO suggests that it should accept unicode (as it checks for argument being an instance of basestring). Digging slightly into this, this seems to be a difference between StringIO and cStringIO. While cStringIO claims it accepts unicode as long as it encode too ASCII it gives invalid results: >>> sys.getdefaultencoding() 'ascii' >>> cStringIO.StringIO(u'foo').getvalue() 'f\x00\x00\x00o\x00\x00\x00o\x00\x00\x00' Perhaps cStringIO should .encode to ASCII encoding before consuming the input, as I can't imagine anyone cares about the above result (which I guess are the UCS-2 or UCS-4 characters). -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 09:47 Message: Logged In: YES user_id=849994 Thanks for your report, this is now fixed in rev. 52301, 52302 (2.5). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548891&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1551238 ] Build of 2.4.3 on fedora core 5 fails to find asm/msr.h
Bugs item #1551238, was opened at 2006-09-03 00:38 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551238&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George R. Goffe (grgoffe) Assigned to: Nobody/Anonymous (nobody) Summary: Build of 2.4.3 on fedora core 5 fails to find asm/msr.h Initial Comment: Howdy, I just downloaded Python-2.4.3 and tried to build it with the enclosed results. I then proceeded to check out the latest from svn and that version DOES build. This is just a fyi bug report unless you think otherwise. Regards, George... gcc -pthread -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I. -I./Include -fPIC -DPy_BUILD_CORE -o Python/ceval.o Python/ceval.c Python/ceval.c:50:21: error: asm/msr.h: No such file or directory Python/ceval.c: In function 'PyEval_EvalFrame': Python/ceval.c:578: warning: implicit declaration of function 'rdtscll' make: *** [Python/ceval.o] Error 1 -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 10:49 Message: Logged In: YES user_id=849994 If it works in SVN, it will work in 2.4.4 and 2.5. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551238&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1560032 ] confusing error msg from random.randint
Bugs item #1560032, was opened at 2006-09-17 06:22 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560032&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: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: confusing error msg from random.randint Initial Comment: See the following output. The reason for the confusing message is that random.randint is actually a bound method to a Random instance inside the module, i.e. someone got a little bit too clever. It should be an ordinary function that calls that instance method instead. >>> import random >>> random.randint(1) Traceback (most recent call last): File "", line 1, in ? TypeError: randint() takes exactly 3 arguments (2 given) -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 10:51 Message: Logged In: YES user_id=849994 Note that it is documented that the random functions are actually bound methods. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560032&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1562092 ] IDLE: Dedent with Italian keyboard
Bugs item #1562092, was opened at 2006-09-20 11:01 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562092&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: neclepsio (neclepsio82) >Assigned to: Kurt B. Kaiser (kbk) >Summary: IDLE: Dedent with Italian keyboard Initial Comment: In IDLE, with an Italian keyboard, it's impossible to dedent the text without using the menu, because the shortcut Ctrl+] cannot be typed. In fact, with an Italian keybaord, the ] is typed with Ctrl+Alt++. While indent can be achieved with Tab, so that's no problem, dedent is only accesible from menu: I suggest you to shortcut it as Shift+Tab too, like many other IDEs. Thank you Ignazio -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562092&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1546628 ] urlparse.urljoin odd behaviour
Bugs item #1546628, was opened at 2006-08-25 13:04
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546628&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andres Riancho (andresriancho)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse.urljoin odd behaviour
Initial Comment:
Hi !
I think i have found a bug on the urljoin function
of the urlparse
module. I'm using Python 2.4.3 (#2, Apr 27 2006,
14:43:58), [GCC 4.0.3
(Ubuntu 4.0.3-1ubuntu5)] on linux2 . Here is a demo of
the bug :
>>> import urlparse
>>>urlparse.urljoin('http://www.f00.com/','//a')
'http://a'
>>>
urlparse.urljoin('http://www.f00.com/','https:///somethingIsWrong')
'https:///somethingIsWrong'
>>>
urlparse.urljoin('http://www.f00.com/','https:///somethingIsWrong')
'https:///somethingIsWrong'
>>>
urlparse.urljoin('http://www.f00.com/','file:///etc/passwd')
'file:///etc/passwd'
The result for the first call to urljoin should be
either
'http://www.f00.com/a' or 'http://www.f00.com//a'. The
result to the
second and third call to urljoin should be
'http://www.f00.com/', or maybe an
exception ?
Please correct me if i'm wrong and this is some kind
of feature or
the bug was already reported. This bug can result in a
security vuln,
take this code as an example:
// viewImage.py //
import htmlTools
# Some fake
module, just for the example
import urlparse
# module
with bug.
htmlTools.startHtml()
# print
params = htmlTools.getParams()# get the
query string
parameters
htmlTools.printToHtml( 'http://myWebsite/' , params['image'] ) + '>' )
htmlTools.endHtml()
# print
// viewImage.py //
The code should generate an html that shows an image
from the site
http://myWebsite/, but with the urljoin bug, the image
source can be
manipulated and result in a completely different html.
Cheers,
Andres Riancho
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 11:15
Message:
Logged In: YES
user_id=849994
The behavior is okay, but the docs didn't say that. I added
a note in rev. 52303, 52304 (2.5).
--
Comment By: Andrew Jones (the_j10)
Date: 2006-08-29 11:29
Message:
Logged In: YES
user_id=332575
The second argument in the urljoin method can be either an
absolute url or a relative url as specified by rfc1808. So
your 1st example: '//a' gives a relative position w.r.t the
base resulting in: 'http://a'. This is similar to how `cd
/boot` takes you to a path relative to the filesystem's root
'/'.
In the rest of your examples you have the scheme name
'https'in the url as the 2nd argument. urljoin follows the
rfc1808 and accepts the second argument if it has a scheme
name as the absolute url and returns it.
This behavior is not very intuitive. Perhaps the urlparse
could be extended to have a urlappend method, which has the
behavior you expected. Hmmm...
-- Andrew
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546628&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1563243 ] python_d python
Bugs item #1563243, was opened at 2006-09-22 01:20 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563243&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: Pending Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: python_d python Initial Comment: I'v added _d to python (python_d.exe) while performing standard tests ... it dies after testInfinitRecursion without any message - just dissapears :( -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 11:15 Message: Logged In: YES user_id=849994 "I'v added _d to python" is not clear to me. Can you give more information? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563243&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545497 ] inconsistent treatment of NULs in int()
Bugs item #1545497, was opened at 2006-08-23 19:37
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545497&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: Fixed
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Georg Brandl (gbrandl)
Summary: inconsistent treatment of NULs in int()
Initial Comment:
In int_new (Objects/intobject.c), embedded NUL chars
are handled differently.
We should check that the entire string is converted
like PyNumber_Int(). int('5\0') raises an exception.
int('5\0', 10) returns 5.
>>> int('5\0', 10)
5
>>> int('5\0')
Traceback (most recent call last):
File "", line 1, in
ValueError: null byte in argument for int()
The difference is the explicit vs implicit base.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 11:28
Message:
Logged In: YES
user_id=849994
Fixed in rev. 52305, 52306 (2.5).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545497&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1556261 ] Move fpectl elsewhere in library reference
Bugs item #1556261, was opened at 2006-09-11 10:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556261&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Hoffman (hoffmanm) >Assigned to: Georg Brandl (gbrandl) Summary: Move fpectl elsewhere in library reference Initial Comment: The fpectl module is not installed by default, but it still has a prominent place in the library reference. I think it should be moved to Optional Operating System Services and a note added at the top that it is not installed by default. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 11:41 Message: Logged In: YES user_id=849994 Added a note in rev. 52307, 52308 (2.5). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556261&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1560114 ] Tutorial: incorrect info about package importing and mac
Bugs item #1560114, was opened at 2006-09-17 12:24 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560114&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: C L (cl_) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial: incorrect info about package importing and mac Initial Comment: Section 6.4.1 of the Python tutorial says: "Now what happens when the user writes from Sound.Effects import *? Ideally, one would hope that this somehow goes out to the filesystem, finds which submodules are present in the package, and imports them all. Unfortunately, this operation does not work very well on Mac and Windows platforms, where the filesystem does not always have accurate information about the case of a filename! On these platforms, there is no guaranteed way to know whether a file ECHO.PY should be imported as a module echo, Echo or ECHO." This is incorrect. It's true that the (default *) Mac file system does not allow file names differing only in case in the same directory, and lets you access a file by any variation of case; but the file system always records and returns the file name with the exact capitalization that was given when the name was assigned. In other words, if you create a file called "MixedCase.py" you can access it as "mixedcase.py", "MiXeDcAsE.pY" etc., but if you list the contents of its parent directory the name will always be given as "MixedCase.py". This has been true of all versions of the Mac OS going back to System 1.0. Therefore, none of that paragraph applies to any Mac system; on the contrary, the file system always has accurate information about the case of a file name. That section of the text should be changed to remove the reference to the Mac platform. (*: recent Mac OS X systems also allow one to use the HFSX filesystem variant, which allows file names differing only in case and matches file names only when the case is exactly identical - ie, the fully case-sensitive Unix semantics. But again, this has no bearing on the ability to reliably obtain the exact case of the name of a file.) -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 11:47 Message: Logged In: YES user_id=849994 Removed "Mac and" in rev. 52309, 52310 (2.5). -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-08 18:25 Message: Logged In: YES user_id=580910 +1 here. MacOS was case-preserving when I started using it (around OS8) and that hasn't changed. It also doesn't have the odd behaviour of windows where some versions of windows might convert short names to all uppercase. Hence the Mac shouldn't be mentioned in this section. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560114&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1544295 ] Fix Lib/test/test___all__.py
Bugs item #1544295, was opened at 2006-08-22 00:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544295&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.5 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Hasan Diwan (hdiwan650) Assigned to: Nobody/Anonymous (nobody) Summary: Fix Lib/test/test___all__.py Initial Comment: There's a comment saying: # In case _socket fails to build, make this test fail more gracefully # than an AttributeError somewhere deep in CGIHTTPServer. The proposed fix is attached. Applies to revision 51453. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 11:49 Message: Logged In: YES user_id=849994 The existing code's comment is not a To-Do. It states that the test will fail clearly at the import of _socket instead of somewhere in CGIHTTPServer. (closing) -- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-06 17:38 Message: Logged In: YES user_id=11375 Please explain more clearly what the problem is. Does the existing code not work? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544295&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545696 ] structmember T_LONG won't accept a python long
Bugs item #1545696, was opened at 2006-08-24 05:07
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&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: 7
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: structmember T_LONG won't accept a python long
Initial Comment:
An attribute defined as T_LONG throws a vague error
when set to a python long, even when the value is
within the range of a LONG.
TypeError: bad argument type for built-in operation
--
Comment By: Roger Upole (rupole)
Date: 2006-08-30 05:06
Message:
Logged In: YES
user_id=771074
Submitted patch 1549049.
--
Comment By: Roger Upole (rupole)
Date: 2006-08-28 02:23
Message:
Logged In: YES
user_id=771074
In the process of creating a patch for this, I came across
some more 'ugh'-liness. T_UINT's are returned via
PyInt_FromLong, so you actually get back a negative value
for large numbers. Changing it to use
PyLong_FromUnsignedLong will break backward compatibility,
but this is so wrong I can't possibly see keeping it. Your
call. (plus it makes it impossible to test T_UINT with
values larger than INT_MAX)
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-25 00:52
Message:
Logged In: YES
user_id=33168
Ugh. This code is lax in checking/conversion. Do you think
you could provide a patch?
All of the int cases should call PyInt_AsLong() if this call
fails (returns -1), then that should be returned from
PyMember_SetOne. If it succeeds, there should be a range
check that ensures the value is valid. If that fails a
warning should be produced. We need to issue a warning
rather than an error for backwards compatability (at least
for 2.6).
The float/double cases can be simplified some by calling
PyFloat_AsDouble and doing similar checks as in the int cases.
--
Comment By: Roger Upole (rupole)
Date: 2006-08-24 19:56
Message:
Logged In: YES
user_id=771074
The DEVMODE object from pywintypes has attributes defined
as T_LONG via the structmember API.
>>> import pywintypes
>>> dm=pywintypes.DEVMODEType()
>>> dm.Position_x=3
>>> dm.Position_x
3
>>> dm.Position_x=long(3)
Traceback (most recent call last):
File "", line 1, in ?
TypeError: bad argument type for built-in operation
>>>
Here's the relevant code from structmember.c
that throws the error:
case T_LONG:
if (!PyInt_Check(v)) {
PyErr_BadArgument();
return -1;
}
*(long*)addr = PyInt_AsLong(v);
break;
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-24 18:30
Message:
Logged In: YES
user_id=33168
Can you provide example code that demonstrates what you mean?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1555842 ] email package and Unicode strings handling
Bugs item #1555842, was opened at 2006-09-10 16:04 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555842&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: Manlio Perillo (manlioperillo) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email package and Unicode strings handling Initial Comment: The support for Unicode strings in the email package (notably MIMEText and Header class) is not uniform. The behaviour with Unicode strings in Header is documented but the interface is not good. This code works, but it should not: >>> h = Header.Header(u"àèìòù", charset="us-ascii") >>> m = Message.Message() >>> m["Subject"] = h >>> print m.as_string() Allowing this to work can cause confusion, I'm saying that the charset is us-ascii, not utf-8. With MIMEText I obtain: m = MIMEText.MIMEText(u"àèìòù", _charset="us-ascii") >>> print m.as_string() [ exception ] I think that the correct behaviour (for all functions accepting strings) is: - Do not accept plain str strings (8-bit). Accept only if they are plain ascii (7-bit). - The charset specified should not be considered an hint, but the charset I want to be used. Regards Manlio Perillo -- Comment By: Manlio Perillo (manlioperillo) Date: 2006-09-10 17:35 Message: Logged In: YES user_id=1054957 The last example is not right. Here is the correct one: >>> m = MIMEText.MIMEText(u"àèìòù", _charset="utf-8") Traceback (most recent call last): File "", line 1, in ? File "C:\Python2.4\lib\email\MIMEText.py", line 28, in __init__ self.set_payload(_text, _charset) File "C:\Python2.4\lib\email\Message.py", line 218, in set_payload self.set_charset(charset) File "C:\Python2.4\lib\email\Message.py", line 260, in set_charset self._payload = charset.body_encode(self._payload) File "C:\Python2.4\lib\email\Charset.py", line 366, in body_encode return email.base64MIME.body_encode(s) File "C:\Python2.4\lib\email\base64MIME.py", line 136, in encode enc = b2a_base64(s[i:i + max_unencoded]) UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128) So it seems that email.Message does not handle Unicode strings. The code works if I set the charset to latin-1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1555842&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1573394 ] struct module doesn't use weakref for cache
Bugs item #1573394, was opened at 2006-10-08 23:37 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&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 Submitted By: Mark Flacy (markaflacy) >Assigned to: Bob Ippolito (etrepum) Summary: struct module doesn't use weakref for cache Initial Comment: At the moment, when you attempt to add your 101st different Struct object to the cache, all the other 100 entries are tossed into the garbage. That seems a trifle odd. The Struct cache would appear to be a perfect use for a weakref dictionary. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1571841 ] email module does not complay with RFC 2046: CRLF issue
Bugs item #1571841, was opened at 2006-10-06 01:30
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571841&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: Andy Leszczynski (andrzejl)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email module does not complay with RFC 2046: CRLF issue
Initial Comment:
According to rfc2046, line breaks in MIME are CRLF.
However python just
uses LF like in the following example:
from email.MIMEMultipart import MIMEMultipart
from email.MIMEText import MIMEText
msg = MIMEMultipart()
msg['Subject'] = 'Our family reunion'
msg['From'] = '[EMAIL PROTECTED]'
msg['To'] = '[EMAIL PROTECTED]'
msg.epilogue = ''
msg.attach(MIMEText(''))
print `msg.as_string()`
gives:
'Content-Type: multipart/mixed;
boundary="===1018679223=="\nMIME-Version:
1.0\nSubject: Our
family reunion\nFrom: [EMAIL PROTECTED]:
[EMAIL PROTECTED]:
text/plain;
charset="us-ascii"\nMIME-Version:
1.0\nContent-Transfer-Encoding:
7bit\n\n\n--===1018679223==--\n'
Found in version 2.3 and 2.4
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571841&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1572084 ] .eml attachments in email
Bugs item #1572084, was opened at 2006-10-06 12:23 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572084&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 Submitted By: rainwolf8472 (rainwolf8472) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: .eml attachments in email Initial Comment: I think there's a bug somewhere in the email package. I wanted to write a script to send emails with certain attachments using libgmail, and found this one, http://pramode.net/articles/lfy/fuse/4.txt , it works fine with most files, but it fails with .eml files, and what i can't understand is that if I change the extension of those .eml files to .txt, the script works fine. However, when trying to mail a simple textfile containing "hello", en changing the extension to .eml before sending, it fails again. it doesn't fail when I don't change the extension to .eml. Any help please? I pasted the output I get (over and over again) in the attached textfile. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572084&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1049615 ] smeared title when installing
Bugs item #1049615, was opened at 2004-10-18 22:09 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1049615&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.4 >Status: Closed >Resolution: Out of Date Priority: 3 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: smeared title when installing Initial Comment: Python 2.4b1 on Windows XP. 1280x800. The "python: for windows" heading looks smeared. Other graphical elements also look somewhat smeared, but it isn't as much of a problem when it isn't text to begin with. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 12:29 Message: Logged In: YES user_id=849994 The PC build now has entirely different icons, using the new Python.org style. Closing this. -- Comment By: Martin v. Löwis (loewis) Date: 2004-10-20 06:35 Message: Logged In: YES user_id=21627 Scratch the remark on PCbuild/installer.bmp. I somehow thought that 1.2.18.2 has a different resolution than the HEAD version, which it doesn't. I don't understand the phrase "highest-level source". If you are asking whether this is the primary source: for us, it is. Erik van Blokland has some mechanism to generate that, but we don't. -- Comment By: Martin v. Löwis (loewis) Date: 2004-10-20 06:32 Message: Logged In: YES user_id=21627 We would need to ask the original author of that picture. I have not been able to contact him; please try yourself. Using PCbuild/installer.bmp might indeed be an option. I could try to arrange the dialogs so that it won't need scaling. -- Comment By: Jim Jewett (jimjjewett) Date: 2004-10-20 00:23 Message: Logged In: YES user_id=764593 Would it be possible to recreate the original picture (or at least parts of it) at the full size, instead of stretching? If the picture parts have to be stretched, that isn't such a problem, but it is better if the button frames aren't stretched -- and particularly the text. Even just replacing the "windows: python" with blank space and text (or redoing that one portion at full size -- maybe not aliased?) would help. Is this the highest-level source? If so, what size would you like it stretched to, and I'll see if I can help. http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/ python/dist/src/PCbuild/installer.bmp?rev=1.2.18.2 -- Comment By: Martin v. Löwis (loewis) Date: 2004-10-19 19:30 Message: Logged In: YES user_id=21627 I don't know what to do about this. Any suggestion appreciated; without suggestions, this likely is what 2.4 will look like. -- Comment By: Mike Brauwerman (brauwerman) Date: 2004-10-18 23:09 Message: Logged In: YES user_id=71983 The "smearing" is the effect of a small bitmap picture, with aliased text, blown up (stretched) to fit into a large space. The graphic has fat pixels, which look a little funny, but they look better if you squint :-) -- Comment By: Jim Jewett (jimjjewett) Date: 2004-10-18 22:16 Message: Logged In: YES user_id=764593 I used a .bmp to avoid additional info loss. Zipped file is only 20K, but unzips to over a meg. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1049615&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1283491 ] nit for builtin sum doc
Bugs item #1283491, was opened at 2005-09-07 00:18 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&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: Fixed Priority: 4 Submitted By: daishi harada (daishiharada) >Assigned to: Georg Brandl (gbrandl) Summary: nit for builtin sum doc Initial Comment: the docstring signature for sum in bltinmodule.c should be changed from: sum(sequence, start=0) to: sum(sequence[, start]) to reflect the current implementation in builtin_sum. (or else the implementation should be changed to accept kwargs.) -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 12:33 Message: Logged In: YES user_id=849994 Fixed in rev. 52315. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-09-14 20:24 Message: Logged In: YES user_id=1188172 If we change the function signature in the docstring, we must include the "defaults to 0" somewhere. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-08 02:37 Message: Logged In: YES user_id=80475 """ >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? """ FYI, the answer is no. The requirement for parenthesis cannot change. To see why, parse this: f(g(t) for t in a, b). -- Comment By: daishi harada (daishiharada) Date: 2005-09-07 19:02 Message: Logged In: YES user_id=493197 This is relatively minor so I don't mean to push particularly hard, but I'd like to at least show how the docstring made me stray: >>> sum([x] for x in xrange(10)) Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for +: 'int' and 'list' >>> help(sum) Help on built-in function sum in module __builtin__: sum(...) sum(sequence, start=0) -> value Returns the sum of a sequence of numbers (NOT strings) plus the value of parameter 'start'. When the sequence is empty, returns start. >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? >>> sum(([x] for x in xrange(10)), start=[]) Traceback (most recent call last): File "", line 1, in ? TypeError: sum() takes no keyword arguments # examine lib docs, which give the signature: # sum(sequence[, start]) >>> sum(([x] for x in xrange(10)), []) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> # examine bltinmodule.c to confirm that # sum doesn't accept kwargs. -- Comment By: daishi harada (daishiharada) Date: 2005-09-07 19:02 Message: Logged In: YES user_id=493197 This is relatively minor so I don't mean to push particularly hard, but I'd like to at least show how the docstring made me stray: >>> sum([x] for x in xrange(10)) Traceback (most recent call last): File "", line 1, in ? TypeError: unsupported operand type(s) for +: 'int' and 'list' >>> help(sum) Help on built-in function sum in module __builtin__: sum(...) sum(sequence, start=0) -> value Returns the sum of a sequence of numbers (NOT strings) plus the value of parameter 'start'. When the sequence is empty, returns start. >>> sum([x] for x in xrange(10), start=[]) File "", line 1 SyntaxError: invalid syntax # The problem above is orthogonal to the issue in this bug, # but I wonder if at some point we'll be able to write such? >>> sum(([x] for x in xrange(10)), start=[]) Traceback (most recent call last): File "", line 1, in ? TypeError: sum() takes no keyword arguments # examine lib docs, which give the signature: # sum(sequence[, start]) >>> sum(([x] for x in xrange(10)), []) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> # examine bltinmodule.c to confirm that # sum doesn't accept kwargs. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-09-07 03:11 Message: Logged In: YES user_id=80475 While the proposed change is technically correct, I find the original to be more informative. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283491&group_id=5470 ___ Python-bugs-li
[ python-Feature Requests-1043446 ] Interpreter should be interruptable everywhere
Feature Requests item #1043446, was opened at 2004-10-09 04:26
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1043446&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Python Interpreter Core
>Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jp Calderone (kuran)
Assigned to: Raymond Hettinger (rhettinger)
>Summary: Interpreter should be interruptable everywhere
Initial Comment:
import itertools
list(itertools.repeat('x'))
^C will not interrupt this.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 12:40
Message:
Logged In: YES
user_id=849994
Turning into a feature request.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 22:15
Message:
Logged In: YES
user_id=1188172
What to do here?
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2004-10-15 22:25
Message:
Logged In: YES
user_id=593130
Killing the interpreter will, of course, interrupt anything ;-).
The ability to ask the interpreter, via an alternate non-code
communication channel, to stop doing what one just
requested via the normal code input channel, is an
implementation-specific metafeature independent of the
language definition. So I see this as a CPython feature-
expansion request rather than a bug report.
If the CPython interpreter documentation promises that ^C
or whatever will always grab the interpreter's attention, then
that overpromise is a bug that should be modified.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-10-10 08:06
Message:
Logged In: YES
user_id=80475
FWIW, there are many variations of this theme using almost
anything accepting an iterable input (dict.fromkeys, tuple,
set, etc) paired with any long running or infinite iterator
(itertools.count, xrange(sys.maxint), etc). Even the
tp_print slot can get caught up in emitting oversized output
in a way that is uninterruptable.
I don't see a clean way of teaching all of these functions
to periodically check for signals, and either handle them,
raise an exception or continue. Fixing this could muck-up
and complicate a bunch of otherwise clean code.
Still, it would be nice if everything were interruptable.
I'm just not sure it's worth it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1043446&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-231540 ] threads and profiler don't work together
Feature Requests item #231540, was opened at 2001-02-08 15:53
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=231540&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: Threads
>Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Dave Brueck (dbrueck)
>Assigned to: Nobody/Anonymous (nobody)
Summary: threads and profiler don't work together
Initial Comment:
When a new thread is created, it doesn't inherit from the parent thread the
trace and profile functions (sys_tracefunc and sys_profilefunc in
PyThreadState), so multithreaded programs can't easily be profiled.
This may be by design for safety/complexity sake, but the profiler module
should still find some way to function correctly. A temporary (and
performance-killing) workaround is to modify the standard profiler to hook into
threads to start a new profiler for each new thread, and then merge the stats
from a child thread into the parent's when the child thread ends.
Here is sample code that exhibits the problem. Stats are printed only for the
main thread because the child thread has no profiling function and therefore
collects no stats:
import threading, profile, time
def yo():
for j in range(5):
print j,
def go():
threading.Thread(target=yo).start()
time.sleep(1)
profile.run('go()')
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 12:40
Message:
Logged In: YES
user_id=849994
Turning into a feature request.
--
Comment By: Tim Peters (tim_one)
Date: 2001-08-10 05:31
Message:
Logged In: YES
user_id=31435
Reassigned to Fred, our current profiler expert.
--
Comment By: Tim Peters (tim_one)
Date: 2001-02-09 23:57
Message:
Assigned to me but reduced the priority. I'll take a look at it, but have to
suspect it will get reclassified as a Feature Request and moved into PEP 42.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=231540&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-586700 ] site-packages & build-dir python
Bugs item #586700, was opened at 2002-07-25 20:36 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586700&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 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: site-packages & build-dir python Initial Comment: A Python interpreter running from the build directory rather than the installation directory should not use the site-packages or site-python directories. This is more important for a debug-build Python than for a release build. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 12:42 Message: Logged In: YES user_id=849994 As far as I can see, sys.path for ./python in the build-dir does not include any site-packages entry. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=586700&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1534014 ] __name__ doesn't show up in dir() of class
Bugs item #1534014, was opened at 2006-08-03 17:23 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534014&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: Type/class unification Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 4 Submitted By: Tim Chase (gumnos) Assigned to: Nobody/Anonymous (nobody) Summary: __name__ doesn't show up in dir() of class Initial Comment: The __name__ attribute doesn't appear in the dir() of a class, yet is an available attribute. The below reproduces the problem: >>> class Foo(object): pass >>> dir(Foo) ['__class__', '__delattr__', '__dict__', '__doc__', '__getattribute__', '__hash__', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', '__weakref__'] >>> Foo.__name__ 'Foo' Note that this is different from the attribute appearing in an *instance* of the class, as in >>> x = Foo() >>> '__name__' in dir(x) -- >Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 12:48 Message: Logged In: YES user_id=849994 Duplicate of #945861. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534014&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1517663 ] Interpreter crash: filter() + gc.get_referrers()
Bugs item #1517663, was opened at 2006-07-05 17:33
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517663&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.5
>Status: Closed
>Resolution: Wont Fix
Priority: 3
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Interpreter crash: filter() + gc.get_referrers()
Initial Comment:
Similar to the bug in tuple() shown in the current
(r47245) version of Lib/test/crashers/gc_inspection.py,
filter() can be exploited in similar ways.
Rather than the tricky generator used to exploit
tuple(), the attached test case uses a subclass of
tuple with a malicious __getitem__ method. The pattern
being exploited is the same, however: a built-in
function pre-allocates a tuple, then fills it using
calls to user-defined code.
gc_inspection.py.diff also expands the infrastructure
in gc_inspection.py, allowing multiple test functions
to run that could crash the interpreter.
The second patch, fix_filter_crash.patch, is against
Python/bltinmodule.c and adds
_PyObject_GC_TRACK/UNTRACK macros around the call to
the type's sq_item slot in filtertuple().
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 13:01
Message:
Logged In: YES
user_id=849994
I will not disagree with Raymond :)
Furthermore, with your patch to gc_inspection.py, it doesn't
even crash anymore (without the other patch applied).
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-07-05 18:01
Message:
Logged In: YES
user_id=80475
FWIW, I think these safe-cracking style efforts at
creating crashers is a waste of time. Please focus your
efforts on fixing real bugs that matter, not in creating
strange self-referential twists designed to poke holes in
specific implementation details. There is no end to the
kind of things like this that can be found and "fixing"
them involves either making the code more convoluted or
making the code slower but it won't make life better for
most users. Also, I'm concerned that these "fixes" would
need to be reviewed with extreme care, lest we introduce
some new, real bug that DOES impact people's lives. If
there were a real problem with filter(), we would have
known it long ago.
--
Comment By: Collin Winter (collinwinter)
Date: 2006-07-05 17:54
Message:
Logged In: YES
user_id=1344176
An alternative fix for this would be not to invoke
filter{tuple,string,unicode} on instances of subclasses of
tuple, str and unicode.
This would fix this bug because you have to be using a
subclass of one of these types to exploit the preallocation.
As a side-effect, this would also resolve the issue I raised
in bug #1517509 concerning filter()'s treatment of these
subtypes re: the iterator protocol.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517663&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1560179 ] Better/faster implementation of os.path.basename/dirname
Bugs item #1560179, was opened at 2006-09-17 14:55
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&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: Accepted
Priority: 5
Submitted By: Michael Gebetsroither (einsteinmg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better/faster implementation of os.path.basename/dirname
Initial Comment:
hi,
basename/dirname could do better (especially on long
pathnames)
def basename(p):
return split(p)[1]
def dirname(p):
return split(p)[0]
both construct base and dirname and discard the unused
one.
what about that?
def basename(p):
i = p.rfind('/') + 1
return p[i:]
def dirname(p):
i = p.rfind('/') + 1
return p[:i]
greets,
michael
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 13:08
Message:
Logged In: YES
user_id=849994
Committed in rev. 52316.
--
Comment By: Michael Gebetsroither (einsteinmg)
Date: 2006-09-18 12:42
Message:
Logged In: YES
user_id=1600082
posixpath with this patch passes all test from
test_posixpath cleanly.
benchmark:
basename( 310 ) means basename called with a 310 chars long
path
sum = 0.0435626506805 min = 4.19616699219e-05
posixpath.basename( 310 )
sum = 0.152147769928 min = 0.00014591217041
posixpath_orig.basename( 310 )
sum = 0.0436658859253 min = 4.07695770264e-05
posixpath.basename( 106 )
sum = 0.117312431335 min = 0.000112771987915
posixpath_orig.basename( 106 )
sum = 0.0426909923553 min = 4.07695770264e-05
posixpath.basename( 21 )
sum = 0.113305330276 min = 0.000110864639282
posixpath_orig.basename( 21 )
sum = 0.12392115593 min = 0.000121831893921
posixpath.dirname( 310 )
sum = 0.152860403061 min = 0.00014591217041
posixpath_orig.dirname( 310 )
sum = 0.0942873954773 min = 9.08374786377e-05
posixpath.dirname( 106 )
sum = 0.114937067032 min = 0.000111818313599
posixpath_orig.dirname( 106 )
sum = 0.0918889045715 min = 8.79764556885e-05
posixpath.dirname( 21 )
sum = 0.114675760269 min = 0.000109910964966
posixpath_orig.dirname( 21 )
greets
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1575945 ] from_param and _as_parameter_ truncating 64-bit value
Bugs item #1575945, was opened at 2006-10-12 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=1575945&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: Albert Strasheim (albertstrasheim)
Assigned to: Nobody/Anonymous (nobody)
Summary: from_param and _as_parameter_ truncating 64-bit value
Initial Comment:
There seems to be something strange going on with
ctypes' _as_parameter_ on 64-bit machines. I haven't
been able to replicate this problem without NumPy, but
it looks like a ctypes issue since NumPy's
_as_parameter_ contains a valid value but the value
that arrives in the C function has had its upper 4
bytes zeroed.
SConstruct to build library:
env = Environment()
env.Replace(CCFLAGS=['-O0','-ggdb','-Wall','-ansi','-pedantic'])
env.SharedLibrary('spfuncs',['spfuncs.c'])
C code:
#include
void nnz(double *ary) {
printf("ary = %p\n", (void*)ary);
}
Python code:
import numpy as N
from ctypes import *
from numpy.ctypeslib import ndpointer
_libspfuncs = N.ctypeslib.load_library('libspfuncs',
__file__) _libspfuncs.nnz.restype = None A =
N.eye((128)) print 'data_as',
A.ctypes.data_as(c_void_p) print 'array interface',
hex(A.__array_interface__['data'][0])
_libspfuncs.nnz.argtypes = [POINTER(c_double)]
_libspfuncs.nnz(A.ctypes.data_as(POINTER(c_double)))
_libspfuncs.nnz.argtypes = [ndpointer(dtype = N.float64)]
_libspfuncs.nnz(A)
print '_as_parameter', hex(A.ctypes._as_parameter_)
Output on 32-bit system:
data_as c_void_p(-1212006392)
array interface -0x483dbff8
ary = 0xb7c24008
ary = 0xb7c24008
_as_parameter -0x483dbff8
Output on 64-bit system:
data_as c_void_p(46912559644688)
array interface 0x2e740010
ary = 0x2e740010
ary = 0xae740010
_as_parameter 0x2e740010
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575945&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1086642 ] Compile of _socket fails on 2.4
Bugs item #1086642, was opened at 2004-12-16 12:21 Message generated for change (Comment added) made by amcnabb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&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: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: "_SS_ALIGNSIZE" redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension -- Comment By: Andrew McNabb (amcnabb) Date: 2006-10-12 09:37 Message: Logged In: YES user_id=1234027 There IS a specific report. It won't compile with gcc. Either it needs to be acknowledged that gcc doesn't work and only allow the IRIX compiler, or else it needs to be fixed. There's tons of detail in the many reports in this thread. -- Comment By: Georg Brandl (gbrandl) Date: 2006-10-12 02:44 Message: Logged In: YES user_id=849994 Is anyone going to do something about this, without a specific report? Anyway, lowering priority. -- Comment By: Andrew McNabb (amcnabb) Date: 2006-09-19 15:42 Message: Logged In: YES user_id=1234027 When I use the native IRIX cc to compile socketmodule.c in Python 2.5, I get: cc -OPT:Olimit=0 -DNDEBUG -O -I. -I/auto/fsc/awm27/bzr/Python-2.5/./Include -I/fsc/awm27/i nclude -I./Include -I. -I/usr/local/include -I/auto/fsc/awm27/bzr/Python-2.5/Include -I/au to/fsc/awm27/bzr/Python-2.5 -c /auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.c -o bu ild/temp.irix64-6.5-2.5/auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.o cc-1047 cc: WARNING File = /usr/include/sys/param.h, Line = 372 Macro "MAX" (declared at line 77 of "/auto/fsc/awm27/bzr/Python-2.5/Modules/socketmodule.c") has an incompatible redefinition. #define MAX(a,b) (((a)>(b))?(a):(b)) ^ When I commented out the macro definition in socketmodule.c, I was able to get it to compile (with the IRIX compiler). It seems to me that --without-gcc should be the default for IRIX until the gcc problem gets fixed because ./configure is currently automatically choosing gcc as the compiler when both are available. And I'm really not sure why the "#undef MAX" didn't happen. Anyway, I hope this is helpful for someone. --
[ python-Bugs-1573394 ] struct module doesn't use weakref for cache
Bugs item #1573394, was opened at 2006-10-09 01:37 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&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 Submitted By: Mark Flacy (markaflacy) Assigned to: Bob Ippolito (etrepum) Summary: struct module doesn't use weakref for cache Initial Comment: At the moment, when you attempt to add your 101st different Struct object to the cache, all the other 100 entries are tossed into the garbage. That seems a trifle odd. The Struct cache would appear to be a perfect use for a weakref dictionary. -- Comment By: �iga Seilnacht (zseil) Date: 2006-10-12 17:52 Message: Logged In: YES user_id=1326842 WeakValueDictionary would be useless here; the cache is the only thing that holds references to Struct objects. Replacing the _cache.clear() call with _cache.popitem() seems like a better solution. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1573394 ] struct module doesn't use weakref for cache
Bugs item #1573394, was opened at 2006-10-08 19:37 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&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: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Mark Flacy (markaflacy) Assigned to: Bob Ippolito (etrepum) Summary: struct module doesn't use weakref for cache Initial Comment: At the moment, when you attempt to add your 101st different Struct object to the cache, all the other 100 entries are tossed into the garbage. That seems a trifle odd. The Struct cache would appear to be a perfect use for a weakref dictionary. -- >Comment By: Bob Ippolito (etrepum) Date: 2006-10-12 12:56 Message: Logged In: YES user_id=139309 Weakrefs would slow it down.. probably to the point where the cache wouldn't be an improvement at all. The re module does the same thing with the regular expression cache. This isn't a bug until someone presents a patch that proves another strategy is better for performance. -- Comment By: �iga Seilnacht (zseil) Date: 2006-10-12 11:52 Message: Logged In: YES user_id=1326842 WeakValueDictionary would be useless here; the cache is the only thing that holds references to Struct objects. Replacing the _cache.clear() call with _cache.popitem() seems like a better solution. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1573394 ] struct module doesn't use weakref for cache
Bugs item #1573394, was opened at 2006-10-09 01:37 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&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: Closed Resolution: Wont Fix Priority: 5 Submitted By: Mark Flacy (markaflacy) Assigned to: Bob Ippolito (etrepum) Summary: struct module doesn't use weakref for cache Initial Comment: At the moment, when you attempt to add your 101st different Struct object to the cache, all the other 100 entries are tossed into the garbage. That seems a trifle odd. The Struct cache would appear to be a perfect use for a weakref dictionary. -- Comment By: �iga Seilnacht (zseil) Date: 2006-10-12 19:36 Message: Logged In: YES user_id=1326842 I was thinking abot something like this: Index: Lib/struct.py === --- Lib/struct.py (revision 52316) +++ Lib/struct.py (working copy) @@ -35,7 +35,7 @@ def _compile(fmt): # Internal: compile struct pattern if len(_cache) >= _MAXCACHE: -_cache.clear() +_cache.popitem() s = Struct(fmt) _cache[fmt] = s return s (sorry, I don't have the rights to attach a file) -- Comment By: Bob Ippolito (etrepum) Date: 2006-10-12 18:56 Message: Logged In: YES user_id=139309 Weakrefs would slow it down.. probably to the point where the cache wouldn't be an improvement at all. The re module does the same thing with the regular expression cache. This isn't a bug until someone presents a patch that proves another strategy is better for performance. -- Comment By: �iga Seilnacht (zseil) Date: 2006-10-12 17:52 Message: Logged In: YES user_id=1326842 WeakValueDictionary would be useless here; the cache is the only thing that holds references to Struct objects. Replacing the _cache.clear() call with _cache.popitem() seems like a better solution. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1573394 ] struct module doesn't use weakref for cache
Bugs item #1573394, was opened at 2006-10-08 19:37 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&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: Closed Resolution: Wont Fix Priority: 5 Submitted By: Mark Flacy (markaflacy) Assigned to: Bob Ippolito (etrepum) Summary: struct module doesn't use weakref for cache Initial Comment: At the moment, when you attempt to add your 101st different Struct object to the cache, all the other 100 entries are tossed into the garbage. That seems a trifle odd. The Struct cache would appear to be a perfect use for a weakref dictionary. -- >Comment By: Bob Ippolito (etrepum) Date: 2006-10-12 13:54 Message: Logged In: YES user_id=139309 Yes, that code is different. You haven't shown that it's better though. Using popitem probably doesn't have very good cache effects. -- Comment By: �iga Seilnacht (zseil) Date: 2006-10-12 13:36 Message: Logged In: YES user_id=1326842 I was thinking abot something like this: Index: Lib/struct.py === --- Lib/struct.py (revision 52316) +++ Lib/struct.py (working copy) @@ -35,7 +35,7 @@ def _compile(fmt): # Internal: compile struct pattern if len(_cache) >= _MAXCACHE: -_cache.clear() +_cache.popitem() s = Struct(fmt) _cache[fmt] = s return s (sorry, I don't have the rights to attach a file) -- Comment By: Bob Ippolito (etrepum) Date: 2006-10-12 12:56 Message: Logged In: YES user_id=139309 Weakrefs would slow it down.. probably to the point where the cache wouldn't be an improvement at all. The re module does the same thing with the regular expression cache. This isn't a bug until someone presents a patch that proves another strategy is better for performance. -- Comment By: �iga Seilnacht (zseil) Date: 2006-10-12 11:52 Message: Logged In: YES user_id=1326842 WeakValueDictionary would be useless here; the cache is the only thing that holds references to Struct objects. Replacing the _cache.clear() call with _cache.popitem() seems like a better solution. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1573394&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1576174 ] str(WindowsError) wrong
Bugs item #1576174, was opened at 2006-10-12 22: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=1576174&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 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: str(WindowsError) wrong Initial Comment: str(WindowsError(1001, 'a message') in Python 2.5 gives '[Error 22] a message'. The attached patch with test fixes this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1576174 ] str(WindowsError) wrong
Bugs item #1576174, was opened at 2006-10-12 22:12 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&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 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: str(WindowsError) wrong Initial Comment: str(WindowsError(1001, 'a message') in Python 2.5 gives '[Error 22] a message'. The attached patch with test fixes this. -- >Comment By: Thomas Heller (theller) Date: 2006-10-12 22:13 Message: Logged In: YES user_id=11105 See also: http://mail.python.org/pipermail/python-dev/2006-September/068869.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1576208 ] ConfigParser: whitespace leading comment lines
Bugs item #1576208, was opened at 2006-10-12 16:19
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=1576208&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: gregwillden (gregwillden)
Assigned to: Nobody/Anonymous (nobody)
Summary: ConfigParser: whitespace leading comment lines
Initial Comment:
I'd like to propose the following change to
ConfigParser.py.
This change will enable multiline comments as follows:
[section]
item=value ;first of multiline comment
;second of multiline comment
Right now the behaviour is
In [19]: cfg.get('section','item')
Out[19]: 'value\n;second of multiline comment'
It's a one-line change.
RawConfigParser._read lines 434-437
# comment or blank line?
-if line.strip() == '' or line[0] in '#;':
+if line.strip() == '' or line.strip()[0]
in '#;':
continue
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576208&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1576174 ] str(WindowsError) wrong
Bugs item #1576174, was opened at 2006-10-12 22:12 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&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 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: str(WindowsError) wrong Initial Comment: str(WindowsError(1001, 'a message') in Python 2.5 gives '[Error 22] a message'. The attached patch with test fixes this. -- Comment By: �iga Seilnacht (zseil) Date: 2006-10-12 23:53 Message: Logged In: YES user_id=1326842 The part of the patch that changes EnvironmentError_str should be removed (EnvironmentError doesn't have a winerror member, the change causes compilation errors). Otherwise the patch looks fine. -- Comment By: Thomas Heller (theller) Date: 2006-10-12 22:13 Message: Logged In: YES user_id=11105 See also: http://mail.python.org/pipermail/python-dev/2006-September/068869.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576174&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1576241 ] functools.wraps fails on builtins
Bugs item #1576241, was opened at 2006-10-12 22:24 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=1576241&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.5 Status: Open Resolution: None Priority: 5 Submitted By: kajiuma (kajiuma) Assigned to: Nobody/Anonymous (nobody) Summary: functools.wraps fails on builtins Initial Comment: functools.wraps assumes that the wrapped function has a __dict__ attribute, which is not true for builtins. The attached patch provides an empty dictionaries for functions that do not have the required attributes. This will cause programs expecting an AttributeError (if there are any) to fail. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576241&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1576241 ] functools.wraps fails on builtins
Bugs item #1576241, was opened at 2006-10-12 22:24
Message generated for change (Comment added) made by kajiuma
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576241&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: kajiuma (kajiuma)
Assigned to: Nobody/Anonymous (nobody)
Summary: functools.wraps fails on builtins
Initial Comment:
functools.wraps assumes that the wrapped function
has a __dict__ attribute, which is not true for
builtins.
The attached patch provides an empty dictionaries
for functions that do not have the required
attributes. This will cause programs expecting an
AttributeError (if there are any) to fail.
--
>Comment By: kajiuma (kajiuma)
Date: 2006-10-12 22:33
Message:
Logged In: YES
user_id=1619773
Looks like lynx cannot send files.
The patch changed: getattr(wrapped, attr)
to: getattr(wrapped, attr, {})
At then end of line 35 of Lib/functools.py
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576241&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1576348 ] Example typo in section 4 of 'Installing Python Modules'
Bugs item #1576348, was opened at 2006-10-13 02:36 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=1576348&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: ytrewq1 (ytrewq1) Assigned to: Nobody/Anonymous (nobody) Summary: Example typo in section 4 of 'Installing Python Modules' Initial Comment: On 2006-10-13, in the docs.python.org version of '4 Custom Installation' of 'Installing Python Modules' ( http://docs.python.org/inst/search-path.html) I see: python setup.py --install-base=/tmp It seems to me that that may be missing the mention of a command -- presumably 'install'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576348&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1544339 ] _ctypes fails to build on Solaris x86 32-bit (Sun compiler)
Bugs item #1544339, was opened at 2006-08-21 21:28 Message generated for change (Comment added) made by casevh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544339&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) Assigned to: Thomas Heller (theller) Summary: _ctypes fails to build on Solaris x86 32-bit (Sun compiler) Initial Comment: The _ctypes modules fails to compile on Solaris 10 x86 32-bit using the Sun Studio 11 compiler. _ctypes does compile successfully using gcc. The error messages are attached. If needed, I can provide access to the machine. -- >Comment By: Case Van Horsen (casevh) Date: 2006-10-12 19:57 Message: Logged In: YES user_id=1212585 I have tracked down two issues. First Sun's cc compiler does defines __386 instead of __386__. This causes problems in ffitarget.h Second, Sun's cc compiler fails on the following line in ffi.h: } ffi_closure __attribute__((aligned (8))); This is a problem in Sun's cc compiler. It is fixed in the Sun Studio Express August 2006 release. I don't think there is a patch for the "official" Sun Studio 11 compiler. With these two changes, ctypes does compile but "make test" still fails. I am still researching the "make test" failure. test_crypt test_csv test_ctypes sh: objdump: not found *** Signal 11 - core dumped make: Fatal error: Command failed for target `test' bash-3.00$ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544339&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1576394 ] enable-shared .dso location
Bugs item #1576394, was opened at 2006-10-12 22: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=1576394&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.5 Status: Open Resolution: None Priority: 5 Submitted By: Mike Klaas (mklaas) Assigned to: Nobody/Anonymous (nobody) Summary: enable-shared .dso location Initial Comment: When building on AMD64/FC5 with --enable-shared, libpython.so is placed in /usr/lib. Unfortunately, /usr/lib is not in the shared object search path by default--/usr/lib64 is used. I believe that this is a fairly standard linux configuration for 64bit machines. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576394&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
