[issue46075] CookieJar.extract_cookies doesn't process cookies form local domains when domain is explicitly set in header
New submission from Nick : Apparently, CookieJar.extract_cookies doesn't process cookies form local domains which explicitly set domain in Set-Cookie header. That means that headers with domain specified, like "Set-Cookie: foo=baz; Domain=localhost;", are ignored. As far as I can tell, this might be actually part of the standard: https://stackoverflow.com/questions/1134290/cookies-on-localhost-with-explicit-domain/32210291#32210291 . However, it looks like other HTTP clients, including modern versions of both Chrome and Firefox do accept cookies from localhost with explicit domain=localhost, and this change doesn't appear to break existing software in any way. (simple POC to test behavior in browsers: https://gist.github.com/keddad/e2ce034f68b77e59077cdb1e887fa4a1). Maybe it would be best to also allow this behavior in Python? -- components: Library (Lib) messages: 408564 nosy: keddad priority: normal severity: normal status: open title: CookieJar.extract_cookies doesn't process cookies form local domains when domain is explicitly set in header type: behavior versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue46075> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46075] CookieJar.extract_cookies doesn't process cookies form local domains when domain is explicitly set in header
Change by Nick : -- keywords: +patch pull_requests: +28330 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30108 ___ Python tracker <https://bugs.python.org/issue46075> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1297] pyconfig.h not compatible with MS VC++ Express Edition
New submission from Nick: pyconfig.h checks for _MSC_VER and based on its value decides to include . MS VC++ Express reports _MSC_VER to be 1400 but does _NOT_ have the file basetsd.h. So when including Python.h with the Microsoft VC Express compiler, pyconfig.h will try to include the non existing basetsd.h and compiling fails. -- components: Build messages: 56531 nosy: weegreenblobbie severity: normal status: open title: pyconfig.h not compatible with MS VC++ Express Edition type: compile error versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1297> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1299] distutils.sysconfig is not cross-platform compatible
New submission from Nick: I'm using scons (www.scons.org) and Python's distutils.sysconfig to determine the correct compiler flags automatically to embed Python into my C++ application. I discovered that distuils.sysconfig is not fully implemented on Windows. Using distutils.sysconfg.get_config_var() or get_config_vars() does not work on the Windows distribution. The above calls will return values for INCLUDEPY LIBDIR LIB on Ubuntu Linux, however, on Windows, these variables are not all declared. These variables should be declared on all platforms so one can automatically get the correct compiler flags needed to embed python in one's C/C++ project. -- components: Build messages: 56533 nosy: weegreenblobbie severity: normal status: open title: distutils.sysconfig is not cross-platform compatible type: compile error versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1299> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1299] distutils.sysconfig is not cross-platform compatible
Nick added the comment: I'll look into it this weekend. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1299> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1297] pyconfig.h not compatible with MS VC++ Express Edition
Nick added the comment: MS VC++ 2005 Express Edition __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1297> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7914] IntVar() - AttributeError: 'NoneType' object has no attribute 'tk'
New submission from Nick : I tried to run the attached code and it seems IntVar() dies in the Tkinter module. After discussion with several other coworkers they seem to agree this may be a bug in Tkinter. If you need more info feel free to let me know and I can help with further testing. OS: Windows XP 32-bit SP2 Python: Python 3.1.1 Error: Traceback (most recent call last): File "H:/code/python/hfprog_sounds/intvar-POC.py", line 3, in num_good = IntVar() File "C:\Python31\lib\tkinter\__init__.py", line 265, in __init__ Variable.__init__(self, master, value, name) File "C:\Python31\lib\tkinter\__init__.py", line 174, in __init__ self._tk = master.tk AttributeError: 'NoneType' object has no attribute 'tk' -- components: Tkinter files: intvar-POC.py messages: 99238 nosy: Plazma severity: normal status: open title: IntVar() - AttributeError: 'NoneType' object has no attribute 'tk' type: compile error versions: Python 3.1 Added file: http://bugs.python.org/file16214/intvar-POC.py ___ Python tracker <http://bugs.python.org/issue7914> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7914] IntVar() - AttributeError: 'NoneType' object has no attribute 'tk'
Nick added the comment:
Ok this was my own mistake and not a bug.. really sorry about this.
Moving the following code ABOVE the IntVar() calls allows it to work:
app = Tk()
app.title("TESTING")
app.geometry('300x100+200+100')
See revised attached
--
status: open -> closed
Added file: http://bugs.python.org/file16215/intvar-POC.py
___
Python tracker
<http://bugs.python.org/issue7914>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8019] struct.unpack() expects wrong number of bytes
Nick added the comment: tested on macosx 10.6.2 64-bit and debian amd64 with both python2.6 and python3.1 the output is always the same: b'\x01\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00' 20 (1, 1, 2, 1, 1) (1, 1, 2, 16777216, 16777216) (1, 1, 2, 16777216, 16777216) -- b'\x01\x00\x00\x00\x01\x00\x00\x00\x02\x01\x00\x00\x00\x01\x00\x00\x00' 17 (1, 1, 2, 1, 1) (1, 1, 2, 1, 1) -- Added file: http://bugs.python.org/file16370/struct_test.py ___ Python tracker <http://bugs.python.org/issue8019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8019] struct.unpack() expects wrong number of bytes
New submission from Nick :
the code I'm trying to execute (block is long enough):
unpack("2IB2I", block)
executing this raises an exception:
struct.error: unpack requires a bytes argument of length 20
Setting native byte-order with '@' causes the same error.
Specifying the correct byte-order either with '>' or '<', or
native with '=' helps and unpack expects the correct number (17) of bytes.
--
components: Library (Lib)
messages: 100096
nosy: codingrobot
severity: normal
status: open
title: struct.unpack() expects wrong number of bytes
type: behavior
versions: Python 2.6, Python 3.1
___
Python tracker
<http://bugs.python.org/issue8019>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1544339] _ctypes fails to build on Solaris x86 32-bit (Sun compiler)
Nick added the comment: Hello is this not the fix? Are there any plans for patch and ctypes 1.0.3? ctypes is a setuptools dependency for various Python 3rd party packages, and this breaks any that enlist ctypes on Solaris. http://sourceware.org/ml/libffi-discuss/2010/msg00016.html -- ___ Python tracker <http://bugs.python.org/issue1544339> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1544339] _ctypes fails to build on Solaris x86 32-bit (Sun compiler)
Nick added the comment: Unfortunately I also get core dump applying that patch alone. core 'core' of 12847: /usr/local/Python-2.4.6-SunCC/bin/python setup.py test feaf0cfe ffi_call_SYSV (fefb0fc8, 8045898, feaf0b08, feaf08e4, 8045880, 4) + 66 feaf0caf ffi_call_SYSV (feaf08e4, 8045880, 4, 1, 8045920, fe95133c) + 17 feaf0b08 ffi_call (80458b0) + 64 feaeb47a _call_function_pointer (1001, fe95133c, 8045910, 8045900, 82a27bc, 804 5920) + 86 feaebad0 _CallProc (fe95133c, 842298c, 1001, 0, 82e1e74, 0) + 2dc feae8408 CFuncPtr_call (83fe304, 842298c, 0, 8422a6c) + 190 08063423 PyObject_Call (83fe304, 842298c, 0, 8063423) + 23 080b308c do_call (83fe304, 8045aec, 1, 0) + 54 080b2806 call_function (8045aec, 1, cd24f104, 82ca2cc) + ae 080afd91 PyEval_EvalFrame (8275154, 815ded4, 82b30b4, 0) + 27a1 080b1782 PyEval_EvalCodeEx (82ba460, 82b30b4, 0, 8262388, 1, 826238c) + 8ba 080b2cd6 fast_function (82ca2cc, 8045c9c, 1, 1, 0, 80f1740) + 15a 080b2822 call_function (8045c9c, 0, a0, 0) + ca -- ___ Python tracker <http://bugs.python.org/issue1544339> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1544339] _ctypes fails to build on Solaris x86 32-bit (Sun compiler)
Nick added the comment: Martin, the patch is for libffi included in ctypes 1.0.2. This is python 2.4 (required for plone/zope) so python 2.5/2.6 etc is not a possibility. ctypes 1.0.2 compiles with this patch but then core dumps anyway during tests so false hope. It appears to me that no-one is maintaining this separate ctypes code-base anymore so I'll have to ditch dependencies that use it (Shapely) unfortunately. -- ___ Python tracker <http://bugs.python.org/issue1544339> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44810] nturl2path: drive definition
New submission from Nick :
Due some problem in a third-party package the `url2path` function from
`nturl2path` got `a/"https://b"` (without `, `a`,`b` are just masks ) as the
first and only argument.
In the function there is the following code (
https://github.com/python/cpython/blob/414dcb13aaa4fd42f264fdee47782dede5c83d6c/Lib/nturl2path.py#L30
; current state of the `main` branch):
```
comp = url.split('|')
if len(comp) != 2 or comp[0][-1] not in string.ascii_letters:
error = 'Bad URL: ' + url
raise OSError(error)
drive = comp[0][-1].upper()
```
As a result, the function decided that the file was located on the `S:` drive
and returned the `S:\b` path without a warning.
To my mind, it is not right to take just the last letter as a drive letter
because the returned path must be only for the specified URL and the
unsupported ones must be marked as "bad" without any silent transformations.
--
components: Windows
messages: 398761
nosy: NickVeld, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: nturl2path: drive definition
type: behavior
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue44810>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44810] nturl2path: drive definition
Change by Nick : -- keywords: +patch pull_requests: +26058 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27552 ___ Python tracker <https://bugs.python.org/issue44810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44810] nturl2path: drive definition
Nick added the comment: For the visualization I created a PR with a possible fix. (The link is set into the corresponding field.) If everything is OK, I will perform all the required things like the CLA, news entry... -- ___ Python tracker <https://bugs.python.org/issue44810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9377] socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names
Nick added the comment: I faced with the issue on my own PC. For a Russian version of WinOS default PC name is ИВАН-ПК (C8 C2 C0 CD 2D CF CA in hex) and it returns from gethostbyaddr (CRT) exactly in this form (encoded with system locale cp1251 not UTF8). So when the function PyUnicode_FromString is called, it expects that argument is utf8 encoded string and throws and error. A lot of 3rd party modules use gethostbyaddr or getfqdn (which uses gethostbyaddr) and I can't just use function that returns names as bytes. Surrogate names are also not acceptable because the name mentioned above becomes -?? -- nosy: +spaun2002 ___ Python tracker <http://bugs.python.org/issue9377> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9377] socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names
Nick added the comment:
Originally I tried 3.2.2 (32bit), but I've just checked 3.2.3 and got the same.
A code for reproduce is simple:
from socket import gethostbyaddr
a = gethostbyaddr('127.0.0.1')
leads to:
Traceback (most recent call last):
File "C:\Users\user\test\test.py", line 13, in
a = gethostbyaddr('127.0.0.1')
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xcf in position 5: invalid
continuation byte
Or more complex sample:
def main():
import http.server
port = 80
handlerClass = http.server.SimpleHTTPRequestHandler
srv = http.server.HTTPServer(("", port), handlerClass )
srv.serve_forever()
if __name__ == "__main__":
main()
Attempt of connection to the server leads to:
Exception happened during processing of request from ('127.0.0.1', 1156)
Traceback (most recent call last):
File "C:\Python32\lib\socketserver.py", line 284, in _handle_request_noblock
self.process_request(request, client_address)
File "C:\Python32\lib\socketserver.py", line 310, in process_request
self.finish_request(request, client_address)
File "C:\Python32\lib\socketserver.py", line 323, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "C:\Python32\lib\socketserver.py", line 637, in __init__
self.handle()
File "C:\Python32\lib\http\server.py", line 396, in handle
self.handle_one_request()
File "C:\Python32\lib\http\server.py", line 384, in handle_one_request
method()
File "C:\Python32\lib\http\server.py", line 657, in do_GET
f = self.send_head()
File "C:\Python32\lib\http\server.py", line 701, in send_head
self.send_response(200)
File "C:\Python32\lib\http\server.py", line 438, in send_response
self.log_request(code)
File "C:\Python32\lib\http\server.py", line 483, in log_request
self.requestline, str(code), str(size))
File "C:\Python32\lib\http\server.py", line 517, in log_message
(self.address_string(),
File "C:\Python32\lib\http\server.py", line 559, in address_string
return socket.getfqdn(host)
File "C:\Python32\lib\socket.py", line 355, in getfqdn
hostname, aliases, ipaddrs = gethostbyaddr(name)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xcf in position 5: invalid
continuation byte
P.S. My PC name is "USER-ПК"
--
___
Python tracker
<http://bugs.python.org/issue9377>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31881] subprocess.returncode not set depending on arguments to subprocess.run
New submission from Nick :
If subprocess.run is called with a single string, say:
completed_ps = subprocess.run('mpirun -np 4 myexe.x moreargs', shell=True)
and 'myexe.x moreargs' fails with a returncode of 1, then
'completed_ps.returncode' is None. However, if we split the args with shlex, we
obtain the desired result, which is a returncode of 1:
import shlex
args = shlex.split('mpirun -np 4 myexe.x moreargs')
completed_ps = subprocess.run(args)
# now completed_ps.returncode = 1 if myexe.x moreargs fails.
Reproduced on Mac, Ubuntu 17.04, Python 3.6.1 and Python 3.6.3.
--
messages: 305094
nosy: nthompson
priority: normal
severity: normal
status: open
title: subprocess.returncode not set depending on arguments to subprocess.run
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue31881>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31881] subprocess.returncode not set depending on arguments to subprocess.run
Nick added the comment: I have verified that $ mpirun -np 4 myexe.x moreargs; echo $? 1 -- ___ Python tracker <https://bugs.python.org/issue31881> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31881] subprocess.returncode not set depending on arguments to subprocess.run
Change by Nick : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue31881> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34549] unittest docs could use another header
New submission from Nick : I find myself reaching for a list of the assert methods in the unittest library often. There are several methods but no clear way to link a URL via a header if you intend to bookmark or send it out. I have been using the method above the section in the meantime https://docs.python.org/3.7/library/unittest.html#unittest.TestCase.debug Would be great to have an `Assert Methods` header or some other equivalent. Thank you! -- assignee: docs@python components: Documentation messages: 324385 nosy: docs@python, napsterinblue priority: normal severity: normal status: open title: unittest docs could use another header type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34549] unittest docs could use another header
Nick added the comment: Ah, yes! Was searching for one of those helpful "Permalink to this ___" options. Didn't even see the link at the top. Thank you! -- ___ Python tracker <https://bugs.python.org/issue34549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34549] unittest docs could use another header
Change by Nick : -- resolution: -> works for me stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18917] python won't display greek characters in apache under windows
New submission from Nick:
I've set up apache on Windows 7 and I'm running python with cgi.
I have a script that contains this:
#!C:\Python34\python.exe
print ("Content-Type: text/html; charset=utf-8\n")
print ("Δοκιμή")
Pretty simple, right? When I'm opening the page to my browser in stead of
"Δοκιμή" I get weird ��� symbols (when the browser is set on UTF-8) If I set my
browser to ISO-8859-7 I will get the normal greek letters.
"sys.stdout.encoding" will display "cp1253" instead of "utf-8" as it probably
should.
scripts with only english characters will work totally fine. the problems seems
to be on non-english characters. it displays them as ISO-8859-7.
this doesn't seem to be an apache or windows issue as PHP and Lua will run just
fine and all the scripts will display greek characters in my browser. the
problem occurs only with python.
--
messages: 196886
nosy: nickl1
priority: normal
severity: normal
status: open
title: python won't display greek characters in apache under windows
type: behavior
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue18917>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18917] python won't display greek characters in apache under windows
Changes by Nick : -- components: +Unicode, Windows nosy: +ezio.melotti ___ Python tracker <http://bugs.python.org/issue18917> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18917] python won't display greek characters in apache under windows
Nick added the comment: Turns out adding "SetEnv PYTHONIOENCODING utf-8" to the end of apache's httpd.conf file fixed the problem for me. -- ___ Python tracker <http://bugs.python.org/issue18917> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18917] python won't display greek characters in apache under windows
Changes by Nick : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue18917> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1544339] _ctypes fails to build on Solaris x86 32-bit (Sun compiler)
Nick added the comment: I've stumbled head-first into this bug trying to build ctypes 1.0.2, as required by the python Shapely GIS library for an important Zope project I've been working on. It's a real surprise to see this bug even exists (since 2006!). I don't understand the cause, but it's totally preventing me from deploying code using Shapely (and therefore ctypes) to a new Solaris x86 server that otherwise runs on Windows and Linux right now. How come no progress - is it too hard to solve? I'm using Sun Studio 12.1. Out of a bunch of core libraries we're using (numpy, geos etc), this little package that has been "accepted" into the main Python distro seems to be the only one we've had problems with. :-( Is there really no way around this? -- components: +ctypes nosy: +nick versions: +Python 2.4 Added file: http://bugs.python.org/file14595/ffitarget-error.txt ___ Python tracker <http://bugs.python.org/issue1544339> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45975] Simplify some while-loops with walrus operator
Change by Nick Drozd : -- keywords: +patch pull_requests: +29267 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31083 ___ Python tracker <https://bugs.python.org/issue45975> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46763] os.path.samefile incorrect results for shadow copies
New submission from Nick Venenga :
shutil.copy fails to copy a file from a shadow copy back to its original file
since os.path.samefile returns True. os.path.samefile doesn't reliably detect
these files are different since it relies on ino which is the same for both
files
>>> sc =
>>> pathlib.Path('//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy3/test.file')
>>> o = pathlib.Path("V:/test.file")
>>> os.path.samefile(sc, o)
True
>>> os.stat(sc)
os.stat_result(st_mode=33206, st_ino=3458764513820579328, st_dev=1792739134,
st_nlink=1, st_uid=0, st_gid=0, st_size=1, st_atime=1644973968,
st_mtime=1644974052, st_ctime=1644973968)
>>> os.stat(o)
os.stat_result(st_mode=33206, st_ino=3458764513820579328, st_dev=1792739134,
st_nlink=1, st_uid=0, st_gid=0, st_size=2, st_atime=1644973968,
st_mtime=1644974300, st_ctime=1644973968)
>>> open(sc, "r").read()
'1'
>>> open(o, "r").read()
'12'
In the above example, you can see the shadow copy file and the original file.
Their mode and ino are the same, but their modified time and contents are
different
--
components: Windows
messages: 413307
nosy: nijave, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.samefile incorrect results for shadow copies
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue46763>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46763] os.path.samefile incorrect results for shadow copies
Nick Venenga added the comment: This script can reproduce the issue. The computer must be a Windows computer with volume shadow copy service enabled The computer must have shadow storage added to the drive being used This script changes the host machine by creating a shadow copy (permissions to create shadow copies are required) -- Added file: https://bugs.python.org/file50626/shadow-repro.py ___ Python tracker <https://bugs.python.org/issue46763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1764407] The -m switch does not use the builtin __main__ module
Nick Coghlan added the comment: Fixed committed to SVN as r57461 -- resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1764407> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1056] test_cmd_line starts python without -E
Nick Coghlan added the comment: Fixed for 2.6 in rev 58103 (Is the head still being merged to the py3k branch? Or does this need to be forward-ported manually?) -- nosy: +ncoghlan resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1056> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1739468] Add a -z interpreter flag to execute a zip file
Nick Coghlan added the comment: I like PJE's approach, and the patch works for me. About the only thing I'd change is to switch the expression in PyImport_GetImporter to a simple chain of if-statements in order to: - silence the warning from GCC about an unused value - make it more obvious to a reader what the function is doing An optimising compiler is going to produce similar code either way, and it took me a moment to realise that the && operations are being used purely for their short-circuiting effect, even though there is no real advantage to using an expression instead of a statement at that point in the code. Adding a simple test of the functionality to test_cmd_line would also be good. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1739468> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1705170] contextmanager eats StopIteration
Changes by Nick Coghlan: -- assignee: -> ncoghlan _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1705170> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1705170] contextmanager eats StopIteration
Nick Coghlan added the comment: Fixed for 2.6 in rev 58766. I'm not sure if it will be possible to get this into 2.5.2. Leaving open against 2.5 until it is checked in on the maintenance branch. -- components: +Library (Lib) -None resolution: -> accepted versions: +Python 2.5 _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1705170> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1705170] contextmanager eats StopIteration
Nick Coghlan added the comment: Close, but not quite. The problem is that the 'value' argument may be None if instantiation of the exception hasn't been forced before __exit__ gets called. >>> class TestWith(object): ... def __enter__(self): ... pass ... def __exit__(self, exc_type, exc_value, exc_tb): ... print exc_type, exc_value, exc_tb ... >>> from __future__ import with_statement >>> with TestWith(): iter([]).next() ... None Traceback (most recent call last): File "", line 1, in StopIteration That 'None' in the middle there is the problem - contextmanager.__exit__ needs to be detecting that and instantiating the passed in exception if it isn't already instantiated. Something like the following at the start of the else clause should do the trick: if value is None: value = type() -- nosy: +ncoghlan _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1705170> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1291] test_resource fails on recent linux systems (
Nick Coghlan added the comment: I just hit this as well when rerunning the 2.5 tests before checking something else in. The test itself appears to be fine, but the call to f.close() outside the try/except block attempting to flush the file to disk and raising an IOError. Didn't something like this get fixed recently? Did the new IO module in py3k have a similar problem? (assigning to Neal to make a call on the importance for 2.5.2) -- assignee: -> nnorwitz components: +Interpreter Core -Extension Modules nosy: +ncoghlan, nnorwitz priority: -> high resolution: -> accepted __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1291> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1705170] contextmanager eats StopIteration
Nick Coghlan added the comment: Done in rev 58901 -- resolution: accepted -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1705170> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1291] test_resource fails on recent linux systems (
Nick Coghlan added the comment: I just compared the 2.5 test_resource with the trunk test_resource - the latter has been modified to remove the file size limitation before it attempts to close the file, eliminating the test failure without changing the underlying behaviour of f.close. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1291> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1739468] Add a -z interpreter flag to execute a zip file
Nick Coghlan added the comment:
Attached an updated version of PJE's patch with the suggested cleanups
and a new unit test file (test_cmd_line_script.py). Finding the
roundtuits to finish the latter is actually what has taken me so long.
The basic tests and the directory tests are currently working, but for
some reason the zipfile tests are attempting to load __main__ using
pkgutil.ImpLoader instead of the zipimport module.
I'm posting the patch anyway to see if anyone else can spot where it's
going wrong before I find some more time to try and figure it out for
myself.
Added file: http://bugs.python.org/file8767/runmain_with_tests.diff
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1739468>
_Index: Python/import.c
===
--- Python/import.c (revision 59036)
+++ Python/import.c (working copy)
@@ -104,7 +104,6 @@
};
#endif
-static PyTypeObject NullImporterType; /* Forward reference */
/* Initialize things */
@@ -167,7 +166,7 @@
/* adding sys.path_hooks and sys.path_importer_cache, setting up
zipimport */
- if (PyType_Ready(&NullImporterType) < 0)
+ if (PyType_Ready(&PyNullImporter_Type) < 0)
goto error;
if (Py_VerboseFlag)
@@ -1088,7 +1087,7 @@
}
if (importer == NULL) {
importer = PyObject_CallFunctionObjArgs(
- (PyObject *)&NullImporterType, p, NULL
+ (PyObject *)&PyNullImporter_Type, p, NULL
);
if (importer == NULL) {
if (PyErr_ExceptionMatches(PyExc_ImportError)) {
@@ -1106,6 +1105,20 @@
return importer;
}
+PyAPI_FUNC(PyObject *)
+PyImport_GetImporter(PyObject *path) {
+PyObject *importer=NULL, *path_importer_cache=NULL, *path_hooks=NULL;
+
+ if ((path_importer_cache = PySys_GetObject("path_importer_cache"))) {
+ if ((path_hooks = PySys_GetObject("path_hooks"))) {
+ importer = get_path_importer(path_importer_cache,
+path_hooks, path);
+ }
+ }
+ Py_XINCREF(importer); /* get_path_importer returns a borrowed reference
*/
+ return importer;
+}
+
/* Search the path (default sys.path) for a module. Return the
corresponding filedescr struct, and (via return arguments) the
pathname and an open file. Return NULL if the module is not found. */
@@ -3049,7 +3062,7 @@
};
-static PyTypeObject NullImporterType = {
+PyTypeObject PyNullImporter_Type = {
PyVarObject_HEAD_INIT(NULL, 0)
"imp.NullImporter",/*tp_name*/
sizeof(NullImporter), /*tp_basicsize*/
@@ -3096,7 +3109,7 @@
{
PyObject *m, *d;
- if (PyType_Ready(&NullImporterType) < 0)
+ if (PyType_Ready(&PyNullImporter_Type) < 0)
goto failure;
m = Py_InitModule4("imp", imp_methods, doc_imp,
@@ -3118,8 +3131,8 @@
if (setint(d, "PY_CODERESOURCE", PY_CODERESOURCE) < 0) goto failure;
if (setint(d, "IMP_HOOK", IMP_HOOK) < 0) goto failure;
- Py_INCREF(&NullImporterType);
- PyModule_AddObject(m, "NullImporter", (PyObject *)&NullImporterType);
+ Py_INCREF(&PyNullImporter_Type);
+ PyModule_AddObject(m, "NullImporter", (PyObject *)&PyNullImporter_Type);
failure:
;
}
Index: Include/import.h
===
--- Include/import.h(revision 59036)
+++ Include/import.h(working copy)
@@ -24,6 +24,7 @@
#define PyImport_ImportModuleEx(n, g, l, f) \
PyImport_ImportModuleLevel(n, g, l, f, -1)
+PyAPI_FUNC(PyObject *) PyImport_GetImporter(PyObject *path);
PyAPI_FUNC(PyObject *) PyImport_Import(PyObject *name);
PyAPI_FUNC(PyObject *) PyImport_ReloadModule(PyObject *m);
PyAPI_FUNC(void) PyImport_Cleanup(void);
@@ -42,6 +43,7 @@
void (*initfunc)(void);
};
+PyAPI_DATA(PyTypeObject) PyNullImporter_Type;
PyAPI_DATA(struct _inittab *) PyImport_Inittab;
PyAPI_FUNC(int) PyImport_AppendInittab(char *name, void (*initfunc)(void));
Index: Lib/test/test_cmd_line.py
===
--- Lib/test/test_cmd_line.py (revision 59036)
+++ Lib/test/test_cmd_line.py (working copy)
@@ -1,3 +1,6 @@
+# Tests invocation of the interpreter with various command line arguments
+# All tests are executed with environment variables ignored
+# See test_cmd_line_script.py for testing of script execution
import test.test_support, unittest
import sys
Index: Lib/test/test_cmd_line_script.py
===
--- Lib/test/test_
[issue1739468] Add a -z interpreter flag to execute a zip file
Nick Coghlan added the comment:
I worked out what was wrong with my unit tests (I was incorrectly
including the path information when adding the test script to the zipfile)
I've updated the patch here, and will be committing the change once the
test suite finishes running.
--
versions: +Python 2.6
Added file: http://bugs.python.org/file8770/runmain_with_tests.diff
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1739468>
_Index: Python/import.c
===
--- Python/import.c (revision 59036)
+++ Python/import.c (working copy)
@@ -104,7 +104,6 @@
};
#endif
-static PyTypeObject NullImporterType; /* Forward reference */
/* Initialize things */
@@ -167,7 +166,7 @@
/* adding sys.path_hooks and sys.path_importer_cache, setting up
zipimport */
- if (PyType_Ready(&NullImporterType) < 0)
+ if (PyType_Ready(&PyNullImporter_Type) < 0)
goto error;
if (Py_VerboseFlag)
@@ -1088,7 +1087,7 @@
}
if (importer == NULL) {
importer = PyObject_CallFunctionObjArgs(
- (PyObject *)&NullImporterType, p, NULL
+ (PyObject *)&PyNullImporter_Type, p, NULL
);
if (importer == NULL) {
if (PyErr_ExceptionMatches(PyExc_ImportError)) {
@@ -1106,6 +1105,20 @@
return importer;
}
+PyAPI_FUNC(PyObject *)
+PyImport_GetImporter(PyObject *path) {
+PyObject *importer=NULL, *path_importer_cache=NULL, *path_hooks=NULL;
+
+ if ((path_importer_cache = PySys_GetObject("path_importer_cache"))) {
+ if ((path_hooks = PySys_GetObject("path_hooks"))) {
+ importer = get_path_importer(path_importer_cache,
+path_hooks, path);
+ }
+ }
+ Py_XINCREF(importer); /* get_path_importer returns a borrowed reference
*/
+ return importer;
+}
+
/* Search the path (default sys.path) for a module. Return the
corresponding filedescr struct, and (via return arguments) the
pathname and an open file. Return NULL if the module is not found. */
@@ -3049,7 +3062,7 @@
};
-static PyTypeObject NullImporterType = {
+PyTypeObject PyNullImporter_Type = {
PyVarObject_HEAD_INIT(NULL, 0)
"imp.NullImporter",/*tp_name*/
sizeof(NullImporter), /*tp_basicsize*/
@@ -3096,7 +3109,7 @@
{
PyObject *m, *d;
- if (PyType_Ready(&NullImporterType) < 0)
+ if (PyType_Ready(&PyNullImporter_Type) < 0)
goto failure;
m = Py_InitModule4("imp", imp_methods, doc_imp,
@@ -3118,8 +3131,8 @@
if (setint(d, "PY_CODERESOURCE", PY_CODERESOURCE) < 0) goto failure;
if (setint(d, "IMP_HOOK", IMP_HOOK) < 0) goto failure;
- Py_INCREF(&NullImporterType);
- PyModule_AddObject(m, "NullImporter", (PyObject *)&NullImporterType);
+ Py_INCREF(&PyNullImporter_Type);
+ PyModule_AddObject(m, "NullImporter", (PyObject *)&PyNullImporter_Type);
failure:
;
}
Index: Include/import.h
===
--- Include/import.h(revision 59036)
+++ Include/import.h(working copy)
@@ -24,6 +24,7 @@
#define PyImport_ImportModuleEx(n, g, l, f) \
PyImport_ImportModuleLevel(n, g, l, f, -1)
+PyAPI_FUNC(PyObject *) PyImport_GetImporter(PyObject *path);
PyAPI_FUNC(PyObject *) PyImport_Import(PyObject *name);
PyAPI_FUNC(PyObject *) PyImport_ReloadModule(PyObject *m);
PyAPI_FUNC(void) PyImport_Cleanup(void);
@@ -42,6 +43,7 @@
void (*initfunc)(void);
};
+PyAPI_DATA(PyTypeObject) PyNullImporter_Type;
PyAPI_DATA(struct _inittab *) PyImport_Inittab;
PyAPI_FUNC(int) PyImport_AppendInittab(char *name, void (*initfunc)(void));
Index: Lib/test/test_cmd_line.py
===
--- Lib/test/test_cmd_line.py (revision 59036)
+++ Lib/test/test_cmd_line.py (working copy)
@@ -1,3 +1,6 @@
+# Tests invocation of the interpreter with various command line arguments
+# All tests are executed with environment variables ignored
+# See test_cmd_line_script.py for testing of script execution
import test.test_support, unittest
import sys
Index: Lib/test/test_cmd_line_script.py
===
--- Lib/test/test_cmd_line_script.py(revision 0)
+++ Lib/test/test_cmd_line_script.py(revision 0)
@@ -0,0 +1,145 @@
+# Tests command line execution of scripts
+from __future__ import with_statement
+
+import unittest
+import os
+import os.path
+import sys
+import test
+import tempfile
[issue1739468] Add a -z interpreter flag to execute a zip file
Nick Coghlan added the comment: Committed as rev 59039 (now to see how the buildbots react for other platforms...) -- resolution: -> accepted status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1739468> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1739468] Add a -z interpreter flag to execute a zip file
Nick Coghlan added the comment: Reverted status to open until I figure out why the tests are failing on the Mac OSX buildbot. -- resolution: accepted -> status: closed -> open _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1739468> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1487] PEP 366 implementation
New submission from Nick Coghlan:
Patch to implement PEP 366.
Note that it doesn't implement precisely the semantics described in the
version of the PEP posted in July, as some of those ideas didn't prove
feasible due to the fact that imp.new_module can't tell the difference
between normal modules and packages.
An updated version of the PEP will be posted shortly to correct those
problems.
--
components: Interpreter Core, Library (Lib)
files: pep_366_v1.diff
keywords: patch
messages: 57761
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: PEP 366 implementation
type: rfe
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file8794/pep_366_v1.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1487>
__Index: Python/import.c
===
--- Python/import.c (revision 59120)
+++ Python/import.c (working copy)
@@ -2106,7 +2106,8 @@
{
static PyObject *namestr = NULL;
static PyObject *pathstr = NULL;
- PyObject *modname, *modpath, *modules, *parent;
+ static PyObject *pkgstr = NULL;
+ PyObject *pkgname, *modname, *modpath, *modules, *parent;
if (globals == NULL || !PyDict_Check(globals) || !level)
return Py_None;
@@ -2121,44 +2122,103 @@
if (pathstr == NULL)
return NULL;
}
+ if (pkgstr == NULL) {
+ pkgstr = PyString_InternFromString("__package__");
+ if (pkgstr == NULL)
+ return NULL;
+ }
*buf = '\0';
*p_buflen = 0;
- modname = PyDict_GetItem(globals, namestr);
- if (modname == NULL || !PyString_Check(modname))
- return Py_None;
+ pkgname = PyDict_GetItem(globals, pkgstr);
- modpath = PyDict_GetItem(globals, pathstr);
- if (modpath != NULL) {
- Py_ssize_t len = PyString_GET_SIZE(modname);
- if (len > MAXPATHLEN) {
+ if ((pkgname != NULL) && (pkgname != Py_None)) {
+ /* __package__ is set, so use it */
+ Py_ssize_t len;
+ if (!PyString_Check(pkgname)) {
PyErr_SetString(PyExc_ValueError,
- "Module name too long");
+ "__package__ set to non-string");
return NULL;
}
- strcpy(buf, PyString_AS_STRING(modname));
- }
- else {
- char *start = PyString_AS_STRING(modname);
- char *lastdot = strrchr(start, '.');
- size_t len;
- if (lastdot == NULL && level > 0) {
+ len = PyString_GET_SIZE(pkgname);
+ if (len == 0) {
+ if (level > 0) {
+ PyErr_SetString(PyExc_ValueError,
+ "Attempted relative import in
non-package");
+ return NULL;
+ }
+ return Py_None;
+ }
+ if (len > MAXPATHLEN) {
PyErr_SetString(PyExc_ValueError,
- "Attempted relative import in non-package");
+ "Package name too long");
return NULL;
}
- if (lastdot == NULL)
+ strcpy(buf, PyString_AS_STRING(pkgname));
+ } else {
+ /* __package__ not set, so figure it out and set it */
+ modname = PyDict_GetItem(globals, namestr);
+ if (modname == NULL || !PyString_Check(modname))
return Py_None;
- len = lastdot - start;
- if (len >= MAXPATHLEN) {
- PyErr_SetString(PyExc_ValueError,
- "Module name too long");
- return NULL;
+
+ modpath = PyDict_GetItem(globals, pathstr);
+ if (modpath != NULL) {
+ /* __path__ is set, so modname is already the package
name */
+ Py_ssize_t len = PyString_GET_SIZE(modname);
+ int error;
+ if (len > MAXPATHLEN) {
+ PyErr_SetString(PyExc_ValueError,
+ "Module name too long");
+ return NULL;
+ }
+ strcpy(buf, PyString_AS_STRING(modname));
+ error = PyDict_SetItem(globals, pkgstr, modname);
+
[issue11715] Building Python on multiarch Debian and Ubuntu
Nick Coghlan added the comment: It wouldn't surprise me at all if the laptop's links were a little off - I started with a Kubuntu image off VMWare's site quite some time ago, then dist-upgraded it through a couple of releases as they came out. -- ___ Python tracker <http://bugs.python.org/issue11715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6560] socket sendmsg(), recvmsg() methods
Nick Coghlan added the comment: The feature patch for sendmsg/recvmsg support came with a swathe of new tests, and the failures are in those new tests rather than anything breaking in the old ones. As Charles-François noted though, it doesn't look like the feature implementation itself is doing anything wrong, just that there are limits to what Mac OS X allows us to do with it (hence why I closed this feature request and opened issue #12958 to cover the task of updating the test suite to accurately reflect that situation). -- ___ Python tracker <http://bugs.python.org/issue6560> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12958] test_socket failures on Mac OS X
Nick Coghlan added the comment: OK, I've now looked into *why* the socket tests are throwing errors in tearDown, and it has to do with the way the threaded client/server tests in test_socket are set up. Specifically, ThreadableTest uses tearDown to reraise any exception raised in the client thread, and these are therefore outside the scope of the "expectedFailure" suppression in unittest. Now that I've tracked this down, it would be fairly straightforward to fix this specifically within test_socket.ThreadableTest by appropriately adjusting the definition of ThreadableTest.clientRun to discard exceptions encountered in tests flagged as expected failures. However, I'm wondering if that's the right thing to do. Perhaps it would make more sense to change unittest itself so that "expectedFailure" also suppresses tearDown errors. It doesn't seem all that unusual for a known failing test to also cause problems for the tearDown code. Added Michael to the nosy list to ask for his advice/opinion. In the meantime, I'll work on a patch that adjusts ThreadableTest directly. -- assignee: -> ncoghlan nosy: +michael.foord ___ Python tracker <http://bugs.python.org/issue12958> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294232] Error in metaclass search order
Nick Coghlan added the comment: Looking at Daniel's updated patch is still on my to-do list, but I won't object if anyone else wants to take this forward (it will be at least a few weeks before I get to it). -- ___ Python tracker <http://bugs.python.org/issue1294232> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12958] test_socket failures on Mac OS X
Nick Coghlan added the comment: OK, I'll just deal with the problem directly in test_socket then. It looks like my latest attempt (suppressing unittest._ExpectedFailure in test_socket.ThreadableTest.clientRun) did the trick, so I'll push the updated tests some time this evening: http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%20custom/builds/44/steps/test/logs/stdio -- ___ Python tracker <http://bugs.python.org/issue12958> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10548] Error in setUp not reported as expectedFailure (unittest)
Nick Coghlan added the comment: As another data point, this question came up again in the context of issue #12958. The new test_socket.ThreadableTest uses tearDown() to pick up and reraise any exception that occurred in the client thread. This meant that my initial attempts at flagging some expected failures (due to Mac OS X limitations) didn't work - the client half of the failure was thrown in tearDown() and reported as an error. While I've determined how to avoid that problem in the test_socket case, the general question of whether or not we consider it legitimate to put common assertions in setUp() and tearDown(), or expect that test code explicitly cope with tearDown() failures that occur due to expected test failures still needs to be addressed. To my mind, bugs in my test infrastructure are going to get flushed out by tests that I'm neither skipping nor marking as expected failures. If I have a test that is known to fail in a way that invalidates the standard tearDown procedure for the test infrastructure, having to special case that situation in the tearDown code seems to go against the spirit of offering the "expectedFailure" decorator in the first place. I don't think the same reasoning holds for setUp though - there's no way for a failing test to reach back and force setUp to fail, so any errors raised there are always going to be infrastructure errors. -- nosy: +ncoghlan ___ Python tracker <http://bugs.python.org/issue10548> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13004] pprint: add option to truncate sequences
Changes by Nick Coghlan : -- dependencies: +general pprint rewrite ___ Python tracker <http://bugs.python.org/issue13004> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Changes by Nick Coghlan : Removed file: http://bugs.python.org/file22616/pep380-missing-docs.diff ___ Python tracker <http://bugs.python.org/issue11682> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis
Nick Coghlan added the comment: Attached patch should now be complete, including the documentation for the new keyword-only 'file' parameter on various dis module functions. -- Added file: http://bugs.python.org/file23197/issue11816_get_opinfo_branch_20110920.diff ___ Python tracker <http://bugs.python.org/issue11816> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Changes by Nick Coghlan : Added file: http://bugs.python.org/file22616/pep380-missing-docs.diff ___ Python tracker <http://bugs.python.org/issue11682> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Nick Coghlan added the comment: I have updated the bitbucket repo with changes to address most of Benjamin's review comments. A few points of note: - I agree in principle with the idea of splitting Yield and YieldFrom into distinct AST nodes, but I'd prefer to focus on getting the current implementation into the main repo first - in cleaning up the handling of missing send/close/throw attributes on subiterators I discovered that the PyObject_CallMethod* APIs were discarding exception information and coercing everything to a terse AttributeError. The branch now changes them to allow the error reported by the underlying call to PyObject_GetAttr to pass through unmodified. - the generator close() method treats an AttributeError as expected when looking for a close() method on the subiterator, but uses WriteUnraisable to deal with anything else. - I share Benjamin's suspicion that some of the INCREF/DECREF pairs in genobject.c aren't actually necessary, but I don't think it's worth messing with them at this stage. I haven't looked at Zbyszek's proposed doc changes at this point - the pull request has a lot of irrelevant line wrapping changes in it, so it makes it hard to review. -- ___ Python tracker <http://bugs.python.org/issue11682> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis
Nick Coghlan added the comment: 'Op' is just an abbreviation of 'operation'. So 'operation code' becomes 'opcode' and 'operation information' becomes 'opinfo'. The fact that it comes for the 'dis' module gives the context that the *kind* of operation we're talking about is a Python byte code instruction. When people are hacking on bytecode in the future, they'll likely end up using get_opinfo() a fair bit, so swapping the succinct 'opinfo' for the verbose 'bytecode_instruction' strikes me as a poor trade-off. -- ___ Python tracker <http://bugs.python.org/issue11816> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
New submission from Nick Coghlan : Based on the python-ideas thread about closures, I realised there are two features the inspect module could offer to greatly simplify some aspects of testing closure and generator behaviour: inspect.getclosure(func) Returns a dictionary mapping closure references from the supplied function to their current values. inspect.getgeneratorlocals(generator) Returns the same result as would be reported by calling locals() in the generator's frame of execution The former would just involve syncing up the names on the code object with the cell references on the function object, while the latter would be equivalent to doing generator.gi_frame.f_locals with some nice error checking for when the generator's frame is already gone (or the supplied object isn't a generator iterator). -- messages: 144606 nosy: ncoghlan priority: normal severity: normal status: open title: Introspection generator and function closure state type: feature request ___ Python tracker <http://bugs.python.org/issue13062> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Nick Coghlan added the comment: Yep, that looks right to me. The eval loop then references those cells from the frame object during execution. -- ___ Python tracker <http://bugs.python.org/issue13062> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Nick Coghlan added the comment:
Huh, I didn't actually realise getclosure() could be written as a one liner
until seeing Meador's version above:
{var : cell.cell_contents for var, cell in zip(func.__code__.co_freevars,
func.__closure__)}
--
___
Python tracker
<http://bugs.python.org/issue13062>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13075] PEP-0001 contains dead links
Nick Coghlan added the comment: These pages are all still on python.org - the links just need to be updated to point to the devguide equivalents (under http://docs.python.org/devguide) -- nosy: +ncoghlan ___ Python tracker <http://bugs.python.org/issue13075> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13053] Add Capsule migration documentation to "cporting"
Nick Coghlan added the comment: Mostly looks good - couple of minor comments in Reitveld. As far as the patch flow goes, the 2.x and 3.x branches are actually handled independently (they're too divergent for merging to make sense). So 2.7 and 3.2 will be independent commits, then the changes will be merged into default from the 3.2 branch. -- ___ Python tracker <http://bugs.python.org/issue13053> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Nick Coghlan added the comment:
Because a generator can legitimately have no locals:
>>> def gen():
... yield 1
...
>>> g = gen()
>>> g.gi_frame.f_locals
{}
Errors should be reported as exceptions - AttributeError or TypeError if
there's no gi_frame and then ValueError or RuntimeError if gi_frame is None.
--
___
Python tracker
<http://bugs.python.org/issue13062>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Nick Coghlan added the comment: The function case is simpler - AttributeError or TypeError if there's no __closure__ attribute, empty mapping if there's no closure. I've also changed my mind on the "no frame" generator case - since that mapping will evolve over time as the generator executes anyway, the empty mapping accurately reflects the "no locals currently defined" that applies when the generator either hasn't been started yet or has finished. People can use getgeneratorstate() to find that information if they need to know. -- ___ Python tracker <http://bugs.python.org/issue13062> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7689] Pickling of classes with a metaclass and copy_reg
Nick Coghlan added the comment: Specifically, 2.7.3. A date for that has not yet been set, but somewhere in the December/January time frame is likely. -- ___ Python tracker <http://bugs.python.org/issue7689> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13101] Module Doc viewer closes when browser window closes on Windows 8
Nick Coghlan added the comment: If that's the app I think it is (pydoc -g), we're probably going to kill it off in 3.3 in favour of the -b option. -- nosy: +ncoghlan ___ Python tracker <http://bugs.python.org/issue13101> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13101] Module Doc viewer closes when browser window closes on Windows 8
Nick Coghlan added the comment: Slight correction, pydoc.gui() is already gone in current hg tip. However, this error may be indicative of an underlying problem with webbrowser.open(url) throwing an exception. -- ___ Python tracker <http://bugs.python.org/issue13101> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13105] Please elaborate on how 2.x and 3.x are different heads
Nick Coghlan added the comment: This was from memory, so don't take it as gospel as far as the current security-fix-only branches go, but here's what I sent to Larry: - We maintain two independent heads in hg: 2.7 and default 3.2 is open for general bugfixes 2.5 (IIRC), 2.6 and 3.1 are open for security fixes Security fixes (if applicable to both heads) go: 2.5 -> 2.6 -> 2.7 3.1 -> 3.2 -> default General bug fixes (if applicable to both heads) go: 2.7 3.2 -> default New features are added to default only The relative ordering of 2.x and 3.x changes doesn't really matter - the important thing is not to merge them in *either* direction. I think you can theoretically do cherry-picking with Hg, but most people seem to just do independent commits to the two streams. - -- ___ Python tracker <http://bugs.python.org/issue13105> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12602] Missing using docs cross-references
Nick Coghlan added the comment: The 'using docs' are, oddly enough, the part of the docs called 'using' :) In particular, the part about the command line components (including the '
[issue8087] Unupdated source file in traceback
Nick Coghlan added the comment: (just reviewing the idea here, not the current patch) The problem of "stale code" (i.e. what was executed doesn't match what is displayed in the traceback) is a tricky and subtle one. There are a few different cases: 1. Source displayed does not match source on disk - these cases do happen, but they're almost always due to straight up bugs in the linecache or traceback modules. 2. Source has been changed, but module has not been reloaded - this is the case for "edited source file but forgot to reload module". I've certainly forgotten to do this myself, and I'm far from the only one. This is the case Diego's RFE targets, and I think it has some merit. 3. Source has been changed, module has been reloaded, but object reference is from previous version of module - the patch doesn't detect this. There are various ways we *could* detect it, but they all involve some fairly significant changes to the way compilation and module import work. Aspect 3 is a much deeper (and bigger) problem relating to native introspection support in function and class objects. But that doesn't make Diego's idea to improve Aspect 2 invalid - there have certainly been times when playing at the interactive prompt that such a warning would have reminded me that I needed to reload the module I was working on. -- nosy: +ncoghlan ___ Python tracker <http://bugs.python.org/issue8087> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Nick Coghlan added the comment: No, the naming problem had occurred to me as well. Given the 'vars' builtin, perhaps 'getclosurevars' would do as the name? -- ___ Python tracker <http://bugs.python.org/issue13062> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13062] Introspection generator and function closure state
Nick Coghlan added the comment:
In reviewing Meador's patch (which otherwise looks pretty good), I had a
thought about the functionality and signature of getclosurevars().
Currently, it equates "closure" to "nonlocal scope", which isn't really true -
the function's closure is really the current binding of *all* of its free
variables, and that includes globals and builtins in addition to the lexically
scoped variables from outer scopes.
So what do people think about this signature:
ClosureVars = namedtuple("ClosureVars", "nonlocals globals builtins unbound")
def getclosurevars(func):
"""Returns a named tuple of dictionaries of the current nonlocal, global
and builtin references as seen by the body of the function. A final set of
unbound names is also provided."""
# figure out nonlocal_vars (current impl)
# figure out global_vars (try looking up names in f_globals)
# figure out builtin_vars (try looking up names in builtins)
# any leftover names go in unbound_vars
return ClosureVars(nonlocal_vars, global_vars, builtin_vars, unbound_vars)
Also, something that just occurred to me is that getclosurevars() should work
for already instantiated generator iterators as well as generator functions, so
the current typecheck may need to be made a bit more flexible.
--
___
Python tracker
<http://bugs.python.org/issue13062>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12602] Missing cross-references in Doc/using
Nick Coghlan added the comment: Don't feel bad about not recognising the context - this stuff wasn't documented at all for a long time, and it wasn't until Georg pointed me to the usage docs that I realised adding it there would be the right place. I should have remembered that and been less cryptic when creating this issue. It may suggest a meta-issue though - perhaps 'Documenting Python' should grow a devguide-style description of the Docs layout in source control, with a pointer from the devguide's directory layout description [1]? [1] http://docs.python.org/devguide/setup.html#directory-structure -- ___ Python tracker <http://bugs.python.org/issue12602> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13187] relative imports don't work when circular
Nick Coghlan added the comment: This is the same problem that all "from x import y" circular imports have - it isn't specific to relative imports. Closing as a duplicate of issue 992389 -- resolution: -> duplicate status: open -> closed superseder: -> attribute error after non-from import ___ Python tracker <http://bugs.python.org/issue13187> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue992389] attribute error due to circular import
Nick Coghlan added the comment: Changed the issue title to state clearly that the core issue is with circular imports that attempt to reference module contents at import time, regardless of the syntactic form used. All of the following module level code can fail due to this problem: from . import a from package import submodule from module import a import module module.a -- title: attribute error after non-from import -> attribute error due to circular import ___ Python tracker <http://bugs.python.org/issue992389> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue415492] Compiler generates relative filenames
Nick Coghlan added the comment: It's fairly easy to check this is still a problem: $ ./python Python 3.3.0a0 (default:a06ef7ab7321, Sep 22 2011, 13:41:29) [GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import setup >>> setup.__file__ 'setup.py' That's a relative path rather than an absolute one. If you edit sys.path to use '.' instead of '', it becomes clear that the import machinery is just doing a blind join of the sys.path entry with the relative location of the file: >>> del sys.modules['setup'] >>> sys.path[0] = '.' >>> import setup >>> setup.__file__ './setup.py' -- nosy: +brett.cannon, ncoghlan resolution: fixed -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue415492> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8060] PEP 3101 string formatting missing engineering presentation type for floating point
Changes by Nick Coghlan : -- nosy: +ncoghlan ___ Python tracker <http://bugs.python.org/issue8060> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
Nick Coghlan added the comment: They were removed because adding new methods to builtin types violated the language moratorium. Now that the language moratorium is over, the transform/untransform convenience APIs should be added again for 3.3. It's an approved change, the original timing was just wrong. -- assignee: lemburg -> nosy: +ncoghlan ___ Python tracker <http://bugs.python.org/issue7475> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
Nick Coghlan added the comment: Sorry, I meant to state my rationale for the unassignment - I'm assuming this issue is covered by MAL's recent decision to step away from Unicode and codec maintenance issues. If that's incorrect, MAL can reclaim the issue, otherwise unassigning leaves it open for whoever wants to move it forward. -- ___ Python tracker <http://bugs.python.org/issue7475> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
Nick Coghlan added the comment:
Some further comments after getting back up to speed with the actual status of
this problem (i.e. that we had issues with the error checking and reporting in
the original 3.2 commit).
1. I agree with the position that the codecs module itself is intended to be a
type neutral codec registry. It encodes and decodes things, but shouldn't
actually care about the types involved. If that is currently not the case in
3.x, it needs to be fixed.
This type neutrality was blurred in 2.x by the fact that it only implemented
str->str translations, and even further obscured by the coupling to the
.encode() and .decode() convenience APIs. The fact that the type neutrality of
the registry itself is currently broken in 3.x is a *regression*, not an
improvement. (The convenience APIs, on the other hand, are definitely *not*
type neutral, and aren't intended to be)
2. To assist in producing nice error messages, and to allow restrictions to be
enforced on type-specific convenience APIs, the CodecInfo objects should grow
additional state as MAL suggests. To avoid redundancy (and inaccurate
overspecification), my suggested colour for that particular bikeshed is:
Character encoding codec:
.decoded_format = 'text'
.encoded_format = 'binary'
Binary transform codec:
.decoded_format = 'binary'
.encoded_format = 'binary'
Text transform codec:
.decoded_format = 'text'
.encoded_format = 'text'
I suggest using the fuzzy format labels mainly due to the existence of the
buffer API - most codec operations that consume binary data will accept
anything that implements the buffer API, so referring specifically to 'bytes'
in error messages would be inaccurate.
The convenience APIs can then emit errors like:
'a'.encode('rot_13') ==>
CodecLookupError: text <-> binary codec expected ('rot_13' is text <-> text)
'a'.decode('rot_13') ==>
CodecLookupError: text <-> binary codec expected ('rot_13' is text <-> text)
'a'.transform('bz2') ==>
CodecLookupError: text <-> text codec expected ('bz2' is binary <-> binary)
'a'.transform('ascii') ==>
CodecLookupError: text <-> text codec expected ('ascii' is text <-> binary)
b'a'.transform('ascii') ==>
CodecLookupError: binary <-> binary codec expected ('ascii' is text <->
binary)
For backwards compatibility with 3.2, codecs that do not specify their formats
should be treated as character encoding codecs (i.e. decoded format is 'text',
encoded format is 'binary')
--
___
Python tracker
<http://bugs.python.org/issue7475>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
Nick Coghlan added the comment:
Oops, typo in my second error example. The command should be:
b'a'.decode('rot_13')
(Since str objects don't offer a decode() method any more)
--
___
Python tracker
<http://bugs.python.org/issue7475>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
Nick Coghlan added the comment:
On Thu, Oct 20, 2011 at 8:34 AM, STINNER Victor wrote:
>> str.transform('bz2') ==> CodecLookupError
>
> A lookup error is surprising here. It may be a TypeError instead. The bz2 can
> be used with .transform, but not on str. So:
No, it's the same concept as the other cases - we found a codec with
the requested name, but it's not the kind of codec we wanted in the
current context (i.e. str.transform). It may be that the problem is
the user has a str when they expected to have a bytearray or a bytes
object, but there's no way for the codec lookup process to know that.
> - Lookup error if the codec cannot be used with encode/decode or
> transform/untransform
> - Type error if the value type is invalid
There's no way for str.transform to tell the difference between "I
asked for the wrong codec" and "I expected to have a bytes object
here, not a str object". That's why I think we need to think in terms
of format checks rather than type checks.
> (CodecLookupError doesn't exist, you propose to define a new exception who
> inherits from LookupError?)
Yeah, and I'd get that to handle the process of creating the nice
error messages. I think it may even make sense to build the filtering
options into codecs.lookup() itself:
def lookup(encoding, decoded_format=None, encoded_format=None):
info = _lookup(encoding) # The existing codec lookup algorithm
if ((decoded_format is not None and decoded_format !=
info.decoded_format) or
(encoded_format is not None and encoded_format !=
info.encoded_format)):
raise CodecLookupError(info, decoded_format, encoded_format)
Then the various encode, decode and transform methods can just pass
the appropriate arguments to 'codecs.lookup' without all having to
reimplement the format checking logic.
--
___
Python tracker
<http://bugs.python.org/issue7475>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13227] Option to make the lru_cache type specific
Nick Coghlan added the comment: Features looks good, but the current patch doesn't handle keyword arguments correctly (more details in the Reitveld review). -- nosy: +ncoghlan ___ Python tracker <http://bugs.python.org/issue13227> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
Nick Coghlan added the comment:
I'm fine with people needing to drop down to the lower level lookup() API if
they want the filtering functionality in Python code. For most purposes,
constraining the expected codec input and output formats really isn't a major
issue - we just need it in the core in order to emit sane error messages when
people misuse the convenience APIs based on things that used to work in 2.x
(like 'a'.encode('base64')).
At the C level, I'd adjust _PyCodec_Lookup to accept the two extra arguments
and add _PyCodec_EncodeText, _PyCodec_DecodeBinary, _PyCodec_TransformText and
_PyCodec_TransformBinary to support the convenience APIs (rather than needing
the individual objects to know about the details of the codec tagging
mechanism).
Making new codecs available isn't a backwards compatibility problem - anyone
relying on a particular key being absent from an extensible registry is clearly
doing the wrong thing.
Regarding the particular formats, I'd suggest that hex, base64, quopri, uu, bz2
and zlib all be flagged as binary transforms, but rot13 be implemented as a
text transform (Florent's patch has rot13 as another binary transform, but it
makes more sense in the text domain - this should just be a matter of adjusting
some of the data types in the implementation from bytes to str)
--
___
Python tracker
<http://bugs.python.org/issue7475>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13229] Add shutil.filter_walk
New submission from Nick Coghlan : I needed a depth-limited, filtered search of a directory tree recently and came up with the following wrapper around os.walk that brings in a few niceties like glob-style filtering, depth limiting and symlink traversal that is safe from infinite loops. It also emits a named tuple rather than the bare tuple emitted by os.walk: http://code.activestate.com/recipes/577913-selective-directory-walking/ I think this would make a nice addition to 3.3 as shutil.filter_walk, but it need tests, documentation and reformatting as a patch before it can go anywhere. -- components: Library (Lib) messages: 145999 nosy: ncoghlan priority: normal severity: normal stage: test needed status: open title: Add shutil.filter_walk type: feature request versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue13229> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13227] Option to make the lru_cache type specific
Nick Coghlan added the comment: Looks good to me (although it took me longer than it should have to figure out why you didn't need to store the keyword argument names a second time) -- ___ Python tracker <http://bugs.python.org/issue13227> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13237] subprocess docs should use emphasise convenience functions
New submission from Nick Coghlan : Many typical subprocess use cases can now be handled simply via the convenience functions: subprocess.call() subprocess.check_call() subprocess.check_output() However, readers of the documentation could be forgiven for not realising that, since the docs dive right in with Popen() and will scare most readers away in search of more user friendly APIs (or even other languages). The module documentation should be reordered to introduce the helper function first, then Popen afterwards. The "subprocess replacements" [1] section would ideally help address this, but it hasn't been updated to use the convenience function, instead using confusing direct calls to Popen. [1] http://docs.python.org/library/subprocess.html#subprocess-replacements -- assignee: docs@python components: Documentation messages: 146059 nosy: docs@python, ncoghlan priority: normal severity: normal stage: needs patch status: open title: subprocess docs should use emphasise convenience functions versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13237> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13238] Add shell command helpers to shutil module
New submission from Nick Coghlan : I've been doing a few systems administration tasks with Python recently, and shell command invocation directly via the subprocess module is annoyingly clunky (even with the new convenience APIs). Since subprocess needs to avoid the shell by default for security reasons, I suggest we add the following simple helper functions to shutil: def call(cmd, *args, **kwds): if args or kwds: cmd = cmd.format(*args, **kwds) return subprocess.call(cmd, shell=True) def check_call(cmd, *args, **kwds): if args or kwds: cmd = cmd.format(*args, **kwds) return subprocess.check_call(cmd, shell=True) def check_output(cmd, *args, **kwds): if args or kwds: cmd = cmd.format(*args, **kwds) return subprocess.check_output(cmd, shell=True) Initially posted at: http://code.activestate.com/recipes/577891-simple-invocation-of-shell-commands/ Of course, even if others agree in principle, documentation and tests are still needed before this change can go anywhere. -- components: Library (Lib) messages: 146061 nosy: ncoghlan priority: normal severity: normal status: open title: Add shell command helpers to shutil module versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue13238> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13237] subprocess docs should emphasise convenience functions
Changes by Nick Coghlan : -- title: subprocess docs should use emphasise convenience functions -> subprocess docs should emphasise convenience functions ___ Python tracker <http://bugs.python.org/issue13237> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13238] Add shell command helpers to shutil module
Nick Coghlan added the comment: And that's exactly the problem - a web developer's or security auditor's "shell injection" is a system administrator's "this language sucks". These wrappers are the kind of thing you want for shell invocations when using Python as a replacement for a shell script or rewriting something that was originally written in Perl, but they're a terrible idea if anything you're interpolating came from an untrusted data source. Currently, requiring "shell=True" in the arguments to the subprocess calls is considered a sufficient deterrent against people doing the wrong thing. I'm suggesting that requiring "import shutil" instead of "import subprocess" may be a similarly acceptable compromise that better serves the system administrators that choose to use Python for system automation tasks. -- ___ Python tracker <http://bugs.python.org/issue13238> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13238] Add shell command helpers to shutil module
Nick Coghlan added the comment: Perhaps a better idea would be to use different names, so it's clearer at the point of invocation that the shell is being invoked (and hence shell injection attacks are a potential concern). For example: shell_call check_shell_call check_shell_output That would make large applications easier to audit (just search for 'shell_') while still making life easier for sysadmins. -- ___ Python tracker <http://bugs.python.org/issue13238> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13238] Add shell command helpers to shutil module
Nick Coghlan added the comment: Of the 3 available options (mod style, string.Template and str.format), yes, str.format is the best choice. If people want the shell meaning of the braces, they can escape them by doubling them up in the command string. -- ___ Python tracker <http://bugs.python.org/issue13238> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13238] Add shell command helpers to shutil module
Nick Coghlan added the comment: Initially, because I was suggesting the names shadow the subprocess convenience functions so they *had* to live in a different namespace. However, even after changing the names to explicitly include "shell", I'd like to keep them away from the general subprocess functionality - these wrappers are more convenient for shell operations than the subprocess ones, but it's that very convenience that makes them potentially dangerous in larger applications that may be interpolating data that untrusted users can manipulate. Since the intended audience is system administrators working on shell-like operations, the shell utility module seems like an appropriate place for them. Both the "import shutil" and the "shell" in the names would then serve as red flags on a code review or security audit. -- ___ Python tracker <http://bugs.python.org/issue13238> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13237] subprocess docs should emphasise convenience functions
Nick Coghlan added the comment: You couldn't just move them - you'd need to change the wording of how they cross-link to each other, since the explanations of the convenience function currently assume you understand how Popen works. I'd like us to get to the point where you only need to understand the whole Popen swiss army knife if you actually want that level of flexibility. -- ___ Python tracker <http://bugs.python.org/issue13237> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13238] Add shell command helpers to shutil module
Nick Coghlan added the comment:
It's a flow thing. This idea was kicked off by the process of translating a
large Perl script to Python and paying attention to what the translation made
*worse*.
One of the big things it made worse was the translation of "qx" (quoted
executable) strings. In Perl, those are almost as neat and tidy as if you were
writing directly in the shell:
qx|ls -l $dirname|
The thought process isn't "build this command and then execute it", it's "run
this shell command".
Yes, you have to be careful that "dirname" is legal in the shell, but that
usually isn't a big problem in practice, because dirname came from a previous
listdir call, or you otherwise know that it's valid to interpolate it into the
command (and if it isn't, then the bug lies in the way 'dirname' was populated,
not in this operation).
Now, Python's never going to have implicit string interpolation, and that's
fine - we have explicit interpolation instead. A direct translation of the
above to idiomatic Python 2.7 code looks like the following:
subprocess.check_output("ls -l {}".format(dirname), shell=True)
Now, if I'm doing system administration tasks (like the script I was
translating), then I'm going to be doing that kind of thing a *lot*. I'm also
likely to be a sysadmin rather than a programmer, so rather than going "Oh, I
can write a helper function for this", my natural reaction is going to be "I'm
going to use a language that doesn't get in my way so much".
This proposal is aimed directly at making Python a better language for systems
administration by making shell invocation almost as easy as it is in Perl:
shutil.check_shell_output("ls -l {}", dirname)
Heck, if someone really wanted to, they could even do:
qx = shutil.check_shell_output
qx("ls -l {}", dirname)
However, this is also why I *don't* want these methods in subprocess - they put
the burden on the user to think about their data as if they were writing shell
scripts, because that data is going to get passed straight to the shell for
execution without any additional escaping. That's a reasonable idea for a shell
utility in shutil, it's not reasonable for a general purpose subprocess
manipulation utility in subprocess.
--
___
Python tracker
<http://bugs.python.org/issue13238>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13238] Add shell command helpers to shutil module
Nick Coghlan added the comment:
That's a fair point, but I think it actually *improves* the argument for better
helper functions, since we can have them automatically invoke shlex.quote() on
all of the arguments:
def _shell_format(cmd, args, kwds):
args = map(shlex.quote, args)
kwds = {k:shlex.quote(v) for k, v in kwds}
return cmd.format(*args, **kwds)
def _invoke_shell(func, cmd, args, kwds):
return func(_shell_format(cmd, args, kwds), shell=True)
def format_shell_call(cmd, *args, kwds):
return _shell_format(cmd, args, kwds)
def shell_call(cmd, *args, **kwds):
return _invoke_shell(subprocess.call, cmds, args, kwds)
def check_shell_call(cmd, *args, **kwds):
return _invoke_shell(subprocess.check_call, cmds, args, kwds)
def check_shell_output(cmd, *args, **kwds):
return _invoke_shell(subprocess.check_output, cmds, args, kwds)
--
___
Python tracker
<http://bugs.python.org/issue13238>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13105] Please elaborate on how 2.x and 3.x are different heads
Nick Coghlan added the comment: The devguide actually did align with what I said in my email, but this wasn't clear if you only read the "Forward Porting" section (you had to read the "Porting Between Major Versions" section further down the page as well). I added a new paragraph to the forward porting section so it describes the whole policy, leaving the following two sections to cover the mechanics of actually handling that with Mercurial. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue13105> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294232] Error in metaclass search order
Nick Coghlan added the comment: Fix has been applied to 3.x and hence will be in 3.3 and the next 3.2 release. I have adjusted the issue metadata to reflect the fact 2,7 still exhibits the problem, but the patch requires significant work to account for the 3.x vs 2.x changes in class creation before it can be backported. -- components: -Documentation stage: patch review -> needs patch versions: -Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue1294232> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13252] new decumulate() function in itertools module
Nick Coghlan added the comment: OK, looking at the code I realised what you're trying to get at is the idea of reporting the differences between values in a series, such that: x = list(accumulate(seq)) assert x == list(accumulate(differences(x))) I don't think the use cases are there to justify the addition (not every iterator we can think of should be a building block in itertools), but if such a thing were to be added, "differences" would convey the intention significantly better than the invented term "decumulate". -- nosy: +ncoghlan ___ Python tracker <http://bugs.python.org/issue13252> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
