Mailman 3 August 2020 - Python-ideas

Re: PEP 472 - new dunder attribute, to influence item access
by Christopher Barker Aug. 27, 2020

Aug. 27, 2020

(bringing this back on list) On Thu, Aug 27, 2020 at 10:29 AM Chris Angelico <rosuav(a)gmail.com> wrote: > On Fri, Aug 28, 2020 at 1:22 AM Christopher Barker <pythonchb(a)gmail.com> > wrote: > > But no one is stopping anyone from writing anything they want. iI may > not be a “PEP”, but it’s a good idea to write a document that makes it > clear what your idea is. And it’s also a good idea for that document to > look something like a PEP. > > > > Sometimes one ca. Get a sponsor with a quick one sentence description— > but if it’s a complex idea, it need more than that. > > > > Perhaps. But by the time there's been a thread this long, it's usually > fairly obvious whether there's a plausible sponsor, or if you need to > go hunting one down. The thread *itself* is that document. > kind of -- but as this one illustrates, there are multiple versions of the idea, and I know I can't figure out exactly what I might or might not support. Particularly with the possibility of "competing PEPs" -- if someone has a clear alternative idea, then they're a lot more likely to get support (or clear lack of support) if they write it down clearly in one document. for example, I notice the Guido has been quiet on this thread for a while -- I expect he's waiting for it to settle down. Maybe he's already made up his mind about it, but if you want him, or anyone else, to consider something new, you'll need to do something more confinded than point them to a massive thread on this list. The fact is that it takes a LOT of work to get a vague idea to a clear proposal, and to get anything like consensus on that. Many good ideas die here due to no no one doing that work. -CHB > > ChrisA > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

1 0

Deferred, coalescing, and other very recent reference counting optimization
by Raihan Rasheed Apurbo Aug. 27, 2020

Aug. 27, 2020

In CPython we have reference counting. My question is can we optimize current RC using strategies like Deferred RC and Coalescing? If no then where would I face problem if I try to implement these sorts of strategies? These strategies all depend on the concept that we don't need the exact value of reference count all the time. So far in my observation, we only need exact value before running a cycle collector. If we can manage to make sure that we have exact value before entering the cycle collector then in my opinion we can add these optimizations strategies to some extent. Is there something that I am missing? Or It is quite possible? If not possible please tell me the factors I should consider. Thanks in advance.

4 6

PEP 472 - slices in keyword indices, d[x=1:3]
by Todd Aug. 26, 2020

Aug. 26, 2020

I think it is worth directly discussing the availability of slices in PEP 472-style keyword indices, since we seem to have mostly converged on a dunder method signature. This is an issue that has been alluded to regarding keyword-based (labelled) indices but not directly addressed. The basic syntax would be something like d[x=1:3]. I am strongly in favor of having slices. The main motivating factor for me, labelled dimensions in xarray, would be much, much less useful without support for slices. In fact, as PEP 472 currently mentions, the big benefit of indexing over method calls is that indexing supports slice syntax while method calls don't. In a more general sense, I feel not allowing slices would create an artificial distinction between labelled and positional indices that I don't think is justified. They would work the same, except for slices where labelled indices behave differently. It would be a strange gotcha. So I think any revision to PEP 472 or new PEP should directly and explicitly support the use of slices.

12 19

still more use for pathlib.Path ....
by Christopher Barker Aug. 26, 2020

Aug. 26, 2020

I really like pathlib. But for a while is was painful to use, 'cause there was som much code that still used strings for paths. That was made a lot better when we introduced the __fspath__ protocol, and then updated the standard library to use it (everywhere?). But there are still a few that bug me. For instance: __file__ is a path represented as a string. It's not too big a deal to wrap it in Path(), but it still annoys me. So: would it be entirely too disruptive to replace these kinds of things with Path objects? -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

6 6

FEATURE REQUEST: Make `logging` Module more Pythonic
by Adam Hendry Aug. 26, 2020

Aug. 26, 2020

