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

[Ben Avrahami]

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 modify `__abstractmethods__` and perform abstract logic on
their own- I don't see why the standard library should keep such
computations unavailable.

On Tue, Sep 29, 2020 at 6:41 PM Eric V. Smith  wrote:

> 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
>> 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
>> exactly what this idea is all about.
>>
>> My question is why? Was there an objection for implementing such a thing,
>> or was it complex enough to postpone for the time being?
>>
>
> I think this is fine. The "abstract-ness" of a class is not supposed to
> change throughout its lifetime. The problem arises when decorators change
> the class before it's ever used, as that should still be considered its
> "initialization" as far as the user is concerned, so its "abstract-ness"
> should change accordingly.
> I agree with Guido in that the cleanest solution is to change the
> decorators. Perhaps a module function to recalculate a class's
> __abstractmethods __, that mixin decorators can call prior to returning the
> class. I can't really think of standard library class decorators that would
> use this global function other than `dataclass` and `total_ordering`, but
> in this way, 3rd party decorators can easily support implementing abstract
> functions.
> The one downside to this solution is that it can easily be abused by
> calling it in the middle of a class's lifetime.
>
> I think I'd like to see dataclasses handle this directly, so as to keep it
> easy to use. But I can be argued with: it's not like a beginner would
> stumble over this issue.
>
> Eric
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/EQQVNE4IVG5ZLWZHY3HCIATUY32PHWJG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ASPJKUZ46MAD5FT6HOLIFSQDFZR7IFGY/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

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: it supports equality test, but as of 
3.9 or 3.10, I forget which, it no longer supports use in a bool 
context.



-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GKR2ZZZPUIMS3IKFS2IQQRIPXI6U6NTO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

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 Matrix class:

https://en.wikipedia.org/wiki/Matrix_(mathematics)

There are (at least) three indexing operations needed:

- row
- column
- individual cell

The first two support get, set and delete; the last supports 
only get and set.

One obvious API would be a keyword to disambiguate between the first two 
cases:

matrix[3, 4]   # unambiguously a cell reference
matrix[3]  # ambiguous, forbidden
matrix[3, axis='row']  # unambiguously a row
matrix[3, axis='col']  # unambiguously a column

These could be supported for all of get, set and delete (except for 
cells) operations. A quick sketch of the implementation with minimal 
error checking for brevity:


def __setitem__(self, index, value, *, axis=None):
if isinstance(index, tuple):
# Operate on a cell.
if axis is not None:
raise TypeError('cell ops don't take axis keyword')
i, j = index
... # bind a single cell

elif isinstance(index, int):
if axis == 'row':
... # bind the row
elif axis == 'col':
... # bind the column
else:
raise ValueError('bad axis')

else:
raise TypeError


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CGMHA4LIE6EIFJWLQ5SEMLQWPKRCIY2V/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[David Mertz]

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:10) block the value [[157.48, 78.7402], [39.3701,
> 118.11]]? Is that right?
>

Yes, that's exactly the hypothetical library/class I imagined. A keyword
changing an "aspect" or "interpretation" of the data rather than the the
memory location where bits are stored.

The reason I'd want this is because, e.g. several HDF5 files I work with
together might have different native units. Rather than globally convert
all 10 billion numbers on first read, and convert them back before writing,
only those values specifically utilized/modified would need conversion.

del internally_inches[4:6, 8:10, unit="meters"] and
> del internally_inches[4:6, 8:10, unit="inches"]
>

Again, this is hypothetical. But my way of thinking is that for this code,
unit is ignored. But it shows consistency with the same unit being used
everywhere else in the same program.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WKGT4F7TWAY6MXP5DP75EEKBFCLXSMDA/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

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 have keyword args
doesn't mean you HAVE to have keyword args. It would make good sense
to have an API that involves units for set and get, but ignores them
for delete.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SGWGVVL467IQMYUY6IBBQWKAWXIY3B6W/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Sebastian Kreft]

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 of suggestions have
>>> floated by, and I don't care which one is used, but something to
>>> demonstrate that within the PEP.
>>>
>> I agree, that use case should ideally be one that could have get, set and
>> delete semantics. As most of the examples provided seem to only be meant
>> for accessing the data.
>>
>
> Both the units and source examples I gave would be very natural with set
> and del semantics; enough that I just assumed those were understood.
> Probably units moreso.
>
> internally_inches[4:6, 8:10, unit="meters"] = [[4, 2], [1, 3]]  # Stores
> [[157.48, ...], [..., ...]] in block
>

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:10) block the value [[157.48, 78.7402], [39.3701,
118.11]]? Is that right?

