Mailman 3 May 2019 - Python-ideas

(meta) Broken link to gmane.org archive of python-ideas
by Tom Hale 14 May '19

14 May '19

Heya all, I've joined this list and wanted to read the archives to get a flavour of the community here. I noticed that the link with text: gmane.org archive of python-ideas on the page: https://www.python.org/community/lists/ gives a HTML page with the only text being: Page Not Found I couldn't easily work out what the correct link should be, but part of the solution seems to be httpS:// Perhaps someone here knows how to wrangle gmane.org? -- Tom Hale

5 7

Re: [Python-ideas] add an additional dataclasses.asdict option for non-dataclasses
by Ricky Teachey 13 May '19

13 May '19

> Are "asdict" APIs all that common? There are at least two in the std lib: namedtuple._asdict(), and dataclasses.asdict. I assume there are others I'm not aware of. > Conventionally you would get the caller to do this... > Anything else involves lots of guesswork... > The problem with "casting" a generic non-dataclass object to a dict is > that it's not remotely obvious how you do that. What key do you use if > your object is a simple int or string? If you have even a > straightforward user class aren't just using "thing.__dict__", what > attributes do or do not make it into the dictionary? I get the impression that what I am suggesting wasn't clear. Let me approach it from a different direction. The language already provides the mapping protocol for user defined dict-making; ie, dict(myobj). So "this is how you define dict-making" rabbit hole is not only not worth going down, it's already been addressed for a very long time. The problem I want to address is very specific and two pronged: 1. some of the std lib modules DON'T USE the mapping protocol (for various very legitimate reasons) 2. some user-defined types also don't use the mapping protocol, also often for legit reasons Therefore the proposal is not to guess anything at all. The idea is to rigorously track all the existing dict APIs that have been put into the std lib over the years into a dict-making convenience function, since, for example, dict(my_dataclass) and dict(my_namedtuple) are (legitimately) broken. One can then confidently apply that asdict() convenience function without having to resort to a complicated string of if statements that might not even catch all cases. The language already does this kind of cataloging for other things, like getting a list of all the reserved keywords. Why not catalog all the std lib dict-making APIs into a dict-making convenience function, too? For user-defined protocols, we simply leave HOW to dict-ify to the caller via the factory_dict argument (if it is provided). If it isn't provided, one of the following would happen: - raise an error -- similar or even identical to, perhaps, the error raised for dict("foo") or dict(42) - use the default dict_factory (which is dict; identical to above, but succeeds if there is a dict-casting protocol already implemented) I favor the second, but I'm not dogmatic about which of those would be better. Again: no interest in trying to guess at user defined dict-making APIs as such, aside from allowing the caller to provide that API themselves if they so wish.

22 51

Path conversion for f-strings
by Batuhan Taskaya 13 May '19

13 May '19

Like repr and string the file system path is used alot and something like path!p might be handy. >>> class MyClass: ... def __fspath__(self): ... return "/home/batuhan" ... >>> assert f"{mc!p}" == f"{os.fspath(mc)}" Also it saves us to unnecessarily import os for only fspath().

2 1

Running average and stdev in the statistics module?
by Luca Baldini 12 May '19

12 May '19

Hi here, I wonder if the idea of adding to the statistics module a class to calculate the running statistics (average and standard deviation) of a generic input data stream has ever come up in the past. The basic idea is to do the necessary book-keeping as the data are fed into the accumulator class and to be able to query the average variance of the sequence at any point in time without having to loop over the thing again. The obvious way to do that is well know, and described, e.g., in Knuth TAOCP vol 2, 3rd edition, page 232. FWIW It is something that through the years I have coded myself a myriad of times (e.g., for real-time data processing)---and maybe worth considering for addition to the standard library. For completeness, a cursory look on google brings up this fairly nice package https://pypi.org/project/runstats/ but really, the core algorithm would be trivial to code in a fashion that works with decimal and fraction objects to be integrated into the statistics module. Should this spur enough interest (and assuming that the maintainer(s) of the module are not hostile to the idea) I'd like to volunteer to put together an tentative implementation. [It's my first post on this list, so please be gentle :-)] Luca -- =============================================================================== Luca Baldini Universita' di Pisa and Istituto Nazionale di Fisica Nucleare - Sezione di Pisa Largo Bruno Pontecorvo 3, I-56127, Pisa, ITALY. phone : +39 050 2214438 fax : +39 050 2214317 e-mail : luca.baldini(a)pi.infn.it icq : 396247302 (Garrone) web : http://www.df.unipi.it/~baldini mirror : http://www.pi.infn.it/~lbaldini ===============================================================================

