[issue5712] tkinter - askopenfilenames returns string instead of tuple in windows 2.6.1 release
Clovis Fabricio nosklo+pyt...@gmail.com added the comment: UGH! Sorry for that, I mispasted something and didn't notice, since it filled the comment entry box perfectly :( This is the real message I meant to paste: vijay, The workaround I provided above takes the blank spaces in filepaths you mention into account and splits the paths correctly in all situations I can think of. I'm using it in production now for over an year, and had no issues at all. Perhaps you can provide an example of path that would break the code, so it can be fixed. thanks in advance Clovis -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5712 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8638] Remove suggestion for name mangling from the tutorial
Clovis Fabricio nosklo+pyt...@gmail.com added the comment: I help in #python and always suggest people to not use double-underscore name mangling when they mean private. I agree that name mangling shouldn't be on the tutorial at all. It misleads everybody coming from other languages into thinking that it means private like it does in java or C++. -- nosy: +nosklo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8638 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5712] tkinter - askopenfilenames returns string instead of tuple in windows 2.6.1 release
Changes by Clovis Fabricio nosklo+pyt...@gmail.com: -- versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5712 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5712] tkinter - askopenfilenames returns string instead of tuple in windows 2.6.1 release
Clovis Fabricio nosklo+pyt...@gmail.com added the comment: I've written a quick workaround for the issue, where I manually split the filenames and always return a tuple. It might be useful to someone experiencing this problem, so I'm adding it to the issue here. -- nosy: +nosklo Added file: http://bugs.python.org/file16041/issue5712_workaround.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5712 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7448] when piping output between subprocesses some fd is left open blocking forever
New submission from Clovis Fabricio nosklo+pyt...@gmail.com:
Suppose I want to simulate the following shell pipe using the subprocess
module:
`grep -v not | cut -c 1-10`
The documentation example here
http://docs.python.org/library/subprocess.html#replacing-shell-pipeline
Implies that I want to run this:
grep_process = Popen([grep, -v, not], stdin=PIPE, stdout=PIPE)
cut_process = Popen([cut, -c, 1-10], stdin=p1.stdout, stdout=PIPE)
grep_process.stdin.write('Hello World\n')
grep_process.stdin.close()
result = cut_process.stdout.read() # blocks forever here
assert result == Hello Worl\n
When grep_prcoess starts, two file descriptors are created, one
for each end of the pipe. Lets call those `grep-stdin-w` and
`grep-stdout-r`.
When I run cut_process, `grep-stdout-r` gets passed as cut_process sdtin.
Since `close_fds=False` by default, The effect of that is that
cut_process also
inherits `grep-stdin-w`. So `grep` can't die even if I explicty run
`grep_process.stdin.close()`
because `grep-stdin-w` stdin is still inside cut_process (`cut` ignores
the extra open fd).
Passing `close_fds=True` to the second Popen call makes the code work
perfectly.
`close_fds=True` should be the default on unix systems, because it
closes files descriptors that have nothing to do with the process, leaving
stdin, stdout and stderr working, which is the intended behaviour of
most code.
--
components: Library (Lib)
messages: 96032
nosy: nosklo
severity: normal
status: open
title: when piping output between subprocesses some fd is left open blocking
forever
type: behavior
versions: Python 2.7, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7448
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3839] wsgi.simple_server resets 'Content-Length' header on empty content even if app defined it.
New submission from Clovis Fabricio [EMAIL PROTECTED]: The finish_content method in wsgiref.handlers.BaseHandler class resets Content-Length to 0 if there was no content returned by the application, even if the application has set it already. That makes impossible to implement things like HEAD requests in the application, which should return the Content-Length without returning actual content. The desired behavior would be to respect the header set by the wsgi application, using 0 as a default value instead. -- components: Library (Lib) files: wsgiref.handlers.py.patch keywords: patch messages: 73045 nosy: nosklo severity: normal status: open title: wsgi.simple_server resets 'Content-Length' header on empty content even if app defined it. type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file11466/wsgiref.handlers.py.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
