Mailman 3 November 2019 - Python-ideas

Fixed point format for numbers with locale based separators
by Łukasz Stelmach Dec. 20, 2019

Dec. 20, 2019

Hi, I would like to present two pull requests[1][2] implementing fixed point presentation of numbers and ask for comments. The first is mine. I learnt about the second after publishing mine. The only format using decimal separator from locale data for float/complex/decimal numbers at the moment is "n" which behaves like "g". The drawback of these formats, I would like to overcome, is the inability to print numbers ranging more than one order of magnitude with the same number of decimal digits without "manually" (with some additional custom code) adjusting precission. The other option is to "manually" replace "." as printed by "f" with a local decimal separator. Neither of these option is appealing to my. Formatting 1.23456789 * n (LC_ALL=3Dpl_PL.UTF-8) | n | ".2f" | ".3n" | |---+----------+----------| | 1 | 1.23 | 1,23 | | 2 | 12.35 | 12,3 | | 3 | 123.46 | 123 | | 4 | 1234.57 | 1,23e+03 | In the application I want to create I am going to present users numbers ranging up to 3 orders of magnitude and I (my users) want them to be presented consistently with regards to number of decimal digits AND I want to conform to rules of languages of my users. And I would like to avoid the exponent notation by all means. I can't say much about James Emerton's implementation or his intentions, but please take a look at our patches and give your comments so either of us or together we can implement this feature. PS. In theory both implementations could be merged because James chose to use "l" to use LC_MONETARY category and I chose "m" to use LC_NUMERIC. [1] https://github.com/python/cpython/pull/11405 [2] https://github.com/python/cpython/pull/8612 -- Miłego dnia, Łukasz Stelmach

5 9

math.copysign not to introduce float
by Marein Dec. 4, 2019

Dec. 4, 2019

The math.copysign(x, y) function always returns a float, even when the given x is an int, i.e. math.copysign(3, -1) gives -3.0. This is documented behaviour, but I find it somewhat surprising given that the name suggests that it only copies a sign, and it's also annoying in situations when an int is strictly needed (i.e. as the step argument to range), requiring an additional cast. I'm interested to hear whether it might be a good idea to preserve the int/float type of the argument in math.copysign.

7 8

PEP's shouldn't require a sponsor
by Batuhan Taskaya Dec. 3, 2019

Dec. 3, 2019