When I originally read these examples, I thought the unit modifier would
change the block location. It feels weird to me to have the unit
disassociated from the actual value being stored.

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"]



> internally_cm[4:6, 8:10, unit="metres"] = [[4, 2], [1, 3]]   # apparently
> allow two spellings
>
> del internally_inches[1, unit="furlong"]   # Delete one row, unit ignored
>

>
-- 
> The dead increasingly dominate and strangle both the living and the
> not-yet born.  Vampiric capital and undead corporate persons abuse
> the lives and control the thoughts of homo faber. Ideas, once born,
> become abortifacients against new conceptions.
>


-- 
Sebastian Kreft
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OEXEE5H2OO5QSP3VQWZANVZFILR2RLKT/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[David Mertz]

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 is used, but something to demonstrate that
>> within the PEP.
>>
> I agree, that use case should ideally be one that could have get, set and
> delete semantics. As most of the examples provided seem to only be meant
> for accessing the data.
>

Both the units and source examples I gave would be very natural with set
and del semantics; enough that I just assumed those were understood.
Probably units moreso.

internally_inches[4:6, 8:10, unit="meters"] = [[4, 2], [1, 3]]  # Stores
[[157.48, ...], [..., ...]] in block
internally_cm[4:6, 8:10, unit="metres"] = [[4, 2], [1, 3]]   # apparently
allow two spellings

del internally_inches[1, unit="furlong"]   # Delete one row, unit ignored


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CISMW4YE4OOGLTDYBG5QWDMBFGFGD3RH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Sebastian Kreft]

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.
>
I agree, that use case should ideally be one that could have get, set and
delete semantics. As most of the examples provided seem to only be meant
for accessing the data.


>
> On Tue, Sep 29, 2020 at 11:43 AM Guido van Rossum 
> wrote:
>
>>  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/~guido)
>> *Pronouns: he/him **(why is my pronoun here?)*
>> 
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/7KTEXJX5BCXQTJDFIN4N3VIFF4OY3WYO/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> The dead increasingly dominate and strangle both the living and the
> not-yet born.  Vampiric capital and undead corporate persons abuse
> the lives and control the thoughts of homo faber. Ideas, once born,
> become abortifacients against new conceptions.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/2FDXU6H2VNYBKBEN3DCRADY2DFBEBZG7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Sebastian Kreft
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5CA2X4BSRVEHUXEDJ4AYYW7F7TNOWPCB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[David Mertz]

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:

>  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/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/7KTEXJX5BCXQTJDFIN4N3VIFF4OY3WYO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2FDXU6H2VNYBKBEN3DCRADY2DFBEBZG7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

 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/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7KTEXJX5BCXQTJDFIN4N3VIFF4OY3WYO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[henryfs]

> 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; but we could have ax0, etc, for example. See the SciPy 2020 or 
PyHEP 2020 talks for more examples. Hist extends boost-histogram and adds named 
axes, where this would be _very_ useful.  Now you could make a histogram:

```pyhton
h = Hist(axis.Regular(10,-1,1, name="x"), axis.Boolean(name="signal"))
h_signal= h[x=2:8, signal=True]
```
(of course, you could actually have a lot of axes, and you don't need to slice 
all of them every time)

