Mailman 3 July 2015 - Python-ideas

Indexable dict and set (was: OrderedDict.peekitem())
by Grant Jenks 07 Jul '15

07 Jul '15

>>> On Mon, Jul 6, 2015 at 3:30 PM, Neil Girdhar <mistersheik(a)gmail.com> >>> wrote: >>> SortedDict >>> (http://www.grantjenks.com/docs/sortedcontainers/sorteddict.html) >>> manages to support indexing. Can OrderedDict do the same thing? >> >> On Mon, Jul 6, 2015 at 5:59 PM, Eric Snow <ericsnowcurrently(a)gmail.com> >> wrote: >> >> Don't forget that, as the docs describe, an "OrderedDict is a dict >> that remembers the order that keys were first inserted". While >> obviously there's an implicit sequence for that order, the focus is >> still on dict-ness with the sequence exposed through the normal >> mapping approach (iteration). If you want to get sequence semantics >> then first unpack the order into a sequence type like list or tuple. >> Or use some other type than OrderedDict. > > On Mon, Jul 6, 2015 at 3:04 PM, Neil Girdhar <mistersheik(a)gmail.com> wrote: > You can do indexing, insertion, and removal all in logarithmic time (which > is basically constant) by using a B-tree as the underlying data structure. > (See e.g. the blist package.) If you want a `dict` or `set` that is indexable, it's quite easy using the sortedcontainers module. Just use the hash function as the key: ```python from sortedcontainers import SortedDict, SortedSet class DictWithIndex(SortedDict): def __init__(self, *args, **kwargs): super(DictWithIndex, self).__init__(hash, *args, **kwargs) class SetWithIndex(SortedSet): def __init__(self, *args, **kwargs): super(SetWithIndex, self).__init__(*args, key=hash, **kwargs) ``` The ordering can be quasi-random but the indexing can still be useful. Example usage: ``` In [2]: d = DictWithIndex(enumerate('abcde')) In [3]: d.iloc[4] Out[3]: 4 In [4]: d.iloc[-2] Out[4]: 3 In [5]: s = SetWithIndex('abcde') In [6]: s[4] Out[6]: 'e' In [7]: s[-2] Out[7]: 'd' ``` The likelihood that the hash collides is low and when it does so, the order will be based on insertion order.

1 0

Fwd: [Python-Dev] An yocto change proposal in logging module to simplify structured logs support
by Ludovic Gasc 06 Jul '15

06 Jul '15

Hi Python-Ideas ML, To resume quickly the idea: I wish to add "extra" attribute to LogMessage, to facilitate structured logs generation. For more details with use case and example, you can read message below. Before to push the patch on bugs.python.org, I'm interested in by your opinions: the patch seems to be too simple to be honest. Regards. -- Ludovic Gasc (GMLudo) http://www.gmludo.eu/ ---------- Forwarded message ---------- From: Guido van Rossum <guido(a)python.org> Date: 2015-05-24 23:44 GMT+02:00 Subject: Re: [Python-Dev] An yocto change proposal in logging module to simplify structured logs support To: Ludovic Gasc <gmludo(a)gmail.com> Ehh, python-ideas? On Sun, May 24, 2015 at 10:22 AM, Ludovic Gasc <gmludo(a)gmail.com> wrote: > Hi, > > 1. The problem > > For now, when you want to write a log message, you concatenate the data > from your context to generate a string: In fact, you convert your > structured data to a string. > When a sysadmin needs to debug your logs when something is wrong, he must > write regular expressions to extract interesting data. > > Often, he must find the beginning of the interesting log and follow the > path. Sometimes, you can have several requests in the same time in the log, > it's harder to find interesting log. > In fact, with regular expressions, the sysadmin tries to convert the log > lines strings to structured data. > > 2. A possible solution > > You should provide a set of regular expressions to your sysadmins to help > them to find the right logs, however, another approach is possible: > structured logs. > Instead of to break your data structure to push in the log message, the > idea is to keep the data structure, to attach that as metadata of the log > message. > For now, I know at least Logstash and Journald that can handle structured > logs and provide a query tool to extract easily logs. > > 3. A concrete example with structured logs > > As most Web developers, we build HTTP daemons used by several different > human clients in the same time. > In the Python source code, to support structured logs, you don't have a > big change, you can use "extra" parameter for that, example: > > [handle HTTP request] > LOG.debug('Receive a create_or_update request', extra={'request_id': > request.request_id, > > 'account_id': account_id, > > 'aiohttp_request': request, > > 'payload': str(payload)}) > [create data in database] > LOG.debug('Callflow created', extra={'account_id': account_id, > 'request_id': > request.request_id, > 'aiopg_cursor': cur, > 'results': row}) > > Now, if you want, you can enhance the structured log with a custom logging > Handler, because the standard journald handler doesn't know how to handle > aiohttp_request or aiopg_cursor. > My example is based on journald, but you can write an equivalent version > with python-logstash: > #### > from systemdream.journal.handler import JournalHandler > > class Handler(JournalHandler): > # Tip: on a system without journald, use socat to test: > # socat UNIX-RECV:/run/systemd/journal/socket STDIN > def emit(self, record): > if record.extra: > # import ipdb; ipdb.set_trace() > if 'aiohttp_request' in record.extra: > record.extra['http_method'] = > record.extra['aiohttp_request'].method > record.extra['http_path'] = > record.extra['aiohttp_request'].path > record.extra['http_headers'] = > str(record.extra['aiohttp_request'].headers) > del(record.extra['aiohttp_request']) > if 'aiopg_cursor' in record.extra: > record.extra['pg_query'] = > record.extra['aiopg_cursor'].query.decode('utf-8') > record.extra['pg_status_message'] = > record.extra['aiopg_cursor'].statusmessage > record.extra['pg_rows_count'] = > record.extra['aiopg_cursor'].rowcount > del(record.extra['aiopg_cursor']) > super().emit(record) > #### > > And you can enable this custom handler in your logging config file like > this: > [handler_journald] > class=XXXXXXXXXX.utils.logs.Handler > args=() > formatter=detailed > > And now, with journalctl, you can easily extract logs, some examples: > Logs messages from 'lg' account: > journalctl ACCOUNT_ID=lg > All HTTP requests that modify the 'lg' account (PUT, POST and DELETE): > journalctl ACCOUNT_ID=lg HTTP_METHOD=PUT > HTTP_METHOD=POST HTTP_METHOD=DELETE > Retrieve all logs from one specific HTTP request: > journalctl REQUEST_ID=130b8fa0-6576-43b6-a624-4a4265a2fbdd > All HTTP requests with a specific path: > journalctl HTTP_PATH=/v1/accounts/lg/callflows > All logs of "create" function in the file "example.py" > journalctl CODE_FUNC=create CODE_FILE=/path/example.py > > If you already do a troubleshooting on a production system, you should > understand the interest of this: > In fact, it's like to have SQL queries capabilities, but it's logging > oriented. > We use that since a small time on one of our critical daemon that handles > a lot of requests across several servers, it's already adopted from our > support team. > > 4. The yocto issue with the Python logging module > > I don't explain here a small part of my professional life for my pleasure, > but to help you to understand the context and the usages, because my patch > for logging is very small. > If you're an expert of Python logging, you already know that my Handler > class example I provided above can't run on a classical Python logging, > because LogRecord doesn't have an extra attribute. > > extra parameter exists in the Logger, but, in the LogRecord, it's merged > as attributes of LogRecord: > https://github.com/python/cpython/blob/master/Lib/logging/__init__.py#L1386 > > It means, that when the LogRecord is sent to the Handler, you can't > retrieve the dict from the extra parameter of logger. > The only way to do that without to patch Python logging, is to rebuild by > yourself the dict with a list of official attributes of LogRecord, as is > done in python-logstash: > > https://github.com/vklochan/python-logstash/blob/master/logstash/formatter.… > At least to me, it's a little bit dirty. > > My quick'n'dirty patch I use for now on our CPython on production: > > diff --git a/Lib/logging/__init__.py b/Lib/logging/__init__.py > index 104b0be..30fa6ef 100644 > --- a/Lib/logging/__init__.py > +++ b/Lib/logging/__init__.py > @@ -1382,6 +1382,7 @@ class Logger(Filterer): > """ > rv = _logRecordFactory(name, level, fn, lno, msg, args, exc_info, > func, > sinfo) > + rv.extra = extra > if extra is not None: > for key in extra: > if (key in ["message", "asctime"]) or (key in > rv.__dict__): > > At least to me, it should be cleaner to add "extra" as parameter > of _logRecordFactory, but I've no idea of side effects, I understand that > logging module is critical, because it's used everywhere. > However, except with python-logstash, to my knowledge, extra parameter > isn't massively used. > The only backward incompatibility I see with a new extra attribute of > LogRecord, is that if you have a log like this: > LOG.debug('message', extra={'extra': 'example'}) > It will raise a KeyError("Attempt to overwrite 'extra' in LogRecord") > exception, but, at least to me, the probability of this use case is near to > 0. > > Instead of to "maintain" this yocto patch, even it's very small, I should > prefer to have a clean solution in Python directly. > > Thanks for your remarks. > > Regards. > -- > Ludovic Gasc (GMLudo) > http://www.gmludo.eu/ > > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > > -- --Guido van Rossum (python.org/~guido)

4 6

Re: [Python-ideas] Should iPython Notebook replace Idle
by Todd 06 Jul '15

06 Jul '15

On Jul 4, 2015 5:16 AM, "Jason Swails" <jason.swails(a)gmail.com> wrote: > > > > On Fri, Jul 3, 2015 at 10:01 PM, Sayth Renshaw <flebber.crue(a)gmail.com> wrote: >> >> In future releases of Python should ipython Notebooks replace idle as the default tool for new users to learn python? >> >> >> This would as I see it have many benefits? >> >> 1. A nicer more usual web interface for new users. >> 2. Would allow the python documentation and tutorials to be distributed as ipython notebooks which would allow new users to play and interact with the tutorials as they proceed. No download separate code retyping just edit run and play. >> 3. Would allow teachers to setup notebooks knowing that all users have the same default environment, no need for setting up virtualenvs etc. >> 4. Strengthen the learning base and for new python developers as a whole. >> >> Thoughts? > > > IPython and IDLE are different. IPython is *just* an interactive Python interpreter with a ton of tweaks and enhancements. IDLE, by contrast, is both an upscale interpreter (not *nearly* as feature-complete as IPython), but it's also an IDE. AFAICT, IPython does not do this. > > Also, look at the IPython dependencies for its core functionalities: > > - jinja2 > - sphinx > - pyzmq > - pygments > - tornado > - PyQt | PySide > > None of these are part of the Python standard library. By contrast, IDLE is built entirely with stdlib components (tkinter for the GUI). AFAIK, nothing in the stdlib depends on anything outside of it. And addition to the Python stdlib imposes some pretty serious restrictions on a library. If the IPython team agreed to release their tools with the stdlib instead of IDLE, they'd have to give up a lot of control over their project: > > - License > - Release schedule > - Development environment > > Everything gets swallowed into Python. I can't imagine this ever happening. > It is certainly true that IDLE and IPython do not cover the same use-cases, and it almost certainly true that putting the IPython notebook into the standard library is infeasible. That being said, one thing that IPython and other shells have shown is that it is possible to make a much more powerful python shell. So I don't think it is out of the realm of possibility to take a hard look at the current python shell and see where and how it can be made more useful. The IPython shell is one of many places we could look for ideas. More out-there, but it probably isn't completely impossible for python to provide some sort of native notebook-like interface, or at least some sort of interface that makes it convenient for third parties to make such notebook interfaces.

9 17

Pass a function as the argument "step" of range()
by Pierre Quentel 06 Jul '15

06 Jul '15

In languages such as Javascript, the incrementation of a for loop counter can be done by an operation, for instance : for(i=1; i<N; i*=2) would iterate on the powers of 2 lesser than N. To achieve the same thing in Python we currently can't use range() because it increments by an integer (the argument "step"). An option is to build a generator like : def gen(N): i = 1 while i<=N: yield i i *= 2 then we can iterate on gen(N). My proposal is that besides an integer, range() would accept a function as the "step" argument, taking the current counter as its argument and returning the new counter value. Here is a basic pure-Python implementation : import operator class Range: def __init__(self, start, stop, incrementor): self.start, self.stop = start, stop self.incrementor = incrementor # Function to compare current counter and stop value : <= or >= self.comp = operator.ge if self.stop>self.start else operator.le self.counter = None def __iter__(self): return self def __next__(self): if self.counter is None: self.counter = self.start else: self.counter = self.incrementor(self.counter) if self.comp(self.counter, self.stop): raise StopIteration return self.counter Iterating on the powers of 2 below N would be done by : for i in Range(1, N, lambda x:x*2) I haven't seen this discussed before, but I may not have searched enough. Any opinions ?

14 49

Enabling access to the AST for Python code
by Ben Hoyt 04 Jul '15

04 Jul '15

Hi Python Ideas folks, (I previously posted a similar message on Python-Dev, but it's a better fit for this list. See that thread here: https://mail.python.org/pipermail/python-dev/2015-May/140063.html) Enabling access to the AST for compiled code would make some cool things possible (C# LINQ-style ORMs, for example), and not knowing too much about this part of Python internals, I'm wondering how possible and practical this would be. Context: PonyORM (http://ponyorm.com/) allows you to write regular Python generator expressions like this: select(c for c in Customer if sum(c.orders.price) > 1000) which compile into and run SQL like this: SELECT "c"."id" FROM "Customer" "c" LEFT JOIN "Order" "order-1" ON "c"."id" = "order-1"."customer" GROUP BY "c"."id" HAVING coalesce(SUM("order-1"."total_price"), 0) > 1000 I think the Pythonic syntax here is beautiful. But the tricks PonyORM has to go to get it are ... not quite so beautiful. Because the AST is not available, PonyORM decompiles Python bytecode into an AST first, and then converts that to SQL. (More details on all that from author's EuroPython talk at http://pyvideo.org/video/2968) PonyORM needs the AST just for generator expressions and lambda functions, but obviously if this kind of AST access feature were in Python it'd probably be more general. I believe C#'s LINQ provides something similar, where if you're developing a LINQ converter library (say LINQ to SQL), you essentially get the AST of the code ("expression tree") and the library can do what it wants with that. (I know that there's the "ast" module and ast.parse(), which can give you an AST given a *source string*, but that's not very convenient here.) What would it take to enable this kind of AST access in Python? Is it possible? Is it a good idea? -Ben

15 29

Are there asynchronous generators?
by Adam Bartoš 03 Jul '15

03 Jul '15

Hello, I had a generator producing pairs of values and wanted to feed all the first members of the pairs to one consumer and all the second members to another consumer. For example: def pairs(): for i in range(4): yield (i, i ** 2) biconsumer(sum, list)(pairs()) -> (6, [0, 1, 4, 9]) The point is I wanted the consumers to be suspended and resumed in a coordinated manner: The first producer is invoked, it wants the first element. The coordinator implemented by biconsumer function invokes pairs(), gets the first pair and yields its first member to the first consumer. Then it wants the next element, but now it's the second consumer's turn, so the first consumer is suspended and the second consumer is invoked and fed with the second member of the first pair. Then the second producer wants the next element, but it's the first consumer's turn… and so on. In the end, when the stream of pairs is exhausted, StopIteration is thrown to both consumers and their results are combined. The cooperative asynchronous nature of the execution reminded me asyncio and coroutines, so I thought that biconsumer may be implemented using them. However, it seems that it is imposible to write an "asynchronous generator" since the "yielding pipe" is already used for the communication with the scheduler. And even if it was possible to make an asynchronous generator, it is not clear how to feed it to a synchronous consumer like sum() or list() function. With PEP 492 the concepts of generators and coroutines were separated, so asyncronous generators may be possible in theory. An ordinary function has just the returning pipe – for returning the result to the caller. A generator has also a yielding pipe – used for yielding the values during iteration, and its return pipe is used to finish the iteration. A native coroutine has a returning pipe – to return the result to a caller just like an ordinary function, and also an async pipe – used for communication with a scheduler and execution suspension. An asynchronous generator would just have both yieling pipe and async pipe. So my question is: was the code like the following considered? Does it make sense? Or are there not enough uses cases for such code? I found only a short mention in https://www.python.org/dev/peps/pep-0492/#coroutine-generators, so possibly these coroutine-generators are the same idea. async def f(): number_string = await fetch_data() for n in number_string.split(): yield int(n) async def g(): result = async/await? sum(f()) return result async def h(): the_sum = await g() As for explanation about the execution of h() by an event loop: h is a native coroutine called by the event loop, having both returning pipe and async pipe. The returning pipe leads to the end of the task, the async pipe is used for cummunication with the scheduler. Then, g() is called asynchronously – using the await keyword means the the access to the async pipe is given to the callee. Then g() invokes the asyncronous generator f() and gives it the access to its async pipe, so when f() is yielding values to sum, it can also yield a future to the scheduler via the async pipe and suspend the whole task. Regards, Adam Bartoš

12 27