[ python-Bugs-780714 ] infinite __str__ recursion in thread causes seg fault
Bugs item #780714, was opened at 2003-07-31 18:37 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Stefan Gregory (stefan_gregory) Assigned to: Nobody/Anonymous (nobody) Summary: infinite __str__ recursion in thread causes seg fault Initial Comment: The following code reliably produces a segmentation fault under Solaris8 in Python2.3, Python2.2, Python2.1.3 and Python1.5. It produces a Bus Error when run on Python2.2 under OSX. Clearly it should produce a Python RuntimeError. import thread, time class Frog: def __str__(self): return str(self) f = Frog() thread.start_new_thread(str,(f,)) time.sleep(1000) This problem manifests in scenarios such as when you have 2 publishing objects (such as HTMLgen objects) A and B and you put A inside B and B inside A and each objects __str__ method calls its childrens __str__ methods and voila! (I hope this might be the reason my Zope server has been intermitently crashing for the past year or so though I have not found any recursive structures yet.) With Python2.3 gdb reports: vgetargskeywords (args=0x1bdaf0, keywords=0x0, format=0xd2579 "0:str", kwlist=0xf7b4c, p_va=0xfed0C02c) at Python/getargs.c:1167 Though with Python2.1 it dies at line 330 in getargs.c. -- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-09-10 17:14 Message: Logged In: YES user_id=250749 As of 2.5, the stack size for a thread can be set before the thread is created. Windows and Linux seem to default to generous thread stack sizes (1MB or more), other platforms are parsimonious by comparison (eg FreeBSD at 64kB). -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 10:03 Message: Logged In: YES user_id=21627 I fail to see the problem. You have to change the recursion limit; if you do, you risk a crash, as the documentation says: http://docs.python.org/lib/module-sys.html "This should be done with care, because a too-high limit can lead to a crash." With an unmodified recursionlimit in 2.4.3 on Windows, I get the expected RuntimeError. If it causes a crash on some system, it just means that the default recursion limit is too high for that platform (however, we don't seem to have a confirmation that the default recursion limit is too large for this application on any platform for Python 2.4 or 2.5). It is quite common that the system provides the main thread with a larger stack space than any additional thread, so it is not surprising that the stack overflow is detected on some system when the code is run in the main thread, yet crashes in an additional thread. The default recursion limit should be the conservative minimum of what the system minimally guarantees for any thread. It seems that the original problem has been fixed (although nobody apparently has tested Python 2.4 or 2.5 on Solaris8); I suggest to close this as fixed again. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-08-16 17:42 Message: Logged In: YES user_id=341410 >>> import sys >>> sys.setrecursionlimit(1) >>> class foo: ... def __str__(self): ... return str(self) ... >>> import threading >>> threading.Thread(target=foo().__str__).start() Kills 2.3, 2.4, and 2.5 on Windows, and 2.3 and 2.4 on linux (I can't test 2.5 on linux). Running in the main thread on Windows doesn't seem to be a big deal: >>> import sys >>> sys.setrecursionlimit(1) >>> class foo: ... def __str__(self): ... return str(self) ... >>> try: ... str(foo()) ... except Exception, why: ... print why ... Stack overflow >>> Note that the above crashes 2.3 and 2.4 on Linux. This is still a bug, at least in maintenance on 2.4. Suggested reopen. -- Comment By: SourceForge Robot (sf-robot) Date: 2006-08-14 12: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: Georg Brandl (gbrandl) Date: 2006-07-30 21:16 Message: Logged In: YES user_id=849994 Under 2.5, I get a runtime error now, so this might be fixed. -- Comment By: Brett
[ python-Bugs-1550791 ] UCS-4 tcl not found on SUSE 10.1 with tcl and tk 8.4.12-14
Bugs item #1550791, was opened at 2006-09-02 08:23 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550791&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: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Davin (dmpotts) Assigned to: Martin v. Löwis (loewis) Summary: UCS-4 tcl not found on SUSE 10.1 with tcl and tk 8.4.12-14 Initial Comment: PROBLEM DESCRIPTION: UCS-4 tcl is not found during configuration on a SUSE 10.1 (x86-32) system where tk-8.4.12-14 and tcl-8.4.12-14 have been installed as part of the SUSE installation (and visible/managed by YaST). This results in _tkinter and dependent codes not being built. EXPECTED BEHAVIOUR: The installed tcl/tk packages (provided as part of the SUSE 10.1 install) should have been detected successfully and _tkinter and related packages should have been configured for build. TO REPRODUCE: Install SUSE 10.1 on x86 hardware, taking care to ensure that tcl and tk packages are included in that install. Download, expand, and attempt to configure Python 2.5 release candidate 1 (Python-2.5c1.tar.bz2). Note that the following occurs during configuration and that _tkinter is subsequently not built: checking for UCS-4 tcl... no -- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-09-10 17:27 Message: Logged In: YES user_id=250749 Where are tcl.h and tk.h on this system? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1550791&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails
Bugs item #1531862, was opened at 2006-07-31 18:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&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: None Priority: 5 Submitted By: John A Meinel (jfmeinel) Assigned to: Gustavo Niemeyer (niemeyer) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 11:53 Message: Logged In: YES user_id=21627 How did you run the test cases yourself? They should have failed for you as well; buildbot has nothing to do with that. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-07 02:50 Message: Logged In: YES user_id=7887 Problem fixed again in 51797 (trunk) and 51794 (2.5), after removing tests which were offending buildbot due to sys.stdout being set to a StringIO. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 14:52 Message: Logged In: YES user_id=7887 Notice that in all buildbots that reported the failure, subprocess tests still pass correctly. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 14:48 Message: Logged In: YES user_id=7887 Wow.. this is strange. I don't see any reason why the build bots would break with this change, except for the reason that the test needs to output data to stdout/stderr to check if it's working or not. Is the buildbot checking these somehow? Is there any additional information about these failures? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 05:59 Message: Logged In: YES user_id=33168 I have reverted both of these changes since all the buildbots were broken. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 04:34 Message: Logged In: YES user_id=33168 This change has broken many (all?) of the buildbots. http://www.python.org/dev/buildbot/all/ -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 04:06 Message: Logged In: YES user_id=7887 Fixed in 51758, backported to 2.5 in 51759. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 03:44 Message: Logged In: YES user_id=7887 Neal, I'm preparing a patch which fixes this problem as well. Anthony, we should really be checking fd numbers, since they're the ones dup'ed in the child. If sys.stdout has a fileno() not in (0, 1, 2), that's not an issue. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-08-16 06:16 Message: Logged In: YES user_id=29957 Making it check for particular FD numbers is a bad idea. Instead, it should check that any FD that's being closed isn't in the set (sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno()) -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-16 06:11 Message: Logged In: YES user_id=33168 If stderr == stdout, this patch won't fix that, will it? Shouldn't you add 1, 2 to the blacklist for stderr? (The patch adds 2, I think 1 may also be required.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&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-1547300 ] Wireless on Python
Feature Requests item #1547300, was opened at 2006-08-26 23:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1547300&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: Ahmet Bişkinler (ahmetbiskinler) Assigned to: Nobody/Anonymous (nobody) Summary: Wireless on Python Initial Comment: It would be very nice if Python had a Wireless Module that works on all platforms. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 12:26 Message: Logged In: YES user_id=21627 Would you like to contribute one? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1547300&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-1528154 ] New sequences for Unicode groups and block ranges needed
Feature Requests item #1528154, was opened at 2006-07-25 06:44
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528154&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: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: gmarketer (gmarketer)
Assigned to: Nobody/Anonymous (nobody)
Summary: New sequences for Unicode groups and block ranges needed
Initial Comment:
The special sequences consist of "\" and another
character need to be added to RE sintax to simplify the
finding of several Unicode classes like:
* All uppercase letters
* All lowercase letters
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 12:36
Message:
Logged In: YES
user_id=21627
If anything, I think Python should implement Unicode TR#18:
http://www.unicode.org/unicode/reports/tr18/
This does include the \p notation for property expressions,
e.g. \p{Ll} or \p{East Asian Width:Narrow}.
We currently don't include the Script property, so \p{Greek}
could not be implemented (we can, of course, add support for
the script property). I can't find anything in the report
that makes \p{IsGreek} valid, so we shouldn't support it.
--
Comment By: gmarketer (gmarketer)
Date: 2006-07-26 04:06
Message:
Logged In: YES
user_id=1334865
We need to process several strings in utf-8 and need to use
regular expressions to match pattern, for ex.:
r"[ANY_LANGUAGE_UPPERCASE_LETTER,0-9ANY_LANGUAGE_LOWERCASE_LETTER]+|NOT_ANY_LANGUAGE_CURRENCY"
We don't know how to implement this logic by our hands.
Also, I found this logic implemented in Microsoft dot NET
regular expressions:
\p{name}Matches any character in the named character
class 'name'. Supported names are Unicode groups and block
ranges. For example Ll, Nd, Z, IsGreek, IsBoxDrawing, and Sc
(currency).
\P{name}Matches text not included in the named
character class 'name'.
We need same logic in regular expressions.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-07-25 09:45
Message:
Logged In: YES
user_id=38388
Could you make your request a little more specific ?
We already have catregories in the re module, so adding a
few more would be possible (patches are welcome !). However,
we do need to know why you need them and whether there are
other RE implementations that already have such special
matching characters, e.g. the Perl RE implementation.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528154&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1409455 ] email.Message.set_payload followed by bad result get_payload
Bugs item #1409455, was opened at 2006-01-18 22:09
Message generated for change (Comment added) made by fresh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409455&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.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mark Sapiro (msapiro)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Message.set_payload followed by bad result get_payload
Initial Comment:
Under certain circumstances, in particular when charset
is 'iso-8859-1', where msg is an email.Message() instance,
msg.set_payload(text, charset)
'apparently' encodes the text as quoted-printable and
adds a
Content-Transfer-Encoding: quoted-printable
header to msg. I say 'apparently' because if one prints
msg or creates a Generator instance and writes msg to a
file, the message is printed/written as a correct,
quoted-printable encoded message, but
text = msg._payload
or
text = msg.get_payload()
gives the original text, not quoted-printable encoded, and
text = msg.get_payload(decode=True)
gives a quoted-printable decoding of the original text
which is munged if the original text included '=' in
some ways.
This is causing problems in Mailman which are currently
worked around by flagging if the payload was set by
set_payload() and not subsequently 'decoding' in that
case, but it would be better if
set_payload()/get_payload() worked properly.
A script is attached which illustrates the problem.
--
Comment By: Chris Withers (fresh)
Date: 2006-09-10 12:26
Message:
Logged In: YES
user_id=24723
This fix seems to have caused issues for code that does the
following:
from email.Charset import Charset,QP
from email.MIMEText import MIMEText
charset = Charset('utf-8')
charset.body_encoding = QP
msg = MIMEText(
u'Some text with chars that need encoding: \xa3',
'plain',
)
# set the charset
msg.set_charset(charset)
print msg.as_string()
Before this fix, the above would result in:
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
Some text with chars that need encoding: =A3
Now I get:
Traceback (most recent call last):
File "test_encoding.py", line 14, in ?
msg.as_string()
File "c:\python24\lib\email\Message.py", line 129, in
as_string
g.flatten(self, unixfrom=unixfrom)
File "c:\python24\lib\email\Generator.py", line 82, in flatten
self._write(msg)
File "c:\python24\lib\email\Generator.py", line 113, in _write
self._dispatch(msg)
File "c:\python24\lib\email\Generator.py", line 139, in
_dispatch
meth(msg)
File "c:\python24\lib\email\Generator.py", line 182, in
_handle_text
self._fp.write(payload)
UnicodeEncodeError: 'ascii' codec can't encode character
u'\xa3' in position 41:
ordinal not in range(128)
Am I doing something wrong here or is this patch in error?
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-02-08 13:34
Message:
Logged In: YES
user_id=12800
r42270 for Python 2.3/email 2.5. I will forward port these
to Python 2.4 and 2.5 (email 3.0).
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-02-08 03:07
Message:
Logged In: YES
user_id=12800
See the latest patch in issue 1409458:
https://sourceforge.net/support/tracker.php?aid=1409538
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2006-02-06 03:42
Message:
Logged In: YES
user_id=12800
See the attached patch for what I think is ultimately the
right fix. The idea is that when set_payload() is called,
the payload is immediately encoded so that get_payload()
will do the right thing. Also, Generator.py has to be fixed
to not doubly encode the payload.
Run against your example, it seems to DTRT. It also passes
all but one of the email pkg unit tests. The one failure
is, I believe due to an incorrect test. The patch includes
a fix for that as well as adding a test for
get_payload(decode=True).
I'd like to get some feedback from the email-sig before
applying this, but it seems right to me.
--
Comment By: Mark Sapiro (msapiro)
Date: 2006-01-20 23:19
Message:
Logged In: YES
user_id=1123998
I've looked at the email library and I see the problem.
msg.set_payload() never QP encodes msg._payload. When the
message is stringified or flattened by a generator, the
generator's _handle_text() method does the encoding and it
is msg._charset that signals the need to do this. Thus when
the message object is ultimately converted to a suitable
external form, the body is
[ python-Bugs-1545659 ] distutils needs vendor-packages support
Bugs item #1545659, was opened at 2006-08-24 02:28 Message generated for change (Comment added) made by movement You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&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: Distutils Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils needs vendor-packages support Initial Comment: Currently, distutils supports "site-packages". It should also provide an option for "vendor-packages". -- >Comment By: John Levon (movement) Date: 2006-09-10 14:52 Message: Logged In: YES user_id=53034 It appears that I was mistaken that this went upstream, as it was refused for some bizarre reason: http://sourceforge.net/tracker/index.php?func=detail&aid=1298835&group_id=5470&atid=305470 So this should be closed too, and we'll have to fix it locally. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 00:09 Message: Logged In: YES user_id=21627 What is "vendor-packages"? It is not something that is part of Python, AFAICT, so I don't think Python should support it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545658 ] distutils home scheme lacks python versioning
Bugs item #1545658, was opened at 2006-08-24 02:27 Message generated for change (Comment added) made by movement You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). -- >Comment By: John Levon (movement) Date: 2006-09-10 14:55 Message: Logged In: YES user_id=53034 http://www.python.org/doc/1.5.2p2/lib/module-marshal.html specifically: "Details of the format are undocumented on purpose; it may change between Python versions (although it rarely does)." Thus, anyone using the home scheme can hit these changes as the format is not architecturally guaranteed. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 00:13 Message: Logged In: YES user_id=21627 I fail to see the problem. Can you please provide a scenario where breakage does occur (instead of merely suggesting that it "can occur")? What is the specific error message that you get? Also, what does that have to do with OS vendors? They shouldn't use the home scheme. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545659 ] distutils needs vendor-packages support
Bugs item #1545659, was opened at 2006-08-24 02:28 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&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: Distutils Group: Feature Request >Status: Closed Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils needs vendor-packages support Initial Comment: Currently, distutils supports "site-packages". It should also provide an option for "vendor-packages". -- Comment By: John Levon (movement) Date: 2006-09-10 14:52 Message: Logged In: YES user_id=53034 It appears that I was mistaken that this went upstream, as it was refused for some bizarre reason: http://sourceforge.net/tracker/index.php?func=detail&aid=1298835&group_id=5470&atid=305470 So this should be closed too, and we'll have to fix it locally. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 00:09 Message: Logged In: YES user_id=21627 What is "vendor-packages"? It is not something that is part of Python, AFAICT, so I don't think Python should support it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545659 ] distutils needs vendor-packages support
Bugs item #1545659, was opened at 2006-08-24 04:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&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: Distutils Group: Feature Request Status: Closed Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils needs vendor-packages support Initial Comment: Currently, distutils supports "site-packages". It should also provide an option for "vendor-packages". -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 17:24 Message: Logged In: YES user_id=21627 For the record: patch #1298835 wasn't refused; it was withdrawn by the submitter. -- Comment By: John Levon (movement) Date: 2006-09-10 16:52 Message: Logged In: YES user_id=53034 It appears that I was mistaken that this went upstream, as it was refused for some bizarre reason: http://sourceforge.net/tracker/index.php?func=detail&aid=1298835&group_id=5470&atid=305470 So this should be closed too, and we'll have to fix it locally. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 02:09 Message: Logged In: YES user_id=21627 What is "vendor-packages"? It is not something that is part of Python, AFAICT, so I don't think Python should support it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545658 ] distutils home scheme lacks python versioning
Bugs item #1545658, was opened at 2006-08-24 04:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 17:26 Message: Logged In: YES user_id=21627 It's true that the format of marshal may change. More regularly, the format of .pyc files may change due to changes in the byte codes. Yet, I fail to see why this can cause breakage. The pyc format is deliberately so designed that nothing will break even if the format changes. I'm still waiting for a demonstrable problem. -- Comment By: John Levon (movement) Date: 2006-09-10 16:55 Message: Logged In: YES user_id=53034 http://www.python.org/doc/1.5.2p2/lib/module-marshal.html specifically: "Details of the format are undocumented on purpose; it may change between Python versions (although it rarely does)." Thus, anyone using the home scheme can hit these changes as the format is not architecturally guaranteed. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 02:13 Message: Logged In: YES user_id=21627 I fail to see the problem. Can you please provide a scenario where breakage does occur (instead of merely suggesting that it "can occur")? What is the specific error message that you get? Also, what does that have to do with OS vendors? They shouldn't use the home scheme. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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 (Tracker Item Submitted) made by Item Submitter 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: Nobody/Anonymous (nobody) 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 -- 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-1555842 ] email package and Unicode strings handling
Bugs item #1555842, was opened at 2006-09-10 16:04 Message generated for change (Comment added) made by manlioperillo 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: Nobody/Anonymous (nobody) 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-1545658 ] distutils home scheme lacks python versioning
Bugs item #1545658, was opened at 2006-08-24 02:27 Message generated for change (Comment added) made by movement You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). -- >Comment By: John Levon (movement) Date: 2006-09-10 18:51 Message: Logged In: YES user_id=53034 Consider a shared tree where users do not have access to write new .pyc's. Just like the standard python libraries, there could be a significant speed slowdown due to not being able to use the old .pyc's. It's the exact same case that prompts distro's to install into /usr/lib/pythonX.X/ -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 15:26 Message: Logged In: YES user_id=21627 It's true that the format of marshal may change. More regularly, the format of .pyc files may change due to changes in the byte codes. Yet, I fail to see why this can cause breakage. The pyc format is deliberately so designed that nothing will break even if the format changes. I'm still waiting for a demonstrable problem. -- Comment By: John Levon (movement) Date: 2006-09-10 14:55 Message: Logged In: YES user_id=53034 http://www.python.org/doc/1.5.2p2/lib/module-marshal.html specifically: "Details of the format are undocumented on purpose; it may change between Python versions (although it rarely does)." Thus, anyone using the home scheme can hit these changes as the format is not architecturally guaranteed. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 00:13 Message: Logged In: YES user_id=21627 I fail to see the problem. Can you please provide a scenario where breakage does occur (instead of merely suggesting that it "can occur")? What is the specific error message that you get? Also, what does that have to do with OS vendors? They shouldn't use the home scheme. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545658 ] distutils home scheme lacks python versioning
Bugs item #1545658, was opened at 2006-08-24 04:27
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: Distutils
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: John Levon (movement)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils home scheme lacks python versioning
Initial Comment:
The "home scheme", as described here:
http://docs.python.org/inst/alt-install-windows.html
seems to be broken: no version suffix is appended,
yet .pyc files are not guaranteed across Python
revisions. Thus, breakage can occur.
This is quite annoying, as an OS vendor often would like
to install stuff into /usr/lib/python2.x/ (not using
vendor-packages).
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 21:00
Message:
Logged In: YES
user_id=21627
Why would a user not have the right to install to its own
home directory? That's what the home scheme is there for.
In any case, it seems that there won't be actual breakage,
only a possible slowdown. I very much doubt that the
slowdown would ever be significant, though.
It seems you want to use the home scheme for something that
it was not designed for. Notice that it is merely an
abbreviation - you can specify the directories directly if
you want to.
I'm closing this as invalid: the original report ("Thus,
breakage can occur.") is apparently wrong.
--
Comment By: John Levon (movement)
Date: 2006-09-10 20:51
Message:
Logged In: YES
user_id=53034
Consider a shared tree where users do not have access to
write new .pyc's. Just like the standard python libraries,
there could be a significant speed slowdown due to not being
able to use the old .pyc's.
It's the exact same case that prompts distro's to install
into /usr/lib/pythonX.X/
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 17:26
Message:
Logged In: YES
user_id=21627
It's true that the format of marshal may change. More
regularly, the format of .pyc files may change due to
changes in the byte codes. Yet, I fail to see why this can
cause breakage. The pyc format is deliberately so designed
that nothing will break even if the format changes.
I'm still waiting for a demonstrable problem.
--
Comment By: John Levon (movement)
Date: 2006-09-10 16:55
Message:
Logged In: YES
user_id=53034
http://www.python.org/doc/1.5.2p2/lib/module-marshal.html
specifically:
"Details of the format are undocumented on purpose; it may
change between Python versions (although it rarely does)."
Thus, anyone using the home scheme can hit these changes as
the format is not architecturally guaranteed.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 02:13
Message:
Logged In: YES
user_id=21627
I fail to see the problem. Can you please provide a scenario
where breakage does occur (instead of merely suggesting that
it "can occur")? What is the specific error message that you
get?
Also, what does that have to do with OS vendors? They
shouldn't use the home scheme.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545658 ] distutils home scheme lacks python versioning
Bugs item #1545658, was opened at 2006-08-24 02:27
Message generated for change (Comment added) made by movement
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: Distutils
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: John Levon (movement)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils home scheme lacks python versioning
Initial Comment:
The "home scheme", as described here:
http://docs.python.org/inst/alt-install-windows.html
seems to be broken: no version suffix is appended,
yet .pyc files are not guaranteed across Python
revisions. Thus, breakage can occur.
This is quite annoying, as an OS vendor often would like
to install stuff into /usr/lib/python2.x/ (not using
vendor-packages).
--
>Comment By: John Levon (movement)
Date: 2006-09-10 20:12
Message:
Logged In: YES
user_id=53034
> not have the right to install
Did you actually read the example I gave?
Just because it's a "possible slowdown" doesn't mean
that this behaviour is both inconsistent and potentially
troublesome. But I suppose you don't care.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 19:00
Message:
Logged In: YES
user_id=21627
Why would a user not have the right to install to its own
home directory? That's what the home scheme is there for.
In any case, it seems that there won't be actual breakage,
only a possible slowdown. I very much doubt that the
slowdown would ever be significant, though.
It seems you want to use the home scheme for something that
it was not designed for. Notice that it is merely an
abbreviation - you can specify the directories directly if
you want to.
I'm closing this as invalid: the original report ("Thus,
breakage can occur.") is apparently wrong.
--
Comment By: John Levon (movement)
Date: 2006-09-10 18:51
Message:
Logged In: YES
user_id=53034
Consider a shared tree where users do not have access to
write new .pyc's. Just like the standard python libraries,
there could be a significant speed slowdown due to not being
able to use the old .pyc's.
It's the exact same case that prompts distro's to install
into /usr/lib/pythonX.X/
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 15:26
Message:
Logged In: YES
user_id=21627
It's true that the format of marshal may change. More
regularly, the format of .pyc files may change due to
changes in the byte codes. Yet, I fail to see why this can
cause breakage. The pyc format is deliberately so designed
that nothing will break even if the format changes.
I'm still waiting for a demonstrable problem.
--
Comment By: John Levon (movement)
Date: 2006-09-10 14:55
Message:
Logged In: YES
user_id=53034
http://www.python.org/doc/1.5.2p2/lib/module-marshal.html
specifically:
"Details of the format are undocumented on purpose; it may
change between Python versions (although it rarely does)."
Thus, anyone using the home scheme can hit these changes as
the format is not architecturally guaranteed.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 00:13
Message:
Logged In: YES
user_id=21627
I fail to see the problem. Can you please provide a scenario
where breakage does occur (instead of merely suggesting that
it "can occur")? What is the specific error message that you
get?
Also, what does that have to do with OS vendors? They
shouldn't use the home scheme.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545658 ] distutils home scheme lacks python versioning
Bugs item #1545658, was opened at 2006-08-24 04:27
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&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: Distutils
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: John Levon (movement)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils home scheme lacks python versioning
Initial Comment:
The "home scheme", as described here:
http://docs.python.org/inst/alt-install-windows.html
seems to be broken: no version suffix is appended,
yet .pyc files are not guaranteed across Python
revisions. Thus, breakage can occur.
This is quite annoying, as an OS vendor often would like
to install stuff into /usr/lib/python2.x/ (not using
vendor-packages).
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 23:08
Message:
Logged In: YES
user_id=21627
I read the example you gave. In case of a shared directory,
you shouldn't use the "home" scheme. If you do anyway, you
have to live with the consequences. The home scheme is
called "home scheme" for a reason: the target directory is
expected to be inside the user's home directory.
--
Comment By: John Levon (movement)
Date: 2006-09-10 22:12
Message:
Logged In: YES
user_id=53034
> not have the right to install
Did you actually read the example I gave?
Just because it's a "possible slowdown" doesn't mean
that this behaviour is both inconsistent and potentially
troublesome. But I suppose you don't care.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 21:00
Message:
Logged In: YES
user_id=21627
Why would a user not have the right to install to its own
home directory? That's what the home scheme is there for.
In any case, it seems that there won't be actual breakage,
only a possible slowdown. I very much doubt that the
slowdown would ever be significant, though.
It seems you want to use the home scheme for something that
it was not designed for. Notice that it is merely an
abbreviation - you can specify the directories directly if
you want to.
I'm closing this as invalid: the original report ("Thus,
breakage can occur.") is apparently wrong.
--
Comment By: John Levon (movement)
Date: 2006-09-10 20:51
Message:
Logged In: YES
user_id=53034
Consider a shared tree where users do not have access to
write new .pyc's. Just like the standard python libraries,
there could be a significant speed slowdown due to not being
able to use the old .pyc's.
It's the exact same case that prompts distro's to install
into /usr/lib/pythonX.X/
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 17:26
Message:
Logged In: YES
user_id=21627
It's true that the format of marshal may change. More
regularly, the format of .pyc files may change due to
changes in the byte codes. Yet, I fail to see why this can
cause breakage. The pyc format is deliberately so designed
that nothing will break even if the format changes.
I'm still waiting for a demonstrable problem.
--
Comment By: John Levon (movement)
Date: 2006-09-10 16:55
Message:
Logged In: YES
user_id=53034
http://www.python.org/doc/1.5.2p2/lib/module-marshal.html
specifically:
"Details of the format are undocumented on purpose; it may
change between Python versions (although it rarely does)."
Thus, anyone using the home scheme can hit these changes as
the format is not architecturally guaranteed.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-09-10 02:13
Message:
Logged In: YES
user_id=21627
I fail to see the problem. Can you please provide a scenario
where breakage does occur (instead of merely suggesting that
it "can occur")? What is the specific error message that you
get?
Also, what does that have to do with OS vendors? They
shouldn't use the home scheme.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails
Bugs item #1531862, was opened at 2006-07-31 16:53 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&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: None Priority: 5 Submitted By: John A Meinel (jfmeinel) Assigned to: Gustavo Niemeyer (niemeyer) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py -- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-10 22:01 Message: Logged In: YES user_id=7887 Interesting. I was running tests directly most of the times and also in verbose mode, which indeed was hiding the problem that would happen when stdout is replaced. Now, one thing I wonder is about this: http://www.python.org/dev/buildbot/all/g4%20osx.4%20trunk/builds/1424/step-test/0 Why is it failing? In the first run, when all buildbots were broken, this is what was happening. It does look like tests are succeeding, and the implementation is the same as the currently committed one, but buildbot still says it's broken for some reason, and no error messages. Strange. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 09:53 Message: Logged In: YES user_id=21627 How did you run the test cases yourself? They should have failed for you as well; buildbot has nothing to do with that. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-07 00:50 Message: Logged In: YES user_id=7887 Problem fixed again in 51797 (trunk) and 51794 (2.5), after removing tests which were offending buildbot due to sys.stdout being set to a StringIO. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 12:52 Message: Logged In: YES user_id=7887 Notice that in all buildbots that reported the failure, subprocess tests still pass correctly. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 12:48 Message: Logged In: YES user_id=7887 Wow.. this is strange. I don't see any reason why the build bots would break with this change, except for the reason that the test needs to output data to stdout/stderr to check if it's working or not. Is the buildbot checking these somehow? Is there any additional information about these failures? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 03:59 Message: Logged In: YES user_id=33168 I have reverted both of these changes since all the buildbots were broken. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 02:34 Message: Logged In: YES user_id=33168 This change has broken many (all?) of the buildbots. http://www.python.org/dev/buildbot/all/ -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 02:06 Message: Logged In: YES user_id=7887 Fixed in 51758, backported to 2.5 in 51759. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 01:44 Message: Logged In: YES user_id=7887 Neal, I'm preparing a patch which fixes this problem as well. Anthony, we should really be checking fd numbers, since they're the ones dup'ed in the child. If sys.stdout has a fileno() not in (0, 1, 2), that's not an issue. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-08-16 04:16 Message: Logged In: YES user_id=29957 Making it check for particular FD numbers is a bad idea. Instead, it should check that any FD that's being closed isn't in the set (sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno())
[ python-Bugs-1541697 ] Recently introduced sgmllib regexp bug hangs Python
Bugs item #1541697, was opened at 2006-08-16 18:51
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&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: John J Lee (jjlee)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Recently introduced sgmllib regexp bug hangs Python
Initial Comment:
Looks like revision 47154 introduced a regexp that
hangs Python (Ctrl-C won't kill the process, CPU usage
sits near 100%) under some circumstances. A test case
is attached (sgmllib.html and hang_sgmllib.py).
The problem isn't seen if you read the whole file (or
nearly the whole file) at once. But that doesn't make
it a non-bug, AFAICS.
I'm not sure what the problem is, but presumably the
relevant part of the patch is this:
+starttag = re.compile(r'<[a-zA-Z][-_.:a-zA-Z0-9]*\s*('
+r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=\s*'
+
r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)[EMAIL PROTECTED]'
+
r'[][\-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~\'"@]*(?=[\s>/<])))?'
+r')*\s*/?\s*(?=[<>])')
The patch attached to bug 1515142 (also from Sam Ruby
-- claims to fix a regression introduced by his recent
sgmllib patches, and has not yet been applied) does NOT
fix the problem.
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-10 21:25
Message:
Logged In: YES
user_id=33168
I reverted the patch and added the test case for sgml so the
infinite loop doesn't recur.
Committed revision 51854. (head)
Committed revision 51850. (2.5)
Committed revision 51853. (2.4)
I will add the hang_re test cause to test_crashers or somewhere.
--
Comment By: kovan (kovan)
Date: 2006-09-05 14:40
Message:
Logged In: YES
user_id=1426755
Sorry, correct URL is
http://svn.python.org/view/python/trunk/Lib/sgmllib.py?rev=47154&r1=47080&r2=47154
--
Comment By: kovan (kovan)
Date: 2006-09-05 14:24
Message:
Logged In: YES
user_id=1426755
Again FYI, here's the diff where presumably the bug was
introduced:
http://svn.python.org/view/python/trunk/Lib/sgmllib.py?rev=47080&r1=46996&r2=47080
--
Comment By: kovan (kovan)
Date: 2006-09-05 14:04
Message:
Logged In: YES
user_id=1426755
I've been testing quiver's test case:
- With Eclipse's QuickREx plugin: it hangs. It was
configured in PCRE mode (which uses Jakarta-ORO Perl 5
regular expressions implementation), and no additional options.
- With grep: grep exits with a fatal error and dumps a stack
trace. grep was run also in Perl mode, with the command:
grep -P -f regexp.txt test.txt
I can't find an explanation for this, but I don't know much
about regexps. I hope it has some utility for the resolution
of this bug nevertheless.
--
Comment By: George Yoshida (quiver)
Date: 2006-08-17 21:55
Message:
Logged In: YES
user_id=671362
Slimmed down test case is attached.(The regex pattern in
question is used)
FYI, r47154 is backported to 2.4 branch(r47155).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1504333 ] sgmllib should allow angle brackets in quoted values
Bugs item #1504333, was opened at 2006-06-11 05:58
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504333&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Open
>Resolution: None
Priority: 5
Submitted By: Sam Ruby (rubys)
>Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib should allow angle brackets in quoted values
Initial Comment:
Real live example (search for "othercorrections")
http://latticeqcd.blogspot.com/2006/05/non-relativistic-qcd.html
This addresses the following (included in the file):
# XXX The following should skip matching quotes (' or ")
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-09-10 21:26
Message:
Logged In: YES
user_id=33168
I reverted the patch and added the test case for sgml so the
infinite loop doesn't recur. This was mentioned several
times on python-dev.
Committed revision 51854. (head)
Committed revision 51850. (2.5)
Committed revision 51853. (2.4)
--
Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2006-06-29 10:17
Message:
Logged In: YES
user_id=3066
I checked in a modified version of this patch: changed to
use separate REs for start and end tags to reduce matching
cost for end tags; extended tests; updated to avoid breaking
previous changes to support IPv6 addresses in unquoted
attribute values.
Committed as revisions 47154 (trunk) and 47155
(release24-maint).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504333&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails
Bugs item #1531862, was opened at 2006-07-31 18:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&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: None Priority: 5 Submitted By: John A Meinel (jfmeinel) Assigned to: Gustavo Niemeyer (niemeyer) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py -- >Comment By: Martin v. Löwis (loewis) Date: 2006-09-11 07:16 Message: Logged In: YES user_id=21627 It often happens that the tests fail first and then pass when rerun; it is not that clear why that happens. In many cases, this has turned out to be a consequence of the sequence in which the tests are run, where earlier tests "break" some state information to let later tests fail. It should be possible to enhance regrtest/unittest to keep more information about a failure, e.g. which specific test method failed. This might give a clue in cases like this. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-11 00:01 Message: Logged In: YES user_id=7887 Interesting. I was running tests directly most of the times and also in verbose mode, which indeed was hiding the problem that would happen when stdout is replaced. Now, one thing I wonder is about this: http://www.python.org/dev/buildbot/all/g4%20osx.4%20trunk/builds/1424/step-test/0 Why is it failing? In the first run, when all buildbots were broken, this is what was happening. It does look like tests are succeeding, and the implementation is the same as the currently committed one, but buildbot still says it's broken for some reason, and no error messages. Strange. -- Comment By: Martin v. Löwis (loewis) Date: 2006-09-10 11:53 Message: Logged In: YES user_id=21627 How did you run the test cases yourself? They should have failed for you as well; buildbot has nothing to do with that. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-07 02:50 Message: Logged In: YES user_id=7887 Problem fixed again in 51797 (trunk) and 51794 (2.5), after removing tests which were offending buildbot due to sys.stdout being set to a StringIO. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 14:52 Message: Logged In: YES user_id=7887 Notice that in all buildbots that reported the failure, subprocess tests still pass correctly. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 14:48 Message: Logged In: YES user_id=7887 Wow.. this is strange. I don't see any reason why the build bots would break with this change, except for the reason that the test needs to output data to stdout/stderr to check if it's working or not. Is the buildbot checking these somehow? Is there any additional information about these failures? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 05:59 Message: Logged In: YES user_id=33168 I have reverted both of these changes since all the buildbots were broken. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-06 04:34 Message: Logged In: YES user_id=33168 This change has broken many (all?) of the buildbots. http://www.python.org/dev/buildbot/all/ -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 04:06 Message: Logged In: YES user_id=7887 Fixed in 51758, backported to 2.5 in 51759. -- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-09-06 03:44 Message: L