Dear Python-ideas, After looking at the `logging` module, I slammed my fist on my desk and declared "There has to be a better way!" ( https://www.youtube.com/watch?v=wf-BqAjZb8M). Can we make the `logging` module more "Pythonic" per Raymond Hettinger's presentation "Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015"? Thank you, Adam Hendry

8 15

Type Implications in Python 4 (or 3.9)
by krishnans2006＠gmail.com Aug. 26, 2020

Aug. 26, 2020

One suggestion I had for the next Python release is to add type-implication support. Many developers have learned Python, but do not want to use it since it is slow. An awesome way to fix this is to have optional type-implications. For example, if you know for sure that variable x is an int, you can make Python just a bit smaller by somehow specifying to the interpreter that the variable is an integer. Something like 'x::int = 5'. By having optional type implications, you can still do everything you do with normal Python, except you can speed it up a little bit by telling the Interpreter that this variable is starting off with this datatype.

5 6

Consider allow functools.singledispatch to work with typing.Union?
by Neil Girdhar Aug. 26, 2020

Aug. 26, 2020

Julia's burgeoning popularity has renewed my interest in dynamic dispatch. It seems to me that many methods that have been written as a giant switch on types can more clearly be written using dynamic dispatch. It was prettty exciting to see that Python already has single dispatch built in, and that it supports type annotations! Would it be possible and desirable to extend it slightly to support Union types? --- In [1]: from functools import singledispatch In [3]: from typing import Any, Union In [4]: @singledispatch ...: def a(x: Any): ...: print("a") ...: In [5]: class X: pass In [6]: class Y: pass In [7]: @a.register ...: def _(x: Union[X, Y]): ...: print("b") ...: --------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-7-b6a194bcade0> in <module> 1 @a.register ----> 2 def _(x: Union[X, Y]): 3 print("b") 4 ~/.pyenv/versions/3.8.5/lib/python3.8/functools.py in register(cls, func) 858 argname, cls = next(iter(get_type_hints(func).items())) 859 if not isinstance(cls, type): --> 860 raise TypeError( 861 f"Invalid annotation for {argname!r}. " 862 f"{cls!r} is not a class." TypeError: Invalid annotation for 'x'. typing.Union[__main__.X, __main__.Y] is not a class.

1 0

Re: Adding additionnal common request handlers to http.server
by Simon Aug. 25, 2020

Aug. 25, 2020

I find that flask's approach to this is quite pythonic. It's also relatively easy to use and explain. With this approach, as demonstrated by the example I provided, any dev can spin up a server that serves an API in virtually no time, which is why, out of all the possible approaches (Having an App-like class, designing middlewares, a Resource object with get,post,put,delete methods etc), I personally find flask's is the most appropriate for quick prototyping. Furthermore, in the implementation I made of this request handler, I used nothing but built-in python types. Here are the implementations I thought of, both for the 'RESTRequestHandler' and the 'WebhookRequestHandler'. RESTRequestHandler <https://gist.github.com/Dogeek/dedcac029b8ad3e505acff7ecf3a25ed> WebhookRequestHandler <https://gist.github.com/Dogeek/82b01a10c45ffccd3c8206fa67b5f198> I also can't help but think that this would be a great addition for devs who cannot for one reason or another, use PyPI (for instance, restrictions imposed by the IT staff at their jobs) I can't help the feeling that this is much more appropriate for PyPI than for the stdlib. There are just too many different ways to do it. (For example, what if the user isn't familiar with flask?) On Mon, Aug 24, 2020 at 1:45 PM Simon <simon.bordeyne(a)gmail.com> wrote: > > Fair enough. I guess the real question is, how much advantage is > > RESTRequestHandler over directly subclassing BaseHTTPRequestHandler? > > Maybe it'd be worth it just to simplify that case. > > > > ChrisA > > Well, maybe an example would be more telling. Below is a basic usage of > the handler I wrote : > > @RESTRequestHandler.route('/get/<obj_id:int>', methods=['GET']) > def get_obj(request, obj_id): > objs = [ > {'bar': 'baz'}, > {'lorem': 'ipsum'}, > ] > if obj_id > len(objs): > raise HTTPStatusException(HTTPStatus.NOT_FOUND) > return HTTPStatus.OK, objs[obj_id] > @RESTRequestHandler.errorhandler('*') > def handle_errors(r, exc): > return exc.status_code, {'code': exc.status_code, 'message' > : exc.message} > with HTTPServer(('localhost', 8080), RESTRequestHandler) as httpd: > httpd.serve_forever() > This example demonstrates how such a handler would be used, using a syntax > that > flask users should be pretty familiar with. The handler integrates both a > route and > an errorhandler decorator, which can be used to add new routes to the API > that's being > built. It's not something that's in the standard library either. By the > way, RESTRequestHandler > subclasses SimpleHTTPRequestHandler. > > Overall the advantage is pretty clear, it provides a much simpler API for > devs > who wish to spin up an API, which would be the ultimate goal of this PEP. > Not to mention, > the handler I wrote is 184 lines of code, having to reimplement for every > API is cumbersome.

3 2

keyword arguments before positional arguments- syntax inconsistency
by Ben Avrahami Aug. 25, 2020

Aug. 25, 2020

consider the following function: def foo(a,b,c,x): pass The following calls are equivalent: foo(1,2,3, x=0) foo(*(1,2,3), x=0) However, since python allows keyword arguments before star-unpacking, you can also do: foo(x=0, *(1, 2, 3)) But removing the unpacking, would result in a syntax error: foo(x=0, 1, 2, 3) This is against the understanding of unpacking, is this intentional?

3 2

Fwd: Re: PEP 472 - slices in keyword indices, d[x=1:3]
by Steven D'Aprano Aug. 25, 2020

Aug. 25, 2020

I attempted to send this yesterday, but used the wrong sender email address and it got rejected. I think this is still relevent, just to confirm I understand the proposal correctly. ----- Forwarded message from Steven D'Aprano <steve+python(a)pearwood.info> ----- Date: Mon, 24 Aug 2020 11:46:02 +1000 From: Steven D'Aprano <steve+python(a)pearwood.info> To: python-ideas(a)python.org Subject: Re: [Python-ideas] PEP 472 - slices in keyword indices, d[x=1:3] On Sun, Aug 23, 2020 at 09:40:53PM -0400, Todd wrote: > I think it is worth directly discussing the availability of slices in PEP > 472-style keyword indices, since we seem to have mostly converged on a > dunder method signature. This is an issue that has been alluded to > regarding keyword-based (labelled) indices but not directly addressed. The > basic syntax would be something like d[x=1:3]. I read that as equivalent to `d[x=slice(1, 3)]`. Is that your intention? If that is your intention, then a big +1. If your intention was `d[slice(x=1, 3)]` then I think you would have to justify what it means and why you want it. -- Steven ----- End forwarded message -----

2 1