Mailman 3 July 2015 - Python-ideas

Disallow "00000" as a synonym for "0"
by Neil Girdhar July 20, 2015

July 20, 2015

As per this question: http://stackoverflow.com/questions/31447694/why-does-python-3-allow-00-as-a… It seems like Python accepts "000000000" to mean "0". Whatever the historical reason, should this be deprecated?

9 14

namedtuple fields with default values
by Russell Kaplan July 17, 2015

July 17, 2015

I'm using a namedtuple to keep track of several fields, only some of which ever need to be specified during instantiation. However, there is no Pythonic way to create a namedtuple with fields that have default values. >>> Foo = namedtuple('Foo', ['bar', 'optional_baz']) >>> f = Foo('barValue') # Not passing an argument for every field will cause a TypeError Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: __new__() takes exactly 3 arguments (2 given) If you do want default parameters for a namedtuple, the workaround right now involves modifying Foo.__new__'s defaults: >>> Foo = namedtuple('Foo', ['bar', 'optional_baz']) >>> Foo.__new__.__defaults__ = (None, None) Then you can call Foo's constructor without specifying each field: >>> f = Foo('barValue') >>> f Foo(bar='barValue', optional_baz=None) Having to assign to Foo.__new__.__defaults__ is a bit ugly. I think it would be easier and more readable to support syntax like: >>> Foo = namedtuple('Foo', ['optional_bar=None', 'optional_baz=None']) This suggestion is fully backwards compatible and allows for cleaner definitions of nametuples with default-value fields. Thanks for considering. Russell

6 5

Should a single/double quote followed by a left parenthesis raise SyntaxError?
by Jacob Niehus July 17, 2015

July 17, 2015

I recently forgot the '%' between a format string and its tuple of values and got "TypeError: 'str' object is not callable." The error makes sense, of course, because function calling has higher precedence than anything else in the expression, so while: >>> '%s' 'abc' yields '%sabc', >>> '%s' ('abc') yields a TypeError. My question is whether this should be caught as a syntax error instead of a runtime error. I can't think of any possible case where a single/double quote followed by '(' (optionally separated by whitespace) would not raise an exception when the '(' is not in a string or comment. I even wrote a script (below) to check every Python file on my computer for occurrences of the regular expression r'[''"]\s*\(' occurring outside of a string or comment. The sole result of my search, a file in a wx library, is a definite runtime error by inspection: raise IndexError, "Index out of range: %d > %d" (idx, len(self._items)) Can anyone think of a counter-example? -Jake -------------------------------------------------------------------------------- #!/usr/bin/env python2 import re import sys import tokenize from py_compile import PyCompileError, compile ttypes = {v: k for k, v in tokenize.__dict__.items() if isinstance(v, int) and k == k.upper()} for filename in sys.argv[1:]: lines = file(filename, 'r').readlines() matches = [] for lnum, line in enumerate(lines, 1): for match in re.finditer(r'[''"]\s*\(', line): matches.append((lnum, match.span(), match.group(0))) try: assert(matches) compile(filename, doraise=True) except (AssertionError, PyCompileError, IOError): continue matchdict = {k: [] for k in [m[0] for m in matches]} for match in matches: matchdict[match[0]].append(match) with open(filename, 'r') as f: gen = tokenize.generate_tokens(f.readline) for ttype, tstr, (srow, scol), (erow, ecol), line in gen: if srow == erow: for mrow, (mscol, mecol), mstr in matchdict.get(srow, []): pcols = [mscol + i for i, x in enumerate(mstr) if x == '('] for p in pcols: if (p in range(scol, ecol) and ttypes[ttype] not in ['COMMENT', 'STRING']): print filename print srow print ttypes[ttype]

8 16

Concurrency Modules
by Sven R. Kunze July 11, 2015

July 11, 2015

Hi, that's a follow up on the discussion started on python-dev ('The importance of the async keyword') and this issue http://bugs.python.org/issue24571 . After discussing the whole topic and reading it up further, it became clear to me what's actually missing in Python. That is a definitive guide of why/when a certain concurrency module is supposed to be used: Currently, I can name 4 modules of which I know that they more or less deal with the topic: - concurrent - threading - asyncio - multiprocessing In order to make a sound decision for the question: "Which one(s) do I use?", at least the following items should be somehow defined clearly for these modules: 1) relationship between the modules 2) NON-overlapping usage scenarios 3) future development intentions 4) ease of usage of the modules => future syntax 5) examples Remarks to the items: 1) For the basic understanding Do they complement each other? Differences in behavior? Do they overlap from the perspective of the programmer? They mostly do not care about internal details; they need to get things done (threads <-> processes) as long as the result is the same. 2) Extremely important to make the decision fast 3) Will asyncio incorporate all concepts of the other modules in a seamless way? Or are they just complementary? 4) Closely related to 3) 5) Maybe in close correlation with 2) and 1) Cheers, Chuck

