Mailman 3 May 2019 - Python-ideas

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

May 14, 2019

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 May 13, 2019

May 13, 2019

> 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 &… [View More]gt; 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. [View Less]

22 51

Path conversion for f-strings
by Batuhan Taskaya May 13, 2019

May 13, 2019

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 May 12, 2019

May 12, 2019

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 … [View More]

5 6

More alternate constructors for builtin type
by Serhiy Storchaka May 9, 2019

May 9, 2019

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 … [View More]

13 25

Re: [Python-ideas] Trigonometry in degrees
by Hugh Fisher May 8, 2019

May 8, 2019

> 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 … [View More]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 [View Less]

16 29

Specific equality method for hashable objects
by Phillip Cloud May 8, 2019

May 8, 2019

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* … [View More]

2 1

A proper way to bring real interfaces to Python
by Serge Matveenko May 8, 2019

May 8, 2019

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 … [View More]

6 15

Open parenthesis in REPL completion
by Danilo J. S. Bellini May 6, 2019

May 6, 2019

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 -----------… [View More]

8 12

Adding multiple constructors on one class
by Zakariae Saih May 6, 2019

May 6, 2019

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