[issue16832] Expose cache validity checking support in ABCMeta
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 invalidation, the token has to be read on *every* access to a cache, thus adding unnecessary overhead to every cache access. -- nosy: +pje ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16832 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16832] Expose cache validity checking support in ABCMeta
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 change the implementation in a way that doesn't involve handing out a value... in which case you can just as easily set it as an attribute. So there is actually zero improvement in encapsulation: it's purely a ritualistic wrapping, like Java programmers insisting on having getFoo() methods in Python when an attribute would suffice. If there must be a way to change it later to be dynamic, it can always be exposed as an attribute of an object that could grow a property later, e.g. from abc import object_graph if object_graph.version != old_version: ... Nick Coghlan added the comment: Trading correctness for speed is almost never a good idea. How is correctness relevant to the question of whether a readable value is exposed as an attribute or a method? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16832 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16832] Expose cache validity checking support in ABCMeta
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 amounts to an extra tenth of a microsecond, at least in a hot loop with timeit. So I'll stop being a pain about this now, even though I still think getters are a stinky Java code smell and don't belong in Python anyways. ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16832 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17636] Modify IMPORT_FROM to fallback on sys.modules
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 test to fail even with the change. In addition, even if that is fixed, it's still not testing a cycle involving util; it's really just testing the same thing as basic is supposed to be testing. It also looks as though like the rebinding test doesn't actually test any rebinding, since nobody ever imports the thing that's rebound. It's failing for the same reason as the subpackage test. The subpackage test looks like a valid test, though - i.e., it's the basic case correctly implemented as a parent-child cycle. It's actually the only one of the tests that tests what it says it does. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17636] Modify IMPORT_FROM to fallback on sys.modules
Phillip J. Eby added the comment: On Sun, Apr 14, 2013 at 3:51 AM, Nick Coghlan rep...@bugs.python.org 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 circularity, this will *also* happen if you import 'a' first. This statement is actually false. Importing 'a' first in that example will result in a.util == b.util:util, not a.util=b.util. I made the mistake because I was for some reason thinking that 'a' was going to execute its import while being imported from b.util, and in that scenario it will not. That means there *is* an ordering dependency, and an ambiguity like this one can lie dormant until long after you've introduced the circularity. :-( -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17636] Modify IMPORT_FROM to fallback on sys.modules
Phillip J. Eby added the comment: On Fri, Apr 5, 2013 at 9:07 AM, Kristján Valur Jónsson rep...@bugs.python.org 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 of the circular import order, b.util will not exist as an attribute on b when a does its import. So a.util will end up being util instead of util.util as one might expect. Not quite. It will only do this if the '.b.util' module is *in sys.modules* at the time that a is being imported, which also means that .b.util has to be imported somewhere *before* .a, in order to end up with a stale value. As written, your example actually works correctly if .a is imported first, and fails with an ImportError if .b is imported first. In fact, this example is kind of useful for proving the change *correct*, not broken. At the very least, it shows that you'll have to be more inventive to come up with a breaking case. ;-) Consider that for any module x.y, x must be in sys.modules before x.y can. Therefore, any from x import taking place before x is fully loaded will either happen before x.y is fully loaded, during the load, or after it, and the following cases apply: 1. If it happens before, then it fails with an ImportError as is the case today. 2. If it happens during (i.e. there is a cycle with x.y rather than with just x), then the import returns the module. 3. If it happens after, then either the x.y attribute is bound to the submodule, or has been rebound to something else, or deleted. 4. If after and deleted, the import returns the module. 5. If after and rebound, the import returns the changed attribute (just like today) 6. If after and normally bound, the import returns the module (just like today) The only cases in which the behavior changes from today are cases 2 and 4, which would both fail today with an ImportError. Case 4 also doesn't make much sense, since 'import x.y' would still permit access to the module -- so it'd have to be an odd situation in which you didn't want 'from import' (and *only* from import) to fail. So let's consider case 2, which would have to be written something like: #a.py from .b import util #b.py from .util import util #b/util.py from .. import a def util(): pass #__main__.py import b So, import b leads to starting the load of b.util, which leads to importing a, which succeeds and sees the b.util module instead of the b.util:util function. But, because of the circularity, this will *also* happen if you import a first. So 'a' will *always* see b.util rather than b.util:util, unless you remove the circularity. If you remove the circularity, then 'a' will always see b.util:util as the value of util. So case 2 does not lead to a hard-to-debug ordering dependency, it leads to an immediately discoverable change in behavior the moment you start importing a from b.util. The tl;dr version of the above is that you will only receive a module instead of an attribute if the module that's about to be replaced just imported *you* during its initial loading, and if it does that, it'll do it no matter what order the imports occur in, making the problem occur immediately and consistently as soon as you introduce the circularity. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17636] Modify IMPORT_FROM to fallback on sys.modules
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 that probably deserves whatever they get, especially since a later 'import b.util' would blow away the modified attribute. So, this note is just to satisfy myself that the change doesn't introduce any *new* weirdness unless you are in a case where the parent imports and replaces the child, and the child is involved in an import cycle. If the parent doesn't import the child but just assigns an attribute, it's already broken the minute somebody else imports the child, and the same thing applies if something else sets the attribute without importing the child first, and if it imports the child first, then the previous analysis (mostly) applies, but either way that code is broken and will have plenty of other ordering dependencies to debug on its own. ;-) (No wonder Nick said nobody wanted to touch this... the analysis alone is a killer. ;-) Luckily, it seems we're good to go unless somebody can find a case I missed.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17636] Modify IMPORT_FROM to fallback on sys.modules
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' sake, because my original enumeration of cases ignored the possibility that 'a' could be doing the import *after* b.util is loaded and bound, but *before* it's rebound. However, it doesn't produce any new or problematic effects: it's essentially the same as if 'a' were imported from 'b.util'. Once again, regardless of the order in which imports happen, 'a' ends up with 'b.util' the moment the circularity is introduced, and it stays that way. It's also hard to argue that a case written this way isn't getting exactly what it *says* it wants. In fact, it looks like code that was deliberately written to *force* a to end up with the original b.util instead of the replaced one. ;-) Final (hopefully) conclusion: this change replaces the FAQ of Don't use 'from-import' for circular imports with the hopefully-less-FA'd Q of when from-import is part of an import cycle, it works *exactly* like regular import, so you're going to get a submodule rather than an attribute. If you need the attribute instead, move the import so that it happens after the attribute is set up. (Which is exactly the same advice that would apply in a cycle with any other unitialized attribute, whether you were using from-import or not.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17636] Modify IMPORT_FROM to fallback on sys.modules
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 implementations should be informed of the update. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14905] zipimport.c needs to support namespace packages when no 'directory' entry exists
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 property of distutils-generated zip files. So ISTM the right thing to do is to synthesize the entries at directory read time, when they're being looped over anyway. Reviewing the patch, there is a performance optimization possible by making a slight change to the algorithm. Currently the patch loops from the start of the string to the end, looking for path prefixes. This means that the total overall performance is determined by the length of the strings and especially the average directory depth. However, there is a significant shortcut possible: looping from the *end* of each string to the beginning, it's possible to break out of the loop if the prefix has already been seen -- thus saving (depth-1) dictionary lookups in the average case, and only looking at the characters in the base filename, unless a new directory is encountered... for a typical overhead of one unicode substring, dictionary lookup, and strrchr per zipfile directory entry. (Which is very small compared to what else is going on at that point in the process.) To elaborate, if you have paths of the form: x/y/a x/y/b x/y/c/d Then when processing 'x/y/a', you would first process x/y -- it's not in the dict, add it. Then x -- not in the dict, add it. Then you go to x/y/b, your first parent is x/y again -- but since it's in the dict you skip it, and don't even bother with the x. Next you see x/y/c, which is not in the dict, so you add it, then x/y, which is, so you break out of the loop for that item. Basically, about all that would change would be the for() loop starting at the end of the string and going to the beginning, with the loop position still representing the end of the prefix to be extracted. And the PyDict_Contains check would result in a break rather than a continue. So, if the only concern keeping the patch from being accepted is that it adds to startup time, this approach would cut down quite a bit on the overhead for generating the path information, in cases of repeated prefixes. (And in the common cases for zipfile use on sys.path, one would expect to see a lot of common prefixes, if only for package names.) -- nosy: +pje ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14905 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16679] Wrong URL path decoding
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 property of how WSGI handles HTTP headers. Under Python 2.x, PATH_INFO was a byte string (and still is), and to maintain also side-compatibility with Jython and IronPython, header strings are always maintained as bytes in unicode form, with applications having responsibility to decode-recode as needed. This isn't a minor corner of the spec, it's central to how headers are handled, and has been so long before Python 3 even existed. To mess with it now means you break applications and frameworks that are already correctly written to follow the specs. To put it in brief, the reported behavior is not a bug, it is a feature and by design. A server that returns a UTF-8 decoded PATH_INFO is in violation of the spec, so the reference implementation of the spec should absolutely not do so. ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16679 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16220] wsgiref does not call close() on iterable response
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 this long, but I guess that either: 1. other servers are probably catching errors from .run() and closing, 2. they're not using BaseHandler in their implementation, or 3. most apps don't have anything that essential in close() and/or the clients don't disconnect that often. ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16220 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15295] Import machinery documentation
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 entries due to its use of an __init__ module). Also, technically, namespace portions do not only contribute subpackages; they can contribute modules as well. Another point of possible confusion: meta finders and path finders are both described as hooks, but this terminology seems in conflict with the use of hook as describing a callable on path_hooks. Perhaps we could drop the term hook from this section, and retitle it Import System Extensions and say you can extend the system by writing meta finders and path entry finders. This would let the term hook be the exclusive property of path_hooks, which is how you extend the import system to use your custom finders. The statement about __path__ being a list is also out-of-date; as of PEP 420, it can be an immutable, iterable object. Specification-wise, __path__ need only be a re-iterable object, and people reading its value must NOT assume that it's a list or even indexable. The term sys path finder should also be replaced by path entry finder. The former term is both incorrect and misleading, as it both implies that such a finder actually searches sys.path, and that it is exclusive to sys.path. Path entry finders are used to look for modules within a location specified by a path entry - a string found in sys.path or in a __path__ attribute. The term path importer is also horribly confusing in context... after some reflection, I suggest the following additional terminology changes: 1. Replace meta path finder with import handler 2. Replace path importer with sys.path import handler Now we can say that you extend the import system by adding import handlers to sys.meta_path, and that one of the default handlers is the sys.path import handler, which processes imports using sys.path and module __path__ attributes. The sys.path import handler can of course in turn be extended by adding path hooks to sys.path_hooks, which are used to create module finder objects for the path entry strings found in sys.path and module __path__ attributes. A path hook must return a finder object, which implements similar methods to those of an import handler, but with some important differences. Whew. It's a bit of a mouthful, but I think that this set of terms would keep all the roles and functions clear, along with their relationships to one another. In addition, I think it provides greater clarity as to which pieces you need to extend when, why, and how. What do you think? -- nosy: +pje ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15502] Meta path finders and path entry finders are different, but share an ABC
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 non-namespace packages. (i.e., a self-contained package is one that cannot be split across different sys.path entries due to its use of an __init__ module). Also, technically, namespace portions do not only contribute subpackages; they can contribute modules as well. (The trunk doc says they contribute subpackages ATM.) Another point of possible confusion: meta finders and path finders are both described as hooks, but this terminology seems in conflict with the use of hook as describing a callable on path_hooks. Perhaps we could drop the term hook from this section, and retitle it Import System Extensions and say you can extend the system by writing meta finders and path entry finders. This would let the term hook be the exclusive property of path_hooks, which is how you extend the import system to use your custom finders. With respect to the current discussion about importer, handler, finder, etc., I'd like to propose a slight tweak that I think can clear up the remaining confusing points: 1. Replace meta path finder with import handler 2. Replace path finder with sys.path import handler Rationale: Despite the similarity in interface between the two types of finders, they perform different sorts of functions. A object in sys.meta_path can (and MUST) implement a broad module-finding policy, whereas a path entry finder is much more limited in scope - it only gets to override later path entry finders, and can't, for example, decide to use some other sort of __path__ attribute. (I'm not married to the term handler here, either - I just think importer is too generic, finder conflates with the more-commonly used kind of finder. Policy could be another possibility. Both imply a broader scope of responsibility than finder, and don't impinge on the special meaning of importer.) With a bigger distinction drawn between these two types of finders, we can say that you... Extend the import system by adding import handlers to sys.meta_path, and that one of the default handlers is the sys.path import handler, which processes imports using sys.path and module __path__ attributes. The sys.path import handler can of course in turn be extended by adding path hooks to sys.path_hooks, which are then used to create module finder objects for the path entry strings found in sys.path and module __path__ attributes. A path hook must return a finder object, which implements similar methods to those of an import handler, but with some important differences. Of course, if you make that sys.path import policy instead of sys.path import handler, it still works. Thoughts? -- nosy: +pje ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5931] Python runtime name hardcoded in wsgiref.simple_server
Phillip J. Eby p...@telecommunity.com 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 rep...@bugs.python.org http://bugs.python.org/issue5931 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Phillip J. Eby p...@telecommunity.com 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 it's not already broken in newer Python versions. (For this scenario, AFAIK, the no-cygwin option is required, or at least I believe it was the last time I intentionally compiled something.) -- nosy: +pje ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13926] pydoc - stall when requesting a list of available modules in the online help utility
Phillip J. Eby p...@telecommunity.com 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 does that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13926 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13926] pydoc - stall when requesting a list of available modules in the online help utility
Phillip J. Eby p...@telecommunity.com 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 rep...@bugs.python.org http://bugs.python.org/issue13926 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6703] cross platform failure and silly test in doctest
Phillip J. Eby p...@telecommunity.com 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 rep...@bugs.python.org http://bugs.python.org/issue6703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10935] wsgiref.handlers.BaseHandler and subclasses of str
Phillip J. Eby p...@telecommunity.com 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()'. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10935 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11968] wsgiref's wsgi application sample code does not work
Phillip J. Eby p...@telecommunity.com 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 browser crashed trying to view that huge second revision, so I'm not sure if there were any other regressions therein. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11968 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11671] Security hole in wsgiref.headers.Headers
Phillip J. Eby p...@telecommunity.com 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 suggest to filter/warn/except header tuples which contain the above characters upon assignment in wsgiref.headers. Applications that send them are not WSGI compliant anyway, since the spec forbids control characters in header strings -- and wsgiref.validate already validates this. Still, I'm not aware of any legitimate use case for apps sending user input as an HTTP header where the data wouldn't already be escaped in some fashion -- cookies, URLs, ...? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11671 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5135] Expose simplegeneric function in functools module
Phillip J. Eby p...@telecommunity.com 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 ambiguity causes an error at call time. But simplegeneric can avoid ambiguities, since it's strictly single-dispatch. Basically, you just have two dictionaries instead of one. The first dictionary is the same registry that's used now, but the second is a cache of virtual MROs you'll use in place of a class' real MRO. The virtual MRO is built by walking the registry for classes that the class is a subclass of, but which are *not* found in the class's MRO, e.g.: for rule_cls in registry: if issubclass(cls, rule_cls) and rule_cls not in real_mro: # insert rule_cls into virtual_mro for cls You then insert those classes (abcs) in the virtual MRO at the point just *after* the last class in the MRO that says it's a subclass of the abc in question. IOW, you implement it such that an abc declaration appears in the MRO just after the class that was registered for it. (This has to be recursive, btw, and the MRO cache has to be cleared when a new method is registered with the generic function.) This approach, while not trivial, is still simple, in that it has a consistent, unambiguous resolution order. Its main downside is that it holds references to the types of objects it has been called with. (But that could be worked around with a weak key dictionary, I suppose.) It also doesn't reset the cache on unregistration of an abc subclass, and it will be a bit slower on the first call with a previously-unseen type. The downside of a PEP, to me, is that it will be tempting to go the full overloading route -- which isn't necessarily a bad thing, but it won't be a *simple* thing, and it'll be harder to get agreement on what it should do and how -- especially with respect to resolution order. Still, if someone wants to do a PEP on *simple* generics -- especially one that can replace pkgutil.simplegeneric, and could be used to refactor things like copy.copy, pprint.pprint, et al to use a standardized registration mechanism, I'm all in favor -- with or without abc registration support. Btw, the current patch on this issue includes code that is there to support classic classes, and metaclasses written in C. Neither should be necessary in 3.x. Also, a 3.x version could easily take advantage of type signatures, so that: @foo.register def foo_bar(baz: bar): ... could be used instead of @foo.register(bar, foo_bar). But all that would be PEP territory, I suppose. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5135 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5800] make wsgiref.headers.Headers accept empty constructor
Phillip J. Eby p...@telecommunity.com added the comment: Looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5800 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10935] wsgiref.handlers.BaseHandler and subclasses of str
Phillip J. Eby p...@telecommunity.com 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're really str does not. And the reason why that is, is because the first specification allows server implementers to say, your type is not str, so you are not conformant; go fix your code. The second specification is just an invitation to (number of server implementations)*(number of string implementations) arguments about what conformance is. That makes the latter an objectively worse specification than the first, even if EVERYONE would prefer to be able to use their own string type. Practicality beats purity, and explicit is better than implicit. These principles are doubly true where interop protocol definitions are concerned. To put it another way, the greater the social separation between parties, the more explicit and specific a contract between those two parties has to be in order to co-ordinate their actions, because they can't rely on having the same operating assumptions as the other party. This situation is a terrific example of that principle in action. ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10935 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10935] wsgiref.handlers.BaseHandler and subclasses of str
Phillip J. Eby p...@telecommunity.com 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), and thus have *different* implementation-dependent details of what constitutes a native string, other than that it has type 'str' as seen by Python code. (See my previous point about people bringing these sorts of implicit assumptions to the table!) (Also, as you may or may not be aware, WSGI supports Python 2.1, mainly for Jython's sake at the time, and in Python 2.1 there was *no such thing* as a subclass of 'str' to begin with.) 2. The specific practical goal of WSGI is interoperability, *not* programmer convenience. (Says so right in the PEP.) 3. You are free to patch wsgiref's Headers class to *accept* non-str values (as long as they are converted to conforming strings in the process) and to make any proposals you like for future versions of WSGI or another interop protocol via the Web-SIG, so this entire discussion has been moot for some time now. 4. The explicit-vs-implicit is about the contract defined in the spec (making explicit what, precisely, is required of both parties), not the type test. 5. Since this discussion is moot (see point 3), we'll have to agree to disagree here. Whether you (or I!) like what the spec says is not what matters: wsgiref is the *reference library* for the specification, and therefore must conform to the actual spec, not what any of us would like the spec to be. Heck, I tried to add some *much* more minor amendments to PEP 333 than this about three or four months ago, and Guido said he'd reject the whole PEP if I tried! That's why we have PEP instead of a slightly-amended PEP 333. This particular bikeshed was painted six years ago, so let's get on with the actual bicycling already. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10935 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10935] wsgiref.handlers.BaseHandler and subclasses of str
Phillip J. Eby p...@telecommunity.com 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 as an object of type str... which means all we've really done is to make the specification longer and more complicated. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10935 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10935] wsgiref.handlers.BaseHandler and subclasses of str
Phillip J. Eby p...@telecommunity.com 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 therefore buggy.) In principle, this class could allow non-str objects if and ONLY if they were converted to actual str objects upon receipt -- but they would have to be the *exact* type after this conversion. If somebody wants to implement that, I have no objection. But it MUST reject non-basestring input values and values that don't convert to an exact type str. (IOW, type(str(x)) is str must hold.) To put it another way, the WSGI protocol requires output headers to be of type 'list' where all elements are type 'tuple' and containing two 'str' entries. The Headers class cannot fulfill this contract if it allows non-conforming input. So non-conforming input must either be rejected or made to conform. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10935 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10935] wsgiref.handlers.BaseHandler and subclasses of str
Phillip J. Eby p...@telecommunity.com 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 appears to work correctly on one server, but breaks strangely when run on another. (IOW, Python's C API and built-in types often break the Liskov principle: there are C-level operations that don't call back into Python subclass methods, so overriding just a few methods usually doesn't work as expected.) Another reason was to avoid having to document precisely which methods of a str, list, etc. are required to be implemented. (This is somewhat easier now that we have abc's, but really, it's still a royal PITA.) In any event, it's entirely moot now, six years later. Any change requests should be sent to the Web-SIG for WSGI 2.0 discussion, as changing the existing PEPs is not an option. (Guido has pronounced that I cannot change PEP 333 in any way, so even if I agreed with the requests in this thread, there is simply no way that wsgiref is changing in 2.x. PEP has just been approved as well, so the odds of even a 3.x change are low. But as I said, I won't object to a Headers patch that *converts* its non-conforming inputs to objects of type str, as long as they were stringlike objects to start with.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10935 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10751] REMOTE_USER and Remote-User collision in wsgiref
Phillip J. Eby p...@telecommunity.com 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. So I don't get how this is a security issue, or even a bug at all. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10751] REMOTE_USER and Remote-User collision in wsgiref
Phillip J. Eby p...@telecommunity.com 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's not done to header *names*. Please write a test case for wsgiref.headers.Headers that demonstrates the behavior you think it would be doing. AFAICT, you will not even be able to get the replace() calls to execute without writing explicit add_header() calls, and even then, you *still* won't get the results you're describing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10751] REMOTE_USER and Remote-User collision in wsgiref
Phillip J. Eby p...@telecommunity.com 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 to happen instead. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10155] Add fixups for encoding problems to wsgiref
Phillip J. Eby p...@telecommunity.com added the comment: So, do you have any suggestions for a specific change to the patch? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10367] python setup.py sdist upload --show-response can fail with UnboundLocalError: local variable 'result' referenced before assignment
Phillip J. Eby p...@telecommunity.com 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 the patch, it looks good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10367 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10367] python setup.py sdist upload --show-response can fail with UnboundLocalError: local variable 'result' referenced before assignment
Phillip J. Eby p...@telecommunity.com 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, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10367 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10367] python setup.py sdist upload --show-response can fail with UnboundLocalError: local variable 'result' referenced before assignment
Phillip J. Eby p...@telecommunity.com 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 slack. Sorry about that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10367 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10367] python setup.py sdist upload --show-response can fail with UnboundLocalError: local variable 'result' referenced before assignment
Phillip J. Eby p...@telecommunity.com 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 *something*. In hindsight, that was not necessarily the best tactic. ;-) (Given the nature of the bugfix and the bugfix-only status of the 2.7 line, I don't think the lack of an automated test is a big deal; the odds that anything other than trivial bugfixes will be applied to this module in the future seem negligible to me. At least, I would *hope* that it is not planned to destabilize this module in 2.7.x any further than it already was by the changes that broke it in the first place.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10367 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5800] make wsgiref.headers.Headers accept empty constructor
Phillip J. Eby p...@telecommunity.com 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 to be executable on 2.x versions, but this doesn't mean the protocol itself can be altered in backwards-incompatible ways, just the implementation.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5800 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10367] python setup.py sdist upload --show-response can fail with UnboundLocalError: local variable 'result' referenced before assignment
Phillip J. Eby p...@telecommunity.com 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10367 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10367] python setup.py sdist upload --show-response can fail with UnboundLocalError: local variable 'result' referenced before assignment
Phillip J. Eby p...@telecommunity.com 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 +167,9 @@
request = Request(self.repository, data=body,
headers=headers)
+
+result = None
+
# send the data
try:
result = urlopen(request)
@@ -186,4 +189,4 @@
self.announce('Upload failed (%s): %s' % (status, reason),
log.ERROR)
if self.show_response:
-self.announce('-'*75, result.read(), '-'*75)
+self.announce('-'*75, result.read() if result is not None else
'ERROR', '-'*75)
--
nosy: +pje
resolution: duplicate -
stage: committed/rejected - needs patch
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10367
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9199] distutils upload command crashes when displaying server response
Phillip J. Eby p...@telecommunity.com 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 - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9199 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10155] Add fixups for encoding problems to wsgiref
Phillip J. Eby p...@telecommunity.com added the comment: Committed to Py3K in r86146, with added docs and a larger list of transcodable CGI variables. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9199] distutil upload command crashes when displaying server response
New submission from Phillip J. Eby p...@telecommunity.com:
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 module
scripts = scripts,
File /usr/lib/python2.7/distutils/core.py, line 152, in setup
dist.run_commands()
File /usr/lib/python2.7/distutils/dist.py, line 953, in run_commands
self.run_command(cmd)
File /usr/lib/python2.7/distutils/dist.py, line 972, in run_command
cmd_obj.run()
File /usr/lib/python2.7/distutils/command/upload.py, line 60, in run
self.upload_file(command, pyversion, filename)
File /usr/lib/python2.7/distutils/command/upload.py, line 189, in
upload_file
self.announce('-'*75, result.read(), '-'*75)
TypeError: announce() takes at most 3 arguments (4 given)
This is apparently due to the change made in r70889, which replaced a print
statement with a call to self.announce(), but did not change the parameters
appropriately. (The announce() method takes a string and a log level, not an
arbitrary number of string arguments.)
I don't know what versions of Python this is in besides 2.7; it may exist in a
2.6.x release or 3.x as well, but it is definitely in the 2.7 release.
--
assignee: tarek
components: Distutils
messages: 109541
nosy: pje, tarek
priority: normal
severity: normal
status: open
title: distutil upload command crashes when displaying server response
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9199
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7250] wsgiref.handlers.CGIHandler caches os.environ, leaking info between requests
Phillip J. Eby p...@telecommunity.com 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 rep...@bugs.python.org http://bugs.python.org/issue7250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7250] wsgiref.handlers.CGIHandler caches os.environ, leaking info between requests
Phillip J. Eby p...@telecommunity.com 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 get right), while the alternative of simply testing that CGIHandler has an empty os_environ seems a bit like a cheat. Any thoughts? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6792] Distutils-based installer does not detect 64bit versions of Python
Phillip J. Eby p...@telecommunity.com 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 registry path used, rather than anything that Python or distutils is doing. The other way, which has more probability of working, is for the 64-bit Python installer to include an extra registry entry that would allow the 32 bit versions to find the 64-bit version. (This might also require an install-time 64/32 compatibility check being added to the .exe header for bdist_wininst to prevent installing binary-incompatible extensions.) -- nosy: +pje ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6792 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7250] wsgiref.handlers.CGIHandler caches os.environ, leaking info between requests
Phillip J. Eby p...@telecommunity.com 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 also be applied as a monkeypatch, by simply doing
'CGIHandler.os_environ = {}' before using CGIHandler.
--
keywords: +26backport, easy, patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7250
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7250] wsgiref.handlers.CGIHandler caches os.environ, leaking info between requests
Phillip J. Eby p...@telecommunity.com 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't leak. In normal (i.e. pre-GAE) long-running web environments, os.environ would not contain any request information, only the process startup environment. This limitation of CGIHandler should be better documented, but it's a natural consequence of its design. The os_environ and base_environ variables are provided so that subclasses with specialized needs can handle them differently, and GAE is definitely a specialized need. If someone wants to provide a GAEHandler class, great; otherwise, the documented way to run a WSGI app under GAE is the google.appengine.ext.webapp.util.run_wsgi_app function. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7250] wsgiref.handlers.CGIHandler caches os.environ, leaking info between requests
Phillip J. Eby p...@telecommunity.com 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 behavior for any existing uses of CGIHandler that weren't already worse broken than the GAE case. ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7250 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError
Phillip J. Eby p...@telecommunity.com 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 here: http://mail.python.org/pipermail/distutils-sig/2009-October/013822.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7064] Python 2.6.3 / setuptools 0.6c9: extension module builds fail with KeyError
Phillip J. Eby p...@telecommunity.com 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), and so I will fix it in setuptools as well. I would like to point out, however, that subclassing is not monkeypatching. The distutils explicitly documents the ability to extend and subclass commands, and this particular subclassing was based on code provided by another distutils user, who'd extended build_ext to support building dynamic libraries. It is likely that that user, and anyone else who extended the build_ext command in a similar way (e.g. numpy's and Twisted's distutils extensions), could be affected by the change. So, this was neither a matter of monkeypatching, nor special treatment for setuptools. Setuptools is far from the first or last distutils extension ever written, and build_ext tends to get extended more than most other commands. It's important to remember subclassing use cases when modifying distutils commands; subclasses inherently rely on a stricter interface than a class's public API. -- nosy: +pje ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7064 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Phillip J. Eby p...@telecommunity.com 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 bytearray and memoryview objects in 3.0 really the same as bytestrings? It seems to me that allowing mutable bytes objects is a mistake from a bug-finding standpoint, even if it could be a win from a performance standpoint. I think it might be better to be more restrictive to start out, and then let people lobby for supporting other types, rather than the other way around, where we'll never get to narrow the list. Apart from that, the patch looks pretty good. Thank you! ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Phillip J. Eby p...@telecommunity.com 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 that your arguments regarding what revision should take place are irrelevant here; the correct forum for that discussion is the Web-SIG. Personally, I think they are valid arguments; WSGI simply did not have the benefit of having a sane (and standard!) bytes type available, and were we writing the spec today, I would absolutely have specified it in a bytes-oriented way, and treated older Pythons as the special case. However, we have to take into consideration how applications will be *migrated* to Py3K. I am not an expert in this, nor do I personally have huge volumes of code that will be migrated. Therefore, the correct forum for discussing migration impact and how best to write the spec is the Web-SIG. Making the change to bytes is not something to be undertaken on a whim: the spec must include how to handle inadvertent mixing of bytes and unicode, in order to allow unambiguous error handling and migration support. It will not be solved by the fiat of one individual: certainly not by you or I. And it has absolutely nothing to do with what is right in the technical sense, because it is not a technical problem. A specification is a social construct, not a technical one, so changing wsgiref by itself solves nothing. And that's why those three choices are the only available options, so far as I am aware. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Phillip J. Eby p...@telecommunity.com 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 that if Python had bytes from day 1, bytes would've been the way to go with it. But simply changing the reference library is not the way to change the spec. In the meantime, as far as I'm aware, there are two other patches pending to address these issues, but I'm not in a position to assess their readiness/correctness since I have yet to even download Py3K. In principle, I approve their approaches, so if someone else can handle the code review, those fixes could in principle be put in without changing the PEP. But to put *this* patch in, the PEP would have to be changed. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Phillip J. Eby p...@telecommunity.com 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 rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4718] wsgiref package totally broken
Phillip J. Eby p...@telecommunity.com 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 effects of running 2to3 on existing WSGI applications and/or servers. Will their code be converted to use bytes, or Unicode? The previous choice to use Unicode was based on source compatibility across Python implementations, so this shouldn't be thrown out on the basis of simple expediency. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4718 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4617] SyntaxError when free variable name is also an exception target
Phillip J. Eby p...@telecommunity.com 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 appropriate to drop the temporary nature of the variable. I could perhaps get behind resetting the variable to None instead of deleting it, but of course the PEP would need changing. There's also a question of whether we should do the same thing with with ... as variables. (Btw, I'm not sure why this one's assigned to me; ISTM I might have proposed the current except/as GC semantics, but I'm not familiar with the actual implementation in 2.6 or 3.0) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4617 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4330] wsgiref.validate doesn't accept arguments to readline
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 PROTECTED] http://bugs.python.org/issue4330 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4330] wsgiref.validate doesn't accept arguments to readline
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 reporting the failure of compliance. -- resolution: - invalid ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4330 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4330] wsgiref.validate doesn't accept arguments to readline
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's the cgi module that changed, not wsgiref. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4330 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3834] wsgiref.validator.InputWrapper readline method has wrong signature
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 code is to catch broken programs that pass an argument to readline() -- they are not WSGI-compliant. -- resolution: - invalid status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3834 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3348] Cannot start wsgiref simple server in Py3k
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-related questions. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3348 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3348] Cannot start wsgiref simple server in Py3k
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. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3348 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3348] Cannot start wsgiref simple server in Py3k
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 encoding; I'm just not clear on whether there are any other ramifications. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3348 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3348] Cannot start wsgiref simple server in Py3k
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 Python data structures, without imposing any *new* higher-level structures or conventions. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3348 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1180] Option to ignore or substitute ~/.pydistutils.cfg
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.python.org/issue1180 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1180] Option to ignore or substitute ~/.pydistutils.cfg
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. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1180 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1180] Option to ignore or substitute ~/.pydistutils.cfg
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 really bothers you, just create a temporary directory for HOME to point to, and test a Distribution subclass with an overridden check_environ. By the way, the patch could be simpler if you just made the if 'HOME' in os.environ read if not self.no_user_cfg and 'HOME' in os.environ, rather than reworking the entire code region. On the other hand, if you'd rather have ultra-clean unit tests, you could split the functionality of find_config_files() into two methods: one that creates the candidate list and the other that filters it by existence. Personally, my vote is to keep the monkeypatching in the tests and make the barest minimal changes to the Distribution class though. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1180 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1180] Option to ignore or substitute ~/.pydistutils.cfg
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 (if not actually parsing the command line enough to find the option). -- nosy: +pje __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1180 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
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 module. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2439 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
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 counter in the module it returns, making it into a loader that keeps track of how many times you reload the same module. Then it's a useful example loader. :) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2439 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
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_pep302 (__main__.PkgutilTests) ... ok
==
FAIL: test_alreadyloaded (__main__.PkgutilTests)
--
Traceback (most recent call last):
File Lib/test/test_pkgutil.py, line 45, in test_alreadyloaded
self.assertEqual(foo.loads, 1)
AssertionError: 2 != 1
==
FAIL: test_getdata_filesys (__main__.PkgutilTests)
--
Traceback (most recent call last):
File Lib/test/test_pkgutil.py, line 30, in test_getdata_filesys
self.assert_('PkgutilTests' in this_file)
AssertionError
--
Ran 3 tests in 0.017s
FAILED (failures=2)
I'm rebuilding my entire 2.6 checkout to double-check there's not
something else going on, but I know my Lib/ tree is up-to-date.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2439
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
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 a test case for that? -- nosy: +pje __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2439 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
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 problem (really the only one) that I spotted on this re-read. Your patch is calling load_module() even if the module is already in sys.modules. This will *reload* the module, potentially causing problems elsewhere in the system. You can test this by adding an assertion to your test's load_module(), that the module isn't already in sys.modules. Then call get_data for the same module twice. Sorry again for the mixup. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2439 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
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.python.org/issue2439 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1886] Permit to easily use distutils --formats=tar, gztar, bztar on all systems
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) instead of at the top level. Other than those two points, the patch looks great. -- nosy: +pje __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1886 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1576] First draft of a post import hook
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). Finally, it's not clear to me whether there's any way one of the import APIs can exit with the module added to sys.modules, but *without* the notify operation being called. It seems to me that those code paths were cleared up in 2.4 (i.e. failure to import causes the module to be removed from sys.modules), but it might be good to doublecheck that. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1576 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1004] MultiMethods with type annotations in 3000
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.org/issue1004 __ ___ 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
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 means that you don't need an option on the #! line in a zip file, which avoids hairy #! issues on platforms like Linux (where a #! line can have at most one argument). __main__ is used instead of __zipmain__, since it is not zipfile specific. -- nosy: +pje _ 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
Changes by Phillip J. Eby: _ 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
