[issue8704] cgitb sends a bogus HTTP header if the app crashes before finishing headers
Colin 't Hart added the comment: 1. This module is scheduled to be removed by Python 3.13 (although I preseonally am of the opinion that it is a useful module and would like to see it brought up-to-date). 2. Is reset() even necessary anymore? Can't the same results be achieved with CSS since we are in the third decade of the 2000s after all? -- nosy: +cthart ___ Python tracker <https://bugs.python.org/issue8704> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46759] sys.excepthook documentation doesn't mention that it isn't called for SystemExit
Change by Colin Watson : -- keywords: +patch pull_requests: +29507 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31357 ___ Python tracker <https://bugs.python.org/issue46759> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46759] sys.excepthook documentation doesn't mention that it isn't called for SystemExit
New submission from Colin Watson : In https://bugs.debian.org/1005803, Matthew Vernon reports that the library documentation for sys.excepthook doesn't mention the detail that that sys.excepthook isn't called for uncaught SystemExit exceptions, although help(sys) does mention this. (He also mentions that help(sys.excepthook) doesn't mention this. I think this would make less sense, since that gets the docstring of a particular implementation of an excepthook - on a given system it might not be Python's built-in version, for instance. But adding information to the main library documentation seems reasonable.) -- assignee: docs@python components: Documentation messages: 413285 nosy: cjwatson, docs@python priority: normal severity: normal status: open title: sys.excepthook documentation doesn't mention that it isn't called for SystemExit versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46759> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43743] BlockingIOError: [Errno 11] Resource temporarily unavailable: on GPFS.
Change by Alexei Colin : -- versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue43743> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43743] BlockingIOError: [Errno 11] Resource temporarily unavailable: on GPFS.
Change by Alexei Colin : -- versions: +Python 3.10 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue43743> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43743] BlockingIOError: [Errno 11] Resource temporarily unavailable: on GPFS.
Alexei Colin added the comment: Can confirm that this BlockingIOError happens on GPFS (alpine) on Summit supercomputer, tested with Python 3.8 and 3.10a7. I found that it happens only for file sizes above 65536. Minimal example: This filesize works: $ rm -f srcfile dstfile && truncate --size 65535 srcfile && python3.10 -c "import shutil; shutil.copyfile(b'srcfile', b'dstfile')" This file size (and larger) does not work: $ rm -f srcfile dstfile && truncate --size 65536 srcfile && python3.10 -c "import shutil; shutil.copyfile(b'srcfile', b'dstfile')" Traceback (most recent call last): File "", line 1, in File "/.../usr/lib/python3.10/shutil.py", line 265, in copyfile _fastcopy_sendfile(fsrc, fdst) File "/.../usr/lib/python3.10/shutil.py", line 162, in _fastcopy_sendfile raise err File "/.../usr/lib/python3.10/shutil.py", line 142, in _fastcopy_sendfile sent = os.sendfile(outfd, infd, offset, blocksize) BlockingIOError: [Errno 11] Resource temporarily unavailable: b'srcfile' -> b'dstfile' I tried patching shutil.py to retry the the call on this EAGAIN, but subsequent attempts fail with EAGAIN again indefinitely. I also use OP's workaround: set _USE_CP_SENDFILE = False in shutil.py -- nosy: +alexeicolin ___ Python tracker <https://bugs.python.org/issue43743> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38974] using tkinter.filedialog.askopenfilename() freezes python 3.8
Colin Caprani added the comment:
In case it helps, I have the same problem. Running python 3.8.8 on Windows 10,
and any MWE doesn't work, e.g.:
from tkinter import filedialog
from tkinter import *
root = Tk()
root.filename = filedialog.askopenfilename(initialdir = "/",title = "Select
file",filetypes = (("jpeg files","*.jpg"),("all files","*.*")))
print (root.filename)
I just get the spinning circle and unresponsive dialog. I have quite a few
shell integrations so uninstalling them is not ideal.
--
nosy: +colin.caprani
___
Python tracker
<https://bugs.python.org/issue38974>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42669] "except" documentation still suggests nested tuples are allowed
Change by Colin Watson : -- keywords: +patch pull_requests: +22682 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23822 ___ Python tracker <https://bugs.python.org/issue42669> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42669] "except" documentation still suggests nested tuples are allowed
New submission from Colin Watson : In Python 2, it was possible to use `except` with a nested tuple, and occasionally natural. For example, `zope.formlib.interfaces.InputErrors` is a tuple of several exception classes, and one might reasonably think to do something like this (this is real code used in several places in https://git.launchpad.net/launchpad): try: self.getInputValue() return True except (InputErrors, SomethingElse): return False As of Python 3.0, this raises "TypeError: catching classes that do not inherit from BaseException is not allowed" instead: one must instead either break it up into multiple "except" clauses or flatten the tuple. The change was mentioned in https://bugs.python.org/issue2380 and seems to have been intentional: I'm not requesting that the previous behaviour be restored, since it's a fairly rare porting issue and by now well-established in Python 3. However, the relevant sentences of documentation in https://docs.python.org/2/reference/compound_stmts.html#try and https://docs.python.org/3/reference/compound_stmts.html#the-try-statement are identical aside from punctuation, and they both read: For an except clause with an expression, that expression is evaluated, and the clause matches the exception if the resulting object is “compatible” with the exception. An object is compatible with an exception if it is the class or a base class of the exception object or a tuple containing an item compatible with the exception. I think this admits a recursive reading: I certainly read it that way. It should make it clear that nested tuples are not allowed. -- assignee: docs@python components: Documentation messages: 383243 nosy: cjwatson, docs@python priority: normal severity: normal status: open title: "except" documentation still suggests nested tuples are allowed versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42669> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42188] forkserver not reused in child processes
Change by Colin : Added file: https://bugs.python.org/file49549/test.py ___ Python tracker <https://bugs.python.org/issue42188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42188] forkserver not reused in child processes
Change by Colin : Removed file: https://bugs.python.org/file49547/test.py ___ Python tracker <https://bugs.python.org/issue42188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42188] forkserver not reused in child processes
New submission from Colin : The docstring on Forkserver.ensure_running states that a child process will use the forkserver process started by its parent: """ Make sure that a fork server is running. This can be called from any process. Note that usually a child process will just reuse the forkserver started by its parent, so ensure_running() will do nothing. """ Link to definition: https://github.com/python/cpython/blob/master/Lib/multiprocessing/forkserver.py#L105 That is not the behavior that I am seeing, however. I'm seeing each child (that start a process itself) will first spawn a *new* forkserver. -- components: Library (Lib) files: test.py messages: 379851 nosy: cchomey priority: normal severity: normal status: open title: forkserver not reused in child processes type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file49547/test.py ___ Python tracker <https://bugs.python.org/issue42188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42027] /passive run of Windows installer fail silently on Win7
New submission from Colin : As expected, Python 3.9.0 cannot be installed on Windows 7. Running the installer displays a message clearly stating this. However, running the installer in passive mode (/passive) is expected to display errors that might occur. As stated in https://docs.python.org//3.9/using/windows.html#installing-without-ui But this is not the case, nothing is displayed when launching the installer in passive mode. I would expect the same message as in the UI. -- components: Installation, Windows messages: 378572 nosy: colin-b, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: /passive run of Windows installer fail silently on Win7 versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38634] Symbol resolution conflict when embeding python in an application using libedit
Colin Watson added the comment: Here's a reasonably minimal reproduction recipe reduced from real code in the Launchpad test suite that doesn't require compiling a separate C extension. It fails on Ubuntu 18.04 with the gir1.2-gtk-3.0, python3-gi, and xvfb packages installed. (The xvfb-run part is just so that it works on a headless system; you can omit it if you have a working $DISPLAY.) xvfb-run python3 -c 'from gi.repository import Gtk; import readline' -- ___ Python tracker <https://bugs.python.org/issue38634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38634] Symbol resolution conflict when embeding python in an application using libedit
Colin Watson added the comment: FWIW I just ran into what I believe to be this bug with the Launchpad test suite on Python 3.6.9. The output shows some normal test output followed by: No entry for terminal type "unknown"; using dumb terminal settings. bind: Invalid command `enable-meta-key'. No entry for terminal type "unknown"; using dumb terminal settings. No entry for terminal type "unknown"; using dumb terminal settings. Segmentation fault The test suite imports a lot of stuff, but it includes something which links against libLLVM which links against libedit (I haven't worked out exactly what, but probably GTK-related). Then something else much later imports readline - again, I haven't worked out what yet, as it's taken me a day just to set up the exact right environment in which to reproduce this at all and an strace doesn't make the cause of the import especially clear. So I understand why you see this as a rare use case, but it's *extremely* confusing and a massive time sink when you do run across it, as the cause is a long way distant from the effect and it can arise in situations where it is in no way deliberate to have this sort of setup, but rather an emergent effect of several other things. -- nosy: +cjwatson ___ Python tracker <https://bugs.python.org/issue38634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37485] dataclass __foo__ methods inheritance is not working
Colin added the comment: I personally find it easier to understand if inheritance is the default behaviour, instead of having to explicitly disable a feature that's seems primarily designed for non-herited dataclasses. But whatever suits best the community :-) Thanks for the quick reply -- ___ Python tracker <https://bugs.python.org/issue37485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37485] dataclass __foo__ methods inheritance is not working
New submission from Colin : Hi, When using inheritance with dataclass, "standard" instance methods that are provided with a default behavior thanks to dataclass are not overridable using inheritance. Please see the sample below (or the attached file): import dataclasses @dataclasses.dataclass class A: def __eq__(self, other): return True @dataclasses.dataclass class B(A): pass print(A() == 1) # Returns True as expected print(B() == 1) # Returns False instead of True as expected via inheritance Thanks again -- components: Library (Lib) files: inheritance_dataclass_issue.py messages: 347142 nosy: colin-b priority: normal severity: normal status: open title: dataclass __foo__ methods inheritance is not working type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file48453/inheritance_dataclass_issue.py ___ Python tracker <https://bugs.python.org/issue37485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36514] -m switch revisited
Colin Dick added the comment: No, the first example is expected, BUT the middle two work HENCE the last should NOT have a problem either... No? Because the middle two work, so should the last complete without any errors. There were no code changes, Therefore the problem is with python On Wed, 3 Apr 2019, 23:42 Ronald Oussoren wrote: > > Ronald Oussoren added the comment: > > This is not a bug: > > * "python -m NAME" runs module (or package) NAME as a script, NAME should > therefore be a module name and not a filename (and hence not have a .py > suffix) > > * "python NAME" runs a script in file NAME and should therefore by a > complete file name, including a suffix when the file name has a suffix. > > In your examples "python -m vixsd.py" and "python vixsd" correctly raise > an error. > > -- > nosy: +ronaldoussoren > resolution: -> not a bug > stage: -> resolved > status: open -> closed > > ___ > Python tracker > <https://bugs.python.org/issue36514> > ___ > -- ___ Python tracker <https://bugs.python.org/issue36514> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36514] -m switch revisited
New submission from Colin Dick : -m switch revisited - see issue 27487 Win 10 64bit python 3.6.3 & 3.7.3 initially running code using py 3.6.3 with this command python -m vixsd.py produced C:\Python36\python.exe: Error while finding module specification for 'vixsd.py' (AttributeError: module 'vixsd' has no attribute '__path__') updated python from 3.6.3 to 3.7.3 searched & read web retried the 4 options with & without "-m" & ".py" results reproduced below c:\shared\python\vmw>python vixsd python: can't open file 'vixsd': [Errno 2] No such file or directory c:\shared\python\vmw>python vixsd.py A c:\shared\python\vmw>python -m vixsd A c:\shared\python\vmw>python -m vixsd.py A C:\Python3\python.exe: Error while finding module specification for 'vixsd.py' (ModuleNotFoundError: __path__ attribute not found on 'vixsd' while trying to find 'vixsd.py') while this was initially produced thru my ignorance, handling all 4 options still does not work correctly appears to have been a problem at least since issue 27487 cheers team, keep up the great work ColinDNZ -- messages: 339374 nosy: Colin Dick priority: normal severity: normal status: open title: -m switch revisited type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue36514> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35525] Incorrect keyword name in NNTP.starttls() documentation
New submission from Colin McPhail : The library documentation for nntplib.NNTP.starttls() says that it takes a keyword parameter called ssl_context. The source code referenced via the link at the top of the nntplib documentation shows the keyword is actually called context. The result is a TypeError if the documented name is used: TypeError: starttls() got an unexpected keyword argument 'ssl_context' -- assignee: docs@python components: Documentation messages: 332066 nosy: cmcp22, docs@python priority: normal severity: normal status: open title: Incorrect keyword name in NNTP.starttls() documentation versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15631] Python 3.3/3.4 installation issue on OpenSUSE lib/lib64 folders
Colin McCabe added the comment: When installing Python 3.6.3 from source on openSUSE Leap 42.2, this bug still occurs. Python cannot find the readline module, until you symlink $prefix/lib/python3.6/lib-dynload to $prefix/lib64/python3.6/lib-dynload. -- nosy: +cmccabe versions: +Python 3.6 -Python 3.3, Python 3.4 ___ Python tracker <https://bugs.python.org/issue15631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31811] async and await missing from keyword list in lexical analysis doc
Colin Dunklau added the comment: Hi Yury, perhaps I've misinterpreted PEP 492, and I can't claim to understand how the parser works and thus how the changes in https://github.com/python/cpython/pull/1669 affect things, but it seems to me that async and await are truly reserved words now, not just only reserved in certain contexts. If that's true, shouldn't they also appear in the list in the lexical analysis doc? I'd appreciate any clarification you (or anyone else) can offer. -- ___ Python tracker <https://bugs.python.org/issue31811> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31811] async and await missing from keyword list in lexical analysis doc
New submission from Colin Dunklau : I see that code making async/await real keywords has been merged, but it looks like Doc/reference/lexical_analysis.rst doesn't have those added https://github.com/python/cpython/blob/4a2d00c/Doc/reference/lexical_analysis.rst#keywords Is that list autogenerated somehow or was it just overlooked? -- assignee: docs@python components: Documentation messages: 304583 nosy: Colin Dunklau, docs@python priority: normal severity: normal status: open title: async and await missing from keyword list in lexical analysis doc type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31811> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28975] os.walk generator giving inconsistent results
Colin David Chen added the comment: Ah, you're correct. The behavior is consistent if you use strings in both invocations. The Path conversion strips the final '\\'. Doc examples do use the names of directories rather than a Path object. I will close the issue. Thanks for the quick response! -- resolution: -> not a bug status: open -> closed ___ Python tracker <http://bugs.python.org/issue28975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28975] os.walk generator giving inconsistent results
Changes by Colin David Chen : -- title: os.walk generator vs -> os.walk generator giving inconsistent results ___ Python tracker <http://bugs.python.org/issue28975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28975] os.walk generator vs
New submission from Colin David Chen: os.walk in 3.6rc1 (Windows) appears to generate different output depending on its invocation. In the first invocation, I use the generator to yield one result at a time: source = "C:\\cdchen_data\\downloads\\python-xlib-0.18\\" texasranger = os.walk(Path(source)) roottree = [next(texasranger)] roottree[0][0] Output: 'C:\\cdchen_data\\downloads\\python-xlib-0.18' The same result occurs when using the generator in a for loop. In the second invocation, I generate the complete list first: sourcetree = [x for x in os.walk(source)] sourcetree[0][0] Output: 'C:\\cdchen_data\\downloads\\python-xlib-0.18\\' The particular behavior causing me trouble is the omission in the first result of the final '\\'. I checked in 2.7.6 and os.walk is consistent and I believe more correct in that it will yield equivalent results and includes the '\\'. Not sure if earlier Python 3 implementations have this problem, I couldn't get 3.5 to run this function without failing. -- components: Library (Lib) messages: 283221 nosy: Colin David Chen priority: normal severity: normal status: open title: os.walk generator vs type: behavior versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue28975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27153] Default value shown by argparse.ArgumentDefaultsHelpFormatter is backwards for action='store_false'
New submission from Colin Morris:
Small example:
import argparse
parser =
argparse.ArgumentParser(formatter_class=argparse.ArgumentDefaultsHelpFormatter)
parser.add_argument('--no-foo', dest='foo', action='store_false',
help="Suppress foo")
args = parser.parse_args()
print('foo = {}'.format(args.foo))
Output with "-h":
optional arguments:
-h, --help show this help message and exit
--no-fooSuppress foo (default: True)
A reasonable person reading that would think that we suppress foo by default.
But actually, foo is True by default - "--no-foo" is off by default. I would
suggest that if action='store_false', the default value reported by the
formatter should be flipped.
--
components: Library (Lib)
messages: 266602
nosy: Colin Morris
priority: normal
severity: normal
status: open
title: Default value shown by argparse.ArgumentDefaultsHelpFormatter is
backwards for action='store_false'
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue27153>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21614] Case sensitivity problem in multiprocessing.
New submission from Colin Davidson: On windows 7, if a Python app is run (under python 2.7.6) and the invoking filename is capitalized differently from the source file itself, a subsequent attempt to use the multiprocessing module to "fork" a process will fail in the "forking" module. This happens because the fopen at line 1559 in import.c (in the "imp" module find_module method) uses the invoking capitalization, rather than the file capitalization and fails to open the file. The traceback gives lines 380 then 489 in forking.py, but as noted, the problem is in import.c (or in the Python startup, which could convert the capitalization...). -- components: Interpreter Core, Windows messages: 219423 nosy: ColinPDavidson priority: normal severity: normal status: open title: Case sensitivity problem in multiprocessing. type: crash versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue21614> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19417] Add tests for bdb (previously not tested)
Colin Williams added the comment: I've updated the patch to consolidate some duplicated code. Unfortunately, I wasn't able to move anything to setUpClass without messing even more with the internals. I haven't had a chance to refine the code further based on xdegaye's suggestions, but I wanted to make sure I was getting feedback on the most up-to-date code. -- Added file: http://bugs.python.org/file32485/bdb.patch ___ Python tracker <http://bugs.python.org/issue19417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19417] bdb test coverage
New submission from Colin Williams: This one is pretty involved. The tests might reach into the guts of the modules a bit too much, I'd be open to less invasive suggestions. -- files: bdb.patch keywords: patch messages: 201481 nosy: Colin.Williams priority: normal severity: normal status: open title: bdb test coverage Added file: http://bugs.python.org/file32389/bdb.patch ___ Python tracker <http://bugs.python.org/issue19417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19383] nturl2path test coverage
New submission from Colin Williams: Full coverage on this module -- files: nturl2path.patch keywords: patch messages: 201197 nosy: Colin.Williams priority: normal severity: normal status: open title: nturl2path test coverage Added file: http://bugs.python.org/file32345/nturl2path.patch ___ Python tracker <http://bugs.python.org/issue19383> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19382] tabnanny unit tests
Colin Williams added the comment: Alright, I'll wait until that one gets committed, and then add in my changes. I think between the two of us we'll get close to 100% -- ___ Python tracker <http://bugs.python.org/issue19382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19382] tabnanny unit tests
New submission from Colin Williams: I didn't test the stdout and stderr stuff, but I got the module up to 74% coverage. -- files: tabnanny.patch keywords: patch messages: 201194 nosy: Colin.Williams priority: normal severity: normal status: open title: tabnanny unit tests Added file: http://bugs.python.org/file32344/tabnanny.patch ___ Python tracker <http://bugs.python.org/issue19382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19350] macurl2path coverage
New submission from Colin Williams: Ported the tests built into the library requiring manual verification over to the testing framework. Those tests only provided 77% coverage, so I improved that up to 99%. Can't get the last line because it's only reachable on older model macs. -- components: Tests files: url2pathname.patch keywords: patch messages: 200947 nosy: Colin.Williams priority: normal severity: normal status: open title: macurl2path coverage Added file: http://bugs.python.org/file32301/url2pathname.patch ___ Python tracker <http://bugs.python.org/issue19350> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19265] Increased test coverage for datetime pickling
New submission from Colin Williams: This just increases test coverage for the datetime module by one line. -- components: Library (Lib) files: datetimepickling.patch keywords: patch messages: 13 nosy: Colin.Williams priority: normal severity: normal status: open title: Increased test coverage for datetime pickling type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file32132/datetimepickling.patch ___ Python tracker <http://bugs.python.org/issue19265> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18108] shutil.chown should support dir_fd and follow_symlinks keyword arguments
New submission from Colin Watson: Python 3.3 added the dir_fd and follow_symlinks keyword arguments to os.chown; it also added the shutil.chown function. Unfortunately the latter, while useful, does not support these new keyword arguments. It would be helpful if it did. -- components: Library (Lib) messages: 190404 nosy: cjwatson priority: normal severity: normal status: open title: shutil.chown should support dir_fd and follow_symlinks keyword arguments versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue18108> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1525919] email package quoted printable behaviour changed
Changes by Colin Su : -- assignee: -> docs@python components: +Documentation -Library (Lib), email nosy: +docs@python ___ Python tracker <http://bugs.python.org/issue1525919> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1525919] email package quoted printable behaviour changed
Colin Su added the comment: Confirmed with David, we work on this together on sprints. This is not a bug, if you do "set_payload" directly by yourself, you need to encode the payload by yourself because set_payload() doesn't encode payload if 'Content-Transfer-Encoding' did exist. -- nosy: +littleq0903 ___ Python tracker <http://bugs.python.org/issue1525919> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1525919] email package quoted printable behaviour changed
Changes by Colin Su : -- versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 -Python 2.4 ___ Python tracker <http://bugs.python.org/issue1525919> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3840] if TESTFN == "/tmp/@test", some tests fail
Colin Su added the comment:
TESTFN will be in format "@test_{pid}_tmp" instead of "@test" right now.
So it's not easy to have exactly the same name "@test_{pid}_tmp" in case if you
put "@test_{X}_tmp" (for X in range(1,10)) so many files into the top
folder.
does it need to keep open anymore?
--
nosy: +littleq0903
___
Python tracker
<http://bugs.python.org/issue3840>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15716] Ability to specify the PYTHONPATH via a command line flag
Colin Su added the comment: started working on it :) -- ___ Python tracker <http://bugs.python.org/issue15716> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15716] Ability to specify the PYTHONPATH via a command line flag
Colin Su added the comment: s/properly/proper (typo) -- ___ Python tracker <http://bugs.python.org/issue15716> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15716] Ability to specify the PYTHONPATH via a command line flag
Colin Su added the comment: Could anyone provide some properly command line usage for this issue? ex. python -P "path_1:path_2:path_3" I think this point need to be discussed :D -- ___ Python tracker <http://bugs.python.org/issue15716> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15716] Ability to specify the PYTHONPATH via a command line flag
Changes by Colin Su : -- nosy: +littleq0903 ___ Python tracker <http://bugs.python.org/issue15716> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15786] IDLE code completion window does not scoll/select with mouse
Colin Su added the comment: On which platform? -- nosy: +littleq0903 ___ Python tracker <http://bugs.python.org/issue15786> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
Colin Marc added the comment: Ah ok, just curious. Thanks! -- ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
Colin Marc added the comment: Just noticed this is missing from "What's new in Python 3.3": http://docs.python.org/dev/whatsnew/3.3.html. Should I submit a patch for that? -- ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13344] closed sockets don't raise EBADF anymore
Changes by Colin Marc : -- nosy: +colinmarc ___ Python tracker <http://bugs.python.org/issue13344> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
Colin Marc added the comment: More updates to the patch. -- Added file: http://bugs.python.org/file24797/npn_patch_py3.diff ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
Colin Marc added the comment: Updated patch. -- Added file: http://bugs.python.org/file24786/npn_patch_py3.diff ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
Colin Marc added the comment: Here's the OpenSSL code I referenced for my implementation. It's an excerpt of ssl/lib_ssl.c, starting at line 1514. -- Added file: http://bugs.python.org/file24778/npn_openssl_ref.c ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
Colin Marc added the comment: Oops, I had my vim configured wrong and left a few tab characters in there. Here's another updated patch =) -- Added file: http://bugs.python.org/file24777/npn_patch_py3.diff ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
Colin Marc added the comment: Here's an updated patch against 3.3. -- Added file: http://bugs.python.org/file24775/npn_patch_py3.diff ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
Colin Marc added the comment: Re the IETF draft: I'm not sure. However, I didn't actually have to implement the specification at all - that was all handled by OpenSSL. My patch just calls the appropriate SSL_CTX_* methods. Thanks for the tip. I'm still interested in this getting included, so I'll work on porting it over. -- ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
Colin Marc added the comment: If I ported it to 3.3 or 3.4, would it then be backported to 2.7? Or is there zero chance of that either? If so, why? I apologize, I'm new to the process. -- ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14204] Support for the NPN extension to TLS/SSL
New submission from Colin Marc : Recent versions of OpenSSL (1.0.1 and greater) support a new extension to SSL/TLS called Next Protocol Negotiation, defined here: http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-02. The extension allows servers and clients to advertise which protocols they support (for example, both HTTP and SPDY) and then agree on one during the handshake according to a simple algorithm. This patch to 2.7 adds support for the NPN extension via another parameter to ssl.wrap_socket, called 'npn_protocols', and by using the OpenSSL API. It should fail gracefully if the linked version of OpenSSL has no support for NPN, using a macro guard. Once the handshake is completed, SSLSocket.selected_protocol() returns whatever was agreed upon. Although I included client/server tests with the patch, testing this functionality in real-life situations proved difficult. Google chrome has SPDY and NPN functionality baked in, so I wrote a simple socket server that advertises SPDY/2 in addition to HTTP/1.1. Chrome, pointed at this server, correctly completed the handshake and started merrily sending SPDY control frames. -- files: npn_patch.diff keywords: patch messages: 154973 nosy: colinmarc priority: normal severity: normal status: open title: Support for the NPN extension to TLS/SSL type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file24739/npn_patch.diff ___ Python tracker <http://bugs.python.org/issue14204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper
New submission from Colin Watson : The file-like object returned by TarFile.extractfile can't be wrapped in an io.TextIOWrapper (which would be rather convenient in some cases to get something that reads str rather than bytes). The attached patch demonstrates the problem by way of a test case, and fixes it. It's just a matter of adding a no-op flush method so that TextIOWrapper.close is happy with it. -- components: Library (Lib) files: tarfile-exfileobject-flush.patch keywords: patch messages: 151536 nosy: cjwatson priority: normal severity: normal status: open title: tarfile.ExFileObject can't be wrapped using io.TextIOWrapper versions: Python 3.3 Added file: http://bugs.python.org/file24271/tarfile-exfileobject-flush.patch ___ Python tracker <http://bugs.python.org/issue13815> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1703592] have a way to ignore nonexisting locales in locale.setlocale
Colin Watson added the comment:
Yes, the same symptoms are still present.
I'd argue that it generally isn't an error in practice for applications, and
thus the net effect of this exception is negative; it's extraordinarily rare
for a crash to be preferable to running without localisation. Adding a new
function would help because I think it would be easier to persuade people to
call a new function that just does what they want ("turn on localisation if
possible") than to catch an exception (at which point they have to think "hm,
could that exception be for some other reason than
you-just-don't-have-that-locale", etc.).
--
___
Python tracker
<http://bugs.python.org/issue1703592>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8819] variable resolution within exec() incorrect
Colin Hawkett added the comment: Apologies for raising it in the tracker against your advice. My thinking was that you were suggesting discussions about 3.x content shouldn't be in the tracker, and I wanted to argue that it is a bug and should be fixed in 2.6+ -- ___ Python tracker <http://bugs.python.org/issue8819> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue991196] An inconsistency with nested scopes
Colin Hawkett added the comment: #8819 was closed as duplicate. That issue linked a description of the problem on stack overflow http://stackoverflow.com/questions/2904274/globals-and-locals-in-python-exec. I would like to argue that this is a bug, and should be fixed in 2.6+. The definition of bug here is that python does not behave as documented - that variable name resolution does *not* check the locals() of the enclosing scope. The fact that the code mistakenly assumes locals and globals would be the same thing in this situation does not mean it is not a bug. The statement in the previous comment - 'if you want exec to mimc the top level environment, you need to pass it a single dictionary' is true, but it hides that fact that this is the *only* thing you can do - if you *don't* want exec to mimic the top level environment, what's the approach? Doing anything else just creates a unique, undocumented, oddly behaving scope that doesn't apply closures correctly. What are the use cases for passing in locals? Doing so means your code behaves abnormally, unless you think carefully about how you write it, and that's not good - 'Write python code like this, except for this situation where it doesn't work, and you have to write your python like this, avoiding certain closure scenarios that would otherwise work.' What's the exec() API with locals for? If you don't pass in locals, or make globals and locals the same dictionary, then its an absolute pain to retrieve the definitions created in the exec'd code - they're mixed in with all the globals python adds, and if you don't know in advance what is being defined in the code block, it's close to impossible. To me, this is the primary use case for locals being passed in, and was surely the intention when the API was constructed. This bug prevents this use case. I'm guessing that somewhere in the python source there is some code that goes (pseudo) if scope == module: check_globals() else: check_locals() check_globals() and that this is done for performance reasons, but surely the check could be different without giving up much, and fix the problem? if locals() is globals(): check_globals() else: check_locals() check_globals() -- nosy: +hawkett ___ Python tracker <http://bugs.python.org/issue991196> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8819] variable resolution within exec() incorrect
Colin Hawkett added the comment: Agreed, this is the same issue. I'll make my argument that this is a bug (intentional or otherwise) on that issue. -- ___ Python tracker <http://bugs.python.org/issue8819> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8819] variable resolution within exec() incorrect
New submission from Colin Hawkett : A discussion on stack overflow - http://stackoverflow.com/questions/2904274/globals-and-locals-in-python-exec - has led to the conclusion that the variable lookup behaviour within code run using exec() is not behaving as expected. Variable lookup inside a class definition does not search the enclosing scope's locals() prior to issuing a NameError - there are full details and test cases at the above URL. -- components: None messages: 106447 nosy: hawkett priority: normal severity: normal status: open title: variable resolution within exec() incorrect type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8819> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1117601] os.path.exists returns false negatives in MAC environments.
Colin Alston added the comment: I also hit upon this issue and IMHO returning False in a "permission denied" scenario is less than obvious behaviour. It also means I have no way to catch this edge case in my own code immediately, I have to implement far larger logic to check now if False means the file doesn't exist, or if the user doesn't have access to the file. os.path.exists should absolutely raise a Permission exception. -- nosy: +cda32 ___ Python tracker <http://bugs.python.org/issue1117601> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6686] xml.sax.xmlreader.XMLReader.getProperty (xml.sax.handler.property_xml_string) returns bytes
Colin Stewart added the comment: Adding second patch. -- Added file: http://bugs.python.org/file14702/expatreader.py.patch2 ___ Python tracker <http://bugs.python.org/issue6686> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6686] xml.sax.xmlreader.XMLReader.getProperty (xml.sax.handler.property_xml_string) returns bytes
Colin Stewart added the comment: I'm not familiar with the inner workings of the expat integration with Python, so the attached patches need careful review. The first patch (expatreader.py.patch) is the minimum to resolve this issue. The second patch (expatreader.py.patch2) also exposes the version and encoding parameters via the Locator2 interface (http://www.saxproject.org/apidoc/org/xml/sax/ext/Locator2.html), which I'd recommend including. -- keywords: +patch Added file: http://bugs.python.org/file14701/expatreader.py.patch ___ Python tracker <http://bugs.python.org/issue6686> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6686] xml.sax.xmlreader.XMLReader.getProperty (xml.sax.handler.property_xml_string) returns bytes
New submission from Colin Stewart : The documentation for the xml.sax.handler.property_xml_string SAX property states that it should be "data type: String". However when retrieving this value in Python 3.1 it returns a bytes object instead. This makes handling the returned value very difficult because there is no method for retrieving the character set encoding that the XML was originally encoded with. This is currently blocking the port of SimpleTAL to Python 3 achieving feature parity with Python 2. -- components: XML messages: 91482 nosy: cms103 severity: normal status: open title: xml.sax.xmlreader.XMLReader.getProperty (xml.sax.handler.property_xml_string) returns bytes type: behavior versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue6686> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6571] Help index
New submission from Colin J. Williams : Shift operators. It would be good if "<<" and ">>" could be included in the index. Incidentally, the usage seems counter-intuitive. One would expect ">>" to be a shift to the right and "<<" to be a shift to the left. -- assignee: georg.brandl components: Documentation messages: 90917 nosy: cjw, georg.brandl severity: normal status: open title: Help index versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue6571> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1652] subprocess should have an option to restore SIGPIPE to default action
Colin Watson added the comment: Is there anything more I can do to move this along? Thanks. -- ___ Python tracker <http://bugs.python.org/issue1652> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4280] Version Checker
New submission from Colin J. Williams <[EMAIL PROTECTED]>: Versions 2.5, 2.6 and 3.0 contain a Version Checker in the Tools directory. This appears to no longer serve a useful purpose. Perhaps it can be dropped from the distribution. Colin W -- components: Tests files: pyversioncheck.py messages: 75611 nosy: cjw severity: normal status: open title: Version Checker type: feature request versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file11962/pyversioncheck.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4280> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1652] subprocess should have an option to restore SIGPIPE to default action
Colin Watson <[EMAIL PROTECTED]> added the comment: 2.6 is fine if that's what the release process dictates; I don't want it to be lost, that's all. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1652> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1652] subprocess should have an option to restore SIGPIPE to default action
Colin Watson added the comment: To be quite honest I can't think of any incompatibilities that wouldn't have the basic result of improving matters. I put the migration stuff in my bug report in case somebody else could, because I don't want the bug fix to stall on that. My preference would be for Python to move to behaviour equivalent to restore_sigpipe=True in the next release, but I would rather that it gained restore_sigpipe with the wrong default than that it didn't gain it at all. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1652> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1170] shlex have problems with parsing unicode
Colin Walters added the comment:
Patch to add Unicode support.
Note: this patch recodes shlex.py from iso-8859-1 to utf-8, so it has
mixed encodings.
--
nosy: +cgwalters
Added file: http://bugs.python.org/file9025/shlex-unicode.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1170>
__--- /usr/lib64/python2.5/shlex.py 2007-10-30 13:45:31.0 -0400
+++ hotwire/shlex.py 2007-12-22 13:05:52.0 -0500
@@ -1,4 +1,4 @@
-# -*- coding: iso-8859-1 -*-
+# -*- coding: utf-8 -*-
"""A lexical analyzer class for simple shell-like syntaxes."""
# Module and documentation by Eric S. Raymond, 21 Dec 1998
@@ -6,9 +6,11 @@
# push_source() and pop_source() made explicit by ESR, January 2001.
# Posix compliance, split(), string arguments, and
# iterator interface by Gustavo Niemeyer, April 2003.
+# Modified to support Unicode by Colin Walters, Dec 2007
import os.path
import sys
+import unicodedata
from collections import deque
try:
@@ -20,7 +22,7 @@
class shlex:
"A lexical analyzer class for simple shell-like syntaxes."
-def __init__(self, instream=None, infile=None, posix=False):
+def __init__(self, instream=None, infile=None, posix=False, utf=True):
if isinstance(instream, basestring):
instream = StringIO(instream)
if instream is not None:
@@ -34,13 +36,21 @@
self.eof = None
else:
self.eof = ''
+self.utf = utf
self.commenters = '#'
self.wordchars = ('abcdfeghijklmnopqrstuvwxyz'
'ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_')
-if self.posix:
-self.wordchars += ('ßàáâãäåæçèéêëìíîïðñòóôõöøùúûüýþÿ'
- 'ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞ')
-self.whitespace = ' \t\r\n'
+if self.posix and not self.utf:
+self.wordchars += ('Ãà áâãäåæçèéêëìÃîïðñòóôõöøùúûüýþÿ'
+ 'ÃÃÃÃÃÃ
ÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃÃ')
+elif self.posix:
+# We dynamically determine character classes below, except
+# by default _ is a word character
+self.wordchars = '_'
+if not self.utf:
+self.whitespace = ' \t\r\n'
+else:
+self.whitespace = ''
self.whitespace_split = False
self.quotes = '\'"'
self.escape = '\\'
@@ -116,12 +126,22 @@
else:
print "shlex: token=EOF"
return raw
+
+def __is_whitespace(self, c, category):
+return c in self.whitespace or (self.utf and category[0] == 'Z')
+
+def __is_wordchar(self, c, category):
+return c in self.wordchars or (self.utf and category[0] in ('L', 'N'))
def read_token(self):
quoted = False
escapedstate = ' '
while True:
nextchar = self.instream.read(1)
+if nextchar and self.utf:
+nextcategory = unicodedata.category(nextchar)
+else:
+nextcategory = None
if nextchar == '\n':
self.lineno = self.lineno + 1
if self.debug >= 3:
@@ -134,7 +154,7 @@
if not nextchar:
self.state = None # end of file
break
-elif nextchar in self.whitespace:
+if self.__is_whitespace(nextchar, nextcategory):
if self.debug >= 2:
print "shlex: I see whitespace in whitespace state"
if self.token or (self.posix and quoted):
@@ -147,7 +167,7 @@
elif self.posix and nextchar in self.escape:
escapedstate = 'a'
self.state = nextchar
-elif nextchar in self.wordchars:
+elif self.__is_wordchar(nextchar, nextcategory):
self.token = nextchar
self.state = 'a'
elif nextchar in self.quotes:
@@ -199,8 +219,8 @@
elif self.state == 'a':
if not nextchar:
self.state = None # end of file
-break
-elif nextchar in self.whitespace:
+break
+if self.__is_whitespace(nextchar, nextcategory):
if self.debug >= 2:
print "shlex: I see whitespace in word state"
self.state = ' '
@@ -222,7 +242,7 @@
[issue1652] subprocess should have an option to restore SIGPIPE to default action
New submission from Colin Watson: On Unix, Python sets SIGPIPE to SIG_IGN on startup, because it prefers to check every write and raise an IOError exception rather than taking SIGPIPE. This is all well and good for Python itself. However, non-Python Unix subprocesses generally expect to have SIGPIPE set to the default action, since that's what will happen if they're started from a normal shell. If this is not the case, then rather than taking SIGPIPE when a write fails due to the reading end of a pipe having been closed, write will return EPIPE and it's up to the process to check that. Many programs are lazy and fail to check for write errors, but in the specific case of pipe closure they are fine when invoked from a normal shell because they rely on taking the signal. Even correctly written programs that diligently check for write errors will typically produce different (and confusing) output when SIGPIPE is ignored. For instance, an example only very slightly adapted from one in the subprocess documentation: $ dd if=/dev/zero of=bigfile bs=1024 seek=1 count=1 1+0 records in 1+0 records out 1024 bytes (1.0 kB) copied, 0.000176709 seconds, 5.8 MB/s $ cat bigfile | head -n0 $ cat t.py from subprocess import Popen, PIPE p1 = Popen(["cat", "bigfile"], stdout=PIPE) p2 = Popen(["head", "-n0"], stdin=p1.stdout, stdout=PIPE) output = p2.communicate()[0] $ python t.py cat: write error: Broken pipe In some cases this problem can be much more significant. For instance, it is very common for shell scripts to rely on SIGPIPE's default action in order to behave correctly. A year or two ago I ran into this in OS installer code I was writing in Python, which called some underlying utility code in shell and C to deal with disk partitioning. In the event that the Python code failed to handle an exception, the shell script being run in a subprocess would spiral out of control rather than cleanly exiting at the first sign of trouble. This actually caused massive data loss on several testers' systems and required a quick release to fix (https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/40464 and https://wiki.ubuntu.com/DapperBeta/PartitionTableCorruption). Now obviously this was ultimately my fault for failing to catch the exceptional condition in testing, but this misdesign in Python and the lack of any documentation of this gotcha really didn't help at the time. For the record, the fix was to call this in a preexec_fn: signal.signal(signal.SIGPIPE, signal.SIG_DFL) This is an area of Unix that's very easy to get wrong. I've written my own subprocess handling library in C for another project, and I still found it non-trivial to track this down when it bit me. Since it essentially arises due to an implementation detail of the Python language, I think it should also be Python's responsibility to fix it up when subprocesses are involved. There are many ways to invoke subprocesses in Python, but the new, all-singing, all-dancing one is of course the subprocess module. I think it would be sufficient for that to do the right thing, or at least have an option to do so, and it's certainly the easiest place to add the option. I'm attaching a suggested patch which adds a restore_sigpipe option and documents it in what seem to be all the relevant places. Note that nearly all the examples end up with restore_sigpipe enabled. In some future release of Python, I think this should be the default. I'm not entirely familiar with migration plan processes in Python; how should this be done? -- components: Library (Lib) files: subprocess-sigpipe.patch messages: 58750 nosy: cjwatson severity: normal status: open title: subprocess should have an option to restore SIGPIPE to default action versions: Python 2.5 Added file: http://bugs.python.org/file8986/subprocess-sigpipe.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1652> __Index: Doc/library/subprocess.rst === --- Doc/library/subprocess.rst (revision 59547) +++ Doc/library/subprocess.rst (working copy) @@ -30,7 +30,7 @@ This module defines one class called :class:`Popen`: -.. class:: Popen(args, bufsize=0, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=False, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None, creationflags=0) +.. class:: Popen(args, bufsize=0, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=False, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None, creationflags=0, restore_sigpipe=False) Arguments are: @@ -112,6 +112,12 @@ underlying CreateProcess() function. They can specify things such as appearance of the main window and pri
