Mailman 3 October 2015 - Python-ideas

PEP 505 (None coalescing operators) thoughts
by Jeff Hardy 05 Oct '15

05 Oct '15

TL;DR: +1 for the idea -1 on the propagating member-access or index operators +1 on spelling it "or?" C# has had null-coalescing since about 2005, and it's one feature I miss in every other language that I use. I view null/None as a necessary evil, so getting rid of them as soon possible is a good thing in my book. Nearly every bit of Python I've ever written would have benefitted from it, if just to get rid of the "x if x is not None else []" mess. That said, I think the other (propagating) operators are a mistake, and I think they were a mistake in C# as well. I'm not I've ever had a situation where I wished they existed, in any language. Better to get rid of the Nones as soon as possible than bring them along. It's worth reading the C# design team's notes and subsequent discussion on the associativity of "?." [1] since it goes around and around with no really good answer and no particularly intuitive behaviour. Rather than worry about that, I'd prefer to see just the basic None-coalescing added. I like Alessio's suggestion of "or?" (which seems like it should be read in a calm but threatening tone, a la Liam Neeson). It just seems more Pythonic; ?? is fine in C# but seems punctuation-heavy for Python. It does mean the ?= and ?. and ?[] are probably out, and I'm OK with that. - Jeff [1] https://roslyn.codeplex.com/discussions/543895

34 122

secrets module -- secret.keeper?
by Jim J. Jewett 03 Oct '15

03 Oct '15

Will the secrets module offer any building blocks to actually protect a secret? e.g., an easy way to encrypt a file with a given password? an encrypted datastore? a getpass that works even in IDLE? -jJ

6 5

asyncio: factoring-out of the general mechanism
by Christoph Groth 03 Oct '15

03 Oct '15

Hello, I have a question/idea about the support for asynchronous programming in Python. With Python 3.5, support for asynchronous programming has been added to the core Python language. The new language features, however, are only useful with an event loop, as provided (only?) by the asyncio stdlib module. I notice that already the class asyncio.AbstractEventLoop contains many things that to me seem very specific to particular applications. For examples that class contains placeholders for methods that expect IP host names and IP ports as arguments. In a world where networking is done in other ways than through IP, Python would be still useful. One could keep using most of the standard library that is not specific to IP networking. Asynchronous programming is a concept that is way more universal than many of the things in asyncio (IP ports, unix pipes, etc.). Has there been a discussion about separating the abstract bits needed for asynchronous programming in Python from the application-specific ones? Or would this be a bad idea for some reason? Christoph

3 4

Re: [Python-ideas] Consider making enumerate a sequence if its argument is a sequence
by Brett Cannon 02 Oct '15

02 Oct '15

On Wed, 30 Sep 2015 at 09:38 Neil Girdhar <mistersheik(a)gmail.com> wrote: > In fairness, one is a superset of the other. You always get an Iterable. > You sometimes get a Sequence. It's a bit like multiplication? with > integers you get integers, with floats, you get floats. > No, it's not like multiplication. =) I hate saying this since I think it's tossed around too much, but int/float substitution doesn't lead to a Liskov substitution violation like substituting out a sequence for an iterator (which is what will happen if the type of the argument to `enumerate` changes). And since you can just call `list` or `tuple` on enumerate and get exactly what you're after without potential bugs cropping up if you don't realize from afar you're affecting an assumption someone made, I'm -1000 on this idea. -Brett > > On Wed, Sep 30, 2015 at 12:35 PM Brett Cannon <brett(a)python.org> wrote: > >> On Wed, 30 Sep 2015 at 08:28 Neil Girdhar <mistersheik(a)gmail.com> wrote: >> >>> What are the pros and cons of making enumerate a sequence if its >>> argument is a sequence? >>> >>> I found myself writing: >>> >>> for vertex, height in zip( >>> self.cache.height_to_vertex[height_slice], >>> range(height_slice.start, height_slice.stop)): >>> >>> I would have preferred: >>> >>> for height, vertex in enumerate( >>> self.cache.height_to_vertex)[height_slice]: >>> >> >> Because you now suddenly have different types and semantics of what >> enumerate() returns based on its argument which is easy to mess up if >> self.cache.height_to_vertex became an iterator object itself instead of a >> sequence object. It's also not hard to simply do `tuple(enumerate(...))` to >> get the exact semantics you want: TOOWTDI. >> >> IOW all I see are cons. =) >> >

17 70