Re: [Python-ideas] Proposal to change Python version release cycle

Isn't this recent bit of discussion an argument in favor of a new stdlib module `version`? That would contain things like resolving a version tuple to an executable name (or a cross-platform piece of an executable name)? Obviously this doesn't actually answer the question of how naming should be do

Re: [Python-ideas] lazy import via __future__ or compiler analysis

Replying here, although this was written in response to the other thread: Hey Neil, In general this won't work. It's not generally possible to know if a given statement has side effects or not. As an example, one normally wouldn't expect function or class definition to have side effects, but if a

Re: [Python-ideas] + operator on generators

Argh, you're correct. Thanks for the catch. On Tue, Jun 27, 2017 at 10:06 AM Stephan Houben wrote: > Unfortunately this is existing syntax: > > a++b > is parsed as > a+(+b) > > Stephan > > > Op 27 jun. 2017 6:03 p.m. schreef "Joshua Morton" <

Re: [Python-ideas] + operator on generators

Just another syntactical suggestion: the binary ++ operator is used as concat in various contexts in various languages, and is probably less likely to confuse people as being either a logical or binary &. On Tue, Jun 27, 2017 at 6:53 AM Stephan Houben wrote: > > Its the applications where it *is

Re: [Python-ideas] Run length encoding

and more intuitive > than mine, and the same speed. > > On Sat, Jun 10, 2017 at 8:12 PM, Joshua Morton > wrote: > >> Another is >> >> [(k, len(list(g))) for k, g in groupby(l)] >> >> >> It might be worth adding it to the list of recipies eith

Re: [Python-ideas] Run length encoding

Another is [(k, len(list(g))) for k, g in groupby(l)] It might be worth adding it to the list of recipies either at https://docs.python.org/2/library/itertools.html#itertools.groupby or at https://docs.python.org/2/library/itertools.html#recipes, though. On Sat, Jun 10, 2017 at 8:07 PM David Me

Re: [Python-ideas] Dictionary destructing and unpacking.

While I don't like that syntax, we do know that sets are unhashable, so we can be certain that that would be a TypeError if it was meant to construct a set containing a set. (ie. {{foo}} will always result in a TypeError in python). On Thu, Jun 8, 2017 at 1:40 PM Chris Angelico wrote: > On Fri,

Re: [Python-ideas] Defer Statement

Its also worth mentioning that the `defer` statement has come up in other contexts, and is already often used as an identifier already (see *https://mail.python.org/pipermail/python-ideas/2017-February/044682.html *), so ther

Re: [Python-ideas] π = math.pi

For reference, haskell is perhaps the closest language to providing arbitrary infix operators, and it requires that they be surrounded by backticks. That is A `op` B is equivalent to op(A, B) That doesn't work for python (backtick is taken) and I don't think anything similar is a good i

Re: [Python-ideas] Way to repeat other than "for _ in range(x)"

A for loop in python saves an enormous amount of boilerplate code though (I would post an example, but I'd likely mess up a while loop over an iterator from memory if I posted it here). The `for x in y` construct saves multiple lines an an enormous amount of boilerplate and mental strain in the maj

Re: [Python-ideas] Delayed Execution via Keyword

This comes from a bit of a misunderstanding of how an interpreter figures out what needs to be compiled. Most (all?) JIT compilers run code in an interpreted manner, and then compile subsections down to efficient machine code when they notice that the same code path is taken repeatedly, so in pypy

Re: [Python-ideas] Delayed Execution via Keyword

@ Joseph Function annotations can be arbitrary python expressions, it is completely legal to have something like >>> def foo(bar: lambda x: x + 1): ... pass Why you would want that I can't say, but it is legal. In the same way, `def foo(bar: delayed 1 + 1)` should probably be legal s

Re: [Python-ideas] Delayed Execution via Keyword

Ed, I'm not seeing this perceived problem either. if we have >>> d = delayed {'a': 1, 'b': 2} # I'm not sure how this is delayed exactly, but sure >>> k = delayed string.ascii_lowercase[0] >>> d[k] 1 I'm not sure how the delayedness of any of the subexpressions matter, since e

Re: [Python-ideas] Delayed Execution via Keyword

be true of delayed if it is always followed by a > colon? > > I.e. > delayed=1 > x= delayed: slow_function() > print(delayed) # prints 1 > > -Joseph > > On Feb 17, 2017, at 2:39 PM, Mark E. Haase wrote: > > On Fri, Feb 17, 2017 at 1:55 PM, Joshua Morton > wr

Re: [Python-ideas] Delayed Execution via Keyword

I did some quick thinking and a bit of research about some aspects of this proposal: There are a number of keyword options (delay, defer, lazy, delayed, deferred, etc.), a quick look through github says that of these, "deferred" seems to be the least used, but it still comes up quite a lot (350K t

Re: [Python-ideas] Delayed Execution via Keyword

David, can you elaborate on your example? if we replaced line four with >>> x = my_lazy_func(b, delayed c) what would the value of `x` be, and how would this differ from either >>> x = delayed my_lazy_func(b, delayed c) or >>> x = delayed my_lazy_func(b, c) To put it another way,

Re: [Python-ideas] Fwd: Define a method or function attribute outside of a class with the dot operator

One thing that I don't think has been mentioned, but that brings me from a +0 to a more negative outlook, is the interaction between this proposal and some of python's existing class-related features, metaclasses and descriptors. That is currently we know that function definition, and even method d