Re: [Python-Dev] potential argparse problem: bad mix of parse_known_args and prefix matching
On Tue, Nov 26, 2013 at 9:30 AM, Eli Bendersky wrote:
> Hello,
>
> argparse does prefix matching as long as there are no conflicts. For
> example:
>
> argparser = argparse.ArgumentParser()
> argparser.add_argument('--sync-foo', action='store_true')
> args = argparser.parse_args()
>
> If I pass "--sync" to this script, it recognizes it as "--sync-foo". This
> behavior is quite surprising although I can see the motivation for it. At
> the very least it should be much more explicitly documented (AFAICS it's
> barely mentioned in the docs).
>
> If there's another argument registered, say "--sync-bar" the above will
> fail due to a conflict.
>
> Now comes the nasty part. When using "parse_known_args" instead of
> "parse_args", the above happens too - --sync is recognized for --sync-foo
> and captured by the parser. But this is wrong! The whole idea of
> parse_known_args is to parse the known args, leaving unknowns alone. This
> prefix matching harms more than it helps here because maybe the program
> we're actually acting as a front-end for (and hence using parse_known_args)
> knows about --sync and wants to get it.
>
> Unless I'm missing something, this is a bug. But I'm also not sure whether
> we can do anything about it at this point, as existing code *may* be
> relying on it. The right thing to do would be to disable this prefix
> matching when parse_known_args is called.
>
> Again, at the very least this should be documented (for parse_known_args
> not less than a warning box, IMHO).
>
I created http://bugs.python.org/issue19814 for the documentation patch.
http://bugs.python.org/issue14910 deals with making prefix matching
optional, but that will have to be deferred to 3.5
Eli
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: asyncio: Change write buffer use to avoid O(N**2). Make write()/sendto() accept
2013/11/27 guido.van.rossum : > http://hg.python.org/cpython/rev/80e0040d910c > changeset: 87617:80e0040d910c > user:Guido van Rossum > date:Wed Nov 27 14:12:48 2013 -0800 > summary: > asyncio: Change write buffer use to avoid O(N**2). Make write()/sendto() > accept bytearray/memoryview too. Change some asserts with proper exceptions. Was this change discussed somewhere? Antoine told me on IRC that it was discussed on the tulip mailing list. I would be nice to mention it in the commit message (for the next change ;-). > diff --git a/Lib/asyncio/selector_events.py b/Lib/asyncio/selector_events.py > --- a/Lib/asyncio/selector_events.py > +++ b/Lib/asyncio/selector_events.py > @@ -340,6 +340,8 @@ > > max_size = 256 * 1024 # Buffer size passed to recv(). > > +_buffer_factory = bytearray # Constructs initial value for self._buffer. > + Because the buffer type is now configurable, it would be nice to explain in a short comment why bytearray fits better this use case. (I like the bytearray object, so I like your whole changeset!) > @@ -762,6 +776,8 @@ > > class _SelectorDatagramTransport(_SelectorTransport): > > +_buffer_factory = collections.deque > + > def __init__(self, loop, sock, protocol, address=None, extra=None): > super().__init__(loop, sock, protocol, extra) > self._address = address Why collections.deque is preferred here? Could you also please add a comment? Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] test_uuid.py on HP NonStop Python-2.7.5 fails (test case: testIssue8621)
Hi, We are porting python to HP NonStop & to a large extent we have been successful. While running the unit tests we happen to hit upon the problem reported in issue8621(http://bugs.python.org/issue8621), i.e uuid4 sequences on both parent & child were same . On NonStop we lack support for both hardware randomness & uuid_generate family of calls, so on NonStop "uuid.py" falls throw to random.range() call to generate the random number which in turn is used by the UUID class. Below the code snip that can used to repo the problem... #!/usr/bin/python import os import sys import uuid import random #Code taken from Lib/uuid.py def myuuid(): bytes = [chr(random.randrange(256)) for i in range(16)] val = uuid.UUID(bytes=bytes, version=4) return val # Code taken from Lib/test/test_uuid.py # # On at least some versions of OSX myuuid generates # the same sequence of UUIDs in the parent and any # children started using fork. for i in range(10): fds = os.pipe() pid = os.fork() if pid == 0: os.close(fds[0]) value = myuuid() os.write(fds[1], value.hex) os._exit(0) else: os.close(fds[1]) parent_value = myuuid().hex os.waitpid(pid, 0) child_value = os.read(fds[0], 100) os.close(fds[0]) print parent_value, child_value, (parent_value == child_value) We also ran the above test on Linux & were seeing the same results as on NonStop, i.e uuid4 sequences on both parent & child were same. Output snippet. [vsnag@ Python-2.7.5]$ uname -a Linux 2.6.32-71.el6.x86_64 #1 SMP Wed Sep 1 01:33:01 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux [vsnag@ Python-2.7.5]$ ./python test.py 2b512ef47c9f471a829148ca4e779dff 2b512ef47c9f471a829148ca4e779dff True e39b605476e04ca2b992b5d055278c3b e39b605476e04ca2b992b5d055278c3b True 8249fb9f6a2045c084da549c9e393a51 8249fb9f6a2045c084da549c9e393a51 True e1d9e84b7f134930abf5fb2760f07585 e1d9e84b7f134930abf5fb2760f07585 True 068f9612f0744eeb92dbca8950028a3c 068f9612f0744eeb92dbca8950028a3c True e85df457614f47d5b6300186bdd1c798 e85df457614f47d5b6300186bdd1c798 True a8628a0817b843778e9565b835b8cfac a8628a0817b843778e9565b835b8cfac True 478d8e9e5090498e9fad5356c5ae9568 478d8e9e5090498e9fad5356c5ae9568 True 151d7f1c8f8b42099a89a0f442e98dc7 151d7f1c8f8b42099a89a0f442e98dc7 True 838571b03a5b46f8a06398e020647d89 838571b03a5b46f8a06398e020647d89 True [vsnag@ Python-2.7.5]$ Any thoughts what could be going wrong? Thanks & Regards Nagendra.V.S ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
