[issue18116] getpass.getpass() triggers ResourceWarning
Vajrasky Kok added the comment:
I isolate the bug. It happens in these lines:
# Always try reading and writing directly on the tty first.
fd = os.open('/dev/tty', os.O_RDWR|os.O_NOCTTY)
tty = os.fdopen(fd, 'w+', 1)
So to produce the bug more specifically, you can try this python file:
# bugme2.py
import os
fd = os.open('/dev/tty', os.O_RDWR|os.O_NOCTTY)
os.fdopen(fd, 'w+', 1)
# end of bugme2.py
In Linux Fedora 18, I would get this error:
/home/sky/Code/python/programming_language/cpython/Lib/os.py:1025:
ResourceWarning: unclosed file _io.FileIO name=3 mode='rb+'
return io.open(fd, *args, **kwargs)
Traceback (most recent call last):
File /tmp/bugme2.py, line 4, in module
os.fdopen(fd, 'w+', 1)
File /home/sky/Code/python/programming_language/cpython/Lib/os.py, line
1025, in fdopen
return io.open(fd, *args, **kwargs)
io.UnsupportedOperation: File or stream is not seekable.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18116
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18116] getpass.getpass() triggers ResourceWarning
Vajrasky Kok added the comment: I have investigated this problem and come up with the patch to fix the problem. This patch does the job. Caution: only for Python 3.4. But translating this patch to Python 3.3 should be straightforward. I hope this patch could be the foundation for better programmers to create better patch. Some of the issues with this patch are: I am not sure how to handle encoding and where the best place to close tty is. Reference: https://github.com/stefanholek/term/issues/1 http://stackoverflow.com/questions/5471158/typeerror-str-does-not-support-the-buffer-interface -- Added file: http://bugs.python.org/file30444/getpass_fix_resourcewarning.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18116] getpass.getpass() triggers ResourceWarning
Vajrasky Kok added the comment: Sorry, My previous patch breaks the test. This one should pass the test and fix the bug. Still, there are ugly code in the patch that I hope better programmers could fix. -- Added file: http://bugs.python.org/file30445/getpass_fix_resourcewarning_pass_the_test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18117] Missing symlink:Currnet after Mac OS X 3.3.2 package installation
New submission from Gavan Schneider:
There is a missing symlink.
Context:
Installed package:
http://www.python.org/ftp/python/3.3.2/python-3.3.2-macosx10.6.dmg
with no apparent problems onto a 'clean' system, i.e., no other python packages
other than OS X 10.8.3 defaults.
Found the following in /Library/Frameworks/Python.framework:
pendari:Python.framework postgres$ ls -las
total 24
0 drwxr-xr-x 3 root wheel 204 14 May 06:49 .
0 drwxr-xr-x 8 root wheel 374 2 Jun 17:06 ..
8 lrwxr-xr-x 1 root wheel 24 2 Jun 17:06 Headers -
Versions/Current/Headers
8 lrwxr-xr-x 1 root wheel 23 2 Jun 17:06 Python - Versions/Current/Python
8 lrwxr-xr-x 1 root wheel 26 2 Jun 17:06 Resources -
Versions/Current/Resources
0 drwxr-xr-x 3 root wheel 102 14 May 06:54 Versions
However:
pendari:Versions postgres$ ls -las
total 0
0 drwxr-xr-x 3 root wheel 102 14 May 06:54 .
0 drwxr-xr-x 3 root wheel 204 14 May 06:49 ..
0 drwxrwxr-x 7 root admin 306 14 May 06:54 3.3
Specifically we are missing the following from .../Versions:
8 lrwxr-xr-x 1 root wheel3 2 Jun 17:27 Current - 3.3
to make all the other symlinks work as intended.
This also implies the ~/.bash_profile patch would be improved if the existing:
PATH=/Library/Frameworks/Python.framework/Versions/3.3/bin:${PATH}
was replaced by:
PATH=/Library/Frameworks/Python.framework/Versions/Current/bin:${PATH}
Apologies if this has already been reported. It is my first report so I could
easily have missed something: I searched with terms installer mac.
Regards
Gavan Schneider
--
assignee: ronaldoussoren
components: Installation, Macintosh
messages: 190474
nosy: gavan, ronaldoussoren
priority: normal
severity: normal
status: open
title: Missing symlink:Currnet after Mac OS X 3.3.2 package installation
type: behavior
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18117
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18117] Missing symlink:Current after Mac OS X 3.3.2 package installation
Changes by Gavan Schneider pythonbug-...@snkmail.com: -- title: Missing symlink:Currnet after Mac OS X 3.3.2 package installation - Missing symlink:Current after Mac OS X 3.3.2 package installation ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18117 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16427] Faster hash implementation
Lukas Lueg added the comment: I was investigating a callgrind dump of my code, showing how badly unicode_hash() was affecting my performance. Using google's cityhash instead of the builtin algorithm to hash unicode objects improves overall performance by about 15 to 20 percent for my case - that is quite a thing. Valgrind shows that the number of instructions spent by unicode_hash() drops from ~20% to ~11%. Amdahl crunches the two-fold performance increase to the mentioned 15 percent. Cityhash was chosen because of it's MIT license and advertisement for performance on short strings. I've now found this bug and attached a log for haypo's benchmark which compares native vs. cityhash. Caching was disabled during the test. Cityhash was compiled using -O3 -msse4.2 (cityhash uses cpu-native crc instructions). CPython's unittests fail due to known_hash and gdb output; besides that, everything else seems to work fine. Cityhash is advertised for it's performance with short strings, which does not seem to show in the benchmark. However, longer strings perform *much* better. If people are insterested, i can repeat the test on a armv7l -- nosy: +ebfe Added file: http://bugs.python.org/file30446/cityhash.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16427 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16427] Faster hash implementation
Antoine Pitrou added the comment: I was investigating a callgrind dump of my code, showing how badly unicode_hash() was affecting my performance. Can you tell us about your use case? There are several CityHash variants, which one did you use? CityHash64? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16427 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18111] Add a default argument to min max
Raymond Hettinger added the comment: I'm -1 on expanding this API further. It already is pushing the limits with the dual signature and with the key-function. Many languages have min/max functions. AFAICT, none of them have an API with a default argument. This suggests that this isn't an essential capability. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16427] Faster hash implementation
Lukas Lueg added the comment: It's a cache sitting between an informix db and and an internal web service. Stuff comes out of db, processed, json'ifed, cached and put on the wire. 10**6s of strings pass this process per request if uncached... I use CityHash64WithSeed, the seed being cpython's hash prefix (which I don't care about but found reassuring to put in anyway) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16427 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18118] curses utf8 output broken
New submission from helmut: Consider the test case below. #!/usr/bin/python # -*- encoding: utf8 -*- import curses def wrapped(screen): screen.addstr(0, 0, ä) screen.addstr(0, 1, ö) screen.addstr(0, 2, ü) screen.getch() if __name__ == __main__: curses.wrapper(wrapped) Expected output: äöü Output on py3.3: as expected Output on py2.7.3: ?ü The actual bytes (as determined by strace) were \303\303\303\274. Observe the inclusion of broken utf8 sequences. This issue was initially discovered on Debian sid, but independently confirmed on Arch Linux and two more unknown. -- components: Library (Lib) messages: 190479 nosy: helmut priority: normal severity: normal status: open title: curses utf8 output broken type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18118 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18119] urllib.FancyURLopener does not treat URL fragments correctly
New submission from Shuhei Takahashi:
When urllib.FancyURLopener encounters 302 redirection to a URL with fragments,
it sends wrong URL to servers.
For example, if we run:
urllib.urlopen('http://example.com/foo')
and the server responds like following.
HTTP/1.1 302 Found
Location: /bar#test
Then urllib tries next to fetch http://example.com/bar#test, instead of
http://example.com/bar.
Correctly, urllib should strip fragment part of URL before issuing requests.
--
components: Library (Lib)
messages: 190480
nosy: takahashi.shuhei
priority: normal
severity: normal
status: open
title: urllib.FancyURLopener does not treat URL fragments correctly
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18119
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18111] Add a default argument to min max
R. David Murray added the comment: That's a good point about the __lt__. It occurred to me as well just before I read your post :). Raymond, do any other languages have an iterator protocol as a core language feature? It's the fact that it is in Python, and that it is not simple to LBYL when dealing with iterators, that brings this issue up for min and max. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18111] Add a default argument to min max
R. David Murray added the comment: Oh, and I don't think Haskell counts, since you'd expect them to stick strictly to the mathematical definition, with no consideration of practicality :) Note that I'm not saying I'm +1 on adding this (I haven't decided), I'm just trying to clarify the argument. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18118] curses utf8 output broken in Python2
R. David Murray added the comment: I believe this is one of a class of bugs that are fixed in Python3, and that are unlikely to be fixed in Python2. I'll defer to Victor, though, who made a number of curses unicode fixes in Python3. -- nosy: +haypo, r.david.murray title: curses utf8 output broken - curses utf8 output broken in Python2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18118 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18111] Add a default argument to min max
Stefan Krah added the comment: I'd use foldl() in functional languages, where the default is part of foldl() and not of max(). Translated to Python, I'm thinking of: it = iter([328, 28, 2989, 22]) functools.reduce(max, it, next(it, None)) 2989 I agree with Raymond that a default arg in max() looks out of place. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17998] internal error in regular expression engine
Matthias Klose added the comment: what's the status on this one? Can the proposed patch be applied until the decision whether to backout the original change, or not? -- nosy: +doko, georg.brandl, larry priority: normal - release blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17998] internal error in regular expression engine
Serhiy Storchaka added the comment: I'm working on tests. No need to rush. -- stage: patch review - test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17991] ctypes.c_char gives a misleading error when passed a one-character unicode string
Shriramana Sharma added the comment:
I came upon this too. In Python 2 it used to expect a one character string.
Apparently the same error message has been carried forward to Python 3 too,
though now the actual expected input is either a one character bytes type and
not a str type, or an int corresponding to the ord() value of that char.
Minimal demonstration:
$ python
Python 2.7.4 (default, Apr 19 2013, 18:28:01)
[GCC 4.7.3] on linux2
Type help, copyright, credits or license for more information.
from ctypes import *
class test ( Structure ) :
... _fields_ = [ ( ch, c_char ) ]
...
a = test()
a.ch = ord('a')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: one character string expected
a.ch = 'c'
a.ch
'c'
$ python3
Python 3.3.1 (default, Apr 17 2013, 22:30:32)
[GCC 4.7.3] on linux
Type help, copyright, credits or license for more information.
from ctypes import *
class test ( Structure ) :
... _fields_ = [ ( ch, c_char ) ]
...
a = test()
a.ch = 'c'
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: one character string expected
a.ch = b'c'
a.ch
b'c'
a.ch = ord('c')
a.ch
b'c'
--
nosy: +jamadagni
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17991
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16427] Faster hash implementation
Lukas Lueg added the comment: Here are some benchmarks for a arm7l on a rk30-board. CityHash was compiled with -mcpu=native -O3. CityHash is around half as fast as the native algorithm for small strings and way, way slower on larger ones. My guess would be that the complex arithmetic in cityhash outweights the gains of better scheduling. The results are somewhat inconclusive, as the performance increases again for very long strings. -- Added file: http://bugs.python.org/file30447/cityhash_arm.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16427 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16427] Faster hash implementation
Antoine Pitrou added the comment: Here are some benchmarks for a arm7l on a rk30-board. CityHash was compiled with -mcpu=native -O3. The results look unbelievable. If you take Length 10 ** 4, it means arm7l is able to hash 20 GB/s using the default unicode hash function. (did you disable caching?) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16427 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18117] Missing symlink:Current after Mac OS X 3.3.2 package installation
Ned Deily added the comment: That behavior of the OS X installer is by design. Currently, the Current link is only set for Python 2 installations, not Python 3 ones. While that may have made sense in the early days of Python 3 (assuming there would be mixed installations of both Python 3 and Python 2 to the same framework), that is probably no longer a good idea. Considering the difference between Python 2 and 3 at the API level and that one of the reasons for installing as a framework should be to simplify linking with Python libraries, I've been thinking that it might be a good idea to have Python 3 install in its own framework, say Python3. Or some other arrangement. As it stands today, 'cc ... -framework Python ...' isn't usable for Python 3 out of the box. -- nosy: +ned.deily versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18117 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16427] Faster hash implementation
Lukas Lueg added the comment: The 10**4-case is an error (see insane %), I've never been able to reproduce. Having done more tests with fixed cpu frequency and other daemons' process priority reduced, cityhash always comes out much slower on arm7l. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16427 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18120] multiprocessing: garbage collector fails to GC Pipe() end when spawning child process
New submission from spresse1: [Code demonstrating issue attached] When overloading multiprocessing.Process and using pipes, a reference to a pipe spawned in the parent is not properly garbage collected in the child. This causes the write end of the pipe to be held open with no reference to it in the child process, and therefore no way to close it. Therefore, it can never throw EOFError. Expected behavior: 1. Create a pipe with multiprocessing.Pipe(False) 2. Pass read end to a class which subclasses multiprocessing.Process 3. Close write end in parent process 4. Receive EOFError from read end Actual behavior: 1. Create a pipe with multiprocessing.Pipe(False) 2. Pass read end to a class which subclasses multiprocessing.Process 3. Close write end in parent process 4. Never receive EOFError from read end Examining the processes in /proc/[pid]/fds/ indicates that a write pipe is still open in the child process, though none should be. Additionally, no write pipe is open in the parent process. It is my belief that this is the write pipe spawned in the parent, and is remaining around incorrectly in the child, though there are no references to it. Tested on 2.7.3 and 3.2.3 -- components: Library (Lib) files: bugon.tar.gz messages: 190492 nosy: spresse1 priority: normal severity: normal status: open title: multiprocessing: garbage collector fails to GC Pipe() end when spawning child process versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file30448/bugon.tar.gz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18120] multiprocessing: garbage collector fails to GC Pipe() end when spawning child process
Changes by Matthias Lee matthias.a@gmail.com: -- nosy: +madmaze ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18120] multiprocessing: garbage collector fails to GC Pipe() end when spawning child process
spresse1 added the comment: Now also tested with source-built python 3.3.2. Issue still exists, same example files. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18121] antigravity leaks subprocess.Popen object
New submission from Christian Heimes: $ ./python Python 3.4.0a0 (default:801567d6302c+, May 23 2013, 14:22:00) [GCC 4.7.2] on linux Type help, copyright, credits or license for more information. import gc gc.set_debug(gc.DEBUG_UNCOLLECTABLE) import antigravity Fontconfig warning: /etc/fonts/conf.d/50-user.conf, line 9: reading configurations from ~/.fonts.conf is deprecated. gc: uncollectable Popen 0x7faa2e37bd58 gc: uncollectable dict 0x7faa2f535f38 gc: uncollectable type 0x26e3198 gc: uncollectable list 0x7faa2e36c138 gc: uncollectable dict 0x7faa2e366f38 gc: uncollectable tuple 0x7faa2e3699f8 gc: uncollectable function 0x7faa2e36ee00 gc: uncollectable function 0x7faa2e382a68 gc: uncollectable function 0x7faa2e382280 gc: uncollectable function 0x7faa2e3821c8 gc: uncollectable function 0x7faa2e382618 gc: uncollectable getset_descriptor 0x7faa2e37d1c0 gc: uncollectable function 0x7faa2e36eeb8 gc: uncollectable function 0x7faa2e382840 gc: uncollectable function 0x7faa2e382bd8 gc: uncollectable getset_descriptor 0x7faa2e37d2b0 gc: uncollectable function 0x7faa2e36ed48 gc: uncollectable function 0x7faa2e382b20 gc: uncollectable function 0x7faa2e382c90 gc: uncollectable function 0x7faa2e3823f0 gc: uncollectable function 0x7faa2e382110 gc: uncollectable function 0x7faa2e3824a8 gc: uncollectable function 0x7faa2e3826d0 gc: uncollectable function 0x7faa2e36ef70 gc: uncollectable function 0x7faa2e382058 gc: uncollectable function 0x7faa2e382788 gc: uncollectable function 0x7faa2e3829b0 gc: uncollectable function 0x7faa2e382e00 gc: uncollectable function 0x7faa2e3828f8 gc: uncollectable function 0x7faa2e382d48 gc: uncollectable function 0x7faa2e382560 gc: uncollectable function 0x7faa2e382338 gc: uncollectable dict 0x7faa2e35bf38 gc: uncollectable tuple 0x7faa2e37fed8 gc: uncollectable tuple 0x7faa2e369b48 gc: uncollectable tuple 0x7faa2e37fe58 gc: uncollectable list 0x7faa2e366138 gc:0: ResourceWarning: gc: 1 uncollectable objects at shutdown [subprocess.Popen object at 0x7faa2e37bd58] platform: Ubuntu 12.10 AMD64 browser: Firefox 20.0 -- components: Library (Lib) messages: 190494 nosy: christian.heimes, pitrou priority: low severity: normal status: open title: antigravity leaks subprocess.Popen object type: resource usage versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18121 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17967] urllib2.open failed to access a url when a perent directory of the url is permission denied
Roundup Robot added the comment: New changeset e9d0fb934b46 by Senthil Kumaran in branch '2.7': Fix #17967 - Fix related to regression on Windows. http://hg.python.org/cpython/rev/e9d0fb934b46 New changeset f5906026a7e9 by Senthil Kumaran in branch '3.3': Fix #17967 - Fix related to regression on Windows. http://hg.python.org/cpython/rev/f5906026a7e9 New changeset adfec512fb32 by Senthil Kumaran in branch 'default': merge from 3.3 http://hg.python.org/cpython/rev/adfec512fb32 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17967 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17967] urllib2.open failed to access a url when a perent directory of the url is permission denied
Changes by Senthil Kumaran sent...@uthcode.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17967 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18120] multiprocessing: garbage collector fails to GC Pipe() end when spawning child process
Richard Oudkerk added the comment: The way to deal with this is to pass the write end of the pipe to the child process so that the child process can explicitly close it -- there is no reason to expect garbage collection to make this happen automatically. You don't explain the difference between functional.py and nonfunctional.py. The most obvious thing is the fact that nonfunctional.py seems to have messed up indentation: you have a while loop in the class declaration instead of in the run() method. -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18120] multiprocessing: garbage collector fails to GC Pipe() end when spawning child process
spresse1 added the comment: The difference is that nonfunctional.py does not pass the write end of the parent's pipe to the child. functional.py does, and closes it immediately after breaking into a new process. This is what you mentioned to me as a workaround. Corrected code (for indentation) attached. Why SHOULDN'T I expect this pipe to be closed automatically in the child? Per the documentation for multiprocessing.Connection.close(): This is called automatically when the connection is garbage collected. The write end of that pipe goes out of scope and has no references in the child thread. Therefore, per my understanding, it should be garbage collected (in the child thread). Where am I wrong about this? -- Added file: http://bugs.python.org/file30449/bugon.tar.gz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18122] RuntimeError: not holding the import lock
New submission from Armin Rigo: A new bug, introduced in recent Python 2.7 (2.7.3 passes, 2.7 trunk fails): With the attached x.py, running python -c 'import x' fails with RuntimeError: not holding the import lock. It occurs when doing a fork() while holding the import lock, if the child process imports more things (here distutils, could be anything) before finally trying to release the import lock (here by returning from the original 'import x'). -- files: x.py messages: 190498 nosy: arigo priority: normal severity: normal status: open title: RuntimeError: not holding the import lock versions: Python 2.7 Added file: http://bugs.python.org/file30450/x.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18122 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18123] fnmatchicase for case insensitive file search
New submission from anatoly techtonik: http://docs.python.org/2/library/glob.html and http://docs.python.org/2/library/fnmatch.html both lack ability to do case-insensitive search for filenames. Due to this difference, scripts that work ok on Windows start produce surprises on Linux. -- messages: 190499 nosy: techtonik priority: normal severity: normal status: open title: fnmatchicase for case insensitive file search versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18123 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18118] curses utf8 output broken in Python2
STINNER Victor added the comment: Is your Python curses module linked to libncurses.so.5 or libncursesw.so.5? Example: $ ldd /usr/lib/python2.7/lib-dynload/_cursesmodule.so |grep curses libncursesw.so.5 = /lib/libncursesw.so.5 (0x00375000) libncursesw has a much better support of Unicode than libncurses. Since Python 3.3, the Python curses.window.addstr() method uses waddwstr() when the module is linked to libncursesw, which also improves the Unicode support. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18118 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18118] curses utf8 output broken in Python2
helmut added the comment: All reproducers confirmed that their _cursessomething.so is linked against libncursesw.so.5. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18118 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18122] RuntimeError: not holding the import lock
Changes by Amaury Forgeot d'Arc amaur...@gmail.com: -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18122 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18120] multiprocessing: garbage collector fails to GC Pipe() end when spawning child process
Richard Oudkerk added the comment: The write end of that pipe goes out of scope and has no references in the child thread. Therefore, per my understanding, it should be garbage collected (in the child thread). Where am I wrong about this? The function which starts the child process by (indirectly) invoking os.fork() never gets a chance to finish in the child process, so nothing goes out of scope. Anyway, relying on garbage collection to close resources for you is always a bit dodgy. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18118] curses utf8 output broken in Python2
STINNER Victor added the comment: uäöü encoded to utf-8 gives '\xc3\xa4\xc3\xb6\xc3\xbc' \303\303\303\274 is '\xc3\xc3\xc3\xbc'. I guess that curses considers that '\xc3\xa4' is a string of 2 characters: screen.addstr(0, 1, ö) replaces the second character, '\xa4'. I suppose that screen.addstr(0, 0, uäöü.encode(utf-8)) works. If _cursessomething.so is already linked against libncursesw.so.5, the fix is to use waddwstr(), but such change cannot be done in a minor release like Python 2.7.6. So I'm closing this issue as wont fix = you have to move to Python 3.3. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18118 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18120] multiprocessing: garbage collector fails to GC Pipe() end when spawning child process
spresse1 added the comment: So you're telling me that when I spawn a new child process, I have to deal with the entirety of my parent process's memory staying around forever? I would have expected this to call to fork(), which gives the child plenty of chance to clean up, then call exec() which loads the new executable. Either that or the same instance of the python interpreter is used, just with the knowledge that it should execute the child function and then exit. Keeping all the state that will never be used in the second case seems sloppy on the part of python. The semantics in this case are much better if the pipe gets GC'd. I see no reason my child process should have to know about pipe ends it never uses in order to close them. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18117] Missing symlink:Current after Mac OS X 3.3.2 package installation
Gavan Schneider added the comment: Appreciate the comment about potential problems with mixed installations of python3 and python2. And note that along these lines there is no attempt by the installer to symlink python - python3 (which could have nasty side effects if the full path was not specified in system applications). However there is still a problem: the installer is creating three dead symlinks, which is not correct. Agree putting Python3 into its own /Library/Frameworks/Python3.framework would be a better way to go. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18117 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18120] multiprocessing: garbage collector fails to GC Pipe() end when spawning child process
Richard Oudkerk added the comment: So you're telling me that when I spawn a new child process, I have to deal with the entirety of my parent process's memory staying around forever? With a copy-on-write implementation of fork() this quite likely to use less memory than starting a fresh process for the child process. And it is certainly much faster. I would have expected this to call to fork(), which gives the child plenty of chance to clean up, then call exec() which loads the new executable. There is an experimental branch (http://hg.python.org/sandbox/sbt) which optionally behaves like that. Note that clean up means close all fds not explcitly passed, and has nothing to do with garbage collection. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18123] fnmatchicase for case insensitive file search
Changes by Giampaolo Rodola' g.rod...@gmail.com: -- nosy: +giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18123 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18121] antigravity leaks subprocess.Popen object
Richard Oudkerk added the comment: Presumably this is caused by the fact that Popen.__del__() ressurects self by appending self to _active if the process is still alive. On Windows this is unnecessary. On Unix it would be more sensible to just append the *pid* to _active. -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18121 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18121] antigravity leaks subprocess.Popen object
R. David Murray added the comment: See also issue 5993. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18121 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18120] multiprocessing: garbage collector fails to GC Pipe() end when spawning child process
spresse1 added the comment: So you're telling me that when I spawn a new child process, I have to deal with the entirety of my parent process's memory staying around forever? With a copy-on-write implementation of fork() this quite likely to use less memory than starting a fresh process for the child process. And it is certainly much faster. Fair enough. I would have expected this to call to fork(), which gives the child plenty of chance to clean up, then call exec() which loads the new executable. There is an experimental branch (http://hg.python.org/sandbox/sbt) which optionally behaves like that. Note that clean up means close all fds not explcitly passed, and has nothing to do with garbage collection. I appreciate the pointer, but I am writing code intended for distribution - using an experimental branch isn't useful. What I'm still trying to grasp is why Python explicitly leaves the parent processes info around in the child. It seems like there is no benefit (besides, perhaps, speed) and that this choice leads to non-intuitive behavior - like this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18123] fnmatchicase for case insensitive file search
anatoly techtonik added the comment: https://gist.github.com/techtonik/5694830 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18123 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18120] multiprocessing: garbage collector fails to GC Pipe() end when spawning child process
Richard Oudkerk added the comment: What I'm still trying to grasp is why Python explicitly leaves the parent processes info around in the child. It seems like there is no benefit (besides, perhaps, speed) and that this choice leads to non-intuitive behavior - like this. The Windows implementation does not use fork() but still exhibits the same behaviour in this respect (except in the experimental branch mentioned before). The real issue is that fds/handles will get inherited by the child process unless you explicitly close them. (Actually on Windows you need to find a way to inject specific handles from the parent to child process). The behaviour you call non-intuitive is natural to someone used to using fork() and pipes on Unix. multiprocessing really started as a cross-platform work-around for the lack of fork() on Windows. Using fork() is also a lot more flexible: many things that work fine on Unix will not work correctly on Windows because of pickle-issues. The main problem with fork() is that forking a process with multiple threads can be problematic. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18120] multiprocessing: garbage collector fails to GC Pipe() end when spawning child process
spresse1 added the comment: I'm actually a nix programmer by trade, so I'm pretty familiar with that behavior =p However, I'm also used to inheriting some way to refer to these fds, so that I can close them. Perhaps I've just missed somewhere a call to ask the process for a list of open fds? This would, to me, be an acceptable workaround - I could close all the fds I didn't wish to inherit. Whats really bugging me is that it remains open and I can't fetch a reference. If I could do either of these, I'd be happy. Maybe this is more an issue with the semantics of multiprocessing? In that this behavior is perfectly reasonable with os.fork() but makes some difficulty here. Perhaps I really want to be implementing with os.fork(). Sigh, I was trying to save myself some effort... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18120 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2053] IDLE - standardize dialogs
Terry J. Reedy added the comment: The patch does two things. 1. It replaces the existing direct rebinding of messagebox functions as methods, such as self.showerror = tkMessageBox.showerror with binding of a double wrapping of the functions. The middle layer is useless and only serves to allow use of the decorator syntax. The 'old-fashioned' method of wrapping by function call should be used. self.showerror = _tk_dialog_wrapper(tkMessageBox.showerror) A single customized wrapping for the existing bindings seems like it might be a good idea. I do not understand the 'motivation' (of the existing and revised method bindings) of making Idle extensions 'cross-IDE'. How so? What IDEs other than Idle are we concerned with? The patch replaces both parent=self.text and master=self.text in current calls with parent=self.text in the wrapper. This seems to assume that parent==master in these contexts. I gather that this is nearly always the case. ( http://mail.python.org/pipermail/tutor/2010-June/076550.html based on Grayson's book) But I wonder if the choice could ever make a difference. 2. Currently, EditorWindow methods sometimes call a message function as a message module attribute and sometimes as one of the EditorWindow method. The patch makes these calls consistently be methods calls (to the wrappers). It also changes call in classes that are EditorWindow subclasses or containers. (askokcancel is addded to EditorWindow for patches to some of these other classes.) My current Idle concern is testing. The current inconsistency in EditorWindow is not good for that, so I will want to fix that one way or the other in any case. For automated non-gui testing, the message functions (or the message module) need to be replaced with mocks that a) save the args somewhere where they can be later retrieved and b) return without graphics system and user interaction. For modules with non-editor classes, this means monkey-patching the module. (I have done this once for one test.) I will experiment with also monkey-patching editor windows. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2053 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18111] Add a default argument to min max
Raymond Hettinger added the comment: Thanks Stephan. I'm going to close this one. The case for adding it is too weak and isn't worth making the API more complex. If someone wants a default with an iterable of arbitrary size including zero, there are already a number of ways to do it (using itertools.chain for example or just catching the exception). -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18111] Add a default argument to min max
Julian Berman added the comment: I don't really care to push this much harder, but I'll just repeat that I've already made an argument against catching the exception. Calling this making the API too complex also seems quite silly to me. It's a thing that someone looking for would find and someone who wasn't wouldn't. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18111 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18124] Broken build on target machine with incorrect hostname (non-ascii)
New submission from Dmi Baranov: As a part of issue #18109 $ echo hât | sudo tee /proc/sys/kernel/hostname $ hostname #Yes, I know about RFC952;-) hât $ locale LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_MESSAGES=POSIX LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 LC_ALL= $ make ... Consider setting $PYTHONHOME to prefix[:exec_prefix] Traceback (most recent call last): File /home/d9frog9n/workspace/cpython_default/Lib/runpy.py, line 160, in _run_module_as_main __main__, fname, loader, pkg_name) File /home/d9frog9n/workspace/cpython_default/Lib/runpy.py, line 73, in _run_code exec(code, run_globals) File /home/d9frog9n/workspace/cpython_default/Lib/sysconfig.py, line 700, in module _main() File /home/d9frog9n/workspace/cpython_default/Lib/sysconfig.py, line 688, in _main _generate_posix_vars() File /home/d9frog9n/workspace/cpython_default/Lib/sysconfig.py, line 391, in _generate_posix_vars pybuilddir = 'build/lib.%s-%s' % (get_platform(), sys.version[:3]) File /home/d9frog9n/workspace/cpython_default/Lib/sysconfig.py, line 632, in get_platform osname, host, release, version, machine = os.uname() UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128) make: *** [pybuilddir.txt] Error 1 -- components: Installation, Unicode messages: 190516 nosy: dmi.baranov, ezio.melotti priority: normal severity: normal status: open title: Broken build on target machine with incorrect hostname (non-ascii) type: compile error versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18124 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18109] os.uname() crashes if hostname contains non-ascii characters
Dmi Baranov added the comment:
Thanks Charles - I'm reproduced Dominik's issue at default branch:
$ python -c 'import os, sys;print(sys.version);print(os.uname())'
3.4.0a0 (default:adfec512fb32, Jun 3 2013, 08:09:43)
[GCC 4.6.3]
Traceback (most recent call last):
File string, line 1, in module
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal
not in range(128)
Lastest branches affected only, so - this a bug.
$ python -c 'import os, sys;print(sys.version);print(os.uname())'
2.7.5+ (2.7:e9d0fb934b46, Jun 3 2013, 08:05:55)
[GCC 4.6.3]
('Linux', 'h\xc3\xa2t', '3.2.0-32-generic', '#51-Ubuntu SMP Wed Sep 26 21:32:50
UTC 2012', 'i686')
$ python -c 'import os, sys;print(sys.version);print(os.uname())'
3.2.5 (3.2:b9b521efeba3, Jun 3 2013, 08:24:06)
[GCC 4.6.3]
('Linux', 'hât', '3.2.0-32-generic', '#51-Ubuntu SMP Wed Sep 26 21:32:50 UTC
2012', 'i686')
Env:
$ hostname
hât
$ locale
LANG=en_US.UTF-8
...
BTW, that issue do not allow to compile from sources on hosts with similar
names, I've created separate issue #18124 (possible a duplicate, but another
behavior)
--
components: +Library (Lib)
type: crash - behavior
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18109
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18122] RuntimeError: not holding the import lock
Dmi Baranov added the comment: Looks like old history from issue 7242 -- nosy: +dmi.baranov, gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18122 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