10 13

Rename python-dev?
by Ryan Gonzalez July 10, 2015

July 10, 2015

This is a crazy idea that popped into my head recently. What if python-dev were to be renamed to something like python-internals? (Yeah, that's a bad name, but my naming skills suck...) Basically, something that gets across the idea that it's for development of Python, not in Python. Python-dev would visibly disappear, but mails sent to python-dev would be redirected to the new name. BTW, in reality, it's not an uncommon mistake. I know of a few mailing lists built for development *with* a tool that end in -dev, such as asmjit-dev. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

6 5

@contextlib.contextmanager(with_context=True) - passing a context to contextmanager
by Giampaolo Rodola' July 10, 2015

July 10, 2015

contextlib.contextmanager in Python 3 added the ability to define functions which work both as decorators and context managers, which is great and one of the features I appreciate the most about Python 3 (seriously). I am facing a use case where I find contextlib.contextmanager has some limitations though. I have a decorator which looks like this: def wrap_exceptions(fun): """Decorator which translates bare OSError and IOError exceptions into NoSuchProcess and AccessDenied. """ @functools.wraps(fun) def wrapper(self, *args, **kwargs): # here "self" is the Process class instance try: return fun(self, *args, **kwargs) except EnvironmentError as err: if err.errno in (errno.ENOENT, errno.ESRCH): raise NoSuchProcess(self.pid, self._name) if err.errno in (errno.EPERM, errno.EACCES): raise AccessDenied(self.pid, self._name) raise return wrapper ...and I use it like this: class Process: @wrap_exceptions def exe(): ... The two key things about this decorator are: - it's designed to be used with class methods - it has a reference to the method's class instance (self) I would like to push this a bit further and make wrap_exceptions() work also a contextmanager, which is what contextlib.contextmanager should allow me to do in an easy way. As contextlib.contextmanager stands right it won't allow my use case though as there's no way to pass a reference of the class instance (Process) to wrap_exceptions. So here is my proposal: what if we add a new "with_context" argument to contextlib.contextmanager? The resulting code would look like this: @contextlib.contextmanager(with_context=True) def wrap_exceptions(ctx): # ctx is the Process class instance try: yield except EnvironmentError as err: pid = ctx.pid name = ctx.name if err.errno in (errno.ENOENT, errno.ESRCH): raise NoSuchProcess(pid, name) if err.errno in (errno.EPERM, errno.EACCES): raise AccessDenied(pid, name) raise class Process: @wrap_exceptions() def exe(): ... class Process: def exe(self): with wrap_exceptions(self): ... It must be noted that: - when with_context=True and wrap_exceptions is used as a decorator it can only be used to decorate class methods and not regular functions - when used as a decorator "self" is automatically passed as the first argument for wrap_exceptions I'm not sure if this is actually possible as I haven't gone through contextlib.contextmanager in details (it's quite magical). Thoughts? -- Giampaolo - http://grodola.blogspot.com

2 1

Reporting unmatched parentheses in SyntaxError messages?
by Nick Coghlan July 9, 2015

July 9, 2015

One of the more opaque error messages new Python users can encounter is a syntax error due to unmatched parentheses: File "/home/me/myfile.py", line 11 data = func() ^ SyntaxError: invalid syntax While I have no idea how we could implement it, I'm wondering if that might be clearer if the error message instead looked more like this: File "/home/me/myfile.py", line 11 data = func() ^ SyntaxError: invalid syntax (Unmatched '(' on line 10) Or, similarly, SyntaxError: invalid syntax (Unmatched '[' on line 10) SyntaxError: invalid syntax (Unmatched '{' on line 10) I'm not sure it would be feasible though - we generate syntax errors from a range of locations where we don't have access to the original token data any more :( Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

11 13

OrderedDict.peekitem()
by Kale Kundert July 7, 2015

July 7, 2015

Today I was trying to use collections.OrderedDict to manage a LIFO queue, and I was surprised to realize that OrderedDict doesn't provide a way to look at its first or last item. There is an OrderedDict.popitem() method, which removes and returns either the first or last item, but it's not hard to imagine cases where you would want to see what's on the queue without popping it right away. My proposal is to add a peekitem() method to OrderedDict. This method would have the same signature and would return the same thing as popitem(), it just wouldn't modify the data structure. -Kale P.S. There is already a way to peek at the last item an OrderedDict, but it hides the intent of the code and you wouldn't think of it if you weren't familiar with python: next(reversed(ordered_dict))

12 24

Re: [Python-ideas] [Python-Dev] PEP 493: Redistributor guidance for Python 2.7 HTTPS
by Stephen J. Turnbull July 7, 2015

July 7, 2015

Cross-posted to redirect discussion. Replies directed to Python-Ideas. Erik Bray writes on Python-Dev: > On Mon, Jul 6, 2015 at 6:21 AM, Antoine Pitrou <solipsis(a)pitrou.net> wrote: > > On Mon, 6 Jul 2015 14:22:46 +1000, Nick Coghlan <ncoghlan(a)gmail.com> wrote: > >> > >> The main change from the last version discussed on python-ideas > > > > Was it discussed there? That list has become totally useless, I've > > stopped following it. > > Considering that a useful discussion of a useful PEP occurred there > (not to mention other occasionally useful discussions) I'd say that > such a value judgment is not only unnecessary but also inaccurate. As you point out, the words "totally" and "useless" were unnecessary and inaccurate respectively. However, the gist of his post, that the S/N on Python-Ideas has become substantially lower in the last few months, seems accurate to me. At least two recent threads could have been continued on Python-List, where they would have benefited a lot more users, and they didn't seem profitable on Python-Ideas since it was quite evident that Those Who Know About Python were adamantly opposed to the idea as discussed in the thread, while the proponent kept pushing on that brick wall rather than seeking a way around it. I myself continue to follow Python-Ideas, Nick and other committers are posting here daily, and even Guido manages to pop up occasionally, so that may be no problem (or even a good thing if it results in educating and inviting new committers in the long run). But I think it's worth considering whether it we should cultivate a bit more discipline here. Again, discussion on Python-Ideas, please.

3 2

Re: [Python-ideas] [Python-Dev] PEP 493: Redistributor guidance for Python 2.7 HTTPS
by Guido van Rossum July 7, 2015

July 7, 2015

On Tue, Jul 7, 2015 at 11:24 AM, Mark Lawrence <breamoreboy(a)yahoo.co.uk> wrote: > From https://mail.python.org/mailman/listinfo/python-ideas > > <quote> > This list is to contain discussion of speculative language ideas for > Python for possible inclusion into the language. If an idea gains traction > it can then be discussed and honed to the point of becoming a solid > proposal to put to python-dev as appropriate. > </quote> > > Relative to the above I believe that far too many proposals are for > trivial ideas, mainly targetted at the stdlib, that would be better suited > to the main python list. > > As for gaining traction, it's often the complete opposite, flogging a dead > horse is an understatement for some threads. Gently putting the OP down > with a firm but polite "it ain't gonna happen" would save a lot of time all > around. > > Just my £0.02p worth. > Agreed. It's also probably easier to just ignore an obviously bad or poorly thought-out idea than to try to engage the OP in lengthy explanations of why that is so. After all there's a huge amount of subjectivity -- we won't change our minds, but it takes forever to explain to someone who's new to Python core development. -- --Guido van Rossum (python.org/~guido)

1 0