[Python-ideas] Re: Trouble with "decorator mixins" and ABCs

I encountered this problem when I needed to implement a class that defined all 4 of the comparison operators, once with `dataclass` (for one implementation) and once with `total_order` (for another).Also, 3rd party libs are expected to fall down this rabbit hole, and unless they're expected to modi

[Python-ideas] Re: PEP 637 and keyword only subscripts

On Mon, Sep 28, 2020 at 08:19:01PM -0700, Ben Rudiak-Gould wrote: > Maybe a singleton that supported no useful operations, not even __eq__ or > __bool__, would be sufficiently inconvenient that it would only be used for > defaults and "is" tests for said defaults. NotImplemented is halfway there:

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Sun, Sep 27, 2020 at 07:59:18AM -0300, Sebastian Kreft wrote: > Hi Steven, could you share some examples of what you have in mind. Having a > more concrete example of an API that would benefit from mixed-subscripting > would allow us to better understand its usefulness. I have an experimental

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Tue, Sep 29, 2020, 2:41 PM Sebastian Kreft > You mean that internally_inches means the stored values are in inches, and > that by specifying a unit, you will scale up all the passed values? > > So that, internally_inches[4:6, 8:10, unit="meters"] = [[4, 2], [1, 3]] > would save in the (4:6, 8:1

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Wed, Sep 30, 2020 at 10:41 AM Sebastian Kreft wrote: > If I understood correctly what's going on, what would the difference between > > del internally_inches[4:6, 8:10, unit="meters"] and del > internally_inches[4:6, 8:10, unit="inches"] > Probably nothing, which shows that the ability to hav

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Tue, Sep 29, 2020 at 7:27 PM David Mertz wrote: > On Tue, Sep 29, 2020 at 12:09 PM Sebastian Kreft wrote: > >> On Tue, Sep 29, 2020 at 6:56 PM David Mertz wrote: >> >>> I still think it would improve the PEP significantly if it added one >>> case of mixed positional/keyword indexing. Lots o

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Tue, Sep 29, 2020 at 12:09 PM Sebastian Kreft wrote: > On Tue, Sep 29, 2020 at 6:56 PM David Mertz wrote: > >> I still think it would improve the PEP significantly if it added one case >> of mixed positional/keyword indexing. Lots of suggestions have floated by, >> and I don't care which one

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Tue, Sep 29, 2020 at 6:56 PM David Mertz wrote: > I still think it would improve the PEP significantly if it added one case > of mixed positional/keyword indexing. Lots of suggestions have floated by, > and I don't care which one is used, but something to demonstrate that > within the PEP. >

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

I still think it would improve the PEP significantly if it added one case of mixed positional/keyword indexing. Lots of suggestions have floated by, and I don't care which one is used, but something to demonstrate that within the PEP. On Tue, Sep 29, 2020 at 11:43 AM Guido van Rossum wrote: >

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

At this point I think we're all set for use cases, both for keyword-only and for mixed use. Clearly a lot of libraries are going to be able to provide better APIs using this PEP, and mixed use of positionals and keywords will be quite useful to some of these. -- --Guido van Rossum (python.org/~g

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

> Do you have an example from boost-histogram.. One of the dev's here, and actually, I think "Hist" would use it, rather than boost-histogram directly. In boost-histogram, axis are only represented by numbers, so `h[{0:slice(2,5)}]` probably could not be written `h[0=2:5]` even after this PEP;

[Python-ideas] Re: Add the brotli & zstandard compression algorithms as modules

29.09.20 16:26, Omer Katz пише: > What are the use-cases for LZMA that make it qualify to be part of the > stdlib? Why was that library included? > I think we shouldn't discriminate. If there are a couple of use-cases users > need and the implementation is sufficiently stable, I see no reason not

[Python-ideas] Re: Trouble with "decorator mixins" and ABCs

On 9/29/2020 10:49 AM, Ben Avrahami wrote: On Tue, Sep 29, 2020 at 4:53 PM Bar Harel > wrote: I'd like to bring another insight to the table: According to the pep, "Dynamically adding abstract methods to a class, or attempting to modify the abstraction stat

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Tue, Sep 29, 2020 at 8:02 AM Sebastian Kreft wrote: > But in some instance, there is more than one way to interpolate, so it > would be great to have: > >> >> sea_surface_temp[-78.123, 28.432, interp='linear'] >> > > I presume you would only use this to get the temperature and not to set or >

[Python-ideas] Re: Add the brotli & zstandard compression algorithms as modules

On Tue, Sep 29, 2020 at 6:34 AM Eric V. Smith wrote: > > I think we shouldn't discriminate. If there are a couple of use-cases > users need and the implementation is sufficiently stable, I see no reason > not to include those libraries in stdlib. > I think this was covered earlier in this thread

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)

On Tue, Sep 29, 2020 at 2:29 AM Christopher Barker wrote: > Sorry if this isn't the right thread -- there's a few now. > > But for an example of using both positional and keyword index parameters: > > I maintain a library (gridded) that provides an abstraction over data on > various types of grid

[Python-ideas] Re: Trouble with "decorator mixins" and ABCs

On Tue, Sep 29, 2020 at 4:53 PM Bar Harel wrote: > I'd like to bring another insight to the table: According to the pep, > "Dynamically > adding abstract methods to a class, or attempting to modify the abstraction > status of a method or class once it is created, are not supported." > > The noti

[Python-ideas] Re: Trouble with "decorator mixins" and ABCs

I'd like to bring another insight to the table: According to the pep, "Dynamically adding abstract methods to a class, or attempting to modify the abstraction status of a method or class once it is created, are not supported." The notice exists both in the pep and at the abc module's docs, and is

[Python-ideas] Re: Add the brotli & zstandard compression algorithms as modules

On 9/29/2020 9:26 AM, Omer Katz wrote: I actually disagree on HTTP2 but that's beside the point. What are the use-cases for LZMA that make it qualify to be part of the stdlib? Why was that library included? I think we shouldn't discriminate. If there are a couple of use-cases users need and th

[Python-ideas] Re: Add the brotli & zstandard compression algorithms as modules

I actually disagree on HTTP2 but that's beside the point. What are the use-cases for LZMA that make it qualify to be part of the stdlib? Why was that library included? I think we shouldn't discriminate. If there are a couple of use-cases users need and the implementation is sufficiently stable,

[Python-ideas] Re: Trouble with "decorator mixins" and ABCs

I think it can be easily solved much like a normal bug fix - upon instance creation and before throwing an "ABC doesn't implement..." error, recheck the class __dict__ or even mro using hasattr, and only then throw the exception. It will slow down only the specific course where the methods were de

[Python-ideas] Re: Regular Expression | re - Support String List Input Type List[str]

would rather it took List[str] patterns instead, for matching against List[str] input. so you could do things like: pattern = ["foo", "?", "\", "?", "bar", "baz"] input = ["foo", "?", "bar", "baz"] # matches input = ["?", "bar", "baz"] # matches input = ["foo?barbaz"] # doesn't match bonus points

[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments

Salve Stefano, Stefano Borini schrieb am 23.09.20 um 22:55: > "Support for indexing with keyword arguments" has now been merged with > the assigned PEP number 637. Cool, this looks like a great addition to the language! One thing that I'm missing from the PEP is the C side of things, though. How

[Python-ideas] Re: Regular Expression | re - Support String List Input Type List[str]

import re re_search = re.search def re_search_list(pattern, list_or_text): if isinstance(list_or_text, str): return re_search(pattern, list_or_text) return [re_search_list(pattern, i) for i in list_or_text] re.search = re_search_list Bottom line: no need to change the function, y