[ python-Bugs-1556895 ] typo in encoding name in email package
Bugs item #1556895, was opened at 2006-09-12 09:33 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=1556895&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guillaume Rousse (guillomovitch) Assigned to: Nobody/Anonymous (nobody) Summary: typo in encoding name in email package Initial Comment: gb2132 should be gb2312... Here is a patch against email-2.5.8 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556895&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1557037 ] datetime's strftime limits strings to 127 chars
Bugs item #1557037, was opened at 2006-09-12 06:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557037&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: Eric V. Smith (ericvsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime's strftime limits strings to 127 chars
Initial Comment:
[I'm putting this in category Python Library, because I
assume Extensions Modules is for problems in the
Extensions Module plumbing.]
datetime.date and datetime.time's strftime() methods
call wrap_strftime(), which limits the length of the
format string to 127 chars before calling time.strftime().
This can be seen in the examples below. Note that in
the third example, time.strftime() does not have a
problem with a 128 character format string.
>>> import datetime
>>> datetime.date.today().strftime('x'*128)
Traceback (most recent call last):
File "", line 1, in
MemoryError
>>> import datetime
>>> datetime.date.today().strftime('x'*256)
Traceback (most recent call last):
File "", line 1, in
SystemError: Objects/stringobject.c:4077: bad argument
to internal function
>>> import time
>>> time.strftime('x'*128)
''
Reproduced on 2.5c1 Linux, 2.4.3 Linux, and 2.3.3 Windows.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557037&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1557037 ] datetime's strftime limits strings to 127 chars
Bugs item #1557037, was opened at 2006-09-12 06:56
Message generated for change (Settings changed) made by ericvsmith
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557037&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: Duplicate
Priority: 5
Submitted By: Eric V. Smith (ericvsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime's strftime limits strings to 127 chars
Initial Comment:
[I'm putting this in category Python Library, because I
assume Extensions Modules is for problems in the
Extensions Module plumbing.]
datetime.date and datetime.time's strftime() methods
call wrap_strftime(), which limits the length of the
format string to 127 chars before calling time.strftime().
This can be seen in the examples below. Note that in
the third example, time.strftime() does not have a
problem with a 128 character format string.
>>> import datetime
>>> datetime.date.today().strftime('x'*128)
Traceback (most recent call last):
File "", line 1, in
MemoryError
>>> import datetime
>>> datetime.date.today().strftime('x'*256)
Traceback (most recent call last):
File "", line 1, in
SystemError: Objects/stringobject.c:4077: bad argument
to internal function
>>> import time
>>> time.strftime('x'*128)
''
Reproduced on 2.5c1 Linux, 2.4.3 Linux, and 2.3.3 Windows.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557037&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1557232 ] Parser crash
Bugs item #1557232, was opened at 2006-09-12 17:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&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: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Parser crash Initial Comment: The code def x(((y))):pass crashes the compiler (?) in 2.5c2, on Windows. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1557232 ] Parser crash
Bugs item #1557232, was opened at 2006-09-12 17:28 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&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: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Parser crash Initial Comment: The code def x(((y))):pass crashes the compiler (?) in 2.5c2, on Windows. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1556895 ] typo in encoding name in email package
Bugs item #1556895, was opened at 2006-09-12 03:33 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556895&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guillaume Rousse (guillomovitch) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: typo in encoding name in email package Initial Comment: gb2132 should be gb2312... Here is a patch against email-2.5.8 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556895&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1337400 ] Python.h should include system headers properly [POSIX]
Bugs item #1337400, was opened at 2005-10-25 07:38 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: Python.h should include system headers properly [POSIX] Initial Comment: In Python 2.4.2, Python.h looks like this: #include [...] #include [...] #include #include #include #ifdef HAVE_UNISTD_H #include #endif On POSIX platforms should be included first! Indeed it includes headers such as on Solaris, on Irix, or on GNU systems, which define macros that specify the system interfaces to use, possibly depending on compiler options, which in turn may enable/disable/modify parts of other system headers such as or . By including , you ensure consistent systems interfaces are specified in all system headers included by Python sources. This may seem rather academic, but it actually breaks my Solaris builds: I need to compile Python using Sun's C compiler when building Python for performance and GNU's C++ compiler when building Python modules written in C++ for compatibility with C++ libraries used by these modules that can't be compiled with Sun's C++ compiler. So the same Python.h is used by Sun's C compiler (which it was created for in the first place) and GNU's C++ compiler. GNU's C++ compiler fails to compile some modules. Unfortunately I can't recall the exact modules and error messages right now, but including fixes the problem. -- >Comment By: Skip Montanaro (montanaro) Date: 2006-09-12 15:01 Message: Logged In: YES user_id=44345 I'm coming late to this party (it seems the bar is closed), however... At work we just stumbled upon a similar problem when trying to build the latest release of matplotlib (0.87.5, avaialble at http://matplotlib.sourceforge.net/) on Solaris 10 using gcc 3.4.1. We get errors like the following: In file included from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/bits/postypes.h:46, from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/iosfwd:50, from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/ios:44, from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/ostream:45, from /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/iostream:45, from swig/agg_buffer.h:7, from src/agg.cxx:1584: /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/cwchar:145: error: `::btowc' has not been declared /opt/app/g++lib6/gcc-3.4/lib/gcc/i386-pc-solaris2.10/3.4.1/../../../../include/c++/3.4.1/cwchar:150: error: `::fwide' has not been declared If I add #include at the top of Python.h it builds fine (modulo a couple warnings). One warning which might be significant is: In file included from /opt/app/g++lib6/python-2.4/include/python2.4/Python.h:10, from src/agg.cxx:97: /opt/app/g++lib6/python-2.4/include/python2.4/pyconfig.h:835:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/wchar.h:11, from /opt/app/g++lib6/python-2.4/include/python2.4/Python.h:7, from src/agg.cxx:97: /usr/include/sys/feature_tests.h:266:1: warning: this is the location of the previous definition I don't have enough gcc smarts to understand what's happening, or even if it's the same problem Dimitri encountered on Solaris 8, but it kind of looks like the same sort of problem to me. Skip -- Comment By: Martin v. Löwis (loewis) Date: 2005-11-03 15:34 Message: Logged In: YES user_id=21627 Thanks for the update. I believe nothing in the POSIX spec mandates to include unistd.h before anything else (unlike sys/types.h, which often is prerequisite to other headers), so I'm closing this report. -- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-11-03 04:56 Message: Logged In: YES user_id=52414 Aaargh! I've rebuilt a version of Python 2.4.2 with Sun's C compiler and GNU's C++ compiler but I'm unable to reproduce the problem: $ cat > foo.cpp #include #include $
[ python-Bugs-1557490 ] 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc
Bugs item #1557490, was opened at 2006-09-12 17: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=1557490&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: Tony Bigbee (tony_bigbee) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc Initial Comment: Building with gcc 4.1.1 SunOS 5.9 sun4u sparc SUNW,Sun-Fire-V490 LDFLAGS=-mcpu=v9 -m64 LDDFLAGS=-mcpu=v9 -m64 -G CC=gcc -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1 ./configure --prefix=/projects/python make (many successful .c files omittted) gcc -mcpu Parser/pgenmain.o -lresolv -lsocket -lnsl -lrt -ldl -o Parser/pgen Parser/pgen ./Grammar/grammar ./Include/graminit.h ./Python/graminit.c *** Signal 11 -core dumped (ignored) compiling and linking continues until the new python executable is invoked to run setup.py and that fails. I previously built 2.5c1 without all the compile/link flags above as a vanilla 32-bit app without a problem. LD_LIBRARY=/usr/ccs/lib/:/usr/lib:/usr/local/lib the python executable will not start with any command line option. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557490&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1556784 ] datetime's strftime limits strings to 127 chars
Bugs item #1556784, was opened at 2006-09-11 22:43
Message generated for change (Comment added) made by ericvsmith
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556784&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: Eric V. Smith (ericvsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: datetime's strftime limits strings to 127 chars
Initial Comment:
[I'm putting this in category Python Library, because I
assume Extensions Modules is for problems in the
Extensions Module plumbing.]
datetime.date and datetime.time's strftime() methods
call wrap_strftime(), which limits the length of the
format string to 127 chars before calling time.strftime().
This can be seen in the examples below. Note that in
the third example, time.strftime() does not have a
problem with a 128 character format string.
>>> import datetime
>>> datetime.date.today().strftime('x'*128)
Traceback (most recent call last):
File "", line 1, in
MemoryError
>>> import datetime
>>> datetime.date.today().strftime('x'*256)
Traceback (most recent call last):
File "", line 1, in
SystemError: Objects/stringobject.c:4077: bad argument
to internal function
>>> import time
>>> time.strftime('x'*128)
''
Reproduced on 2.5c1 Linux, 2.4.3 Linux, and 2.3.3 Windows.
--
>Comment By: Eric V. Smith (ericvsmith)
Date: 2006-09-12 18:12
Message:
Logged In: YES
user_id=411198
See patch http://python.org/sf/1557390
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1556784&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1557490 ] 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc
Bugs item #1557490, was opened at 2006-09-12 14:36 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557490&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: Tony Bigbee (tony_bigbee) Assigned to: Nobody/Anonymous (nobody) Summary: 2.5c1 Core dump during 64-bit make on Solaris 9 Sparc Initial Comment: Building with gcc 4.1.1 SunOS 5.9 sun4u sparc SUNW,Sun-Fire-V490 LDFLAGS=-mcpu=v9 -m64 LDDFLAGS=-mcpu=v9 -m64 -G CC=gcc -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1 ./configure --prefix=/projects/python make (many successful .c files omittted) gcc -mcpu Parser/pgenmain.o -lresolv -lsocket -lnsl -lrt -ldl -o Parser/pgen Parser/pgen ./Grammar/grammar ./Include/graminit.h ./Python/graminit.c *** Signal 11 -core dumped (ignored) compiling and linking continues until the new python executable is invoked to run setup.py and that fails. I previously built 2.5c1 without all the compile/link flags above as a vanilla 32-bit app without a problem. LD_LIBRARY=/usr/ccs/lib/:/usr/lib:/usr/local/lib the python executable will not start with any command line option. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 22:47 Message: Logged In: YES user_id=33168 I was able to build with gcc 4.0.2 on Solaris sun4u system with the same flags as above. ./python: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped However, it couldn't build the extension modules because: ld.so.1: python: fatal: libgcc_s.so.1: open failed: No such file or directory That's a different problem though. The interpreter itself is just fine. You might want to try lowering the optimization level to -O1 or -O0 and see if you have the same problem. Or you could try building with a different C compiler. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557490&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1557232 ] Parser crash
Bugs item #1557232, was opened at 2006-09-12 08:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&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: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Parser crash Initial Comment: The code def x(((y))):pass crashes the compiler (?) in 2.5c2, on Windows. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 22:50 Message: Logged In: YES user_id=33168 The problem is in Python/ast.c around line 666. See the comment: /* def foo((x)): setup for checking NAME below. */ The code is not sufficient, we need a loop and need to handle various combinations of: def f(x))),)),))): pass I don't know if the parens above match, but the general idea is that there could be a bunch of parens and commas at various places. I'm not sure how the above should be interpreted. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1557232 ] Parser crash
Bugs item #1557232, was opened at 2006-09-12 08:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&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: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Parser crash Initial Comment: The code def x(((y))):pass crashes the compiler (?) in 2.5c2, on Windows. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 23:00 Message: Logged In: YES user_id=33168 I guess what 2.4 does is the most reasonable behavior: >>> def f((x)),),),)): pass >>> dis.dis(f) 1 0 LOAD_FAST0 (.0) 3 UNPACK_SEQUENCE 1 6 UNPACK_SEQUENCE 1 9 UNPACK_SEQUENCE 1 12 STORE_FAST 1 (x) 15 LOAD_CONST 0 (None) 18 RETURN_VALUE -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 22:50 Message: Logged In: YES user_id=33168 The problem is in Python/ast.c around line 666. See the comment: /* def foo((x)): setup for checking NAME below. */ The code is not sufficient, we need a loop and need to handle various combinations of: def f(x))),)),))): pass I don't know if the parens above match, but the general idea is that there could be a bunch of parens and commas at various places. I'm not sure how the above should be interpreted. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1557232 ] Parser crash
Bugs item #1557232, was opened at 2006-09-12 08:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&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: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Parser crash Initial Comment: The code def x(((y))):pass crashes the compiler (?) in 2.5c2, on Windows. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 23:22 Message: Logged In: YES user_id=33168 The attached patch seems to fix the x problem. I didn't run in debug mode, so I'm not positive the assert works as I expect. However now my test case below doesn't work, it puts in 5 UNPACK_SEQUENCES rather than 3. This looks like a different problem in compiler_complex_args(). Not sure how much farther I'll get tonight. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 23:00 Message: Logged In: YES user_id=33168 I guess what 2.4 does is the most reasonable behavior: >>> def f((x)),),),)): pass >>> dis.dis(f) 1 0 LOAD_FAST0 (.0) 3 UNPACK_SEQUENCE 1 6 UNPACK_SEQUENCE 1 9 UNPACK_SEQUENCE 1 12 STORE_FAST 1 (x) 15 LOAD_CONST 0 (None) 18 RETURN_VALUE -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-12 22:50 Message: Logged In: YES user_id=33168 The problem is in Python/ast.c around line 666. See the comment: /* def foo((x)): setup for checking NAME below. */ The code is not sufficient, we need a loop and need to handle various combinations of: def f(x))),)),))): pass I don't know if the parens above match, but the general idea is that there could be a bunch of parens and commas at various places. I'm not sure how the above should be interpreted. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1557232&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
