Mailman 3 December 2019 - Python-ideas

Fixed point format for numbers with locale based separators
by Łukasz Stelmach 20 Dec '19

20 Dec '19

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

Add symlinks option at shutil.move parameters
by Namjun Kim 18 Dec '19

18 Dec '19

I think shutil.move method should provide symlinks option. It's because if the developer wants to move a specific file with metadata, they must be develop their custom move method. (https://github.com/python/cpython/blob/master/Lib/shutil.py#L807) If shutil.move provide symlinks option, the developer doesn't need to develop the same custom move method and maintain their own metadata.

1 1

Re: Argumenting in favor of first()
by Christopher Barker 15 Dec '19

15 Dec '19

On Sat, Dec 14, 2019 at 2:50 AM Stephen J. Turnbull < turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > Did you intend to reply only to me? Nope - I hate list that don’t default to replying to the list (I know that’s an unpopular opinion). I was wondering why no one comment on it. > I’m quite convinced that first() would NOT cause any particular > > confusion, neither for sets nor iterators. > > I don't see how you make that judgment so confidently, since you don't > claim experience with `first`, only the educationally problematic > `next(iter())`. Well, that’s why I said *I’m* convinced, rather than state it as a general truism. I have a lot of experience with newbies, so I think I have a pretty good idea what tends to trip them up. I could be wrong of course, but without actually introducing it using it in and a couple of years worth of teaching, we’ll never know for sure :-) I don't agree. I can't speak for others, but once I understood the > difference between "iterable" and "iterator", "next(iter(iterable))" > was self-explanatory when I first encountered it. Sure — but the newbies I’m talking about don’t yet understand the difference between "iterable" and "iterator", and many people get very far before they do. I *think* the primary target audience for first() would be those folks, so it’s kind of ironic that we’re concerned about confusing them. > I don't see how you > explain all that in terms of first() without the concept of iter(), > and the detail that (iter(iterator)) == iterator. I don’t think you need to — that’s my whole point. In common code, folks rarely work with bare iterators (usually they are implicitly created in a for loop, for instance), so that distinction doesn’t come up. And when it *does* come up, it applies to every use of the iteration protocol: for loops, next, etc. so nothing special about first() I think I made that point already, probably in a note sent to only one person by mistake. Of the top of my head, I can’t think of a single non-contrived example of using a bare iterator in case that is not specifically doing something “special”. Can anyone else? Sure, you can > *tell* students that's how first() works, but how do they apply it in > their own code? You tell them that can use it to get the first item out of a container or other iterable. And you’re done. Some time in the future, they may encounter a bare iterator, and surprised that first() consumes an item. But as I said before, they’ll have other issues as well, and will need to learn about iterators then. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

6 12

Re: Argumenting in favor of first()
by Juancarlo Añez 14 Dec '19

14 Dec '19

> The argument that first(it) and next(it) "look the same" doesn't convince > me; if these look the same then all function applications look the same, > and that can certainly not have been Meertens' intention. But if everyone > thinks that first() should raise, fine, this thread is way too long already > (I should have kept it muted :-). > The reason why *first()* must raise is so it can be applied to iterables that may yield *None* as the legit, *first* value. I was after *findall(..)[0]* and other anti-patterns, but, I think that the semantics of *next(it)* cannot be changed to those of *next(iter(it))*, which is what solves most problems, so a new function is needed, one with the semantics of *more_itertools.first()*. As I said elsewhere, maybe it's just a matter of finding the right name, or of admitting that *more_itertools.first()* solved it first. It would be absurd for the docs to provide the source code to *more_itertools.first()* as a recipe, and also absurd to recommend including * more_itertools* in projects (stdlib Python must be self-containing/reliant). Yet! Just agreeing on what the recipe and use-cases in the docs for *itertools* should be would be a great step forward. -- Juancarlo *Añez*

1 0

frozen dataclasses attribute initialization
by Arthur Pastel 13 Dec '19

13 Dec '19

