Re: [Python-Dev] cpython (2.7): Issue #17508: Handled out-of-order handler configuration correctly.
Antoine Pitrou pitrou.net> writes: >> Issue #17508: Handled out-of-order handler configuration correctly. > Could you explain what "out-of-order handler configuration" means? In logging, a MemoryHandler buffers records and has a reference to another handler - the "target" - which does the actual output of the buffered records. It can happen when using dictConfig() that the MemoryHandler is configured before the target handler, and in this case the reference to the target wasn't set up correctly. The commit rectifies this. > Also, could you add a Misc/NEWS entry for the change / bugfix? Ok, will do. Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (venv) - why does it copy the DLLs on Windows
On 23 March 2013 01:08, Vinay Sajip wrote: > Paul Moore gmail.com> writes: > >> I don't understand what this is saying - can someone clarify the >> reason behind this statement? What is different about a >> "non-system-wide installation" that causes this issue (I assume >> "non-system-wide" means "not All Users")? The reason I ask is that >> virtualenv doesn't do this, and I'm not clear if this is because of a >> potential bug lurking in virtualenv (in which case, I'd like to find >> out how to reproduce it) or because virtualenv takes a different >> approach which avoids this issue somehow. > > One example of a non-system-wide installation is a source build of Python. > PEP 405 venvs created from a source build should work in the same way as venvs > created using an installed Python. Thanks. I hadn't thought of that case. However, I'm still not entirely clear *why* the DLLs need to be copied. I'll set up a source build and test virtualenv against it to see if it fails. Assuming it does, I should be able to work out what the issue is from that. Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Are undocumented exceptions considered bugs?
Hi,
I'm not sure this is the right place to ask this question, but I thought
I'd give it a shot since it also concerns the Python standard library.
I'm writing an automated test case generation tool for Python programs that
explores all possible execution paths through a program. When applying this
tool on Python's 2.7.3 urllib package, it discovered input strings for
which the urllib.urlopen(url) call would raise a TypeError. For instance:
urllib.urlopen('\x00\x00\x00')
[...]
File "/home/bucur/onion/python-bin/lib/python2.7/urllib.py", line 86, in
urlopen
return opener.open(url)
File "/home/bucur/onion/python-bin/lib/python2.7/urllib.py", line 207, in
open
return getattr(self, name)(url)
File "/home/bucur/onion/python-bin/lib/python2.7/urllib.py", line 462, in
open_file
return self.open_local_file(url)
File "/home/bucur/onion/python-bin/lib/python2.7/urllib.py", line 474, in
open_local_file
stats = os.stat(localname)
TypeError: must be encoded string without NULL bytes, not str
In the urllib documentation it is only mentioned that the IOError is raised
when the connection cannot be established. Since the input passed is a
string (and not some other type), is the TypeError considered a bug (either
in the documentation, or in the implementation)?
Thanks a lot,
Stefan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (venv) - why does it copy the DLLs on Windows
On 23/03/2013 10:06am, Paul Moore wrote: One example of a non-system-wide installation is a source build of Python. PEP 405 venvs created from a source build should work in the same way as venvs created using an installed Python. Thanks. I hadn't thought of that case. However, I'm still not entirely clear *why* the DLLs need to be copied. I'll set up a source build and test virtualenv against it to see if it fails. Assuming it does, I should be able to work out what the issue is from that. Also, couldn't hard links be used instead of copying? (This will fail if not on the same NTFS partition, but then one can copy as a fallback.) -- Richard ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (venv) - why does it copy the DLLs on Windows
On Sat, 23 Mar 2013 12:57:02 + Richard Oudkerk wrote: > On 23/03/2013 10:06am, Paul Moore wrote: > >> One example of a non-system-wide installation is a source build of Python. > >> PEP 405 venvs created from a source build should work in the same way as > >> venvs > >> created using an installed Python. > > > > Thanks. I hadn't thought of that case. However, I'm still not entirely > > clear *why* the DLLs need to be copied. I'll set up a source build and > > test virtualenv against it to see if it fails. Assuming it does, I > > should be able to work out what the issue is from that. > > Also, couldn't hard links be used instead of copying? (This will fail > if not on the same NTFS partition, but then one can copy as a fallback.) Hard links are generally hard to discover and debug (at least under Unix, but I suppose the same applies under Windows). Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (venv) - why does it copy the DLLs on Windows
On 23 March 2013 12:55, Antoine Pitrou wrote: > On Sat, 23 Mar 2013 12:57:02 + > Richard Oudkerk wrote: > >> On 23/03/2013 10:06am, Paul Moore wrote: >> >> One example of a non-system-wide installation is a source build of Python. >> >> PEP 405 venvs created from a source build should work in the same way as >> >> venvs >> >> created using an installed Python. >> > >> > Thanks. I hadn't thought of that case. However, I'm still not entirely >> > clear *why* the DLLs need to be copied. I'll set up a source build and >> > test virtualenv against it to see if it fails. Assuming it does, I >> > should be able to work out what the issue is from that. >> >> Also, couldn't hard links be used instead of copying? (This will fail >> if not on the same NTFS partition, but then one can copy as a fallback.) > > Hard links are generally hard to discover and debug (at least under > Unix, but I suppose the same applies under Windows). Yes. And links in general are less common, and so more of a surprise, on Windows as well. Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Are undocumented exceptions considered bugs?
On Sat, Mar 23, 2013 at 4:05 AM, Stefan Bucur wrote:
> Hi,
>
> I'm not sure this is the right place to ask this question, but I thought I'd
> give it a shot since it also concerns the Python standard library.
It's the right place to ask :)
> I'm writing an automated test case generation tool for Python programs that
> explores all possible execution paths through a program. When applying this
> tool on Python's 2.7.3 urllib package, it discovered input strings for which
> the urllib.urlopen(url) call would raise a TypeError.
That sounds like a really interesting tool.
> For instance:
>
> urllib.urlopen('\x00\x00\x00')
>
> [...]
> File "/home/bucur/onion/python-bin/lib/python2.7/urllib.py", line 86, in
> urlopen
> return opener.open(url)
> File "/home/bucur/onion/python-bin/lib/python2.7/urllib.py", line 207, in
> open
> return getattr(self, name)(url)
> File "/home/bucur/onion/python-bin/lib/python2.7/urllib.py", line 462, in
> open_file
> return self.open_local_file(url)
> File "/home/bucur/onion/python-bin/lib/python2.7/urllib.py", line 474, in
> open_local_file
> stats = os.stat(localname)
> TypeError: must be encoded string without NULL bytes, not str
>
> In the urllib documentation it is only mentioned that the IOError is raised
> when the connection cannot be established. Since the input passed is a
> string (and not some other type), is the TypeError considered a bug (either
> in the documentation, or in the implementation)?
The general answer is that there are certain exceptions that usually
aren't documented because almost all code can trigger them if you pass
the right kind of invalid argument. For example, almost any API can
emit TypeError or AttributeError if you pass an instance of the wrong
type, and many can emit ValueError, IndexError or KeyError if you pass
an incorrect value. Other errors like SyntaxError, ImportError,
NameError and UnboundLocalError usually indicate bugs or environmental
configuration issues, so are also typically omitted when documenting
the possible exceptions for particular APIs.
In this specific case, the error message is
confusing-but-not-really-wrong, due to the "two-types-in-one" nature
of Python 2.x strings - 8-bit strings are used as both text sequences
(generally not containing NUL characters) and also as arbitrary binary
data, including encoded text (quite likely to contain NUL bytes).
I think a bug report for this would be appropriate, with the aim of
making that error message less confusing (it's a fairly obscure case,
though).
Regards,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] wsgi validator with asynchronous handlers/servers
Hi, I have an asynchronous wsgi application handler which yields empty bytes before it is ready to yield the response body and, importantly, to call start_response. Something like this: def wsgi_handler(environ, start_response): body = generate_body(environ) body = maybe_async(body) while is_async(body): yield b'' start_response(...) ... I started using wsgiref.validator recently, nice little gem in the standard lib, and I discovered that the above handler does not validate! Disaster. Reading pep "the application *must* invoke the start_response() callable before the iterable yields its first body bytestring, so that the server can send the headers before any body content. However, this invocation *may* be performed by the iterable's first iteration, so servers *must not* assume that start_response() has been called before they begin iterating over the iterable." The pseudocode above does yields bytes before start_response, but they are not *body* bytes, they are empty bytes so that the asynchronous wsgi server releases the eventloop and call back at the next eventloop iteration. I'm I misinterpreting the pep, or the wsgi validator should be fixed accordingly? Regards, Luca ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] wsgi validator with asynchronous handlers/servers
Hi, The people who best understand WSGI are to be found on the Web-SIG: http://mail.python.org/mailman/listinfo/web-sig 2013/3/23 Luca Sbardella : > Hi, > > I have an asynchronous wsgi application handler which yields empty bytes > before it is ready to yield the response body and, importantly, to call > start_response. > > Something like this: > > def wsgi_handler(environ, start_response): > body = generate_body(environ) > body = maybe_async(body) > while is_async(body): > yield b'' > start_response(...) > ... > > I started using wsgiref.validator recently, nice little gem in the standard > lib, and I discovered that the above handler does not validate! Disaster. > Reading pep > > "the application must invoke the start_response() callable before the > iterable yields its first body bytestring, so that the server can send the > headers before any body content. However, this invocation may be performed > by the iterable's first iteration, so servers must not assume that > start_response() has been called before they begin iterating over the > iterable." > > The pseudocode above does yields bytes before start_response, but they are > not *body* bytes, they are empty bytes so that the asynchronous wsgi server > releases the eventloop and call back at the next eventloop iteration. > > I'm I misinterpreting the pep, or the wsgi validator should be fixed > accordingly? > > Regards, > Luca > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/benjamin%40python.org > -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (venv) - why does it copy the DLLs on Windows
On 23 March 2013 23:55, Antoine Pitrou wrote: > On Sat, 23 Mar 2013 12:57:02 + > Richard Oudkerk wrote: > > > Also, couldn't hard links be used instead of copying? (This will fail > > if not on the same NTFS partition, but then one can copy as a fallback.) > > Hard links are generally hard to discover and debug (at least under > Unix, but I suppose the same applies under Windows). > (Slightly OT, but I think useful in this case.) That's what the Link Shell Extension < http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html> is for. Makes it very easy to work with Hardlinks, Symbolic links, Junctions and Volume Mountpoints. It gives different overlays for each to icons in Explorer (and Save/Open dialogs) and adds a tab to the properties of any link which gives details e.g. for hardlinks it displays the reference count and all the hardlinks to the same file. There's also a command-line version - ln < http://schinagl.priv.at/nt/ln/ln.html>. Highly recommended. Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] wsgi validator with asynchronous handlers/servers
On Sat, Mar 23, 2013 at 3:05 PM, Luca Sbardella wrote: > The pseudocode above does yields bytes before start_response, but they are > not *body* bytes, they are empty bytes so that the asynchronous wsgi server > releases the eventloop and call back at the next eventloop iteration. > > I'm I misinterpreting the pep, or the wsgi validator should be fixed > accordingly? The validator is correct for the spec. You *must* call start_response() before yielding any strings at all. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Are undocumented exceptions considered bugs?
On Sat, Mar 23, 2013 at 11:21 AM, Nick Coghlan wrote:
> In this specific case, the error message is
> confusing-but-not-really-wrong, due to the "two-types-in-one" nature
> of Python 2.x strings - 8-bit strings are used as both text sequences
> (generally not containing NUL characters) and also as arbitrary binary
> data, including encoded text (quite likely to contain NUL bytes).
With your terminology, three types: char, non-NUL-text, encoded-text
(e.g. what happens with ord('ab'))
That's pretty silly, considering that these are all one Python type,
and TypeError is raised into Python code. Obviously it can't change,
because of historical reasons, but documenting it would be
straightforward and helpful. These are not errors you can just infer
will happen, you need to see it via documentation, reading the source,
or experimentation (and re experimentation, then you have to establish
whether or not this was an accident or deliberate).
-- Devin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
