[ python-Bugs-1494314 ] Cannot use high-numbered sockets in 2.4.3
Bugs item #1494314, was opened at 2006-05-24 15:51 Message generated for change (Comment added) made by mlrsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1494314&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: Michael Smith (mlrsmith) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot use high-numbered sockets in 2.4.3 Initial Comment: Python 2.4.3 introduced (in Modules/socketmodule.c) the IS_SELECTABLE() macro, to check whether calling select() on a given file descriptor is permissible. However, it executes this check even when it won't actually call select(). Specifically, select() is called ONLY when s->sock_timeout > 0 (in internal_select mostly, but also internal_connect). I have a twisted application which uses many FDs (several thousand), and upgrading python to 2.4.3 makes it hit this limit (at 1024 file descriptors), regardless of ulimit settings. Twisted itself always uses non-blocking I/O on sockets, so with older versions of python this worked fine. A simple solution relies on the fact that select is only ever actually called, and changes the IS_SELECTABLE macro as in the attached fairly trivial patch. This is sufficient to restore my application to its previous state (where it works fine). This doesn't solve the more general problem in socketmodule - that we simply can't do all operations properly with the current reliance on select(), though, and it seems like a bit of a hack... If I wrote up a patch to use poll() on systems where it's available, throughout socketmodule.c, in preference to select(), would this be accepted? Mike -- >Comment By: Michael Smith (mlrsmith) Date: 2006-06-09 12:31 Message: Logged In: YES user_id=1488997 Ok, I'll attach a patch that uses poll when available (HAVE_POLL is already being set by the configure stuff appropriately). It replaces one of the two uses of select() (specifically, the internal_select() function) in socketmodule.c. The other is win32-specific, so replacing it with poll() wouldn't make sense. greg: epoll/kevent don't make sense for replacing the use of select/poll in this particular case - socketmodule.c always selects/polls precisely one file descriptor. I've tested this locally, and it fixes the problem (linux/x86). I don't have a windows system to test it on, but it shouldn't change behaviour in any way for windows. -- Comment By: Gregory P. Smith (greg) Date: 2006-06-08 07:51 Message: Logged In: YES user_id=413 eew yuck. yes use poll at the very least. we should also consider using epoll (linux) and kevent (bsd) in the future as both of those scale better than O(n) unlike select and poll. -- Comment By: Martin v. Löwis (loewis) Date: 2006-06-04 22:14 Message: Logged In: YES user_id=21627 A patch to replace internal_select with poll(2) where available is acceptable. The current version should be conditionally kept. That Windows doesn't have poll(2) is no problem: its select implementation supports arbitrarily large FDs (just like poll). Relaxing the IS_SELECTABLE usage to cases where select is actually going to be called is optional: there shouldn't be too many systems left without select where people still want to open many file descriptors. -- Comment By: Tim Peters (tim_one) Date: 2006-06-01 00:27 Message: Logged In: YES user_id=31435 akuchling: No, poll() is not part of the Windows socket API. -- Comment By: Michael Smith (mlrsmith) Date: 2006-05-31 23:39 Message: Logged In: YES user_id=1488997 That, of course, is the problem - select() is available more or less universally, but poll() is not. However, it's not terribly difficult to write a poll() wrapper using select(), though doing so in general would have serious performance issues (the specific uses in socketmodule.c do not hit this problem), and retains the limitations of select. It's not clear that the complexity of doing this is worthwhile compared to just implementing the simple API needed internally to socketmodule.c using both APIs (i.e. just adding a poll() option). Regardless, it'd be nice if at least the basic fix I wrote up went in - it solves the immediate problem, at least. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-05-31 20:39 Message: Logged In: YES user_id=11375 I expect such a patch would be acceptable. The largest issue is prob
[ python-Bugs-1503502 ] Pdb doesn't call flush on its stdout file descriptor
Bugs item #1503502, was opened at 2006-06-09 12:57 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=1503502&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: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Pdb doesn't call flush on its stdout file descriptor Initial Comment: When redirecting Pdb's stdout file object, the commands that use this to write output don't call flush() on the object. This leads to problem when setting the stdout file object to a fileobject created from a socket with the makefile() method. My proposed solution to this problem is for the Pdb class to contain a method for writing to fileobjects which can be overridden by programmers if they wish to write to sockets or other streams that require flush()ing. I can work on this patch if people thinks its a good idea. Thanks, Matt -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503502&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472827 ] xml.sax.saxutils.XMLGenerator mangles \r\n\t in attributes
Bugs item #1472827, was opened at 2006-04-19 04:29
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472827&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: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mikhail Gusarov (gusarov)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax.saxutils.XMLGenerator mangles \r\n\t in attributes
Initial Comment:
xml.sax.saxutils.XMLGenerator does not escape \r, \n,
\t symbols when they are present in the attribute:
startElement("name", {"attrib": "value\nvalue"}) will
result in
which will be normalized by XML parser to
According to the XML specs, to preserve this symbols in
the attribute values, they should be replaced with \xD;
\xA; \x9;
Trivial fix is to replace those characters in
xml.sax.saxutils.writeattr
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-09 09:16
Message:
Logged In: YES
user_id=11375
Fixed in trunk in rev. 46773; thanks for reporting this!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472827&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1472827 ] xml.sax.saxutils.XMLGenerator mangles \r\n\t in attributes
Bugs item #1472827, was opened at 2006-04-19 04:29
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472827&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: XML
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mikhail Gusarov (gusarov)
>Assigned to: A.M. Kuchling (akuchling)
Summary: xml.sax.saxutils.XMLGenerator mangles \r\n\t in attributes
Initial Comment:
xml.sax.saxutils.XMLGenerator does not escape \r, \n,
\t symbols when they are present in the attribute:
startElement("name", {"attrib": "value\nvalue"}) will
result in
which will be normalized by XML parser to
According to the XML specs, to preserve this symbols in
the attribute values, they should be replaced with \xD;
\xA; \x9;
Trivial fix is to replace those characters in
xml.sax.saxutils.writeattr
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-09 10:00
Message:
Logged In: YES
user_id=11375
Fixed on release24-maint in rev. 46777.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-09 09:16
Message:
Logged In: YES
user_id=11375
Fixed in trunk in rev. 46773; thanks for reporting this!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472827&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503294 ] 'make install' fails on OS X 10.4 when running compileall
Bugs item #1503294, was opened at 2006-06-08 20:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&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: 7 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: 'make install' fails on OS X 10.4 when running compileall Initial Comment: PYTHONPATH=/Users/drifty/Code/Compiled/lib/python2.5 \ ./python.exe -Wi -tt /Users/drifty/Code/Compiled/lib/python2.5/compileall.py \ -d /Users/drifty/Code/Compiled/lib/python2.5 -f \ -x 'bad_coding|badsyntax|site-packages' /Users/drifty/Code/Compiled/lib/python2.5 Fatal Python error: PyThreadState_Get: no current thread make: *** [libinstall] Abort trap Works if I remove ``-Wi -tt`` from the command. -- >Comment By: Brett Cannon (bcannon) Date: 2006-06-09 09:59 Message: Logged In: YES user_id=357491 Forgot to try this with just one of the two flags; will do that soon. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1496501 ] tarfile.py: dict order dependency
Bugs item #1496501, was opened at 2006-05-28 14:42
Message generated for change (Comment added) made by jackdied
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&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: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.py: dict order dependency
Initial Comment:
When guessing the type of a file, tarfile.py tries to
open it in .tar, .tar.gz and .tar.bz2 modes
successfully. The problem is that in conjunction with a
fileobj argument, failed attempts can advance the
current position of the fileobj, and cause the following
attempts to fail as well.
This didn't show up so far because, by chance, the order
in which the OPEN_METH dictionary is enumerated is
somehow the "correct" one. The problem can be seen by
changing this order and re-running test_tarfile.py; for
example, reverse the order (tarfile.py line 1013):
for comptype in reversed(cls.OPEN_METH):
--
Comment By: Jack Diederich (jackdied)
Date: 2006-06-09 15:56
Message:
Logged In: YES
user_id=591932
I took a look at tarfile.py and though there is this comment
about OPEN_METH
# This concept allows one to subclass TarFile without losing
the comfort of
# the super-constructor. A sub-constructor is registered and
made available
# by adding it to the mapping in OPEN_METH.
because adding items to OPEN_METH could change the order and
break the Tarfile.open() classmethod I doubt adding to
OPEN_METH is done in practice.
+1 for renaming OPEN_METH to _OPEN_METH and making it a list
of two-tuples.
+0 on changing the two tups from ('typename', 'funcname') to
('typename', function_ref) and dropping the getattr
functionality. The three default openers are not listed in
the public interface so if anyone is subclassing Tarfile and
overriding them (doubtful) they are doing so at their own peril.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1496501&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-1491485 ] str.startswith/endswith could take a tuple?
Feature Requests item #1491485, was opened at 2006-05-19 10:24
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&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: Accepted
Priority: 5
Submitted By: Tom Lynn (tlynn)
Assigned to: Georg Brandl (gbrandl)
Summary: str.startswith/endswith could take a tuple?
Initial Comment:
In the same way that exceptions can have a tuple of
types specified and isinstance can take a tuple of
types, str.startswith and endswith could take a tuple
of possible prefixes/suffixes.
One use-case::
if filename.endswith(('jpg', 'gif', 'png')):
# ...
vs:
if (filename.endswith('jpg') or filename.endswith
('gif') or
filename.endswith('png')):
#...
Obviously it's not a huge improvement in clarity, but
it does seem to be an improvement to me.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-09 20:23
Message:
Logged In: YES
user_id=849994
Committed implementation in rev. 46795.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-06-07 21:11
Message:
Logged In: YES
user_id=849994
I will, tomorrow.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-06-06 00:30
Message:
Logged In: YES
user_id=80475
Georg, would you like to implement this one?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-06-05 16:33
Message:
Logged In: YES
user_id=80475
The previous comment was just information. I am +1 on the
proposal because the use case is so common and the proposed
form is concise, clear, and natural.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-05-19 20:58
Message:
Logged In: YES
user_id=80475
FWIW, in Py2.5, this would be written:
if any(filename.startswith(s) for s in suffixes):
. . .
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1491485&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-532646 ] Recursive class instance "error"
Bugs item #532646, was opened at 2002-03-20 10:56 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gregor Mirai (gregmi) Assigned to: Brett Cannon (bcannon) Summary: Recursive class instance "error" Initial Comment: If one writes the following code (tested on Python 2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 98, NT, 2000) one can easily produce several "errors". MacOS X, MacOS X Server (Python 2.1, 2.2) -- class A: def __getattr__(self, name): print name, return A() -- >>> a=A() >>> a.foo Segmentation fault Win98, NT, 2000 (Python 2.1, 2.2) -- class A: def __getattr__(self, name): print name return A() -- >>> a=A() >>> a.foo foo __repr__ __call__ __call__ __call__ ... ad inf -- >Comment By: Brett Cannon (bcannon) Date: 2006-06-09 15:39 Message: Logged In: YES user_id=357491 Rev. 46806 for 2.5 and rev. 46807 for 2.4 have the fix for new-style classes. -- Comment By: Brett Cannon (bcannon) Date: 2006-04-18 12:08 Message: Logged In: YES user_id=357491 The test is already in crashers: infinite_rec_3 . And it is the same crash as in py3k; that's how I found it. -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-04-18 01:09 Message: Logged In: YES user_id=6380 Ironically, I just found the same (?) crash in the p3yk branch, in test_class.py (which is now testing new-style classes for compatibility with the behavior of classic classes). I can't fix this myself, so assigning to Brett. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-17 21:37 Message: Logged In: YES user_id=33168 Please add a test case to Lib/test/crashers. -- Comment By: Brett Cannon (bcannon) Date: 2006-04-17 17:00 Message: Logged In: YES user_id=357491 This was not fixed for new-style classes and still segfaults the interpreter at least back to 2.4. Reopening. -- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-13 14:50 Message: Logged In: YES user_id=6380 It was very specific to __call__ after all, and I found an example that didn't involve __getattr__. See the comments I checked in as part of the fix in classobject.c. -- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-13 13:41 Message: Logged In: YES user_id=6380 Hm. I'm tracing this in the debugger now, and it appears that the problem is when trying to *print* an A instance. The statement a.foo causes the problem simply because it returns an A instance. (Proof: "a=A().foo; print a" fails in the print.) I think that instance_call may not be the real cause of the problem... -- Comment By: Neal Norwitz (nnorwitz) Date: 2002-06-12 15:38 Message: Logged In: YES user_id=33168 The problem is that there is mutual recursion between instance_call() and PyObject_Call(). The recursion apparently goes through the eval_frame() loop. This patch increases the recursion depth so the mutual recursion will eventually end (otherwise, the stack grows without bounds). ISTM the first check SHOULD be reached, but it is not. I don't understand why. The recursion error must be set in eval_frame(). The first block in the patch could be just this line: ++tstate->recursion_depth; I didn't do it that way, since I didn't expect returning to eval_frame(). I'm not sure if it's guaranteed to return to eval_frame() which is why I left the first condition in with the comment. I suppose the comment should say something like: /* this condition doesn't seem to be triggered, the recursion depth limit is exceeded in eval_frame */ The test for recursion_depth is necessary to ensure that the recursion error isn't overwritten. If this check is removed, the follow exception is raised: AttributeError: A instance has no __call__ method Hopefully this makes sense. -- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-10 09:08 Message: Logged In: YE
[ python-Bugs-1503765 ] logger.config problems with comma separated lists
Bugs item #1503765, was opened at 2006-06-09 23:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503765&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: cuppatea (cuppatea) Assigned to: Nobody/Anonymous (nobody) Summary: logger.config problems with comma separated lists Initial Comment: Hello, I have noticed a problem when trying to use the config files. If my config file contains a comma separated list, eg: [logger_root] level=DEBUG handlers= h1, h2 Then the logger throws up an error when reading in the config file as the space is included as part of the handler name. I've included a fix for this in the attached config.py file. Please feel free to use it. Hope this helps, adil -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503765&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503780 ] stdin directory causes crash (SIGSEGV)
Bugs item #1503780, was opened at 2006-06-09 17:03 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=1503780&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ben Liblit (liblit) Assigned to: Nobody/Anonymous (nobody) Summary: stdin directory causes crash (SIGSEGV) Initial Comment: If standard input is redirected from a directory instead of a regular file, Python crashes quite early during startup, before running a single line of the user's script. I admit that redirecting from a directory is a weird thing to do, but even so, Python should respond with something more useful than a segmentation fault. In my particular case, the ideal behavior would be to not complain at all unless the Python script actually attempts to read from stdin. How to reproduce the problem: % touch empty.py % python -V Python 2.4.1 % python -d -v empty.py % python -d -v empty.py https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503780&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503780 ] stdin from directory causes crash (SIGSEGV)
Bugs item #1503780, was opened at 2006-06-09 17:03 Message generated for change (Settings changed) made by liblit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503780&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ben Liblit (liblit) Assigned to: Nobody/Anonymous (nobody) >Summary: stdin from directory causes crash (SIGSEGV) Initial Comment: If standard input is redirected from a directory instead of a regular file, Python crashes quite early during startup, before running a single line of the user's script. I admit that redirecting from a directory is a weird thing to do, but even so, Python should respond with something more useful than a segmentation fault. In my particular case, the ideal behavior would be to not complain at all unless the Python script actually attempts to read from stdin. How to reproduce the problem: % touch empty.py % python -V Python 2.4.1 % python -d -v empty.py % python -d -v empty.py https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503780&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503789 ] Cannot write source code in UTF16
Bugs item #1503789, was opened at 2006-06-09 17:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot write source code in UTF16 Initial Comment: I intend to create some source code in UTF16. I start the file with the encoding declaration line: -- # -*- coding: UTF-16LE -*- print "Hello world" -- Unfortunately Python does not decode it in UTF16 as expected. I have found some language in PEP 0263 that says "It does not include encodings which use two or more bytes for all characters like e.g. UTF-16." While I am disappointed. I accepted this limitation is necessary to make keep the parser simple. So my first complaint is this fact should be documented in http://www.python.org/doc/ref/encodings.html Then I tried to save the source code with BOM. I think there should be no excuse not to decode it in UTF16 in that case. Unfortunately Python does not support this either. Indeed the only way to get it work is to write the encoding declaration line in ASCII and the rest of the file in UTF16 (see u16_hybrid.py). Obviously most text editor would not support this. I come up with this because Microsoft adopt UTF16 in various places. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503789 ] Cannot write source code in UTF16
Bugs item #1503789, was opened at 2006-06-09 17:38 Message generated for change (Comment added) made by tungwaiyip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Wai Yip Tung (tungwaiyip) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot write source code in UTF16 Initial Comment: I intend to create some source code in UTF16. I start the file with the encoding declaration line: -- # -*- coding: UTF-16LE -*- print "Hello world" -- Unfortunately Python does not decode it in UTF16 as expected. I have found some language in PEP 0263 that says "It does not include encodings which use two or more bytes for all characters like e.g. UTF-16." While I am disappointed. I accepted this limitation is necessary to make keep the parser simple. So my first complaint is this fact should be documented in http://www.python.org/doc/ref/encodings.html Then I tried to save the source code with BOM. I think there should be no excuse not to decode it in UTF16 in that case. Unfortunately Python does not support this either. Indeed the only way to get it work is to write the encoding declaration line in ASCII and the rest of the file in UTF16 (see u16_hybrid.py). Obviously most text editor would not support this. I come up with this because Microsoft adopt UTF16 in various places. -- >Comment By: Wai Yip Tung (tungwaiyip) Date: 2006-06-09 17:39 Message: Logged In: YES user_id=561546 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503789&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503294 ] 'make install' fails on OS X 10.4 when running compileall
Bugs item #1503294, was opened at 2006-06-08 20:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&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: 8 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: 'make install' fails on OS X 10.4 when running compileall Initial Comment: PYTHONPATH=/Users/drifty/Code/Compiled/lib/python2.5 \ ./python.exe -Wi -tt /Users/drifty/Code/Compiled/lib/python2.5/compileall.py \ -d /Users/drifty/Code/Compiled/lib/python2.5 -f \ -x 'bad_coding|badsyntax|site-packages' /Users/drifty/Code/Compiled/lib/python2.5 Fatal Python error: PyThreadState_Get: no current thread make: *** [libinstall] Abort trap Works if I remove ``-Wi -tt`` from the command. -- >Comment By: Brett Cannon (bcannon) Date: 2006-06-09 18:42 Message: Logged In: YES user_id=357491 OK, so -Wi is causing the failure. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-09 09:59 Message: Logged In: YES user_id=357491 Forgot to try this with just one of the two flags; will do that soon. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503294 ] -Wi causes a fatal Python error on OS X
Bugs item #1503294, was opened at 2006-06-08 20:20 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&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: Open Resolution: None Priority: 8 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) >Summary: -Wi causes a fatal Python error on OS X Initial Comment: PYTHONPATH=/Users/drifty/Code/Compiled/lib/python2.5 \ ./python.exe -Wi -tt /Users/drifty/Code/Compiled/lib/python2.5/compileall.py \ -d /Users/drifty/Code/Compiled/lib/python2.5 -f \ -x 'bad_coding|badsyntax|site-packages' /Users/drifty/Code/Compiled/lib/python2.5 Fatal Python error: PyThreadState_Get: no current thread make: *** [libinstall] Abort trap Works if I remove ``-Wi -tt`` from the command. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-09 18:42 Message: Logged In: YES user_id=357491 OK, so -Wi is causing the failure. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-09 09:59 Message: Logged In: YES user_id=357491 Forgot to try this with just one of the two flags; will do that soon. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503294 ] -Wi causes a fatal Python error
Bugs item #1503294, was opened at 2006-06-08 23:20 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&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: Open Resolution: None Priority: 8 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) >Summary: -Wi causes a fatal Python error Initial Comment: PYTHONPATH=/Users/drifty/Code/Compiled/lib/python2.5 \ ./python.exe -Wi -tt /Users/drifty/Code/Compiled/lib/python2.5/compileall.py \ -d /Users/drifty/Code/Compiled/lib/python2.5 -f \ -x 'bad_coding|badsyntax|site-packages' /Users/drifty/Code/Compiled/lib/python2.5 Fatal Python error: PyThreadState_Get: no current thread make: *** [libinstall] Abort trap Works if I remove ``-Wi -tt`` from the command. -- >Comment By: Tim Peters (tim_one) Date: 2006-06-09 22:19 Message: Logged In: YES user_id=31435 Removed "on OS X" from the Summary line, since this is trivial to reproduce on Windows too: $ python_d -Wi Fatal Python error: PyThreadState_Get: no current thread Note that I used a debug build there; the error doesn't occur if I use a release build instead. As a matter of fact, Armin recently added a comment to dictobject.c pointing out this very failure mode: /* We can arrive here with a NULL tstate during initialization: try running "python -Wi" for an example related to string interning. Let's just hope that no exception occurs then... */ For that matter, it could be that Armin _created_ this failure mode too ;-) -- Comment By: Brett Cannon (bcannon) Date: 2006-06-09 21:42 Message: Logged In: YES user_id=357491 OK, so -Wi is causing the failure. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-09 12:59 Message: Logged In: YES user_id=357491 Forgot to try this with just one of the two flags; will do that soon. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1495210 ] Install under osx 10.4.6 breaks shell.
Bugs item #1495210, was opened at 05/25/06 15:39 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495210&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: Macintosh Group: Python 2.4 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: ephantom (ephantom) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Install under osx 10.4.6 breaks shell. Initial Comment: Build.txt: # BUILD INFO # Date: Fri Apr 7 11:07:14 2006 # By: Ronald Oussoren The Universal-MacPython-2.4.3-2006-04-07.dmg seems to kludge terminal's shell. We installed it on two systems running 10.4.6, both systems had a previous version of python on them (2.3.5). On one system the shell broke to where it would not run UNIX commands, even after a re-boot. Under both systems the following shell errors occurred right after install. The error appears when you first initiate the shell, or change shells. glacier-wl:~ support$ csh csh: Badly placed ()'s. sh-2.05b$ tcsh tcsh: Badly placed ()'s. -- >Comment By: SourceForge Robot (sf-robot) Date: 06/09/06 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 05/26/06 04:18 Message: Logged In: YES user_id=580910 This is now fixed in the trunk, and will be fixed in the next release of the universal build as well. -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 05/26/06 03:41 Message: Logged In: YES user_id=580910 Assigned to me because I'm at fault here. This seems to be a bug in one of the postinstall scripts, I'll have a look. Sorry about the inconvenience. -- Comment By: ephantom (ephantom) Date: 05/25/06 15:43 Message: Logged In: YES user_id=1528840 Addendum: Both systems where PPC G4 systems, and not Intel chipsets. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495210&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503294 ] -Wi causes a fatal Python error
Bugs item #1503294, was opened at 2006-06-08 20:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&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: Open Resolution: None Priority: 8 Submitted By: Brett Cannon (bcannon) >Assigned to: Armin Rigo (arigo) Summary: -Wi causes a fatal Python error Initial Comment: PYTHONPATH=/Users/drifty/Code/Compiled/lib/python2.5 \ ./python.exe -Wi -tt /Users/drifty/Code/Compiled/lib/python2.5/compileall.py \ -d /Users/drifty/Code/Compiled/lib/python2.5 -f \ -x 'bad_coding|badsyntax|site-packages' /Users/drifty/Code/Compiled/lib/python2.5 Fatal Python error: PyThreadState_Get: no current thread make: *** [libinstall] Abort trap Works if I remove ``-Wi -tt`` from the command. -- >Comment By: Brett Cannon (bcannon) Date: 2006-06-09 19:54 Message: Logged In: YES user_id=357491 Ah-ha! I checked svn blame on PyThreadState_Get() and PyThreadState_GET(), but not on PyDict_GetItem(). Assigning to Armin since he caused this ruckus. =) -- Comment By: Tim Peters (tim_one) Date: 2006-06-09 19:19 Message: Logged In: YES user_id=31435 Removed "on OS X" from the Summary line, since this is trivial to reproduce on Windows too: $ python_d -Wi Fatal Python error: PyThreadState_Get: no current thread Note that I used a debug build there; the error doesn't occur if I use a release build instead. As a matter of fact, Armin recently added a comment to dictobject.c pointing out this very failure mode: /* We can arrive here with a NULL tstate during initialization: try running "python -Wi" for an example related to string interning. Let's just hope that no exception occurs then... */ For that matter, it could be that Armin _created_ this failure mode too ;-) -- Comment By: Brett Cannon (bcannon) Date: 2006-06-09 18:42 Message: Logged In: YES user_id=357491 OK, so -Wi is causing the failure. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-09 09:59 Message: Logged In: YES user_id=357491 Forgot to try this with just one of the two flags; will do that soon. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503294&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503780 ] stdin from directory causes crash (SIGSEGV)
Bugs item #1503780, was opened at 2006-06-10 00:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503780&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: Out of Date Priority: 5 Submitted By: Ben Liblit (liblit) Assigned to: Nobody/Anonymous (nobody) Summary: stdin from directory causes crash (SIGSEGV) Initial Comment: If standard input is redirected from a directory instead of a regular file, Python crashes quite early during startup, before running a single line of the user's script. I admit that redirecting from a directory is a weird thing to do, but even so, Python should respond with something more useful than a segmentation fault. In my particular case, the ideal behavior would be to not complain at all unless the Python script actually attempts to read from stdin. How to reproduce the problem: % touch empty.py % python -V Python 2.4.1 % python -d -v empty.py % python -d -v empty.py Comment By: Georg Brandl (gbrandl) Date: 2006-06-10 06:34 Message: Logged In: YES user_id=849994 This is already fixed in svn: $ ./python < / Python error: is a directory, cannot continue -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503780&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1503157 ] "/".join() throws OverflowError
Bugs item #1503157, was opened at 2006-06-08 20:58 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503157&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: Wummel (calvin) Assigned to: Tim Peters (tim_one) Summary: "/".join() throws OverflowError Initial Comment: I noticed a regression in string.join() behaviour: Running under Python 2.4 works: $ python2.4 Python 2.4.4c0 (#2, Apr 22 2006, 22:39:06) [GCC 4.0.3 (Debian 4.0.3-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> "/".join([u"", u"2"]) u'/2' >>> Running under Python 2.5 SVN build fails: $ python2.5 Python 2.5a2 (trunk:46757, Jun 8 2006, 22:20:31) [GCC 4.1.2 20060604 (prerelease) (Debian 4.1.1-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> "/".join([u"", u"2"]) Traceback (most recent call last): File "", line 1, in OverflowError: join() is too long for a Python string >>> -- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-10 06:45 Message: Logged In: YES user_id=849994 I applied the fix in rev. 46812. I also added the new test to the 2.4 branch in rev. 46813. -- Comment By: Tim Peters (tim_one) Date: 2006-06-09 00:34 Message: Logged In: YES user_id=31435 Fudge -- sorry about that! Your fix is fine. Adding two non-negative signed integers of the same width indeed overflows if and only if the computed result is negative. I was hallucinating when I imagined that a 0 result also indicated overflow (something related to that is a correct fast test when dealing with unsigned integers, but we're not here). -- Comment By: Hye-Shik Chang (perky) Date: 2006-06-08 22:40 Message: Logged In: YES user_id=55188 That occurrs when join sequence includes a zero-length unicode object after Tim's r46084. I attached a patch but can't sure that it's correct fix yet. :) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1503157&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