5 6

More alternate constructors for builtin type
by Serhiy Storchaka 09 May '19

09 May '19

Constructors for builtin types is too overloaded. For example, int constructor: * Converts a number (with truncation) to an integer. * Parses human readable representation of integer from string or bytes-like object. Optional base can be specified. Note that there is an alternate constructor for converting bytes to int using other way: int.frombytes(). * Without arguments returns 0. str constructor: * Converts an object to human-readable representation. * Decodes a bytes-like object using the specified encoding. * Without arguments returns an empty string. bytes constructor: * Converts a bytes-like object to a bytes object. * Creates a bytes object from an iterable if integers. * Encodes a string using the specified encoding. The same as str.encode(). * Creates a bytes object of the specified length consisting of zeros. Equals to b'\0' * n. dict constructor: * Creates a dict from a mapping. * Creates a dict from an iterable of key-value pairs. * Without arguments returns an empty dict. The problem of supporting many different types of input is that we can get wrong result instead of error, or that we can get error later, far from the place where we handle input. For example, if our function should accept arbitrary bytes-like object, and we call bytes() on the argument because we need the length and indexing, and we pass an integer instead, we will get an unexpected result. If our function expects a number, and we call int() on the argument, we may prefer to get an error if pass a string. I suggest to add limited versions of constructors as named constructors: * int.parse() -- parses string or bytes to integer. I do not know whether separate int.parsestr() and int.parsebytes() are needed. I think round(), math.trunc(), math.floor() and math.ceil() are enough for lossy converting numbers to integers. operator.index() should be used for lossless conversion. * bytes.frombuffer() -- accepts only bytes-like objects. * bytes.fromvalues() -- accepts only an iterable if integers. * dict.frommapping() -- accepts only mapping, but not key-value pairs. Uses __iter__() instead of keys() for iterating keys, and can take an optional iterable of keys. Equals to {k: m[k] for k in m} or {k: m[k] for k in keys}. * dict.fromitems() -- accepts only key-value pairs. Equals to {k: v for k, v in iterable}.

13 25

Re: [Python-ideas] Trigonometry in degrees
by Hugh Fisher 08 May '19

08 May '19

> Date: Thu, 7 Jun 2018 12:33:29 +0000 > From: Robert Vanden Eynde <robertvandeneynde(a)hotmail.com> > To: python-ideas <python-ideas(a)python.org> > Subject: [Python-ideas] Trigonometry in degrees > Message-ID: > > > I suggest adding degrees version of the trigonometric functions in the math module. > > - Useful in Teaching and replacing calculators by python, importing something is seen by the young students much more easy than to define a function. I agree that degrees are useful for teaching. They are also very useful for graphics programming, especially with my favourite OpenGL API. But I think that the use of radians in programming language APIs is more prevalent, so the initial advantage of easy learning will be outweighed by the long term inconvenience of adjusting to what everyone else is doing. Writing degrees(x) and radians(x) is a little inconvenient, but it does make it clear what units are being used. And even if your proposal is adopted, there is still going to be a lot of code around that uses the older math routines. With the current API it is a least safe to assume that angles are radians unless stated otherwise. > - Special values could be treated, aka when the angle is a multiple of 90, young students are often surprise to see that cos(pi/2) != 0 > > Testing for a special value Isn't very costly (x % 90 == 0) but it could be pointed out that there is a small overhead using the "degrees" equivalent of trig function because of the radians to degrees conversion And the special values testing. Not just young students :-) I agree with this, but I would prefer the check to be in the implementation of the existing functions as well. Any sin/cos very close to 0 becomes 0, any close to 1 becomes 1. > - Standard names will be chosen so that everyone will use the same name convention. I suggest adding a "d" like sind, cosd, tand, acosd, asind, atand, atan2d. Not "d". In the OpenGL 3D API, and many 3D languages/APIs since, appending "d" means "double precision". It's even sort of implied by the C math library which has sinf and friends for single precision. > > Creating a new package like 'from math.degrees import cos' however I would not recommend that because "cos" in the source code would mean to lookup the import to know if it's in degrees or radians (and that leads to very filthy bugs). Also "degrees" is already so the name would have to change the name of the package. Agree, not a good idea. -- cheers, Hugh Fisher

