[issue45690] Argparse exclusive group inside required exclusive group displays incorrectly
New submission from andrew cooke : The code below, when invoked with -h, prints: (.env) [andrew@localhost py]$ python -m tests_sa.argparse_bug -h usage: argparse_bug.py [-h] (-a A | [-b B | -c C)] options: -h, --help show this help message and exit -a A -b B -c C where the final two characters in the usage line are swapped. It should be usage: argparse_bug.py [-h] (-a A | [-b B | -c C]) or maybe even usage: argparse_bug.py [-h] (-a A | (-b B | -c C)) from argparse import ArgumentParser def main(): parser = ArgumentParser() outer = parser.add_mutually_exclusive_group(required=True) outer.add_argument('-a') inner = outer.add_mutually_exclusive_group() inner.add_argument('-b') inner.add_argument('-c') parser.parse_args() if __name__ == '__main__': main() -- components: Library (Lib) messages: 405509 nosy: acooke priority: normal severity: normal status: open title: Argparse exclusive group inside required exclusive group displays incorrectly versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue45690> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18422] is_package missing so can't use -m
andrew cooke added the comment: in case anyone else ends up here through google... the problem described here is not related to the linked issue. it was just a missing `__init__.py` in the module (plus sucky error messages). the following works fine: . ├── README.md ├── src │ └── simplessl │ ├── ca.py │ ├── __init__.py │ ├── __main__.py │ ├── req.py │ └── utils.py └── ssl.iml -- ___ Python tracker <http://bugs.python.org/issue18422> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18423] Document limitations on -m
New submission from andrew cooke: Apparently the limited support for -m is standard behaviour - see http://bugs.python.org/issue18422 - but it's not documented at http://docs.python.org/3/using/cmdline.html#cmdoption-m That should say, somewhere, that it only applies to leaf modules and packages. -- assignee: docs@python components: Documentation messages: 192804 nosy: acooke, docs@python priority: normal severity: normal status: open title: Document limitations on -m ___ Python tracker <http://bugs.python.org/issue18423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18422] is_package missing so can't use -m
andrew cooke added the comment: can't see how to edit posts, so adding as a comment, this is what triggers the bug: > PYTHONPATH=src python -m simplessl -- ___ Python tracker <http://bugs.python.org/issue18422> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18422] is_package missing so can't use -m
New submission from andrew cooke: Using python 3.3, if I try to run __main__ I see this error: Traceback (most recent call last): File "/usr/local/lib/python3.3/runpy.py", line 140, in _run_module_as_main mod_name, loader, code, fname = _get_module_details(mod_name) File "/usr/local/lib/python3.3/runpy.py", line 105, in _get_module_details if loader.is_package(mod_name): AttributeError: 'NamespaceLoader' object has no attribute 'is_package' My directory structure is: > tree . . ├── README.md ├── src │ └── simplessl │ ├── ca.py │ ├── __main__.py │ ├── req.py │ └── utils.py └── ssl.iml i assume this is related to http://bugs.python.org/issue18058 but don't understand why this is not a bugfix that can be back-ported. this appears to be a bug to me... -- components: Installation messages: 192799 nosy: acooke priority: normal severity: normal status: open title: is_package missing so can't use -m versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue18422> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17403] Robotparser fails to parse some robots.txt
andrew cooke added the comment: thanks (only subscribed to this now, so no previous email). my guess is that google are assuming a dumb regexp so http://example.com/foo? in a rule does not match http://example.com/foo and also i realised that http://google.com/robots.txt doesn't contain any url with multiple parameters. so perhaps i was wrong about needing a canonical representation (ie parameter ordering). -- ___ Python tracker <http://bugs.python.org/issue17403> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17403] Robotparser fails to parse some robots.txt
andrew cooke added the comment: what is rietveld? and why is this marked as "easy"? it seems like it involves issues that aren't described well in the spec - it requires some kind of canonical way to describe urls with (and without) parameters to solve completely. -- nosy: +acooke ___ Python tracker <http://bugs.python.org/issue17403> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12897] Support for iterators in multiprocessing map
andrew cooke added the comment: hi - i'm the original author (may be using a different account). as far as i remember, i raised this because it seemed relevant given the link i gave. if you've looked at the issue and think your approach would work, or that this should be closed, or whatever, that's fine by me. i'm not going to check myself - i can't remember anything about this now (nearly a year later) and it's not my place to worry about your code (no offence - just trying to clarify that i have no skin in this game). -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue12897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12029] Catching virtual subclasses in except clauses
Changes by andrew cooke : -- nosy: -acooke ___ Python tracker <http://bugs.python.org/issue12029> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12029] Catching virtual subclasses in except clauses
andrew cooke added the comment: perhaps it could just work in a simple, consistent way? in my original report i wondered whether there was a significant performance hit. but so far the objections against fixing this seem to be (1) a lawyer could be convinced the current behaviour is consistent with the docs (2) python 3 should remain compatible with python 2 (3) abcmeta is the sucksorz. those don't seem like great arguments against making it just work right, to me. -- ___ Python tracker <http://bugs.python.org/issue12029> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12897] Support for iterators in multiprocessing map
New submission from andrew cooke : http://stackoverflow.com/questions/7306522/combining-itertools-and-multiprocessing/7307078 suggests (and the idea itself seems reasonable) that it would sometimes be useful for multiprocessing to operate correctly (ie lazily) with lazy input (iterables). for example, if the input is large, or perhaps generated by some other process "on demand". obviously this complicates matters, given the asynchronous nature of a worker pool, and would mean re-allocating the results list as required. but in principle i suspect it would be possible and might be a useful extension. -- components: Library (Lib) messages: 143511 nosy: acooke priority: normal severity: normal status: open title: Support for iterators in multiprocessing map type: feature request versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue12897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12029] ABC registration of Exceptions
New submission from andrew cooke : Hi, In general, registering a class with an ABC is equivalent to making it a subclass (isinstance and issubclass are patched through ABCMeta). However, this does not work for exceptions (see example below, where exception is not caught). This doesn't seem terribly surprising to me - I imagine that checking would slow down exception handling - but I couldn't find any documentation (and posting on c.l.p didn't turn up anything either). So I thought I would raise it here - perhaps there is a possible fix (my obscure use case is that I have a backtracking search; backtracking occurs when a certain exception is encountered; making that exception an ABC and allowing existing exceptions to be registered with it allows the search to work with existing code without a wrapper that catches and translates exceptions that should trigger a backtrack). Or perhaps the docs could be extended. Or perhaps I've misunderstood something... Cheers, Andrew Python 3.2 (r32:88445, Feb 27 2011, 13:00:05) [GCC 4.5.0 20100604 [gcc-4_5-branch revision 160292]] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from abc import ABCMeta >>> class RootException(Exception,metaclass=ABCMeta): pass ... >>> class MyException(Exception): pass ... >>> RootException.register(MyException) >>> try: ... raise MyException ... except RootException: ... print('caught') ... Traceback (most recent call last): File "", line 2, in __main__.MyException -- components: Interpreter Core messages: 135521 nosy: acooke priority: normal severity: normal status: open title: ABC registration of Exceptions type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue12029> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
andrew cooke added the comment: Ah good point, thanks. -- ___ Python tracker <http://bugs.python.org/issue9179> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
andrew cooke added the comment: I thought someone was working on the re module these days? I thought there I'd seen some issues with patches etc? Anyway, short term, sorry - no patch. Medium/long term, yes it's possible, but please don't rely on it. The simplest way to document it is as you suggest, I think - just extend the qualifier on lookback requiring fixed length to exclude references to groups (it does seem to *bind* groups correctly on lookback, so there's no need to exclude them completely). -- ___ Python tracker <http://bugs.python.org/issue9179> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
andrew cooke added the comment: If it's any help, these are the equivalent tests as I think they should be (you'll need to translate engine(parse(... to compile(...) http://code.google.com/p/rxpy/source/browse/rxpy/src/rxpy/engine/backtrack/_test/engine.py?r=fc52f6959a0cfabdddc6960f47d7380128bb3584#284 -- ___ Python tracker <http://bugs.python.org/issue9179> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
andrew cooke added the comment: I hope the above is clear enough (you need to stare at the regexps for a time) - basically, lookback with a group conditional is not as expected (it appears to be evaluated as lookahead?). Also, some patterns compile that probably shouldn't. The re package only supports (according to the docs) lookback on expressions whose length is known. So I guess it's also possible that (?(n)pat1|pat2) should always fail that, even when len(pat1) = len(pat2)? Also, the generally excellent unit tests for the re package don't have much coverage for lookback (I am writing my own regexp lib and it passes all the re unit tests but had a similar bug - that's how I found this one...). -- ___ Python tracker <http://bugs.python.org/issue9179> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
New submission from andrew cooke : from re import compile # these work as expected assert compile('(a)b(?<=b)(c)').match('abc') assert not compile('(a)b(?<=c)(c)').match('abc') assert compile('(a)b(?=c)(c)').match('abc') assert not compile('(a)b(?=b)(c)').match('abc') # but when you add groups, you get bugs assert not compile('(?:(a)|(x))b(?<=(?(2)x|c))c').match('abc') # matches! assert not compile('(?:(a)|(x))b(?<=(?(2)b|x))c').match('abc') assert compile('(?:(a)|(x))b(?<=(?(2)x|b))c').match('abc') # fails! assert not compile('(?:(a)|(x))b(?<=(?(1)c|x))c').match('abc') # matches! assert compile('(?:(a)|(x))b(?<=(?(1)b|x))c').match('abc') # fails! # but lookahead works as expected assert compile('(?:(a)|(x))b(?=(?(2)x|c))c').match('abc') assert not compile('(?:(a)|(x))b(?=(?(2)c|x))c').match('abc') assert compile('(?:(a)|(x))b(?=(?(2)x|c))c').match('abc') assert not compile('(?:(a)|(x))b(?=(?(1)b|x))c').match('abc') assert compile('(?:(a)|(x))b(?=(?(1)c|x))c').match('abc') # these are similar but, in my opinion, shouldn't even compile # (group used before defined) assert not compile('(a)b(?<=(?(2)x|c))(c)').match('abc') # matches! assert not compile('(a)b(?<=(?(2)b|x))(c)').match('abc') assert not compile('(a)b(?<=(?(1)c|x))(c)').match('abc') # matches! assert compile('(a)b(?<=(?(1)b|x))(c)').match('abc') # fails! assert compile('(a)b(?=(?(2)x|c))(c)').match('abc') assert not compile('(a)b(?=(?(2)b|x))(c)').match('abc') assert compile('(a)b(?=(?(1)c|x))(c)').match('abc') # this is the error we should see above try: compile('(a)\\2(b)') assert False, 'expected error' except: pass -- components: Library (Lib) messages: 109382 nosy: acooke priority: normal severity: normal status: open title: Lookback with group references incorrect (two issues?) type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue9179> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7792] Errors registering non-classes with ABCs
New submission from andrew cooke : There are two related issues here. The first is, I think, a simple bug: When I try to register a function as a subclass of an ABC I get the error: TypeError: issubclass() arg 2 must be a class or tuple of classes Looking at the code - http://svn.python.org/view/python/trunk/Lib/abc.py?annotate=72278 - it seems that instead the test at line 99 should have triggered a better error: TypeError("Can only register classes") In other words, line 99 should read: if not isinstance(subclass, type): (currently the code tests the "self class", cls, which is pointless). My second issue is that this shouldn't raise an error at all. It should be possible for functions to be registered as subclasses of ABCs. This would simplify some code of mine that uses functions and classes interchangeably, and I can see no "real" reason why it shouldn't work. From the user's point of view, my library provides a bunch of "things" that all look the same (they are provided with arguments and do stuff). Whether these are constructors or functions is irrelevant... and yet my code has to handle constructors and functions differently simply because of the errors here. What I suspect I will do is have my own hash table, and forget ABCs, but that is a pity because these functions really do work as constructors (they are factories) and so the idea of them being subclasses of an ABC helps clarify my code. -- components: Library (Lib) messages: 98387 nosy: acooke severity: normal status: open title: Errors registering non-classes with ABCs type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue7792> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3058] Let SimpleXMLRPCServer pass client_address to called functions.
andrew cooke added the comment: Came here wondering how best to solve this myself. I already subclass the request handler to do client validation (password etc) and it stuck me that a simpler solution would be to use thread local storage. This avoids having to modify dispatch. The disadvantage is that this uses a single global scope. I don't think it's a better solution than that suggested by samwyse for a final solution, but I thought I'd note it here because it's a simpler alternative for people needing to add a work-around, and I suspect many people aren't aware of the possibility. >>> import _threading_local ; help(_threading_local) If this wouldn't work (maybe I've misunderstood the server threading?) then I'd appreciate someone correcting me. Thanks. -- nosy: +acooke ___ Python tracker <http://bugs.python.org/issue3058> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4986] Augmented Assignment / Operations Confusion in Documentation
andrew cooke added the comment: thanks! ___ Python tracker <http://bugs.python.org/issue4986> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4986] Augmented Assignment / Operations Confusion in Documentation
New submission from andrew cooke : There's a small confusion in terminology in the documentation related to methods that implement augmented assignment. The "Expressions" section of the language reference ("Simple statements") refers to augmented assignment - http://docs.python.org/3.0/reference/simple_stmts.html#augmented-assignment-statements - and this seems to be a carefully chosen (and correct) phrase because the parsing is related to assignments, which are augmented with various operators. It is important to note that augmented assignments ("+=" etc) are *not* parsed as operators. It is syntax error to use them in many places where an operator would be accepted. In the "Data Model" section, however, things are less clear http://docs.python.org/3.0/reference/datamodel.html#emulating-numeric-types . The methods used to implement augmented assignment are grouped near those used to implement arithmetic operators. That seems natural. But the text confuses the two more than is strictly necessary. In particular there is the phrase "augmented arithmetic operations". As I have already tried to make clear, these are not operations. They are augmented assignments. Calling them operations is misleading, because they cannot be used in the same places as "real" operations - the parser simply will not accept them. Apart from changing "augmented arithmetic operations" to "augmented assignments" it might be worth adding some kind of note that explains to the user that the parser calls those methods to implement assignment, and that they are not valid in the same syntax as operations. I am not sure the following will help, but it does illustrate the confusion caused - http://groups.google.com/group/comp.lang.python/browse_thread/thread/f1322928300b2b71 Cheers, Andrew -- assignee: georg.brandl components: Documentation messages: 80098 nosy: acooke, georg.brandl severity: normal status: open title: Augmented Assignment / Operations Confusion in Documentation versions: Python 3.0 ___ Python tracker <http://bugs.python.org/issue4986> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2697] Logging ancestors ignored after configuration
andrew cooke <[EMAIL PROTECTED]> added the comment: Got more important things than this to worry about, but yes, original response not very helpful. In a perfect world this might be either justified more clearly or addressed. OTOH, I get the impression hardly anyone uses this package (docs were pretty opaque...) Also, isn't this a "won't fix" rather than an "invalid"? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2697> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2697] Logging ancestors ignored after configuration
New submission from andrew cooke <[EMAIL PROTECTED]>: I am seeing some odd behaviour with logging which would be explained if loggers that are not defined explicitly (but which are controlled via their ancestors) must be created after the logging system is configured via fileConfig(). That's a bit abstract, so here's the problem itself: I define my log within a module by doing import logging log = logging.getLogger(__name__) Now typically __name__ will be something like "acooke.utils.foo". That happens before the application configures logging, which it does by calling logging.config.fileConfig() to load a configuration. If I do that, then I don't see any logging output from "acooke.utils.foo" (when using "log" from above after "fileConfig" has been called) unless I explicitly define a logger with that name. Neither root nor an "acooke" logger, defined in the config file, are called. One way to handle this is to make creation of module-level Loggers lazy, and make sure that logging initialisation occurs before any other logging is actually used (which is not so hard - just init log at the start of the application). Of course, there's a performance hit... For example: class Log(object): def __init__(self, name): super(Log, self).__init__() self._name = name self._lazy = None def __getattr__(self, key): if not self._lazy: self._lazy = logging.getLogger(self._name) return getattr(self._lazy, key) and then, in some module: from acooke.util.log import Log log = Log(__name__) [...] class Foo(object): def my_method(self): log.debug("this works as expected") -- components: Library (Lib) messages: 65843 nosy: acooke severity: normal status: open title: Logging ancestors ignored after configuration type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2697> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com