Python-ideas September 2015

python-ideas@python.org

107 participants
55 discussions

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

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

Fwd: Consider making enumerate a sequence if its argument is a sequence
by Alexander Belopolsky 30 Sep '15

30 Sep '15

On Wed, Sep 30, 2015 at 11:28 AM, Neil Girdhar <mistersheik(a)gmail.com> wrote: > 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]: > This does not seem to be an big improvement over for height, vertex in enumerate( self.cache.height_to_vertex[height_slice], height_slice.start):

1 0

Submitting a job to an asyncio event loop
by Vincent Michel 30 Sep '15

30 Sep '15

Hi, I noticed there is currently no standard solution to submit a job from a thread to an asyncio event loop. Here's what the asyncio documentation says about concurrency and multithreading: > To schedule a callback from a different thread, the BaseEventLoop.call_soon_threadsafe() method should be used. > Example to schedule a coroutine from a different thread: > loop.call_soon_threadsafe(asyncio.async, coro_func()) The issue with this method is the loss of the coroutine result. One way to deal with this issue is to connect the asyncio.Future returned by async (or ensure_future) to a concurrent.futures.Future. It is then possible to use a subclass of concurrent.futures.Executor to submit a callback to an asyncio event loop. Such an executor can also be used to set up communication between two event loops using run_in_executor. I posted an implementation called LoopExecutor on GitHub: https://github.com/vxgmichel/asyncio-loopexecutor The repo contains the loopexecutor module along with tests for several use cases. The README describes the whole thing (context, examples, issues, implementation). It is interesting to note that this executor is a bit different than ThreadPoolExecutor and ProcessPoolExecutor since it can also submit a coroutine function. Example: with LoopExecutor(loop) as executor: future = executor.submit(operator.add, 1, 2) assert future.result() == 3 future = executor.submit(asyncio.sleep, 0.1, result=3) assert future.result() == 3 This works in both cases because submit always cast the given function to a coroutine. That means it would also work with a function that returns a Future. Here's a few topic related to the current implementation that might be interesting to discuss: - possible drawback of casting the callback to a coroutine - possible drawback of concurrent.future.Future using asyncio.Future._copy_state - does LoopExecutor need to implement the shutdown method? - removing the limitation in run_in_executor (can't submit a coroutine function) - adding a generic Future connection function in asyncio - reimplementing wrap_future with the generic connection - adding LoopExecutor to asyncio (or concurrent.futures) At the moment, the interaction between asyncio and concurrent.futures only goes one way. It would be nice to have a standard solution (LoopExecutor or something else) to make it bidirectional. Thanks, Vincent

3 7

Consider making enumerate a sequence if its argument is a sequence
by Neil Girdhar 30 Sep '15

30 Sep '15

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]:

2 1

PEP 505 (None coalescing operators) thoughts
by Brian O'Neill 30 Sep '15

30 Sep '15

> On 9/29/2015 9:20 AM, Rob Cliffe wrote: > Why not > > > > def __init__(self, vertices=None, edges=None, weights=None, > > source_nodes=None): > > self.vertices = vertices if vertices is not None else [] > > self.edges = edges if edges is not None else [] > > self.weights = weights if weights is not None else {} > > self.source_nodes = source_nodes if source_nodes is not None else [] > > I don't understand why not: > > self.vertices = vertices or [] > self.edges = edges or [] > self.weights = weights or {} > self.source_nodes = source_nodes or [] > > > Emile A further virtue of self.vertices = vertices or [] and the like is that they coerce falsy parameters of the wrong type to the falsy object of the correct type. E.g. if vertices is '' or 0, self.vertices will be set to [], whereas the ternary expression only tests for not-None so self.vertices will be set to a probably crazy value.

3 2

list as parameter for the split function
by Niilos 29 Sep '15

29 Sep '15

Hello everyone, I was wondering how to split a string with multiple separators. For instance, if I edit some subtitle file and I want the string '00:02:34,452 --> 00:02:37,927' to become ['00', '02', '34', '452', '00', '02', '37', '927'] I have to use split too much time and I didn't find a "clean" way to do it. I imagined the split function with an iterator as parameter. The string would be split each time its substring is in the iterator. Here is the syntax I considered for this : >>> '00:02:34,452 --> 00:02:37,927'.split([ ':', ' --> ', ',' ]) ['00', '02', '34', '452', '00', '02', '37', '927'] Is it a relevant idea ? What do you think about it ? Regards, Niilos.

9 9

PEP 505 (None coalescing operators) thoughts
by Brian O'Neill 29 Sep '15

29 Sep '15

> > A further virtue of > > > > self.vertices = vertices or [] > > > > and the like is that they coerce falsy parameters of the wrong type to the falsy object of the correct type. > > E.g. if vertices is '' or 0, self.vertices will be set to [], whereas the ternary expression only tests > > > > for not-None so self.vertices will be set to a probably crazy value. > > Doesn't seem like a virtue to me, seems like it's probably hiding a bug > in the calling code, which may have other ramifications. Better to have > the "crazy value" visible and fail faster, so you can go fix that bug. > > Carl I have to agree. It isn't a "virtue", and it's best not to mask such mistakes. But it *is* a... property of the shorter construct that it's more forgiving, and doesn't have the same semantics. PS -- My first post, and I lost the "Re:" in the Subject, hence this orphan thread which I'm content to see go no further.

1 0

Using `or?` as the null coalescing operator
by Alessio Bogon 29 Sep '15

29 Sep '15

I really like PEP 0505. The only thing that does not convince me is the `??` operator. I would like to know what you think of an alternative like `or?`: a_list = some_list or? [] a_dict = some_dict or? {} The rationale behind is to let `or` do its job with “truthy” values, while `or?` would require non-None values. The rest of the PEP looks good to me. I apologise in advance if this was already proposed and I missed it. Regards, Alessio

4 4

Maybe python should support arrow syntax for easier use async call ?
by 张沈鹏 29 Sep '15

29 Sep '15

# The example works with tornado dev verison & python3.5 import tornado from tornado.httpclient import AsyncHTTPClient from tornado.concurrent import Future from tornado.gen import convert_yielded from functools import wraps Future.__or__ = Future.add_done_callback def future(func): @wraps(func) def _(*args, **kwds): return convert_yielded(func(*args, **kwds)) return _ ############## @future async def ping(url): httpclient = AsyncHTTPClient() r = await httpclient.fetch(url) return r.body.decode('utf-8') ping("http://baidu.com") | ( lambda r:print(r.result()) ) """ Maybe python should support arrow syntax for easier use async call ? Now lambda only can write one line and must have parentheses ... FOR EXAMPLE ping("http://baidu.com") | r -> print(r.result()) print("something else") I saw some discuss in https://wiki.python.org/moin/AlternateLambdaSyntax """ tornado.ioloop.IOLoop.instance().start()

2 1

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Python-ideas September 2015