[issue23532] regex "|" behavior differs from documentation

Mark Shannon added the comment: This looks like the expected behaviour to me. re.sub matches the leftmost occurence and the regular expression is greedy so (x|xy) will always match xy if it can. -- nosy: +Mark.Shannon ___ Python tracker <h

[issue23601] use small object allocator for dict key storage

Changes by Mark Shannon : -- nosy: +Mark.Shannon ___ Python tracker <http://bugs.python.org/issue23601> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue21992] New AST node Else() should be introduced

Mark Shannon added the comment: I would say yes, it is too late. Any change to the AST is a breaking change. The current AST is full of missing line numbers, incorrect column offsets and other inconsistencies. To fix them all would be a major undertaking with no obvious benefit to the core

[issue23601] use small object allocator for dict key storage

Mark Shannon added the comment: I don't remember why PyMem_Malloc rather than PyObject_MALLOC was used, it may have been inherited from the allocation of dict tables in the earlier implementation. My only concern is that the benchmark only tests performance for very small dictionaries

[issue21295] Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse

Mark Shannon added the comment: You are on the nosy list. You should have got sent an email. This bug is the regression. https://hg.python.org/cpython/rev/7c5c678e4164/ resulted in incorrect column offsets for many compound expressions

[issue21295] Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse

Mark Shannon added the comment: The column offset has always been the offset of the start of the expression. Therefore the expression `x.y` should have the same offset as the sub-expresssion `x`. Likewise for calls, `f(args)` should have the same offset as the `f` sub expression. Our static

[issue21295] Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse

Mark Shannon added the comment: How do I get the start of `(x+y).bit_length()` in `total += (x+y).bit_length()`? With your change, I can't get it from `x`, `x+y`, or from the whole statement. The primary purpose of the locations are for tracebacks, not for static tools. Also, most tools

[issue24119] Carry comments with the AST

Mark Shannon added the comment: Comments don't belong on the AST. Where would you attach them? The tokenizer module provides all information about comments. Tools can get the information quite easily if they need it. -- nosy: +Mark.Sh

[issue22865] Document how to make pty.spawn not copy data

Geoff Shannon added the comment: Okay, I just found another way to achieve the same effect of letting the _read function ignore data but not inadvertantly close the stream. It relies on the fact that terminals will ignore null bytes fed to them. Now there are no code changes required, just

[issue24275] lookdict_* give up too soon

Mark Shannon added the comment: I don't understand why this has been closed. I agree with Jim's analysis. Lookups do not change the dict and the choice of lookdict_* variant depends solely on the set of keys. In fact, lookdict_split *doesn't* replace itself, it merely

[issue16991] Add OrderedDict written in C

Mark Shannon added the comment: I realise that I am bit late to the party, but I would like to point out that a smaller, arguably simpler, and almost certainly faster alternative design exists. This design simply consists of an array of (prev, next, key) nodes attached to the base dict. The

[issue1649329] Extract file-finding and language-handling code from gettext.find

Shannon -jj Behrens added the comment: > OTOH maybe a lightweight ABC with mixin methods and a concrete implementation > of the full gettext logic may be clear and educational here. Shannon, if > you’re still getting those emails, what do you think? Yep, that&

[issue1649329] Extract file-finding and language-handling code from gettext.find

Shannon -jj Behrens added the comment: Although, perhaps this bug is going away. It seems like using zip files for eggs is going out of vogue. -- ___ Python tracker <http://bugs.python.org/issue1649

[issue1649329] Extract file-finding and language-handling code from gettext.find

Shannon -jj Behrens added the comment: I've never managed to get a patch into Python, but I wouldn't mind trying ;) -- ___ Python tracker <http://bugs.python.org

[issue1649329] Extract file-finding and language-handling code from gettext.find

Shannon -jj Behrens added the comment: Sorry, I just had a baby on Saturday. Hence, I'm a bit late getting to this. It might take me a couple weeks. -- ___ Python tracker <http://bugs.python.org/issu

[issue1649329] Extract file-finding and language-handling code from gettext.find

Shannon -jj Behrens added the comment: The more I think about this, the more I think we should just drop it. * The easiest way around my original problem was to not install the eggs in zipped format. That's easy. Just mark the egg as not zip safe. * I don't currently

[issue3893] timedelta overflows in a surprising way

New submission from Shannon -jj Behrens <[EMAIL PROTECTED]>: I was very surprised by the following behavior: >>> from datetime import datetime >>> now = datetime.today() >>> future = datetime.today() >>> (now - future).seconds 86395 I kno

[issue3893] timedelta overflows in a surprising way

Shannon -jj Behrens <[EMAIL PROTECTED]> added the comment: Yes, that makes perfect sense. Sorry, I missed that part of the docs. Please feel free to close this bug. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue30443] datetime.datetime.__add__ does not respect fold.

New submission from Michael R. Shannon: datetime.datetime.__add__ is currently implemented by converting the date into a datetime.timedelta object (using toordinal) before adding it to the other (timedelta) object and reconstructing with datetime.combine. With this method, fold will always

<    8   9   10   11   12   13