[issue16398] deque.rotate() could be much faster
Simon Law added the comment: Raymond, looking at your patch, can we assert that deque->leftblock is never equal to deque->rightblock? If not, you need to use memmove() instead of memcpy(), which is unsafe for overlapping arrays. It is not clear to me that this invariant is true. At the very least, an assertion should be there to protect future refactorings. -- ___ Python tracker <http://bugs.python.org/issue16398> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9974] tokenizer.untokenize not invariant with line continuations
Changes by Simon Law : -- nosy: +sfllaw ___ Python tracker <http://bugs.python.org/issue9974> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16398] deque.rotate() could be much faster
New submission from Simon Law: If you look at the implementation of deque.rotate(), it does the equivalent of deque.append(deque.popleft()) or deque.appendleft(deque.pop()). Unfortunately, for larger rotations, the pop() and append() calls just do too much work. Since the documentation recommends using rotate() to do slicing-style operations, this could get seriously slow. deque.rotate() could just touch up the internal pointers and use memmove() to realign the data. Benchmarks, of course, would have to be written to make sure this is a win. -- components: Library (Lib) messages: 174679 nosy: sfllaw priority: normal severity: normal status: open title: deque.rotate() could be much faster type: performance versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue16398> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15125] argparse: positional arguments containing - in name not handled well
Simon Law added the comment: 15125-2.patch applies to the default branch. It makes dest behave the same for positional and optional arguments in terms of name mangling. Also, there is a backward-compatibility path in Namespace to support old-style getattr() access. However, it's not documented as we really don't want people to use it. -- Added file: http://bugs.python.org/file27863/15125-2.patch ___ Python tracker <http://bugs.python.org/issue15125> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15125] argparse: positional arguments containing - in name not handled well
Simon Law added the comment: Note that 15125-1.patch applies to Python 2.7 cleanly as it is a bugfix. -- ___ Python tracker <http://bugs.python.org/issue15125> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15125] argparse: positional arguments containing - in name not handled well
Simon Law added the comment: Sorry, there was a small typo in the previous patch. Here's the newer version. -- Added file: http://bugs.python.org/file27860/15125-1.patch ___ Python tracker <http://bugs.python.org/issue15125> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15125] argparse: positional arguments containing - in name not handled well
Simon Law added the comment:
>> But patching the module to allow explicitly setting dest via keyword
>> argument shouldn't hurt anybody.
>
> I agree that it wouldn't hurt anybody. If you can find a way to do
> this, feel free to provide a patch.
>
> However, the correct way to have one name for the attribute (i.e.
> dest=) and one name for the help (i.e. metavar=) is to use the
> metavar argument like so:
>
> parser.add_argument('positional_args', metavar='positional-args')
I don't think that making ``dest`` more magical is a good idea. In the
included patch, you'll find a change that makes the ValueError tell
people about ``metavar``, which is the right way to go about things
anyway.
> That said, this is not the first time I've seen someone run into this
> problem. I think the documentation could be improved in a few ways:
>
> (1) In the "name or flags" section, describe how the flags (for
> optional arguments) are translated into both a default "dest"
> (stripping initial '-' and converting '-' to '_') and into a default
> "metavar" (stripping initial '-' and uppercasing). Part of this is
> in the "dest" and "metavar" documentation, but probably belongs up
> in the "name or flags" documentation. Add cross-references to "dest"
> and "metavar" sections.
In the included patch.
> (2) In the "name or flags" section, describe how the name (for
> positional arguments) are translated into the same default "dest"
> and "metavar" (no string munging at all). Again, move stuff from the
> "dest" and "metavar" sections as necessary. Add cross-references to
> "dest" and "metavar" sections.
>
> (3) In the "dest" section and somewhere in the "parse_args" section,
> describe how "getattr" can be used to get attributes whose names
> aren't valid Python identifiers. Maybe cross-reference this section
> from the edits in (2).
If we make optional and positional arguments consistent, and provide
backwards-compatibility for positional arguments, then these two are
not necesssary.
--
nosy: +sfllaw
Added file: http://bugs.python.org/file27859/15125-1.patch
___
Python tracker
<http://bugs.python.org/issue15125>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16395] Documentation claims that PySequence_Fast returns a tuple, when it actually returns a list.
Simon Law added the comment: It looks like this was caught in the 3.3 branch, but only fixed it in the comment: changeset: 75448:d8f68195210e user:Larry Hastings date:Mon Mar 05 22:59:13 2012 -0800 summary: Fix a comment: PySequence_Fast() creates a list, not a tuple. The included patch applies cleanly to Python 2.7 and 3.2. When applying to 3.3, include the failure in Objects/abstract.c because the same change has already been made. -- keywords: +patch Added file: http://bugs.python.org/file27857/16395.patch ___ Python tracker <http://bugs.python.org/issue16395> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16395] Documentation claims that PySequence_Fast returns a tuple, when it actually returns a list.
New submission from Simon Law: The documentation in Python 2.7, 3.2, and 3.3 claim that: PyObject* PySequence_Fast(PyObject *o, const char *m) Return value: New reference. Returns the sequence o as a tuple, unless it is already a tuple or list, in which case o is returned... Unfortunately, the code does this in Objects/abstract.c: v = PySequence_List(it); And the header file in Include/abstract.h matches the documentation: PyAPI_FUNC(PyObject *) PySequence_Fast(PyObject *o, const char* m); /* Returns the sequence, o, as a tuple, unless it's already a tuple or list. */ -- components: Interpreter Core messages: 174633 nosy: sfllaw priority: normal severity: normal status: open title: Documentation claims that PySequence_Fast returns a tuple, when it actually returns a list. type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue16395> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue444582] Finding programs in PATH, adding shutil.which
Changes by Simon Law : -- nosy: +sfllaw ___ Python tracker <http://bugs.python.org/issue444582> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1697175] winreg module for cygwin?
Simon Law added the comment: zooko: You may be interested in http://pypi.python.org/pypi/cygwinreg/ -- nosy: +sfllaw ___ Python tracker <http://bugs.python.org/issue1697175> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
