Phillip J. Eby added the comment:
Patch implementing an alternate approach: support automatically
importing __main__ when sys.argv[0] is an importable path. This allows
zip files, directories, and any future importable locations (e.g. URLs)
to be used on the command line. Note that this also
Changes by Phillip J. Eby:
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1739468>
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python
Phillip J. Eby added the comment:
Interested, yes. Have time for at the moment, no. :( Seems unlikely
I'll have time before 2008Q1 at this point.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Phillip J. Eby added the comment:
That change to the spec is fine, though you might also want to add something
like, "Like all other WSGI specification types", since *all* types specified in
WSGI are 'type()' not 'isinstance()'.
--
Phillip J. Eby added the comment:
No, I only consolidated the two copies of the code to a single function, in
order to more easily add the PEP 302 support. The feature was already there.
--
___
Python tracker
<http://bugs.python.org/issue6
Phillip J. Eby added the comment:
Committed to Py3K in r86146, with added docs and a larger list of transcodable
CGI variables.
--
___
Python tracker
<http://bugs.python.org/issue10
Phillip J. Eby added the comment:
To better show what the problem is, here's a change that would fix the problem
(albeit in an ugly way):
--- upload.py 2010-07-07 20:16:33.0 -0400
+++ /home/pje/upload.new2010-11-09 14:30:21.0 -0500
@@ -167,6 +
Phillip J. Eby added the comment:
Btw, a quick review of the 3.x trunk code for this shows that it does *not*
have this problem; this is specific to 2.7 and AFAICT *only* 2.7.
(This problem was introduced in r73436, btw, as of the move to urllib2 vs.
httplib
Phillip J. Eby added the comment:
Confirmed - issue10367 is not a dupe. This bug was that a *successful* upload
would crash; issue10367 occurs only in the HTTPError case, and isn't fixed by
this issue's patch. Reclosing this and reopening 10367.
--
stage: commit review -&
Phillip J. Eby added the comment:
Looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue5800>
___
___
Python-bugs-list mailing list
Unsubscribe:
Phillip J. Eby added the comment:
> It is not uncommon that developers provide web applications
to the public in which the HTTP response headers are not filtered for
newlines but are controlled by the user.
Really? Which applications, and which response headers?
> Therefore, I sugg
Phillip J. Eby added the comment:
Just as an FYI, it *is* possible to do generic functions that work with
Python's ABCs (PEAK-Rules supports it for Python 2.6), but it requires caching,
and a way of handling ambiguities. In PEAK-Rules' case, unregistering is
simply ignored, and
Phillip J. Eby added the comment:
Yes, the 'b' is a docs error.
I previously removed this in:
http://hg.python.org/cpython-fullhistory/rev/2697326d4a77
It appears to have been reverted during a merge, here:
http://hg.python.org/cpython-fullhistory/rev/88d04f0143c7
My brows
Phillip J. Eby added the comment:
It looks to me as though this patch reintroduces issue9199, as it passes
multiple arguments to self.announce() once again. The patch needs to be made
against the SVN version of Python, not the released version
Phillip J. Eby added the comment:
Yes, please consider the type->isinstance part of the change rejected. I just
got done reverting a bunch of those in 3.2. Where WSGI specifies types, it
means "type() is", not "isinstance".
(The 3.x version of wsgiref does not need
Phillip J. Eby added the comment:
Given that this is a pure bugfix to revert a problem in 2.7 -- where no *new*
development is being done -- a test isn't actually needed for this patch.
There is no point in holding up a distutils1 fix for distutils2's benefit.
Daniel: thanks for
Phillip J. Eby added the comment:
Committed Daniel's patch to r86978 in the 2.7 maintenance branch.
(The 2.x trunk still has this bug, but is permanently closed to new checkins.)
--
stage: needs patch -> committed/rejected
versions: -3rd party, Python 3.1, Py
Phillip J. Eby added the comment:
Whoops, my bad... I misread Eric's earlier message as throwing it back onto
*Daniel* to produce a test, not that *he* (Eric) was working on the test.
IOW, I thought that progress had been stalled a second time on this, and went
ahead to pick up the
Phillip J. Eby added the comment:
The urgency was only that I didn't want the other contributors to this issue to
feel as though the bar on their contributions were being raised higher every
time they jumped the previous bar.
IOW, I did it to make them feel like somebody was doing *some
Phillip J. Eby added the comment:
So, do you have any suggestions for a specific change to the patch?
--
___
Python tracker
<http://bugs.python.org/issue10
Phillip J. Eby added the comment:
I don't understand. HTTP_REMOTE_USER is not the name of a standard CGI
variable - it's REMOTE_USER.
It would help if you could show code for what client/proxy/server combination
has this problem, what happens when that code runs, and what you want
Phillip J. Eby added the comment:
I'm still baffled. How does this matter to anything?
The HTTP headers you describe would end up in an HTTP_REMOTE_USER environment
variable, with no impact on REMOTE_USER. REMOTE_USER could only be set by an
actual web server, not via an HTTP header.
Phillip J. Eby added the comment:
You say it "would" do this. Have you actually *tested* it?
Looking at the code in wsgiref again, I don't think it does what you think it
does. The '_' substitution is done to keyword arguments for header
*parameters* only; it&#x
Phillip J. Eby added the comment:
Doesn't matter how unpythonic it is: the spec calls for exact types and has
done so for six years already, so it's a bit late to do anything about it.
(And any version of Python that allowed string subclasses was in violation of
the spec and there
Phillip J. Eby added the comment:
One of the original reasons was to make it easier for server authors writing C
code to interface with WSGI. C APIs that operate on lists and dicts often do
not do what you would expect, when called on a subclass. Essentially, this
could lead to an app that
Phillip J. Eby added the comment:
PyString_AsString() only "works on subclasses" if their internal representation
is the same as type str. So we can't say "subclass of str" without *also*
specifying that the subclass store its contents in exactly the same way
Phillip J. Eby added the comment:
Implicit knowledge in your own head about what might or might not be a good
idea to program is not the same thing as a specification. "type(x) is str" is
a good specification in this context, while "string subclasses, but only if
they'
Phillip J. Eby added the comment:
1. WSGI is a *Python* spec, not a *CPython* spec, so CPython implementation
details have little bearing on how the spec should work.
Most non-CPython implementations have a native string type optimized for their
runtime or VM (i.e. Jython and IronPython
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
I'm good with it; the issue with the comment in core.py was my only
remaining objection.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
The encoding must be latin-1, not utf-8, and the stream must be binary
mode, not text.
I have no idea how to deal with the test suite, and don't have time at
the moment to investigate.
___
Pyt
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
For the "why Latin-1", read the WSGI spec's explanation of how
strings should be handled in Python implementations where 'str' is unicode.
I suppose that you *could* make it a text stream with Latin-1
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
HTTP is defined as a stream of bytes; the fact that you can specify
encodings for headers and content is a different level of the
spec. WSGI wants to basically be as transparent a mapping as
possible between HTTP and Pytho
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
Any package which is using the length argument to readline() is in
violation of PEP 333 and should be fixed. The argument is intentionally
not supported by wsgiref.validate, since its purpose is to catch
incorrect programs that are vio
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
Not any time soon; I don't currently use Py3K and can't even vouch for
the correctness of the posted patch within Py3K. (i.e., what really
happened to the message class?) Sorry; all I can really do here is
clarify WSGI-r
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
Per PEP 333:
"""The optional "size" argument to readline() is not supported, as it
may be complex for server authors to implement, and is not often used in
practice."""
The whole point of this
Phillip J. Eby added the comment:
What sort of test did you have in mind? To test the desired outcome, it seems
we'd need to poison os.environ, reload wsgiref.handlers, remove the poison, and
then make sure it didn't get in. That seems a bit like overkill (as well as
hard to
Phillip J. Eby added the comment:
Will I be able to do what? I have a kludgy test and a patch in my checkout, I
was just waiting for word back from you (since Feb 19) on whether that would be
ok.
--
___
Python tracker
<http://bugs.python.
Phillip J. Eby added the comment:
It also needs to hold the import lock during both the "register" and
"notify" operations. In addition, the "notify" operation needs to be
exposed for calling from Python (so that lazy module implementations
can interop).
Phillip J. Eby added the comment:
On systems where the gzip or bz2 modules aren't installed, this patch
can raise a tarfile.CompressionError, which should be caught and handled
correctly. The import of tarfile should also be inside the relevant
function (as is done for make_zipfile) inste
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
Hi Paul. AFAICT, this doesn't look like it will actually work for
filesystem data. get_loader() will return None for "regular",
filesystem-installed modules, at least in Python 2.5. Perhaps you
should add
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
Oops, my bad. I'm thinking of an entirely unrelated get_loader()
function. Meanwhile, I misread your patch entirely, and thought you had
some dead code for os.path processing that is in fact live. So there is
"another"
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
reload() is implemented by calling the PEP 302 load_module() method
on the existing module object.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
An easy way to test it: just change your load_module() to raise an
AssertionError if the module is already in sys.modules, and the main
body of the test to make two get_data() calls for the same
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
Why does it need to be a valid loader? It's a mock, not a real
loader. But if it really bothers you, have it increment a global in
the module or something, and put the assertion in the test
proper. Heck, have it update a cou
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
But I'm getting a failure on that test, and the other one, too:
$ ./python Lib/test/test_pkgutil.py
test_alreadyloaded (__main__.PkgutilTests) ... FAIL
test_getdata_filesys (__main__.PkgutilTests) ... FAIL
test_getdata_pep30
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
Both versions of the patch have a problem, in that the Distribution
object is looking for an option directly in sys.argv. At the very
least, this should be looking at the 'script_args' attribute of the
Distribution instead
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
I much prefer the simpler of the two patches - better to monkeypatch in
the tests than adding complications to the already over-complicated
distutils.dist. I don't find monkeypatching in tests to be horrible at
all, but if it rea
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
It looks like you can drop the change to distutils.core, too, since
it's just a change in the comment, and the changed comment is
inaccurate, AFAICT. Apart from that, it looks good.
__
Trac
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
Oh, I thought you meant that it overrides *which* config files --
i.e., implied that it was handling --no-user-config.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
No, it shouldn't. The purpose of wsgiref.validate is to validate spec
compliance, and the use of a readline() argument means that the program
doing the invocation is not valid, per the spec. wsgiref.validate is
correctly re
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
Uh, Ian, do you not remember being the person who *wrote* this code a
few years ago? This is the old paste.lint with a little
renaming. Of course it can be used with existing code -- code that
complies with the WSGI spec.
It
Phillip J. Eby <[EMAIL PROTECTED]> added the comment:
Then obviously it makes no sense to update wsgiref before the
spec. ISTM the correct way to deal with this is update the cgi
module to include a WSGI-compatible API.
___
Python tracker <[EMAIL
Phillip J. Eby added the comment:
I could argue either way on this one; it's true that deleting a
nested-scope variable is sometimes desirable, but it also seems to me
like closing over an except: variable is a Potentially Bad Idea.
In neither case, however, do I think it's appropria
Phillip J. Eby added the comment:
If you want to change to using bytes, you're going to have to take it to
the Web-SIG and hash out a revision to PEP 333, which at the moment
requires the use of strings, period.
This has nothing to do with the desirability of bytes vs. strings; I am
sure
Phillip J. Eby added the comment:
At 03:37 PM 12/22/2008 +, Antoine Pitrou wrote:
>So, not accepting bytes in py3k is clearly a violation of the PEP!
On the contrary. Please read the two paragraphs *after* the one you quoted.
___
Python tracker
&l
Phillip J. Eby added the comment:
To be quite clear: this change requires discussion on the Web-SIG and an
appropriate revision of the PEP. Ideally, the patch should include the
necessary PEP revision.
The Web-SIG discussion regarding a switch to bytes should also take into
consideration the
Phillip J. Eby added the comment:
Antoine, you have three choices here:
1. Follow the PEP,
2. Take it to the Web-SIG and get the appropriate discussion,
consensus, and PEP revision, or
3. Drop wsgiref from the current release of Py3K until #2 can be done.
Which would you prefer?
Please note
Phillip J. Eby added the comment:
Graham: thanks for pointing that out; I completely forgot we already
*had* the migration discussion on the Web-SIG! It just slipped my
mind because I didn't have any 3.0 work on the horizon.
Dmitry: A question about the new patch. Are bytearra
Phillip J. Eby added the comment:
The problem might be that you're iterating over more than just the top
level; if you look for submodules then the parent package has to be
imported... and that might make that window load, if there's module-level
code in the package __init__ that
Phillip J. Eby added the comment:
I don't have the code you're talking about in front of me; just wanted to
give you a lead on the likely cause.
--
___
Python tracker
<http://bugs.python.o
Phillip J. Eby added the comment:
Please expose this as an attribute of the class or module, not as a function.
A function is orders of magnitude slower than attribute access, and the entire
point of exposing this is to allow caches to be invalidated.
In order to be useful for cache
Phillip J. Eby added the comment:
Antoine Pitrou added the comment:
> -1. Exposing a function allows to modify the underlying implementation
> without breaking any API.
This doesn't make any sense. Once you've exposed an API that gives
out a value for this, you can't chan
Phillip J. Eby added the comment:
All that being said, I took out some time to get actual numbers, and
found my original guesstimate of overhead was incorrect; it's only 3
times slower, not "orders of magnitude". ;-)
And even on a relatively old machine, that 3 times slower amou
Phillip J. Eby added the comment:
Just adding a data point: I use the "mingw32" compiler setting with the Cygwin
GCC installation, to compile extensions for standard Windows Python (*not*
Cygwin Python). It would be good if any change doesn't break this scenario --
assuming i
Phillip J. Eby added the comment:
On Sat, Jul 7, 2012 at 2:37 PM, Terry J. Reedy wrote:
> Phillip, this is a trivial wsgiref patch. Do you have any opinion?
>
Nope.
--
___
Python tracker
<http://bugs.python.org/
Phillip J. Eby added the comment:
Hope I'm not too late to the bikeshed painting party; just wanted to chip in
with the suggestion of "self-contained package" for non-namespace packages.
(i.e., a self-contained package is one that cannot be split across different
sys.path ent
Phillip J. Eby added the comment:
Per Nick's request that I redirect this here instead of #15295...
(w/already-fixed things deleted):
Hope I'm not too late to the bikeshed painting party; just wanted to chip in
with the suggestion of "self-contained package" for no
Phillip J. Eby added the comment:
FYI, this looks like a bug in wsgiref.handlers.BaseHandler.finish_response(),
which should probably be using a try/finally to ensure .close() gets called.
(Which would catch a failed write() to the client.)
I'm kind of amazed this has gone undetected
Phillip J. Eby added the comment:
> Wouldn't it be possible to amend PEP ?
Sure... except then it would also be necessary to amend PEP , and also all
WSGI applications already written that assume this, any time in the last nine
years.
This is a known and intended consistent
Phillip J. Eby added the comment:
I appreciate the change being made. The specific code in setuptools is
relying on an erroneous reading of get_ext_filename()'s docstring (which
as of 2.3 at least, implied to me at least that it is always called with
an extension's full dotted name)
Phillip J. Eby added the comment:
FYI, a fix allowing setuptools to work with 2.6.3 is now checked in, and
will be released soon (preferably in a few days, unless new bugs turn
up). If you are experiencing issues with this and would like to try the
fixed version(s), please see the announcement
Phillip J. Eby added the comment:
This is not an issue with CGI, but an issue with using an inappropriate
WSGI handler for a long-running process environment that only emulates CGI.
That is, in a true CGI environment, there can't be *multiple* requests
made to CGIHandler, and so it can&#
Phillip J. Eby added the comment:
Hm. In retrospect, CGIHandler should probably just set os_environ to an
empty dictionary in its class body (thereby not using the cached
environ), and this would then work correctly for repeated uses.
This would be a clean bugfix and wouldn't affect beh
Phillip J. Eby added the comment:
I've forwarded the suggested fix to the GAE team; it is to add this line:
os_environ = {} # Handle GAE and other multi-run CGI use cases
to the class body of CGIHandler. This should also be done in the Python
stdlib.
Btw, this fix can al
Phillip J. Eby added the comment:
ISTM there may be two ways to fix this problem; one was to change the
.exe header produced by bdist_wininst, but in retrospect, it can't fix
this because it's likely Windows' 64-to-32 bit conversion (Wow6432Node)
that's changing the regist
New submission from Phillip J. Eby :
When showing a server response (--show-response), the upload command crashes
with the following traceback:
Traceback (most recent call last):
File "setup.py", line 94, in
scripts = scripts,
File "/usr/lib/python2.7/distutils/core.py
Phillip J. Eby added the comment:
Just a note: the zip files produced by the distutils and friends (sdist,
bdist_dumb, eggs) do not include entries for plain directories. I would guess
that this is also true for wheels at the moment, unless something was
specifically done to work around this
Phillip J. Eby added the comment:
On Fri, Apr 5, 2013 at 9:07 AM, Kristján Valur Jónsson
wrote:
> But I can think of contrived examples where this could break things:
> #a.py:
> from .b import util
>
> #b.py
> from . import a
> from .util import util
>
> Because o
Phillip J. Eby added the comment:
Actually, after a little reflection, I can see that there are more
complex conditions to analyze, if 'b' doesn't import 'b.util', but
some other module imports b and sets b.util. But that's just freaking
insane and whoever does t
Phillip J. Eby added the comment:
...and I thought of *one* more way to trigger the changed behavior,
which looks like:
#b.py
from .b import util
import .a
util = util.util
#b/util.py
def util(): pass
(with the other files the same as before).
I'm including it only for completeness&
Phillip J. Eby added the comment:
I don't care much one way or the other about it being considered a bug
in 2.x, but it might be worth considering a bug in 3.x.
Either way, though, the language reference for "from import" should
reflect the change, and "alternative implem
Phillip J. Eby added the comment:
On Sun, Apr 14, 2013 at 3:51 AM, Nick Coghlan wrote:
> Your analysis is one of the pieces that was missing,
Unfortunately, I just noticed it's actually incorrect in a pretty
important part In my original example, I said, "because of the
circulari
Phillip J. Eby added the comment:
It looks like maybe basic2 should be importing basic, not basic2.
Otherwise, you might as well just import basic2 directly and be done
with it. ;-) Likewise, I think indirect should be importing from
indirect2, not from itself? i.e., I'd expect that te
83 matches
Mail list logo