Why do i need to convince a core developer for my PEP? AFAIK the steering council can include non core developers (i know it isn't that current case but for the future this is important). And if the last authority who will approve my PEP is the steering council i just need to convince them not core developers. Sponsors can stay (and they should because guidance is important) but thy shouldn't be mandatory. Let everyone to send their peps.

22 29

namedtuple for dict.items()/collections.abc.Mappings.items()
by Soni L. Dec. 1, 2019

Dec. 1, 2019

I have a lot of code that looks like this: def filter(self, it, defs): for x in it: for y in _match_helper(self.key, defs, x[0]): yield (y, x[1]) def filter(self, it): for el in it: try: if self.compiled.search(el[0]): yield el elif not self.skippable: raise ValidationError except TypeError: if not self.skippable: raise ValidationError def filter(self, it, ty): for el in it: # this may TypeError if ty is not a type nor a tuple of types # but that's actually the programmer's error if isinstance(el[1], ty): yield el elif not self.skippable: # and this one is for actual validation raise ValidationError It'd be quite nice if dict.items() returned a namedtuple so all these x[0], x[1], el[0], el[1], etc would instead be x.key, x.value, el.key, el.value, etc. It would be more readable and more maintainable.

8 12

Access to member name/names via context during Enum instance initialization
by Steve Jorgensen Dec. 1, 2019

Dec. 1, 2019

I brought this up before, but I had a kind of weak understanding of `enum.Enum` at the time, so my expression of the issue and proposal for a solution were pretty awkward. Basically, with the current implementation of `Enum` and supporting classes, the only way that a member can have access to its own name during or prior to its initialization is if/when its value is auto-generated, so if you want to specify a value rather than having it auto-generated (e.g. to generate a label attribute) then there's no convenient way to do it. One can work around that by writing the code to make use of the `name` property after installation, but why should we force the developer to write code in an awkward manner when we could simply make the name available to the `__new__ method. It might also be nice to supply the list of all names (in case the value is assigned to multiple names) as well as the primary name. The idea that comes to mind is to pass a `context` object argument to `__new__` with `name` and `names` attributes. To preserve backward compatibility, there could be have a class attribute named something like `_use_context_` (`False` by default) to enable or disable passing that parameter. Going forward, additional attributes could be added to the context without additional backward compatibility concerns. Of course, the exact mechanism could be something completely different, but I'd like to see this or some other mechanism that addresses the concern.

5 12

Request: pointers to exemplar threads from python-ideas?
by C. Titus Brown Nov. 29, 2019

Nov. 29, 2019

Hi folks, I’m working on some help documentation for python-ideas and first-time contributors, and I’d like to include a few examples of discussions that were productive and led to changes. I browsed through the archives and found a few positive and negative examples (below) but didn’t find one that led to a full PEP proposal (I know they’re rare!) I’d like to crowdsource this and get some good examples from y’all, if you don’t mind. If people have any exemplar discussions in mind, could you drop them to me privately? Thanks in advance! (Threads from python-dev also welcome, but my intent is to show people new to the python-ideas list what they should expect.) best, —titus —— ** Brief thread about bad fit with Python philosophy: Specific equality method for hashable objects https://mail.python.org/archives/list/python-ideas@python.org/thread/X2FXOY… ** Brief thread about a simple fix that could be implemented without a PEP: Add a `dir_fd` parameter to `os.truncate`? https://mail.python.org/archives/list/python-ideas@python.org/thread/RLW76D… ** Brief thread about not using undocumented Windows APIs in the stdlib: Add subprocess.Popen suspend() and resume() https://mail.python.org/archives/list/python-ideas@python.org/thread/NNNCG4… ** A long discussion of small changes that adjusted PEPs but did not require a new one: PEP: Dict addition and subtraction https://mail.python.org/archives/list/python-ideas@python.org/thread/KLDQAP… ** Clarification of behavior leading to documentation fix, no PEP required: Fix documentation for __instancecheck__ https://mail.python.org/archives/list/python-ideas@python.org/thread/5BPDKW…

3 2

Calendar.year()
by Abdur-Rahmaan Janhangeer Nov. 28, 2019

Nov. 28, 2019

Greetings list, In the calendar module, i find it terribly unintuitive to have a calendar.month but not a calendar.year, the default being calendar.calendar Suggestion: replace calendar.calendar by calendar.year Yours, Abdur-Rahmaan Janhangeer pythonmembers.club <http://www.pythonmembers.club/> | github <https://github.com/Abdur-rahmaanJ> Mauritius

5 4

Update pep8 for stressing type hinted long parameter in functions
by Stefano Borini Nov. 27, 2019

Nov. 27, 2019

This may be a pet peeve of mine, but with the introduction of type hints, more and more function definitions have become longer than 80 characters. This used to seldom happen in the past. The problem, as I see it, is that there seem to be a general tendency to use this way of indenting, e.g. see (among many): https://github.com/samuelcolvin/pydantic/blob/c71326d4a6898612597d3c647a425… def load_file( path: Union[str, Path], *, content_type: str = None, encoding: str = 'utf8', proto: Protocol = None, allow_pickle: bool = False, ) -> Any: path = Path(path) b = path.read_bytes() if content_type is None: if path.suffix in ('.js', '.json'): proto = Protocol.json elif path.suffix == '.pkl': proto = Protocol.pickle This violates pep8 # Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest. def long_function_name( var_one, var_two, var_three, var_four): print(var_one) However, no coding styles tools report that. Flake8 does however report a similar error for if conditions if path.suffix in ( '.js', '.json' ): proto = Protocol.json x.py:20:5: E125 continuation line with same indent as next logical line But says nothing for this monstrosity, which is the equivalent of the opening case if path.suffix in ( '.js', '.json' ): proto = Protocol.json It is not my intention to trigger a massive discussion. My stance is that the appropriate visual aspect of the above code should be def load_file( path: Union[str, Path], *, content_type: str = None, encoding: str = 'utf8', proto: Protocol = None, allow_pickle: bool = False) -> Any: path = Path(path) b = path.read_bytes() to keep a visual distinction in indentation between the argument list and the function body, as in the spirit of pep8. Regardless of the choice, I think that pep8 should be updated with the appropriate style for this specific case, and style tools should enforce this choice. -- Kind regards, Stefano Borini

6 6

Percent notation for array and string literals, similar to Perl, Ruby
by Steve Jorgensen Nov. 25, 2019

Nov. 25, 2019

See https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Literals#The_%_Notati… for what Ruby offers. For me, the arrays are the most useful aspect. %w{one two three} => ["one", "two", "three"] I did a search, and I don't see that this has been suggested before, but I might have missed something. I'm guessing I'm not the first person to ask whether this seems like a desirable feature to add to Python.

19 78

Re: Python should take a lesson from APL: Walrus operator not needed
by Martin Euredjian Nov. 22, 2019

Nov. 22, 2019

> Really? Because I’ve been using ABC notation for music for decades Try writing an orchestral suite in ASCII and see how well it goes. C'mon. I know people use tablature and similar ideas. Sure. So what? > The fact that I can enter Python code as plain text is even more useful than music and math. Sure, because you speak English. Go talk to a kid who has to learn this in, I don't know, Egypt or China. Sorry, notation is far more powerful. As I said in one of my other notes, people who have not had the unique experience of using something like APL for non-trivial development work simply don't get it. This is very much a conservative reaction (I do not mean this in the political sense at all) in that people are always more comfortable with things they know staying the same. I suspect that, had I not been pulled from a FORTRAN class by my APL-evangelist Physics professor in college I would likely react similarly if someone told me it might be better to consider notation as a way to improve computational expression of ideas. I get it. I am not oblivious to the absolute fact that context is crucially important here and very few people without the appropriate context are open minded enough to consider new ideas without becoming passionately involved in a negative way. Anyhow, I'll repeat, I am nobody and I am certainly not going to change the Python world. Sleep well knowing this is just another random moron saying something he probably should not have said. I now see this is an intellectually welcoming community, which completely explains the walrus operator and other issues. Thanks anyway, -Martin On Wednesday, November 6, 2019, 02:22:00 PM PST, Andrew Barnert <abarnert(a)yahoo.com> wrote: On Nov 6, 2019, at 18:05, Martin Euredjian via Python-ideas <python-ideas(a)python.org> wrote: > > No, using "<--" is going in the wrong direction. We want notation, not ASCII soup. One could argue even walrus is ASCII soup. Another example of ASCII soup is regex. Without real notation one introduces a huge cognitive load. Notation makes a massive difference. Any classically trained musician sees this instantly. If we replaced musical notation with sequences of two or three ASCII characters it would become an incomprehensible mess. Really? Because I’ve been using ABC notation for music for decades, and it’s never felt like an incomprehensible mess to me. While it doesn’t look as nice as normal musical notation, it’s even easier to learn, and it doesn’t take that long to be able to read it. And the fact that I can enter it a lot faster—and, more importantly, that I can enter it in exactly the same way in any email client, text editor, etc.—makes it hugely useful. When I’m out somewhere and think of a riff, I can just pull out my phone, fire up the Notes app, and type in the ABC. That’s visual enough for me to get it out of my consciousness and then read it off and hear it in my head so I can come up with a bassline to go with it. Or to read back a few days later and play it (after a couple seconds of processing, which admittedly isn’t as good as musical notation—but a lot better than nothing, which is what I’d have if I insisted on musical notation or nothing). For some reason, ABC is something that only musicologists learn, not musicians, unless you happen to get lucky and find it by accident. But many other musicians come up with their own idiosyncratic systems for the same purpose. You also mentioned math. The last visual editor for math I didn’t absolutely hate was my HP42. And I’d still rather use ASCIIMathML over that, much less something like Microsoft Word’s equation editor. It’s great to have something like MathJax on-the-fly rendering, but when I don’t have that, I can read x_0, or (-b +- sqrt(b^2 – 4ac))/(2a). Some things are too complicated for ASCIIMathML, but for them, I’ll use TeX; there’s no way I’d figure it out in a symbolic editor without a whole lot of painful trial and error. The fact that I can enter Python code as plain text is even more useful than music and math. Sure, in your IDE, alt-[ types an arrow. But what happens when you type alt-[ in your iPhone mail app, in emacs or vi over an ssh session to a deployed server, in web text boxes like the the answer box on StackOveflow, in your favorite editor’s markdown mode, in a WYSIWYG word processor, or even just in someone else’s IDE? And I do all those things a lot more often with source code than I do with music or equations. How are you entering the arrows in these emails? Do you fire up your IDE, type an arrow, and then copy and paste it into your webmail or something like that? If you were on your phone instead of your laptop, would you go search the web for the Unicode arrow and copy and paste from there? Does any of that really seem as easy to you as typing := the exact same way in every editor in the world? I wouldn’t mind an editor that had the same kind of “presentation mode” as markdown and mathjax editors, and if it rendered := as an arrow, that would be fine. But I’d still want to be able to type it as :=, because as long as I have to type it that way on a mailing list, I’d rather have just := in my muscle memory than have := and alt-[ and have to remember which one to use in which context. (PS, I’ve never noticed before this that the two main text notations for music have the same name as Python’s predecessor and Python’s creator. Probably not significant…)

19 35