16 29

Specific equality method for hashable objects
by Phillip Cloud 08 May '19

08 May '19

A number of libraries override the equality operator (__eq__) in such a way that it returns an object that isn't a Python bool. This all but precludes making these objects hashable, even though there's nothing in principle that prevents them from being so. The main use case I have in mind is an expression DSL that returns another expression when its __eq__ method is called (sqlalchemy is a good example of such a DSL). In such DSLs you often want to use expressions as keys in dict. You *can* use them as keys, but the code that does is only reliable insofar as it can guarantee that the expressions in the dict are identical (in the sense of a pointer) to the values you're going to later use for lookup. After thinking about this for a bit, I'd like to understand whether it's reasonable to propose a new method __hash_eq__ that would be used during dict key comparisons (in lookdict). This new method would allow an object to override __eq__ *and* be hashable, by defining __hash_eq__. __hash_eq__ would only be allowed to return a bool, unlike __eq__. Regarding backwards compatibility, __hash_eq__ would be defined by default to be equivalent to __eq__. I haven't thought about other standard library mappings like OrderedDict yet, and it's entirely possible that such considerations would kill this idea. I did some googling before writing this up, and I couldn't find anything that proposed anything like this but perhaps my google skills are lacking. If there's a history here that I'm missing I'm happy to learn more about it.

2 1

A proper way to bring real interfaces to Python
by Serge Matveenko 08 May '19

08 May '19

Hi, all! I believe, almost everybody is familiar with the `abc` package. The problem is that the ABC class is not a separate thing from `object`. So, using ABCs often results in complicated inheritance designs and even in the infamous metaclass conflict. Another problem is that ABC performs checks at the moment an object is being instantiated which isn't exactly the way one expects an interface to work. The obvious way would be to enforce the implementation at the moment `type` for that class is created, i.e. on module execution time. I'm aware there was `PEP 245 -- Python Interface Syntax` which was rejected. However, I agree with the idea that the syntax proposed in this PEP wasn't particularly "pythonish". So, I would like to propose adding a third main object called `interface` in addition to `object` and `type` and to use it to define interface objects. Such interfaces could then be used in the class definition in the following way. ``` class MyInterfaceA(interface): def foo(): pass class MyInterfaceB(interface): def bar(): pass class Implementation(implements=[MyInterfaceA, MyInterfaceB]): def foo(): pass def bar(): pass ``` As a proof of concept, I've implemented a library which implements the idea and allows to use this approach right out of the box — https://pypi.org/project/strict-interfaces/. I would like to get any feedback for the idea and the library. Thanks to all!

6 15

Open parenthesis in REPL completion
by Danilo J. S. Bellini 06 May '19

06 May '19

I'm not aware if that was already discussed, but something I find quite annoying is the REPL auto-complete that also includes the open parenthesis symbol. I think it shouldn't be included in TAB completion. At least twice a week I make mistakes like typing "help(something()" with unmatched parentheses, because the "something" was filled by a TAB completion, and the trailing open parenthesis wasn't expected (given that there's no such a completion elsewhere). -- Danilo J. S. Bellini --------------- "*It is not our business to set up prohibitions, but to arrive at conventions.*" (R. Carnap)

8 12

Adding multiple constructors on one class
by Zakariae Saih 05 May '19

05 May '19

Hello python team! you should consider adding the ability to create multiple constructors on one class like c# and Java it is really useful. *Example*: i want a constructor takes 1 argument and other constructor takes 2 and another one takes none in the same class. so when i want to create an object i got a lot of options. i know i can do it by given a default value to the attribute but it will be better with multiple constructors

4 3