Mailman 3 March 2021 - Python-ideas

PEP 9999 (provisional): support for indexing with keyword arguments
by Stefano Borini March 10, 2021

March 10, 2021

PEP for support for indexing with keyword arguments is now submitted as PR. https://github.com/python/peps/pull/1612 Thanks to everybody involved in the development of the PEP and the interesting discussion. All your contributions have been received and often added to the document. If the PEP is approved, I would like to attempt an implementation, but I am not particularly skilled in the python internals. If a core developer is willing to teach me the ropes (especially in the new parser, I … [View More]

20 100

typing.Maybe type annotation
by Ben Avrahami March 10, 2021

March 10, 2021

Hi all, I recently ran into a problem trying to adapt mypy into an older codebase, and it got me thinking about a potential addition to the typing library. This idea comes in two parts (that can even be taken individually): the first is to allow the False singleton literal to be used in type annotations, much like how None is now allowed. False will in fact mean "any object for which the `not` operator will return True". The second part is to add a generic shorthand to the typing module: `… [View More]

4 3

A shortcut to load a JSON file into a dict : json.loadf
by The Nomadic Coder March 10, 2021

March 10, 2021

Hi All, This is the first time I'm posting to this mailing group, so forgive me if I'm making any mistakes. So one of the most common ways to load json, is via a file. This is used extensively in data science and the lines. We often write something like :- with open(filename.json, "r") as f: my_dict = json.load(f) or my_dict = json.load(open("filename.json", "r")) Since this is sooooo common, why doesn't python have something like :- json.loadf("filename.json") Is there an obvious … [View More]

22 67

Make list.reverse() more flexible
by Vincent Cheong March 8, 2021

March 8, 2021

Currently, list.reverse() only works for an entire list. If one wants to reverse a section of it 'in-place', one needs to slicing which makes the space complexity no longer O(1). One can also manually make a loop and do the reversal but that is even slower than slicing. List.reverse() does not take any arguments. Wouldn't it be a good if it can take in parameters such as 'start' and 'stop' to enable list.reverse() work even for a section of the list? When no arguments are specified, then it … [View More]

9 24

Add an __exclude_all__ complement to __all__
by George Harding March 5, 2021

March 5, 2021

Hi, Python has an __all__ variable that can be defined in a module to restrict which members of the module should be included in a call `from foo import *`. However specifying which members of the module should be excluded is more difficult. There are three workarounds that I see: 1) Defining __all__ to specify most of the members of the module, except the few that should be excluded. 2) Naming members to be excluded with a leading underscore. e.g. as done here in ctypes: https://github.com/… [View More]

7 15

class(obj) could return obj.__class__
by Hans Ginzel March 3, 2021

March 3, 2021

Please, consider class(obj) to return obj.__class__ consistenly with dir(), vars(), repr(), str(),… >>> class c: pass >>> o = c() >>> o.__class__ <class '__main__.c'> >>> class(o) File "<stdin>", line 1 class(o) ^ SyntaxError: invalid syntax Thank you in advance, H.

2 2

Re: class(obj) could return obj.__class__
by Paul Bryan March 3, 2021

March 3, 2021

Err, why is it insufficient? On Wed, 2021-03-03 at 14:03 -0800, Paul Bryan wrote: > Since class is a keyword, this is unlikely. Why is type(o) not > insufficient? > > On Wed, 2021-03-03 at 22:59 +0100, Hans Ginzel wrote: > > > > > class c: pass > > > > > o = c() > > > > > o.__class__ > > <class '__main__.c'> > > > > > class(o) > > File "<stdin>", line 1 > > &… [View More]

1 0

list.extend() should return self
by Hans Ginzel March 3, 2021

March 3, 2021

Please, is there a reason why extend() method does not return self? >>> a = [1,2].extend((3,4)) >>> a >>> type(a) <class 'NoneType'> >>> b = [1,2] >>> b.extend((3,4)) >>> b [1, 2, 3, 4]

3 2

Re: Fwd: [Python-Dev] Suggestion About Python Syntax
by anthony.flury March 3, 2021

March 3, 2021

Dear Anthony, Greetings from another Anthony (although my friends call me Tony). Thank you for your suggestion about changes to the Python Syntax. The Idea of having curly braces with blocks of code has been considered many times, and every time it has not been accepted. When you do enough programming even in languages such as C, C++ and Java which do use Curly braces (or languages such as Pascal which use Begin/End and other such keywords), you will find that you do indent your … [View More]code consistently as a matter of habit. Most serious developers in those languages will use auto-formatters to ensure that their code is nicely indented. Even though they use languages which have syntax elements to denote the start and end of a block, they recognize that indentation is a very natural way to layout code to make it readable, and they avoid 'indentation where ever they want'. Python - by adopting indentation as it does - has simply adopted a very natural form for writing code, and made it mandatory. You might be surprised to know that Python does allow semicolons at the end of statements, but they are optional, and really only used to run mutiple statements together on a single line; which is not considered to be a good style of writing. Don't be put off by this message - keep enjoying Python and learning about the world of programming. You have taken your first steps in the Python community, and we all look forward to hearing what ever ideas you might have in future. Good luck in your future journey in the computing universe. Tony Flury. > > On 03/03/2021 18:24, George Harding wrote: >> >> >> ---------- Forwarded message --------- >> From: *Anthony Farino* <anthonyf(a)pacemschool.org >> <mailto:anthonyf@pacemschool.org>> >> Date: Wed, Mar 3, 2021 at 5:52 PM >> Subject: [Python-Dev] Suggestion About Python Syntax >> To: <python-dev(a)python.org <mailto:python-dev@python.org>> >> >> >> I love the Python scripting language, but there’s something that >> would make it much better. Almost every other programming language >> uses curly braces to enclose blocks of code and semicolons after the >> lines of code. That means that: >> >> 1. >> >> You can have as much white space as you want. >> >> 2. >> >> You don’t need to worry about indentation, and you can indent >> whenever you want. >> >> I hope that you consider these issues and fix them in Python 4 (if >> you ever make it). >> >> Sincerely, Anthony, age 10. >> >> >> >> -- >> mm m # >> ## m mm mm#mm # mm mmm m mm m m >> # # #" # # #" # #" "# #" # "m m" >> #mm# # # # # # # # # # #m# >> # # # # "mm # # "#m#" # # "# >> m" >> "" >> _______________________________________________ >> Python-Dev mailing list -- python-dev(a)python.org >> <mailto:python-dev@python.org> >> To unsubscribe send an email to python-dev-leave(a)python.org >> <mailto:python-dev-leave@python.org> >> https://mail.python.org/mailman3/lists/python-dev.python.org/ >> <https://mail.python.org/mailman3/lists/python-dev.python.org/> >> Message archived at >> https://mail.python.org/archives/list/python-dev@python.org/message/RZR2O3Y… >> <https://mail.python.org/archives/list/python-dev@python.org/message/RZR2O3Y…> >> Code of Conduct: http://python.org/psf/codeofconduct/ >> <http://python.org/psf/codeofconduct/> >> >> _______________________________________________ >> Python-ideas mailing list --python-ideas(a)python.org >> To unsubscribe send an email topython-ideas-leave(a)python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived athttps://mail.python.org/archives/list/python-ideas@python.org/message/OEI… >> Code of Conduct:http://python.org/psf/codeofconduct/ [View Less]

1 0

Re: Integer concatenation to byte string
by Barry Scott March 3, 2021

March 3, 2021

We where no longer on the ideas list... > On 2 Mar 2021, at 13:04, Memz <mmax42852(a)gmail.com> wrote: > > There is no specific scenario it solves. The lack of efficiency of the timed code should speak for itself. Non-mutable bytes is a limit of python, since it's reliant on using function calls. > > b"\x00\x00\x00\x00\x00" > bytearray( b"\x00\x00\x00\x00\x00" ) > struct.pack("iiiii",0,0,0,0,0) > b"\x00\x00\x00\x00\x00" + bytes([1,0,0,0,0]) You mean the above … [View More]is what you timed? It is not a realistic problem you are measuring. You also did not share how you measured the the code. If you are not experienced in benchmarking there are variables that you must control for to have meaningful results. > > All function calls take time and resources, it would be impossible to streamline a function call to make it faster than building it in. This goes for most languages, including C. All python byte code is interpreted by calling functions. They take time and resources. Barry > > > On Tue, Mar 2, 2021 at 3:29 AM Barry Scott <barry(a)barrys-emacs.org <mailto:barry@barrys-emacs.org>> wrote: > > > > On 2 Mar 2021, at 02:03, Memz <mmax42852(a)gmail.com <mailto:mmax42852@gmail.com>> wrote: > > > > >When I needed to do the creation of bytes objects from a mix of types the > > >struct.pack() method has been the obvious way to go. > > > > >What is the use case that leads to needing the above? > > > > >Barry > > > > The use of my suggestion is to reduce the reliance of function calls for bytes and bytearrays, which currently can only be done through function calls, and making it more efficient all-together. Here is a timed version of this: > > b-strings: 5-5.4 s > > bytearray() function call: 67.9 s > > struct.pack() 80.9 s > > b-string + bytes([1,...]) 54.3 s > > What code are you benchmarking? What problem does that code solve? > > My experience with creating byte objects is that struct is the fastest way to get the job done. > But that could be becuase of the problems that I need bytes for. > For example calling ioctl(). > > > > > Moving bytearray to a non-function call would overhaul and optimize code that works with bytes, increase flexibility, and reduce reliance on imports, including struct.pack(). There is a lot of code that could, and should be using bytearray but can't, because other, more slow and painful than should be methods are more efficient because of the function call nature of bytearray. > > You are assuming that the problem is the function calls. > Surely its the algorithms that lead to issues in most code that is slow? > > Barry [View Less]

3 3