I realize now on further reading the PEP does discuss the idea, though I only 
agree with one of the arguments; the slow part might be solvable, the 
complexity issue is reversed (adding a new one-off rule ontop of the _already_ 
one-off rule for tuplizing arguments is more complex, IMO, than reusing 
function syntax), the transition/mix could be done, the one where "*args" would 
be needed to represent a tuple of arguments makes no sense to me (of course 
that's how you should write a Python signature for a variable number of args, 
that's not a downside). It would be reasonably easy to write a conversion 
to/from `__getitem_func__`, and the end result would be a cleaner, nicer 
language (in 10ish years?). There have been similar transitions in the past.

Furthermore, you currently can't tell the difference between `x[(a, b)]` and 
`x[a, b]`; with the new function, libraries could differentiate, and maybe 
eventually make them behave reasonably (you can always use x[*c] if you already 
have a tuple, just like for a function, and it's one of the rare / only places 
where list vs. tuple matters in Python).

Just some thoughts, still excited to see this become available in some form. :)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QWJKM7FIS4K4KKPBXT3T7TT2ILV4LUUX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Serhiy Storchaka]

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 to 
> include those libraries in stdlib.

That method was very popular for compressing data at that time (and I
think it is still popular). It was supported by the tar utility, was
included in the zip file specification, was used for distributing source
archives and was used for compressing packages in Linux distributives.
It made bzip2 mostly obsolete.

In Python it was needed for distutils.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/S2JUX7KH2JXC42R37RPBSV75LWAZWKS2/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eric V. Smith]

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 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 exactly what this idea is all about.

My question is why? Was there an objection for implementing such a
thing, or was it complex enough to postpone for the time being?


I think this is fine. The "abstract-ness" of a class is not supposed 
to change throughout its lifetime. The problem arises when decorators 
change the class before it's ever used, as that should still be 
considered its "initialization" as far as the user is concerned, so 
its "abstract-ness" should change accordingly.
I agree with Guido in that the cleanest solution is to change the 
decorators. Perhaps a module function to recalculate a class's 
__abstractmethods __, that mixin decorators can call prior to 
returning the class. I can't really think of standard library class 
decorators that would use this global function other than `dataclass` 
and `total_ordering`, but in this way, 3rd party decorators can easily 
support implementing abstract functions.
The one downside to this solution is that it can easily be abused by 
calling it in the middle of a class's lifetime.


I think I'd like to see dataclasses handle this directly, so as to keep 
it easy to use. But I can be argued with: it's not like a beginner would 
stumble over this issue.


Eric

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EQQVNE4IVG5ZLWZHY3HCIATUY32PHWJG/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Christopher Barker]

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
> delete measurements. Is that correct?
>

yes. working with this gridded data is pretty much a one-way street. If you
want to change the values, you really need to work with the underlying
arrays.

Though now you mention it, I may think about that some more -- maybe
there's something that could be done there? I haven't thought about it
because I (nor any of my users) don't have a use case for that.

-CHB










>
>
>>
>> and that would require having mixed positional and keyword index
>> parameters.
>>
>> -CHB
>>
>> On Sun, Sep 27, 2020 at 6:48 PM Stephan Hoyer  wrote:
>>
>>> On Sat, Sep 26, 2020 at 8:40 PM Steven D'Aprano 
>>> wrote:
>>>
 On Sat, Sep 26, 2020 at 01:47:56PM -0300, Sebastian Kreft wrote:

 > In this fashion have you considering having keyword only indices,
 that is
 > to only allow either obj[1, 2] or obj[row=1, col=2] (if the class
 supports
 > it), and disallow mixing positional and keyword indices, meaning
 obj[1,
 > col=2] would be a SyntaxError.

 That would severely reduce the usefulness of this feature for me,
 probably by 80 or 90%, and possibly make it useless for xarray and
 pandas.

 (I don't speak for the pandas or xarray devs, I'm happy to be
 corrected.)
>>>
>>>
>>> From my perspective as a developer for both xarray and pandas, both
>>> "mixed" and "keyword only" indexing have use cases, but I would guess
>>> keyword only indexing is more important.
>>>
>>> In xarray, we currently have methods that awkwardly approximate keyword
>>> only indexing (e.g., xarray.DataArray.sel() and xarray.DataArray.isel()
>>> both allow for named dimensions with **kwargs), but nothing for the "mixed"
>>> case (neither method supports positional *args).
>>> ___
>>> Python-ideas mailing list -- python-ideas@python.org
>>> To unsubscribe send an email to python-ideas-le...@python.org
>>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>>> Message archived at
>>> https://mail.python.org/archives/list/python-ideas@python.org/message/IPEP5YXUQKCNCARJH4NKF7I757M7XLCA/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>>
>> --
>> Christopher Barker, PhD
>>
>> Python Language Consulting
>>   - Teaching
>>   - Scientific Software Development
>>   - Desktop GUI and Web Development
>>   - wxPython, numpy, scipy, Cython
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/UBQS7YPOS3KD4PBPTWOBTKXOS6QSEAM7/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> Sebastian Kreft
>


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LHZYX2KQF4M4RKZTR2PEBCG2TZXQV35I/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Christopher Barker]

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, but even if there are good
use-cases, a new method won't be included unless there is someone agreeing
to implement and maintain it.