When creating frozen dataclasses, attribute initialization must be done using `object.__setattr__()` it would be nice to allow attribute assignment in the `__init__` and `__post_init__`. Currently we have to do this : ```python @dataclasses.dataclass(frozen=True) class Person: name: str surname: str fullname: str = dataclasses.field(init=False) def __post_init__(self): object.__setattr__(self, "fullname",f"{self.name} {self.surname}") ``` I think it would be more clean like this: ```python @dataclasses.dataclass(frozen=True) class Person: name: str surname: str fullname: str = dataclasses.field(init=False) def __post_init__(self): self.fullname = f"{self.name} {self.surname}" ```

6 19

Re: Argumenting in favor of first()
by Steven D'Aprano 13 Dec '19

13 Dec '19

On Fri, Dec 13, 2019 at 07:41:59AM -0400, Juancarlo Añez wrote: > It was my omission in the OP that *default=* should be explicit, instead of > an implicit *None.* The consistent semantics are those of *dict.get()* and > *dict.pop()*. py> {1:'a'}.get(999) is None True -- Steven

1 0

Python slicing
by Siddharth Prajosh 13 Dec '19

13 Dec '19

Python slicing looks really weird. How do I explain *s=list(range(100)); s[10:20] *gives you a part of the list. Can we have an extra function for lists and string (and wherever slicing works) to explicitly mention that we're slicing?? Something like - *s=list(range(100)); s.slice(10, 20).* Has this been mentioned before? What would be a drawback of having something more readable like a *.slice* function? Would love to know your thoughts. PS: Explicit is better than Implicit :)

12 27

Sets for easy interning(?)
by Soni L. 11 Dec '19

11 Dec '19

This is an odd request but it'd be nice if, given a set s = {"foo"}, s["foo"] returned the "foo" object that is actually in the set, or KeyError if the object is not present. Even use-cases where you have different objects whose differences are ignored for __eq__ and __hash__ and you want to grab the one from the set ignoring their differences would benefit from this.

10 21

Change StopIteration handling inside generator-like builtins
by Chris Angelico 08 Dec '19

08 Dec '19

PEP 479 (https://www.python.org/dev/peps/pep-0479/) changed the rules around generators: if it would have leaked StopIteration, it instead raises RuntimeError. This converts hard-to-debug premature termination into easily-spotted exceptions, but it applies only to actual generator functions. Implementing a map-like function as a generator means you're safe: def poof(x): if x == 5: raise StopIteration # Leak! return x * 3 def mymap(func, it): for value in it: yield func(value) for n in mymap(poof, range(10)): print(n) Boom! RuntimeError that highlights the source of the StopIteration. Similarly, using a list comprehension is safe: [poof(n) for n in range(10)] # raises StopIteration But using the built-in map() will silently terminate: for n in map(poof, range(10)): print(n) I propose to grant PEP 479 semantics - namely, that a StopIteration during the calling of the mapped function be translated into a RuntimeError. Likewise for filter(), guarding the predicate function, and all similar functions in itertools: accumulate, filterfalse, takewhile/dropwhile, starmap, and any that I didn't notice. ChrisA

3 3

Fwd: Re: Fwd: re.findfirst()
by Juancarlo Añez 08 Dec '19

08 Dec '19

On Wed, Dec 4, 2019 at 3:02 PM Guido van Rossum <guido(a)python.org> wrote: > Fair enough. I’ll let the OP defend his use case. > The OP thinks that the case for wanting just the string for a first regex match, or a verifiable default if there is no match, is way too common, that the advice on the web is not very good (it should be "write a findfirst() using next() over finditer()", and that novices default to using findall(..)[0], which is troublesome. The proposed implementation of a findfirst() would handle many common cases, and be friendly to newcomers (why do I need to deal with a Match object?), specially if the semantics are those of *findall()*: next(iter(findall(...)), default=default) BTW, a common function in extensions to *itertools* is *first():* def first(seq, default=None): return next(iter(seq), default= default) That function, *first()*, would also be a nice addition in *itertools*, and *findfirst()* could be implemented using it. *first()* avoids most use cases needing to check if a sequence or iterator is empty before using a default value. MHO is that *first()* deals with so many common cases that it should be a builtin. Note that the case for *findfirst()* is weaker if *first()* is available. Yet *findfirst()* solves the bigger problem. -- Juancarlo *Añez*

8 28