That is: a maintainer is a necessary but not sufficient criteria for
inclusion.

-CHB

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZJ7XTAZA2LH4L4B2MYYYUFQE7KSRFHAV/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Sebastian Kreft]

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 (in this case generally Oceanographic model output)
> -- they can be rectangular grids, curvilinear, unstructured triangular,
>   The point of the library is to save the user from having to
> understand how all those grids work  and, rather, be able to work with the
> data as if it were a continuous field. For example, if I want to know the
> sea surface temperature at a given location, I need to figure out what cell
> that location is in, what the values are at the corners of that cell, and
> then interpolate over the cell.
>
> After abstracting that, one can create a gridded.Variable object, and
> then do:
>
> sea_surface_temp.at(-78.123, 28.432)
>
> and get the value at those coordinates.
>
> So it would be pretty nifty to do:
>
> sea_surface_temp[-78.123, 28.432], which of course I could do with Python
> as it is.
>
> 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
delete measurements. Is that correct?



>
> and that would require having mixed positional and keyword index
> parameters.
>
> -CHB
>
> On Sun, Sep 27, 2020 at 6:48 PM Stephan Hoyer  wrote:
>
>> On Sat, Sep 26, 2020 at 8:40 PM Steven D'Aprano 
>> wrote:
>>
>>> On Sat, Sep 26, 2020 at 01:47:56PM -0300, Sebastian Kreft wrote:
>>>
>>> > In this fashion have you considering having keyword only indices, that
>>> is
>>> > to only allow either obj[1, 2] or obj[row=1, col=2] (if the class
>>> supports
>>> > it), and disallow mixing positional and keyword indices, meaning obj[1,
>>> > col=2] would be a SyntaxError.
>>>
>>> That would severely reduce the usefulness of this feature for me,
>>> probably by 80 or 90%, and possibly make it useless for xarray and
>>> pandas.
>>>
>>> (I don't speak for the pandas or xarray devs, I'm happy to be
>>> corrected.)
>>
>>
>> From my perspective as a developer for both xarray and pandas, both
>> "mixed" and "keyword only" indexing have use cases, but I would guess
>> keyword only indexing is more important.
>>
>> In xarray, we currently have methods that awkwardly approximate keyword
>> only indexing (e.g., xarray.DataArray.sel() and xarray.DataArray.isel()
>> both allow for named dimensions with **kwargs), but nothing for the "mixed"
>> case (neither method supports positional *args).
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/IPEP5YXUQKCNCARJH4NKF7I757M7XLCA/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> Christopher Barker, PhD
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/UBQS7YPOS3KD4PBPTWOBTKXOS6QSEAM7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Sebastian Kreft
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IB5P32UZVK2CIHBYLFPM33LAHIYJOSV6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ben Avrahami]

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 notice exists both in the pep and at the abc module's docs, and is
> exactly what this idea is all about.
>
> My question is why? Was there an objection for implementing such a thing,
> or was it complex enough to postpone for the time being?
>

I think this is fine. The "abstract-ness" of a class is not supposed to
change throughout its lifetime. The problem arises when decorators change
the class before it's ever used, as that should still be considered its
"initialization" as far as the user is concerned, so its "abstract-ness"
should change accordingly.
I agree with Guido in that the cleanest solution is to change the
decorators. Perhaps a module function to recalculate a class's
__abstractmethods __, that mixin decorators can call prior to returning the
class. I can't really think of standard library class decorators that would
use this global function other than `dataclass` and `total_ordering`, but
in this way, 3rd party decorators can easily support implementing abstract
functions.
The one downside to this solution is that it can easily be abused by
calling it in the middle of a class's lifetime.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AFGUJ4B3WMIOR4BTSY5TI5M5EZTVVRYM/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Bar Harel]

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
exactly what this idea is all about.

My question is why? Was there an objection for implementing such a thing,
or was it complex enough to postpone for the time being?

On Tue, Sep 29, 2020 at 2:51 PM Bar Harel  wrote:

> 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 defined
> dynamically. Plus it'll support dynamic __getattr__ on a child metaclass as
> an added bonus.
>
> Bar Harel.
>
> On Thu, Sep 24, 2020, 7:28 PM Ben Avrahami  wrote:
>
>>
>>
>> On Thu, Sep 24, 2020 at 7:02 PM Eric V. Smith  wrote:
>>
>>> Does anyone know if attrs handles this? I don't have a recent version
>>> installed, but I'll take a look later today.
>>>
>>
>> attrs handles this only if you set slots=True (which makes sense since
>> attrs would have to rebuild the class)
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/KLMQ7HDYED32XGJAUCDHCVDDJJ2BX63V/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WN5STOTCEIGX3IS2JPKUKGNPTJ65JY65/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eric V. Smith]

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 the implementation is sufficiently stable, I see no reason not to 
include those libraries in stdlib.


I can't say this is the only reason, but back when distributing and 
installing packages was more difficult, we had a lower bar for stdlib 
inclusion.


Eric
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TP2CHYHV2WHHHPZMC3FP4WYY3D7HLFI4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Omer Katz]

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, I see no reason not to 
include those libraries in stdlib.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/54X74NOPYWOE3LGGHUDK562DZ4PS3FTP/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Bar Harel]

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 defined
dynamically. Plus it'll support dynamic __getattr__ on a child metaclass as
an added bonus.

Bar Harel.

On Thu, Sep 24, 2020, 7:28 PM Ben Avrahami  wrote:

>
>
> On Thu, Sep 24, 2020 at 7:02 PM Eric V. Smith  wrote:
>
>> Does anyone know if attrs handles this? I don't have a recent version
>> installed, but I'll take a look later today.
>>
>
> attrs handles this only if you set slots=True (which makes sense since
> attrs would have to rebuild the class)
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/KLMQ7HDYED32XGJAUCDHCVDDJJ2BX63V/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YSUFVTM7RIZV3JCI7GH6HB5GGQIDZ7AY/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Soni L.]

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 if it also takes arbitrary objects:

pattern = [None, True, False, "?"]
input = [None, True] # matches
input = [None, False] # doesn't match
input = [None, True, False] #matches

On 2020-09-28 8:10 p.m., Giang Le wrote:
> Hi Everyone,
>
> I would like to propose an idea for the regular expression module 
> re.search(Pattern, Input) to support List[str] input type.
> So it will return a matched object list if the input is a string list. 
> Otherwise, it will return a normal matched object, if the input is a normal 
> string
>
> Best Regards
> Giang
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/4LOOP2FDK7JQ7XU3Z4Y7JNLOOW5FQOHH/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QI2QWN7PO7D5JXQ4VPITDTUWCX7SIVZ2/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stefan Behnel]

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 are C extension types going to implement this?

Will there be two new slot methods for them? Something like (but better
named than) "mp_subscript_kw()" and "mp_ass_subscript_kw()"?

Would the extension types signal their availability with a new "TP_*" class
feature flag?

Are the slot methods going to use the vectorcall calling convention, i.e.
pass the keyword names as a tuple, or should they accept (and thus, require
the overhead of) a Python dict as argument?

This design must clearly be part of the PEP. What's the current status of
the discussion there?

Stefan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GIHORXWACHNHF3G4CQBAW3DEO3EMY7SK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Oleg Broytman]

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, you can do it yourself.

On Tue, Sep 29, 2020 at 06:19:29AM -, Giang Le  
wrote:
> Hi, I would like to have the same function re.search(pattern, input) to keep 
> main code structure to be the same. The input into the re.search function 
> will be depended on other previous functions. It is also more dynamic for 
> users. Thank you.

Oleg.
-- 
Oleg Broytmanhttps://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2ZO7GNTT567EQC3DQD6MEVI62WYMK6X2/
Code of Conduct: http://python.org/psf/codeofconduct/