date:20200825

On Tue, Aug 25, 2020 at 9:50 PM Steven D'Aprano  wrote:

> On Mon, Aug 24, 2020 at 01:10:26PM -0400, Ricky Teachey wrote:

> SIGNATURE === SEMANTICS
> > (self, a, b) === (self, key_tuple, value)
> >
> > In the above, a on the left side, semantically, is the key tuple, and b
> in
> > the value on the RHS.
>
> That's not how Python works today. Individual values aren't packed into
> a tuple.
>

Sorry when I wrote that my intention was that `a` would be a tuple. But
you're right, a better version would be to say:

SIGNATURE === SEMANTICS
(self, a, b) === (self, key_tuple_or_atomic_key_value, value)



> I think that the best (correct?) way of interpreting the subscript
> behaviour is that the subscript pseudo-operator `[...]` has a lower
> precedence than the comma pseudo-operator. So when the parser sees the
> subscript square brackets:
>
> obj[   ]
>
> it parses the contents of those brackets as an expression. What do
> commas do inside expressions? They make tuples. So "positional
> arguments" to a subscript are naturally bundled together into a tuple.
> It's not that the interpreter has a special rule for this, it's just a
> way the precedence works out.
>

Makes sense to me.



> The only way it could tell that would be to inspect *at runtime* the
> `__setitem__` method. And it would have to do this on every subscript
> call. Introspection is likely to be slow, possibly very slow. This would
> make subscripting slow.
>

Well it would not have to inspect the signature on every subscript call,
but it would have to call a wrapped function like this on every call

:

def _adapt_get(func):
@wraps(func)
def wrapped(self, key):
return func(self, *key)
return wrapped

So you're right, it would result in the need to make a second function call *if
and only if* the writer of the class chose to write their function with
more than the "normal" number of arguments.

In the case the only one argument is in the signature of __getitem__ and
__delitem__, and two in __setitem__, and all with no default values, it
would not need to be wrapped and everything remains exactly as it does today

:

def _adapt_item_dunders(cls):
for m_name, adapter, n_params in zip(("getitem", "setitem", "delitem"),
 (_adapt_get, _adapt_set,
_adapt_del),
 (2, 3, 2),
 ):
m_dunder = f"__{m_name}__"
if method := getattr(cls, m_dunder, None):
if all(p.default==_empty for p in
signature(method).parameters.values()) \
and len(signature(method).parameters)==n_params:
return
setattr(cls, m_dunder, adapter(method))


> And it would break backwards compatibility. Right now, it is legal for
> subscript methods to be written like this:
>
> def __setitem__(self, item, value, extra=something)
>
> and there is no way for subscripting to call the method with that extra
> argument provided. Only if the user intentionally calls the dunder
> method themselves can they provide that extra argument.
>
> Not only is that legal, but it's also useful. E.g. the class might call
> the dunder directly, and provide non-default extra arguments, or it
> might use parameters as static storage (see the random module for
> examples of methods that do that).
>
> But your proposal will break that code.
>
> Right now, I could even define my dunder method like this:
>
> def __setitem__(*args)
>
> and it will Just Work because there is nothing special at all about
> parameter passing, even self is handled as a standard argument. Your
> proposal will break that...
>

I'll respond to this at the end.


> So, we have a proposal for a change that nobody has requested, that adds
> no useful functionality and fixes no problems, that is backwards
> incompatible and will slow down every single subscripting operation.
> What's not to like about it? :-)
>
>
People have actually been asking for ways to make subscripting operator act
more like a function call, so that's not true. And it could be useful. And
it does help address the problem of incongruity (though not perfectly)
between the way a function call handles args and kwargs, and the way the
subscript operator does it. And it is totally backwards compatible except
for the case of what I'd call skirting very clear convention (more on that
below). And it does not slow down any subscripting operation unless the
class author chooses to use it.


> Maybe we wouldn't have designed subscripting this way back in Python 1
> if we know what we know now, but it works well enough, and we have heard
> from numpy developers like Stephan Hoyer that this is not a problem that
> needs fixing. Can we please stop trying to "fix" positional subscripts?
>

I'm not done trying,

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Wed, Aug 26, 2020 at 11:31:25AM +1200, Greg Ewing wrote:

> I think an argument can be made that the new dunder -- let's call
> it __getindex__ for now -- shouldn't be considered part of the
> mapping protocol. It's a new thing for classes that want to use the
> indexing notation in ways that don't fit the simple idea of mapping a
> key object to a value object.

Most existing uses of subscripts already don't fit that key:value 
mapping idea, starting with lists and tuples.

Given `obj[spam]`, how does the interpreter know whether to call 
`__getitem__` or `__getindex__`?

What if the class defines both?

> The only drawback I can think of right now is that it would make
> possible objects for which x[1, 2] and x[(1, 2)] were not equivalent.

Right now, both sets of syntax mean the same thing and call the same 
method, so you are introducing a backwards incompatible change that will 
break code. Can we postpone this proposal for Python 6000 in 2050?

-- 
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/5BK6FJZY54QENLZ5N6VQEJM62UTURAWQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Mon, Aug 24, 2020 at 01:10:26PM -0400, Ricky Teachey wrote:

> SIGNATURE === SEMANTICS
> (self, a, b) === (self, key_tuple, value)
> 
> In the above, a on the left side, semantically, is the key tuple, and b in
> the value on the RHS.

That's not how Python works today. Individual values aren't packed into 
a tuple.

mylist[5] = "value"

calls `__setitem__(5, "value")`. The argument here is the int 5, not the 
tuple (5,).

Presumably you wouldn't say that the semantics are:

__setitem__(self, key_tuple, value_tuple)

just because we have this:

obj[1] = spam, eggs, cheese

I think that the best (correct?) way of interpreting the subscript 
behaviour is that the subscript pseudo-operator `[...]` has a lower 
precedence than the comma pseudo-operator. So when the parser sees the 
subscript square brackets:

obj[   ]

it parses the contents of those brackets as an expression. What do 
commas do inside expressions? They make tuples. So "positional 
arguments" to a subscript are naturally bundled together into a tuple. 
It's not that the interpreter has a special rule for this, it's just a 
way the precedence works out.

(I welcome correction if that is wrong.)

In the same way that assignment has lower precedence than comma, so the 
parser automatically bundles the `spam, eggs, cheese` into a single 
value which just happens to be a tuple before doing the assignment.

[...]
> Signature dependent semantics, as the name suggests, would change the
> semantic meaning of the __setitem__ signature in the case that more than
> two parameters are given in the signature.
> 
> In other words, if a signature is provided like this, with 3 or more
> arguments:
> 
> def: __setitem__(self, a, b, c): ...
> 
> ...then in that case, the language would know there is a different semantic
> meaning intended.

The only way it could tell that would be to inspect *at runtime* the 
`__setitem__` method. And it would have to do this on every subscript 
call. Introspection is likely to be slow, possibly very slow. This would 
make subscripting slow.

And it would break backwards compatibility. Right now, it is legal for 
subscript methods to be written like this:

def __setitem__(self, item, value, extra=something)

and there is no way for subscripting to call the method with that extra 
argument provided. Only if the user intentionally calls the dunder 
method themselves can they provide that extra argument.

Not only is that legal, but it's also useful. E.g. the class might call 
the dunder directly, and provide non-default extra arguments, or it 
might use parameters as static storage (see the random module for 
examples of methods that do that).

But your proposal will break that code.

Right now, I could even define my dunder method like this:

def __setitem__(*args)

and it will Just Work because there is nothing special at all about 
parameter passing, even self is handled as a standard argument. Your 
proposal will break that:

obj[1, 2, 3] = None

# current semantics will pass in
# args = (obj, (1, 2, 3), None)

# your semantics will presumably pass in
# args = (obj, 1, 2, 3, None)

So, we have a proposal for a change that nobody has requested, that adds 
no useful functionality and fixes no problems, that is backwards 
incompatible and will slow down every single subscripting operation. 
What's not to like about it? :-)

Maybe we wouldn't have designed subscripting this way back in Python 1 
if we know what we know now, but it works well enough, and we have heard 
from numpy developers like Stephan Hoyer that this is not a problem that 
needs fixing. Can we please stop trying to "fix" positional subscripts?

Adding keywords to subscripts is a genuinely useful new feature that I 
personally am really hoping I can use in the future, and it is really 
frustrating to see the PEP being derailed time and time again.

-- 
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/VGZ57HTDRB7A72OHDLXUSIWNDNPPM26N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

2020-08-25 Thread Todd

On Tue, Aug 25, 2020 at 10:58 AM David Mertz  wrote:

> On Tue, Aug 25, 2020 at 2:26 AM Christopher Barker 
> wrote:
>
>> As for "why not" not being a motivator -- I agree, I posted it that easy
>> because this conversation has brought up a number of examples where slice
>> syntax is nice to use. And David Mertz pointed out, both numpy and pandas
>> have a utility to make easier slices -- yes, that's an argument for why you
>> don't need them, but it's also an argument for why there IS a need for
>> slice objects outside of the square brackets, and if we need slice objects,
>> then slice syntax is nice.
>>
>
> Pandas is kinda special though.  It semi-abuses Python syntax in quite a
> few places.  For example, here is an example from the Pandas docs:
>
> >>> idx = pd.IndexSlice>>> dfmi.loc[idx[:, 'B0':'B1'], :]
>
> There is a hierarchical index (MultiIndex) where we want to put slices as
> some of the "dimensions" of slice items.  It definitely makes sense in the
> Pandas world, but I have never once encountered anywhere I would want
> "stand-alone" slice objects outside of Pandas.  I know NumPy includes the
> same convenience, but it's not even coming to me immediately in what
> context you would want that in NumPy.
>

I had to do it in a situation where I needed slices but couldn't tell ahead
of time how many dimensions would be sliced.  So I had to construct a
dynamically-sized tuple of slices on-the-fly.  I doubt this is not a common
situation, though.
___
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/EGEOV6YLGH7IWEWQDFLXPDF3UPQ3UEGS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

2020-08-25 Thread Todd

On Tue, Aug 25, 2020 at 4:41 PM Stefano Borini 
wrote:

> On Sat, 8 Aug 2020 at 02:34, Stephan Hoyer  wrote:
>
> > I'm sorry, I did a poor job of editing this.
> >
> > To fill in my missing word: From my perspective, the *only* reasonable
> way to add keyword arguments to indexing would be in a completely backwards
> compatible way with **kwargs.
>
> Let me clarify that I don't like the kwargs solution to the current
> getitem, and the reason is simple.
>
> The original motivation for PEP-472 was to do axis naming, that is, to
> be sure you would be able to clearly indicate (if you so wished)
> data[23, 2] explicitly as e.g. data[day=23, detector=2] or
> data[detector=2, day=23]
>

But that assumes that all keyword axes can be mapped to positional axes.
This is not the case in xarray, there are axes that are keyword-only.  And
it precludes other uses-cases that have been mentioned, such as parameters
for indexing.  So I understand that this was the original motivation, I
don't think it is good to restrict to it only this use-case when there are
other valid use-cases.

> If you have **kwargs, now the first case would send the two values to
> the nameless index, the second case to the kwargs, and inside the
> getitem you would have to reconcile the two, especially if someone
> then writes data[24, 5, day=23, detector=2]
> typing of course has the same issue. What this extended syntax is
> supposed to be used for is to define specialisation of generics. but
> it's difficult to now handle the cases List[Int] vs List[T=Int] vs
> List[Int, T=int], which are really telling the same thing the first
> two, and something wrong (TypeError multiple arguments) the second.
>

That is a problem that anyone using **kwargs in functions has to deal
with.  It is neither a new problem nor a unique one, and there are plenty
of ways to deal with it.
___
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/52U3F6TRZISVEMVQQ53EI7RBH5YYNUCW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Fri, Aug 07, 2020 at 06:31:02PM -0700, Stephan Hoyer wrote:

> To fill in my missing word: From my perspective, the *only* reasonable way
> to add keyword arguments to indexing would be in a completely backwards
> compatible way with **kwargs.

Do you have a reason for this assertion?

I see no reason why `**kwargs` will be backwards compatible but 
multiple, individually named parameters won't be.


-- 
Steven
___
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/PFUKE7KBLFKWR2JMXA7NVXUETX3CMMD6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Tue, Aug 25, 2020, 7:35 PM Greg Ewing 
wrote:

> On 26/08/20 10:03 am, Stefano Borini wrote:
> > But you have a point that whatever the implementation might be, it has
> > to play nice with the current dict() behavior. Yet, if we were to add
> > an enhanced dunder, nothing for the current dict would change.
>
> Despite arguing against it earlier, I think I'm starting to shift
> towards being in favour of a new dunder. But only if it can be
> justified as existing in its own right alongside __getitem__,
> without any intention to deprecate or remove the latter.
>
> ...
>
> The only drawback I can think of right now is that it would make
> possible objects for which x[1, 2] and x[(1, 2)] were not equivalent.
> I don't think that's a serious problem. A class would always be able to
> arrange for its __getindex__ method to *make* them equivalent, and
> things like pandas would be encouraged to do so. For things like generic
> types, which use the index notation for something that isn't really
> indexing at all, it probably doesn't matter much.
>
> --
> Greg
>

To be backwards compatible, any proposed change has to pass this test:

"""Test #1"""

class D:
def __getitem__(self, key):
return key

d = D()

# note the commas
assert d[1,] == f((1,))

Where f is some function that mimicks how python "translates" the "stuff"
inside the square brackets. It is something like this, not quite:

def f(*args):
if not args:
# empty brackets not allowed
raise SyntaxError()
if len(args) ==1:
return args[0]
return args

The desire of many (me included) seems to be to make it possible for the
subscript operator to utilize syntax very similar, or identical, to the
behavior of a function call.

In other words, to make it possible to write some class, Q, that allows the
following tests to pass:

#
"""Test #2"""

# note the commas
assert q[1,] == f(1,)
assert q[1] == f(1)
assert q[(1,)] == f((1,))
##

The problem is, I don't think it is possible to change python internals in
a backwards compatible way so that we can write a function that passes all
of these tests. Because the index operator recognizes this as a tuple:

1,

But function calls do not. This is an impasse.

Does this constitute a big problem for the idea of providing new dunders?
I'm not sure.
___
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/GZPUUEUONQVYRR3QD5ACR62VG3BXYSAJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Tue, Aug 25, 2020 at 09:23:18PM +0100, Stefano Borini wrote:
> There's another option (but I am not endorsing it):
> 
> a[1:2, 2, j=4:7, k=3] means:
> 
> a.__getitem__((slice(1, 2, None), 2, named("j", slice(4, 7, None)),
> named("k", 3)}))

This is not another option, it's just a variant on Jonathan Fine's "key 
object" idea with a new name.

> Where named is an object kind like slice, and it evaluates to the pure
> value, but also has a .name like slice() has .start.

This is contradictory, and not possible in Python without a lot of work, 
if at all. You want `named("k", 3)` to evaluate to 3, but 3 has no `.name` 
attribute. So you can only have one: either `named("k", 3)` evaluates to 
a special key object with a .name attribute "k", or it evaluates to 3. 
Pick one.

-- 
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/MAPVURJI75EFQWEXMALLBKHUBGMQUP7Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

2020-08-25 Thread Greg Ewing


As a point of interest, is get() considered an official part of the
mapping protocol, or just nice-to-have?

The docs don't seem to be very clear about that. There used to be
some tables listing the methods making up the core sequence and
mapping protocols, but I can't find them now. Have they been removed?
Are the ABCs now the definitions of the protocols?

--
Greg
___
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/SLF3VOX2CQYKGXNE4WS5IK2DLBI2O7BQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Tue, Aug 25, 2020 at 10:22:20AM -0700, Christopher Barker wrote:

> This one is easier than most because it's pretty much a do we or don't we
> question, with the spelling semantics, all pretty much already decided.

Is it to be added to lists, or lists and tuples? How about range 
objects?

range(1, 9, 2).get(100)

Strings and bytes?

"abc".get(100)


Do we require 3rd party sequences to add this as well, in order to 
continue being called sequences?


> Though I haven't quite seen it said explicitly -- is this proposed to be
> added to the Sequence ABC?

If so, do we require that it return None as the default, or are types 
permitted to return whatever missing value they see fit?


-- 
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/FQ66KFBVJUJGBJ6UWHAE5GF4I7EP63UU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

2020-08-25 Thread Greg Ewing

On 26/08/20 10:03 am, Stefano Borini wrote:

But you have a point that whatever the implementation might be, it has
to play nice with the current dict() behavior. Yet, if we were to add
an enhanced dunder, nothing for the current dict would change.

Despite arguing against it earlier, I think I'm starting to shift
towards being in favour of a new dunder. But only if it can be
justified as existing in its own right alongside __getitem__,
without any intention to deprecate or remove the latter.

I think an argument can be made that the new dunder -- let's call
it __getindex__ for now -- shouldn't be considered part of the
mapping protocol. It's a new thing for classes that want to use the
indexing notation in ways that don't fit the simple idea of mapping a
key object to a value object.

The only drawback I can think of right now is that it would make
possible objects for which x[1, 2] and x[(1, 2)] were not equivalent.
I don't think that's a serious problem. A class would always be able to
arrange for its __getindex__ method to *make* them equivalent, and
things like pandas would be encouraged to do so. For things like generic
types, which use the index notation for something that isn't really
indexing at all, it probably doesn't matter much.

--
Greg
___
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/NIJAZKTHPBP6Q3462V3DBUWDTQ5NU7QU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Tue, Aug 25, 2020 at 10:51 AM Alex Hall  wrote:

> On Tue, Aug 25, 2020 at 7:23 PM Christopher Barker
>

I think if it's a potential problem to add it to the ABC then let's just
> defer that and only add it to the built in sequences.
>

Well yes, that’s a fine solution. Though an advantage of adding it into the
ABC is that it could be a mixin, and all Sequences would them get it.

But I'm not clear on what the problem is. If you have some code like this:
>
> ```
> class MySequence(Sequence):
> def get(self, i): ...
>
> MySequence().get(3)
> ```
>
> and then add .get to the Sequence ABC, the existing code will not be
> immediately broken because the custom MySequence.get overrides the ABC
> method so everything behaves as before.
>

Yes, but then the third party object that was a Sequence may no longer be
one.

Maybe if we build up enough methods to add to the collection ABCs
> (Sequence.view, Sequence.get, Set.intersection/union/etc,
> Mapping.__[i]or__) we can justify adding them all at once in Python 4
>

Careful now! No one wants to repeat the py2/3 transition!

or in a new module collections.abc.v2 which has subclasses of the originals.
>

Maybe, but the trick is: how do you “build up” thus stuff before you have a
place to put it? And what’s the point of a place to put new stuff, when
there isn’t any new stuff?

-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/R3RIGL247UNOMSQ3RYJGAK32MOIDX5CO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Tue, 25 Aug 2020 at 22:42, Ricky Teachey  wrote:
> Actually I think this *may not* be true. Consider, if we were starting at 
> zero ,and we agreed we wanted dict literal behavior to work like the 
> following:
>
> >>> idx1 = 1,2,3
> >>> idx2 = 1,2
> >>> idx3 = 1
> >>> d = {idx1: "foo", idx2: "bar", idx2: "baz"}
>
> This is what we have today, and I think most agree this is all a Good Thing.
>
> Then, we might reason, if I want to be able to do a lookup using tuple 
> literals, I'd do this, just as we do today:
>
> >>> d[1,2,3]
> 'foo'
> >>> d[1,2]
> 'bar'
> >>> d[1]
> 'baz'
>
> No tuple brackets required.
>
> I think it is REALLY NICE not to have to do THIS, which is what we'd have to 
> do if things behaved the function-call-way inside square brackets:
>
> >>> d[(1,2,3)]
> 'foo'
> >>> d[(1,2)]
> 'bar'
> >>> d[1]
> 'baz'
>
> Of course all of these DO work today-- it just isn't required to use the 
> tuple brackets. They're optional.
>
> Could it be that the convenience of not needing to give the tuple brackets, 
> if we were starting at zero, might win out over the function-call syntax even 
> today? I don't know. I wonder.

If we were to start from scratch, dict.__getitem__ would probably
accept *args, **kwargs, and use them to create the index.
I would also say that very likely it would not accept kwargs at all.

But you have a point that whatever the implementation might be, it has
to play nice with the current dict() behavior. Yet, if we were to add
an enhanced dunder, nothing for the current dict would change. It
would still use the old getitem, and it would still create a tuple
from its (nameless) index group to be used as a key.




-- 
Kind regards,

Stefano Borini
___
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/XR6SFHPVCXE5D4IB77MBDKNT36DHU276/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Tue, Aug 25, 2020 at 4:26 PM Stefano Borini 
wrote:

> In any case, I think that Ricky Teachey might be onto something.
>

Well when it comes to python ideas, that actually might be a first for me.
;)


> Imagine we start from zero. There's no __getitem__. How would you
> envision it to work?
>
> The answer is probably going to be "like a function". that is, if you pass
>
> a[1, 2]
>
> it will receive two arguments as if it were __new_getitem__(self, v1,
> v2), with only a couple of magic stuff for slices and Ellipsis. From
> this, everything would behave rather naturally: a[v1=1, v2=2] would be
> automatic. and so the flipped one a[v2=2, v1=1] would return the same
> value.
>

Actually I think this *may not* be true. Consider, if we were starting at
zero ,and we agreed we wanted dict literal behavior to work like the
following:

>>> idx1 = 1,2,3
>>> idx2 = 1,2
>>> idx3 = 1
>>> d = {idx1: "foo", idx2: "bar", idx2: "baz"}

This is what we have today, and I think most agree this is all a Good Thing.

Then, we might reason, if I want to be able to do a lookup using tuple
literals, I'd do this, just as we do today:

>>> d[1,2,3]
'foo'
>>> d[1,2]
'bar'
>>> d[1]
'baz'

No tuple brackets required.

I think it is REALLY NICE not to have to do THIS, which is what we'd have
to do if things behaved the function-call-way inside square brackets:

>>> d[(1,2,3)]
'foo'
>>> d[(1,2)]
'bar'
>>> d[1]
'baz'

Of course all of these DO work today-- it just isn't required to use the
tuple brackets. They're optional.

Could it be that the convenience of not needing to give the tuple brackets,
if we were starting at zero, might win out over the function-call syntax
even today? I don't know. I wonder.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler




> Now, my question is, would it _really_ be a major issue to introduce
> this __new_getitem__ to be used if available, like we have done
> already in the past for similar enhanced protocols?
> Because to me, this solution seems the most rational, flexible, and
> clear compared to any other option, which in the end are mostly
> workarounds fraught with either manual work or odd syntax. It would
> solve the ambiguity of the API, it would allow for the parser to
> handle the assignment of named arguments to the correct arguments,
> with the only problem of potentially allowing a[] as valid syntax if
> __new_getitem__(self, *args, **kwargs) is used.
>
>
>
>
>
>
>
>
> On Sat, 8 Aug 2020 at 03:49, Steven D'Aprano  wrote:
> >
> > On Fri, Aug 07, 2020 at 12:09:28PM -0400, Ricky Teachey wrote:
> >
> > > I was actually trying to help the kwd arg case here. As illustrated by
> the
> > > quote I included from Greg Ewing, there seems to be not even close to a
> > > consensus over what the semantic meaning of this should be:
> > >
> > > m[1, 2, a=3, b=2]
> >
> > This is Python-Ideas. If we asked for a consensus on what the print
> > function should do, I'm sure we would find at least one person
> > seriously insist that it ought to erase your hard drive *wink*
> >
> > But seriously, getting consensus is difficult, especially when people
> > seem to be unwilling or unable to articulate why they prefer one
> > behaviour over another, or the advantages vs disadvantages of a
> > proposal.
> >
> >
> > > Which could be made to mean one of the following things, or another
> thing I
> > > haven't considered:
> > >
> > > 1.m.__get__((1, 2), a=3, b=4)  # handling of positional arguments
> > > unchanged from current behavior
> >
> >
> > By the way, I assume you meant `__getitem__` in each of your examples,
> > since `__get__` is part of the descriptor protocol.
> >
> >
> > Advantages:
> >
> > (1) Existing positional only subscripting does not change (backwards
> > compatible).
> >
> > (2) Easy to handle keyword arguments.
> >
> > (3) Those who want to bundle all their keywords into a single object can
> > just define a single `**kw` parameter.
> >
> > (4) Probably requires little special handling in the interpreter?
> >
> > (5) Probably requires the minimum amount of implementation effort?
> >
> > (6) Requires no extra effort for developers who don't need or want
> > keyword parameters in their subscript methods. Just do nothing.
> >
> > Disadvantages: none that I can see. (Assuming we agree that this is a
> > useful feature.)
> >
> >
> > > 2.m.__get__(1, 2, a=3, b=4)  # change positional argument handling
> from
> > > current behavior
> >
> > Advantages:
> >
> > 1. Consistency with other methods and functions.
> >
> > Disadvantages:
> >
> > 1. Breaks backwards compatibility.
> >
> > 2. Will require a long and painful transition period during which time
> > libraries will have to somehow support both calling conventions.
> >
> >
> > > 3.m.__get__((1, 2), {'a': 3, 'b': 4})  #  handling of positional
> > > arguments unchanged from current behavior
> >
> > I assume that if there are no keyword arguments given, only

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Sat, 8 Aug 2020 at 02:34, Stephan Hoyer  wrote:

> I'm sorry, I did a poor job of editing this.
>
> To fill in my missing word: From my perspective, the *only* reasonable way to 
> add keyword arguments to indexing would be in a completely backwards 
> compatible way with **kwargs.

Let me clarify that I don't like the kwargs solution to the current
getitem, and the reason is simple.

The original motivation for PEP-472 was to do axis naming, that is, to
be sure you would be able to clearly indicate (if you so wished)
data[23, 2] explicitly as e.g. data[day=23, detector=2] or
data[detector=2, day=23]

If you have **kwargs, now the first case would send the two values to
the nameless index, the second case to the kwargs, and inside the
getitem you would have to reconcile the two, especially if someone
then writes data[24, 5, day=23, detector=2]
typing of course has the same issue. What this extended syntax is
supposed to be used for is to define specialisation of generics. but
it's difficult to now handle the cases List[Int] vs List[T=Int] vs
List[Int, T=int], which are really telling the same thing the first
two, and something wrong (TypeError multiple arguments) the second.

-- 
Kind regards,

Stefano Borini
___
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/FW453Q3PMRP6ECNATRPCSLQNNCROFOG6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

There's another option (but I am not endorsing it):

a[1:2, 2, j=4:7, k=3] means:

a.__getitem__((slice(1, 2, None), 2, named("j", slice(4, 7, None)),
named("k", 3)}))

Where named is an object kind like slice, and it evaluates to the pure
value, but also has a .name like slice() has .start.

In any case, I think that Ricky Teachey might be onto something.

Imagine we start from zero. There's no __getitem__. How would you
envision it to work?

The answer is probably going to be "like a function". that is, if you pass

a[1, 2]

it will receive two arguments as if it were __new_getitem__(self, v1,
v2), with only a couple of magic stuff for slices and Ellipsis. From
this, everything would behave rather naturally: a[v1=1, v2=2] would be
automatic. and so the flipped one a[v2=2, v1=1] would return the same
value.

Now, my question is, would it _really_ be a major issue to introduce
this __new_getitem__ to be used if available, like we have done
already in the past for similar enhanced protocols?
Because to me, this solution seems the most rational, flexible, and
clear compared to any other option, which in the end are mostly
workarounds fraught with either manual work or odd syntax. It would
solve the ambiguity of the API, it would allow for the parser to
handle the assignment of named arguments to the correct arguments,
with the only problem of potentially allowing a[] as valid syntax if
__new_getitem__(self, *args, **kwargs) is used.








On Sat, 8 Aug 2020 at 03:49, Steven D'Aprano  wrote:
>
> On Fri, Aug 07, 2020 at 12:09:28PM -0400, Ricky Teachey wrote:
>
> > I was actually trying to help the kwd arg case here. As illustrated by the
> > quote I included from Greg Ewing, there seems to be not even close to a
> > consensus over what the semantic meaning of this should be:
> >
> > m[1, 2, a=3, b=2]
>
> This is Python-Ideas. If we asked for a consensus on what the print
> function should do, I'm sure we would find at least one person
> seriously insist that it ought to erase your hard drive *wink*
>
> But seriously, getting consensus is difficult, especially when people
> seem to be unwilling or unable to articulate why they prefer one
> behaviour over another, or the advantages vs disadvantages of a
> proposal.
>
>
> > Which could be made to mean one of the following things, or another thing I
> > haven't considered:
> >
> > 1.m.__get__((1, 2), a=3, b=4)  # handling of positional arguments
> > unchanged from current behavior
>
>
> By the way, I assume you meant `__getitem__` in each of your examples,
> since `__get__` is part of the descriptor protocol.
>
>
> Advantages:
>
> (1) Existing positional only subscripting does not change (backwards
> compatible).
>
> (2) Easy to handle keyword arguments.
>
> (3) Those who want to bundle all their keywords into a single object can
> just define a single `**kw` parameter.
>
> (4) Probably requires little special handling in the interpreter?
>
> (5) Probably requires the minimum amount of implementation effort?
>
> (6) Requires no extra effort for developers who don't need or want
> keyword parameters in their subscript methods. Just do nothing.
>
> Disadvantages: none that I can see. (Assuming we agree that this is a
> useful feature.)
>
>
> > 2.m.__get__(1, 2, a=3, b=4)  # change positional argument handling from
> > current behavior
>
> Advantages:
>
> 1. Consistency with other methods and functions.
>
> Disadvantages:
>
> 1. Breaks backwards compatibility.
>
> 2. Will require a long and painful transition period during which time
> libraries will have to somehow support both calling conventions.
>
>
> > 3.m.__get__((1, 2), {'a': 3, 'b': 4})  #  handling of positional
> > arguments unchanged from current behavior
>
> I assume that if there are no keyword arguments given, only the
> first argument is passed to the method (as opposed to passing an
> empty dict). If not, the advantages listed below disappear.
>
> Advantages:
>
> (1) Existing positional only subscripting does not change (backwards
> compatible).
>
> (2) Requires no extra effort for developers who don't need or want
> keyword parameters in their subscript methods. Just do nothing.
>
> Disadvantages:
>
> (1) Forces people to do their own parsing of keyword arguments to local
> variables inside the method, instead of allowing the interpreter to do
> it.
>
> (2) Compounds the "Special case breaks the rules" of subscript methods
> to keyword arguments as well as positional arguments.
>
> (3) It's not really clear to me that anyone actually wants this, apart
> from just suggesting it as an option. What's the concrete use-case for
> this?
>
>
> > 4.m.__get__(KeyObject( (1, 2), {'a': 3, 'b': 4} ))   # change
> > positional argument handling from current behavior only in the case that
> > kwd args are provided
>
> Use-case: you want to wrap an arbitrary number of positional arguments,
> plus an arbitrary set of keyword arguments, into a single hashable "key
> object", for some unstated

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Tue, Aug 25, 2020 at 7:23 PM Christopher Barker 
wrote:

> Though I haven't quite seen it said explicitly -- is this proposed to be
> added to the Sequence ABC?
>
> If so, there is a potential problem -- the ABC's "namespace" is not
> reserved, so if you add .get(), then any code out in the while that is
> already using .get in a custom sequence could potentially break.
>
> See the discussion about the idea of adding a .view() method to Sequences
> -- same issue. Even of you think it's a good idea, it's still hard to add a
> new (non-dunder) method to an ABC.
>

I think if it's a potential problem to add it to the ABC then let's just
defer that and only add it to the built in sequences.

But I'm not clear on what the problem is. If you have some code like this:

```
class MySequence(Sequence):
def get(self, i): ...

MySequence().get(3)
```

and then add .get to the Sequence ABC, the existing code will not be
immediately broken because the custom MySequence.get overrides the ABC
method so everything behaves as before.

A problem that I can see eventually arising is if someone writes some
generic code for Sequences using .get, MySequence won't work with it. That
won't happen immediately and I'm not sure if I'd call it a break in
compatibility. But I can see that it is a problem.

Maybe if we build up enough methods to add to the collection ABCs
(Sequence.view, Sequence.get, Set.intersection/union/etc,
Mapping.__[i]or__) we can justify adding them all at once in Python 4 or in
a new module collections.abc.v2 which has subclasses of the originals.
___
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/VQXMN23GMCV4FDGS5323ZSTACVJFJMUR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding additionnal common request handlers to http.server

On Tue, Aug 25, 2020 at 7:15 PM Christopher Barker 
wrote:

> On Tue, Aug 25, 2020 at 8:11 AM Simon  wrote:
>
>> I find that flask's approach to this is quite pythonic. It's also
>> relatively easy to use and explain.
>>
>> This is a good point, I think you distracted a bit earlier by saying it
> would be familiar to flask users. That's true, but not the point. Rather,
> we are going for, as you say, a pythonic, simple, easy to use and explain
> API. And this one is inspired by flask, which is a good thing, as flask is
> widely used and excepted, and has a reputation for being fairly easy to get
> started with.opriate for quick prototyping.
>

Personally I'm fine with just using third party libraries for this stuff,
but in terms of whether this is Pythonic, the example has this:

 @RESTRequestHandler.route('/get/', methods=['GET'])
 def get_obj(request, obj_id):

I think it should be written as:

 @RESTRequestHandler.route('/get/{obj_id}', methods=['GET'])
 def get_obj(request, obj_id: int):

The former API is what Flask does and it makes sense because it's an old
library. Nowadays type annotations are possible and make more sense. This
is somewhat inspired by FastAPI which is also well liked:
https://fastapi.tiangolo.com/#example. The curly brackets make a bit more
sense to me as well but that's not really the point.
___
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/E7WMB4VE37XWTOLDEACZI7VSCUVQHVBE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Tue, Aug 25, 2020 at 5:50 AM Alex Hall  wrote:

> I think that the discussion here simply fizzled away because:
>
> 1. People got distracted by talking about PEP 505 which really isn't very
> relevant and would solve a different problem.
> 2. There are no major objections, so there isn't much left to talk about,
> which seems like a silly way for a proposal to die. The only decent
> objection I saw was skepticism about valid and frequent use cases but once
> I answered that no one pursued the matter.
>

A lot of ideas fizzle away on this list. The fact is that it's a lot of
work to get a new feature accepted into Python, even if it's not very
controversial -- it's the classing "scratching an itch" problem -- someone
needs to find it itchy enough to do a LOT of scratching -- any idea needs a
champion that will carry it though.

This one is easier than most because it's pretty much a do we or don't we
question, with the spelling semantics, all pretty much already decided.

Though I haven't quite seen it said explicitly -- is this proposed to be
added to the Sequence ABC?

If so, there is a potential problem -- the ABC's "namespace" is not
reserved, so if you add .get(), then any code out in the while that is
already using .get in a custom sequence could potentially break.

See the discussion about the idea of adding a .view() method to Sequences
-- same issue. Even of you think it's a good idea, it's still hard to add a
new (non-dunder) method to an ABC.

-CHB

> ___
> 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/OMMRKVRCRR4BAXLG2ATRJT5ZWOMQBTPB/
> 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/OHVTXX2EPXLQHUXCLSM7A66VX43GI2AQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Adding additionnal common request handlers to http.server

On Tue, Aug 25, 2020 at 8:11 AM Simon  wrote:

> I find that flask's approach to this is quite pythonic. It's also
> relatively easy to use and explain.
>
> This is a good point, I think you distracted a bit earlier by saying it
would be familiar to flask users. That's true, but not the point. Rather,
we are going for, as you say, a pythonic, simple, easy to use and explain
API. And this one is inspired by flask, which is a good thing, as flask is
widely used and excepted, and has a reputation for being fairly easy to get
started with.

I myself am not familiar with flask, and with a quick glance, your
prototype made sense to me :-)

I think this might be a good addition to the stdlib, but it's still a good
idea to flesh out the API and documentation, and a package we can grab from
PyPi would be a good way to test it out. And we'd want that as a backport
anyway. Also, you can see if you get any uptake -- other than the "can't ue
PyPi" use case, do folks find this useful for simple REST APIs that don't
require templating, and ORMs, and web-based configuration, and sessions,
and all that stuff that the more complete frameworks provide.

So I encourage you to move forward with this and see where it goes.

-CHB






> With this approach, as demonstrated by the example I provided, any dev can
> spin up a server that serves an API in virtually no time, which is why, out
> of all the possible approaches (Having an App-like class, designing
> middlewares, a Resource object with get,post,put,delete methods etc), I
> personally find flask's is the most appropriate for quick prototyping.
>
> Furthermore, in the implementation I made of this request handler, I used
> nothing but built-in python types.
>
> Here are the implementations I thought of, both for the
> 'RESTRequestHandler' and the 'WebhookRequestHandler'.
>
> RESTRequestHandler
> 
> WebhookRequestHandler
> 
>
> I also can't help but think that this would be a great addition for devs
> who cannot for one reason or another, use PyPI (for instance, restrictions
> imposed by the IT staff at their jobs)
>
> I can't help the feeling that this is much more appropriate for PyPI than
> for the stdlib. There are just too many different ways to do it. (For
> example, what if the user isn't familiar with flask?)
>
> On Mon, Aug 24, 2020 at 1:45 PM Simon  wrote:
>
> > > Fair enough. I guess the real question is, how much advantage is
> > > RESTRequestHandler over directly subclassing BaseHTTPRequestHandler?
> > > Maybe it'd be worth it just to simplify that case.
> > >
> > > ChrisA
> >
> > Well, maybe an example would be more telling. Below is a basic usage of
> > the handler I wrote :
> >
> > @RESTRequestHandler.route('/get/', methods=['GET'])
> > def get_obj(request, obj_id):
> > objs = [
> > {'bar': 'baz'},
> > {'lorem': 'ipsum'},
> > ]
> > if obj_id > len(objs):
> > raise HTTPStatusException(HTTPStatus.NOT_FOUND)
> > return HTTPStatus.OK, objs[obj_id]
> > @RESTRequestHandler.errorhandler('*')
> > def handle_errors(r, exc):
> > return exc.status_code, {'code': exc.status_code, 'message'
> > : exc.message}
> > with HTTPServer(('localhost', 8080), RESTRequestHandler) as httpd:
> > httpd.serve_forever()
> > This example demonstrates how such a handler would be used, using a
> syntax
> > that
> > flask users should be pretty familiar with. The handler integrates both a
> > route and
> > an errorhandler decorator, which can be used to add new routes to the API
> > that's being
> > built. It's not something that's in the standard library either. By the
> > way, RESTRequestHandler
> > subclasses SimpleHTTPRequestHandler.
> >
> > Overall the advantage is pretty clear, it provides a much simpler API for
> > devs
> > who wish to spin up an API, which would be the ultimate goal of this PEP.
> > Not to mention,
> > the handler I wrote is 184 lines of code, having to reimplement for every
> > API is cumbersome.
>
> ___
> 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/O53NXLP4BBTRVOZLVRJCM772AYLGIDLH/
> 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

[Python-ideas] Re: Adding additionnal common request handlers to http.server

2020-08-25 Thread Simon

I find that flask's approach to this is quite pythonic. It's also
relatively easy to use and explain. With this approach, as demonstrated by
the example I provided, any dev can spin up a server that serves an API in
virtually no time, which is why, out of all the possible approaches (Having
an App-like class, designing middlewares, a Resource object with
get,post,put,delete methods etc), I personally find flask's is the most
appropriate for quick prototyping.

Furthermore, in the implementation I made of this request handler, I used
nothing but built-in python types.

Here are the implementations I thought of, both for the
'RESTRequestHandler' and the 'WebhookRequestHandler'.

RESTRequestHandler

WebhookRequestHandler

I also can't help but think that this would be a great addition for devs
who cannot for one reason or another, use PyPI (for instance, restrictions
imposed by the IT staff at their jobs)

I can't help the feeling that this is much more appropriate for PyPI than
for the stdlib. There are just too many different ways to do it. (For
example, what if the user isn't familiar with flask?)

On Mon, Aug 24, 2020 at 1:45 PM Simon  wrote:

> > Fair enough. I guess the real question is, how much advantage is
> > RESTRequestHandler over directly subclassing BaseHTTPRequestHandler?
> > Maybe it'd be worth it just to simplify that case.
> >
> > ChrisA
>
> Well, maybe an example would be more telling. Below is a basic usage of
> the handler I wrote :
>
> @RESTRequestHandler.route('/get/', methods=['GET'])
> def get_obj(request, obj_id):
> objs = [
> {'bar': 'baz'},
> {'lorem': 'ipsum'},
> ]
> if obj_id > len(objs):
> raise HTTPStatusException(HTTPStatus.NOT_FOUND)
> return HTTPStatus.OK, objs[obj_id]
> @RESTRequestHandler.errorhandler('*')
> def handle_errors(r, exc):
> return exc.status_code, {'code': exc.status_code, 'message'
> : exc.message}
> with HTTPServer(('localhost', 8080), RESTRequestHandler) as httpd:
> httpd.serve_forever()
> This example demonstrates how such a handler would be used, using a syntax
> that
> flask users should be pretty familiar with. The handler integrates both a
> route and
> an errorhandler decorator, which can be used to add new routes to the API
> that's being
> built. It's not something that's in the standard library either. By the
> way, RESTRequestHandler
> subclasses SimpleHTTPRequestHandler.
>
> Overall the advantage is pretty clear, it provides a much simpler API for
> devs
> who wish to spin up an API, which would be the ultimate goal of this PEP.
> Not to mention,
> the handler I wrote is 184 lines of code, having to reimplement for every
> API is cumbersome.
___
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/O53NXLP4BBTRVOZLVRJCM772AYLGIDLH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

2020-08-25 Thread Daniel.

Oh, thanks :)

Anyway, it still applies for fetching a single arbitrary indexes

Em ter., 25 de ago. de 2020 às 11:07, Alex Hall 
escreveu:

> I mean you could write these as:
>
> if stack[-3:] == [x, y, z]
>
> and
>
> elif stack[-1:] == [t]
>
> But plenty of use cases still exist (
> https://mail.python.org/archives/list/python-ideas@python.org/message/7W74OCYU5WTYFNTKW7PHONUCD3U2S3OO/)
> and I think we shouldn't need to keep talking about them.
>
> On Tue, Aug 25, 2020 at 2:54 PM Daniel.  wrote:
>
>> I just came across this again while implementing an parser
>>
>> I would like to compare stack elements as
>>
>> if stack[-3] == x and stack[-2] == y and stack[-1] == z
>>
>> and somewere below
>>
>> elif stack[-1] == t
>>
>> I had to spread `len(stack)` in a lot of places.
>>
>> People said about the length of a list is usually known, but when you use
>> it as a stack is the oposit.
>>
>> Em ter, 25 de ago de 2020 09:44, Alex Hall 
>> escreveu:
>>
>>> On Thu, Jul 2, 2020 at 10:33 PM Alex Hall  wrote:
>>>
 On the other hand, `list.get` seems very doable to me. It's not new
 syntax. It would be extremely easy to learn for anyone familiar with
 `dict.get`, which is pretty much essential knowledge. You'd probably have
 some people guessing it exists and using it correctly without even seeing
 it first in other code or documentation. I haven't seen anyone in this
 thread suggesting any cost or downside of adding the method, just people
 asking if it would be useful. I feel like I answered that question pretty
 thoroughly, then the thread went quiet.

>>>
>>> I just had a coworker ask if there was something akin to `list.get(0)`,
>>> so I'd like to try to revive this.
>>>
>>> I propose that:
>>>
>>> 1. There is basically no cost in terms of mental capacity, learnability,
>>> or API bloat in adding list.get because of the similarity to dict.get.
>>> 2. There are plenty of times it would be useful, as seen in
>>> https://mail.python.org/archives/list/python-ideas@python.org/message/7W74OCYU5WTYFNTKW7PHONUCD3U2S3OO/
>>> 3. If the above two points are true, we should go ahead and add this.
>>>
>>> I think that the discussion here simply fizzled away because:
>>>
>>> 1. People got distracted by talking about PEP 505 which really isn't
>>> very relevant and would solve a different problem.
>>> 2. There are no major objections, so there isn't much left to talk
>>> about, which seems like a silly way for a proposal to die. The only decent
>>> objection I saw was skepticism about valid and frequent use cases but once
>>> I answered that no one pursued the matter.
>>>
>>

-- 
“If you're going to try, go all the way. Otherwise, don't even start. ..."
  Charles Bukowski
___
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/JTRUNNK2NN6ALD33A4BQCE65TJN26AVP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

2020-08-25 Thread David Mertz

On Tue, Aug 25, 2020 at 2:26 AM Christopher Barker 
wrote:

> As for "why not" not being a motivator -- I agree, I posted it that easy
> because this conversation has brought up a number of examples where slice
> syntax is nice to use. And David Mertz pointed out, both numpy and pandas
> have a utility to make easier slices -- yes, that's an argument for why you
> don't need them, but it's also an argument for why there IS a need for
> slice objects outside of the square brackets, and if we need slice objects,
> then slice syntax is nice.
>

Pandas is kinda special though.  It semi-abuses Python syntax in quite a
few places.  For example, here is an example from the Pandas docs:

>>> idx = pd.IndexSlice>>> dfmi.loc[idx[:, 'B0':'B1'], :]

There is a hierarchical index (MultiIndex) where we want to put slices as
some of the "dimensions" of slice items.  It definitely makes sense in the
Pandas world, but I have never once encountered anywhere I would want
"stand-alone" slice objects outside of Pandas.  I know NumPy includes the
same convenience, but it's not even coming to me immediately in what
context you would want that in NumPy.

Personally, I like the single letter `I` even more than the `idx` name in
the example.  But in general, having to use a somewhat special object to do
something that really is rare and special doesn't feel like a big burden.
Moreover, as others have noted, in dictionaries and elsewhere, allowing
slices as generic expressions allows for very confusing looking code (I
won't say it's *definitely* ambiguous, but certainly hard for humans to
make sense of, even if the parser could).

-- 
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/GANTLNAHYV4OOUDV2MINOM3W3JMBJGFI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: keyword arguments before positional arguments- syntax inconsistency

2020-08-25 Thread Bar Harel

I've found a note about this from Guido back in 2000:
https://mail.python.org/archives/list/python-...@python.org/thread/BIAEXJPSO4ZSUAEKYHGHSOIULSMV3CYK/#HURE3EIQLNHVSMTUSUHGCQF5IGIN7XVE
Not sure if it went anywhere back then.


On Tue, Aug 25, 2020 at 4:27 PM Ben Avrahami  wrote:

> consider the following function:
> def foo(a,b,c,x):
> pass
>
> The following calls are equivalent:
> foo(1,2,3, x=0)
> foo(*(1,2,3), x=0)
> However, since python allows keyword arguments before star-unpacking, you
> can also do:
> foo(x=0, *(1, 2, 3))
> But removing the unpacking, would result in a syntax error:
>  foo(x=0, 1, 2, 3)
> This is against the understanding of unpacking, is this intentional?
> ___
> 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/L5TYF3FRT6VLOKAQBVAQ6AQTLFHAX3WM/
> 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/GNO6SO7UB5H3VDTPZUON7QASTBY2UH35/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

2020-08-25 Thread MRAB


On 2020-08-25 13:52, Daniel. wrote:

I just came across this again while implementing an parser

I would like to compare stack elements as

if stack[-3] == x and stack[-2] == y and stack[-1] == z


if stack[-3 : ] == [x, y, z]:


and somewere below

elif stack[-1] == t


elif stack[-1 : ] == [t]:


I had to spread `len(stack)` in a lot of places.


You can use slicing to reduce the number of `len(stack)`.

People said about the length of a list is usually known, but when you 
use it as a stack is the oposit.



[snip]
___
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/ANGXRSPIQIZL67U2H4G4AEZRA4WF4PAB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

I mean you could write these as:

if stack[-3:] == [x, y, z]

and

elif stack[-1:] == [t]

But plenty of use cases still exist (
https://mail.python.org/archives/list/python-ideas@python.org/message/7W74OCYU5WTYFNTKW7PHONUCD3U2S3OO/)
and I think we shouldn't need to keep talking about them.

On Tue, Aug 25, 2020 at 2:54 PM Daniel.  wrote:

> I just came across this again while implementing an parser
>
> I would like to compare stack elements as
>
> if stack[-3] == x and stack[-2] == y and stack[-1] == z
>
> and somewere below
>
> elif stack[-1] == t
>
> I had to spread `len(stack)` in a lot of places.
>
> People said about the length of a list is usually known, but when you use
> it as a stack is the oposit.
>
> Em ter, 25 de ago de 2020 09:44, Alex Hall 
> escreveu:
>
>> On Thu, Jul 2, 2020 at 10:33 PM Alex Hall  wrote:
>>
>>> On the other hand, `list.get` seems very doable to me. It's not new
>>> syntax. It would be extremely easy to learn for anyone familiar with
>>> `dict.get`, which is pretty much essential knowledge. You'd probably have
>>> some people guessing it exists and using it correctly without even seeing
>>> it first in other code or documentation. I haven't seen anyone in this
>>> thread suggesting any cost or downside of adding the method, just people
>>> asking if it would be useful. I feel like I answered that question pretty
>>> thoroughly, then the thread went quiet.
>>>
>>
>> I just had a coworker ask if there was something akin to `list.get(0)`,
>> so I'd like to try to revive this.
>>
>> I propose that:
>>
>> 1. There is basically no cost in terms of mental capacity, learnability,
>> or API bloat in adding list.get because of the similarity to dict.get.
>> 2. There are plenty of times it would be useful, as seen in
>> https://mail.python.org/archives/list/python-ideas@python.org/message/7W74OCYU5WTYFNTKW7PHONUCD3U2S3OO/
>> 3. If the above two points are true, we should go ahead and add this.
>>
>> I think that the discussion here simply fizzled away because:
>>
>> 1. People got distracted by talking about PEP 505 which really isn't very
>> relevant and would solve a different problem.
>> 2. There are no major objections, so there isn't much left to talk about,
>> which seems like a silly way for a proposal to die. The only decent
>> objection I saw was skepticism about valid and frequent use cases but once
>> I answered that no one pursued the matter.
>>
>
___
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/PI5OFONYFTRZDZWOW4A462XAHWLYYPDT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: keyword arguments before positional arguments- syntax inconsistency

2020-08-25 Thread Jonathan Fine

Ben's right regarding the facts. Here's my examples.

Python 3.6.9 (default, Jul 17 2020, 12:50:27)
>>> def foo(*argv, **kwargs): return argv, kwargs
>>> foo(*'ab', x=1, y=2, *'cd', z=3)
(('a', 'b', 'c', 'd'), {'x': 1, 'y': 2, 'z': 3})

Python 2.7.17 (default, Jul 20 2020, 15:37:01)
>>> def foo(*argv, **kwargs): return argv, kwargs
>>> foo(*'ab', x=1, y=2, *'cd', z=3)
SyntaxError: invalid syntax

Also, in Python 3.6.9
>>> foo(**{}, *())
is a SyntaxError, but
>>> foo(x=1, *())
is not.

I think the change happened as a result of
PEP 448 -- Additional Unpacking Generalizations
https://www.python.org/dev/peps/pep-0448/

It reads, in part,

> Function calls may accept an unbounded number of * and ** unpackings.
> There will be no restriction of the order of positional arguments with
> relation to * unpackings nor any restriction of the order of keyword
> arguments with relation to ** unpackings.


Ben also asked: This is against the understanding of unpacking, is this
intentional?

I was surprised at the unpacking behaviour. My first thought was that Ben
had made some mistake regarding the facts. So I made the check you see
above.
-- 
Jonathan
___
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/W2ACGW2RCK4RQUZTKPXD6Z3O4H4HDS5A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] keyword arguments before positional arguments- syntax inconsistency

2020-08-25 Thread Ben Avrahami

consider the following function:
def foo(a,b,c,x):
pass

The following calls are equivalent:
foo(1,2,3, x=0)
foo(*(1,2,3), x=0)
However, since python allows keyword arguments before star-unpacking, you
can also do:
foo(x=0, *(1, 2, 3))
But removing the unpacking, would result in a syntax error:
 foo(x=0, 1, 2, 3)
This is against the understanding of unpacking, is this intentional?
___
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/L5TYF3FRT6VLOKAQBVAQ6AQTLFHAX3WM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

2020-08-25 Thread Daniel.

Here is one example added in stdlib

https://github.com/python/cpython/pull/14813/files

It's checking the truthness of value before calling value[0], this is a
perfect match for value.get(0)

Here is another, just the same use case,
https://github.com/python/cpython/pull/17515/files

When you deal with parsing problems yielding sequence of tokens are pretty
common and knowing how much tokens are there is a matter of input. When you
deal with recursives problems using a stack too.. so there are use cases
out there and it's a tiny change






Em ter, 25 de ago de 2020 09:52, Daniel.  escreveu:

> I just came across this again while implementing an parser
>
> I would like to compare stack elements as
>
> if stack[-3] == x and stack[-2] == y and stack[-1] == z
>
> and somewere below
>
> elif stack[-1] == t
>
> I had to spread `len(stack)` in a lot of places.
>
> People said about the length of a list is usually known, but when you use
> it as a stack is the oposit.
>
> Em ter, 25 de ago de 2020 09:44, Alex Hall 
> escreveu:
>
>> On Thu, Jul 2, 2020 at 10:33 PM Alex Hall  wrote:
>>
>>> On the other hand, `list.get` seems very doable to me. It's not new
>>> syntax. It would be extremely easy to learn for anyone familiar with
>>> `dict.get`, which is pretty much essential knowledge. You'd probably have
>>> some people guessing it exists and using it correctly without even seeing
>>> it first in other code or documentation. I haven't seen anyone in this
>>> thread suggesting any cost or downside of adding the method, just people
>>> asking if it would be useful. I feel like I answered that question pretty
>>> thoroughly, then the thread went quiet.
>>>
>>
>> I just had a coworker ask if there was something akin to `list.get(0)`,
>> so I'd like to try to revive this.
>>
>> I propose that:
>>
>> 1. There is basically no cost in terms of mental capacity, learnability,
>> or API bloat in adding list.get because of the similarity to dict.get.
>> 2. There are plenty of times it would be useful, as seen in
>> https://mail.python.org/archives/list/python-ideas@python.org/message/7W74OCYU5WTYFNTKW7PHONUCD3U2S3OO/
>> 3. If the above two points are true, we should go ahead and add this.
>>
>> I think that the discussion here simply fizzled away because:
>>
>> 1. People got distracted by talking about PEP 505 which really isn't very
>> relevant and would solve a different problem.
>> 2. There are no major objections, so there isn't much left to talk about,
>> which seems like a silly way for a proposal to die. The only decent
>> objection I saw was skepticism about valid and frequent use cases but once
>> I answered that no one pursued the matter.
>>
>
___
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/VWU4XVVTT3XAWFKFYFPRDLW3QDGF66TC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

2020-08-25 Thread Daniel.

I just came across this again while implementing an parser

I would like to compare stack elements as

if stack[-3] == x and stack[-2] == y and stack[-1] == z

and somewere below

elif stack[-1] == t

I had to spread `len(stack)` in a lot of places.

People said about the length of a list is usually known, but when you use
it as a stack is the oposit.

Em ter, 25 de ago de 2020 09:44, Alex Hall  escreveu:

> On Thu, Jul 2, 2020 at 10:33 PM Alex Hall  wrote:
>
>> On the other hand, `list.get` seems very doable to me. It's not new
>> syntax. It would be extremely easy to learn for anyone familiar with
>> `dict.get`, which is pretty much essential knowledge. You'd probably have
>> some people guessing it exists and using it correctly without even seeing
>> it first in other code or documentation. I haven't seen anyone in this
>> thread suggesting any cost or downside of adding the method, just people
>> asking if it would be useful. I feel like I answered that question pretty
>> thoroughly, then the thread went quiet.
>>
>
> I just had a coworker ask if there was something akin to `list.get(0)`,
> so I'd like to try to revive this.
>
> I propose that:
>
> 1. There is basically no cost in terms of mental capacity, learnability,
> or API bloat in adding list.get because of the similarity to dict.get.
> 2. There are plenty of times it would be useful, as seen in
> https://mail.python.org/archives/list/python-ideas@python.org/message/7W74OCYU5WTYFNTKW7PHONUCD3U2S3OO/
> 3. If the above two points are true, we should go ahead and add this.
>
> I think that the discussion here simply fizzled away because:
>
> 1. People got distracted by talking about PEP 505 which really isn't very
> relevant and would solve a different problem.
> 2. There are no major objections, so there isn't much left to talk about,
> which seems like a silly way for a proposal to die. The only decent
> objection I saw was skepticism about valid and frequent use cases but once
> I answered that no one pursued the matter.
>
___
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/4N6QMLONQQFMRS5LNSX6KGQRPQFH7NQJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reliable Ordering Of Sets

2020-08-25 Thread Jim Fasarakis-Hilliard

This might of been suggested in the other thread, but,

Instead of going after the built-in set why not propose a collections 
based OrderedSet akin to OrderedDict? I would believe that might be less 
contentious.

On 24/08/2020 23:43, Cade Brown wrote:

Hello all,

I have a suggestion/idea for the Python standard (and/or a CPython 
implementation detail, considering its memory impact): having sets 
behave similar to dictionaries in that they preserve first-appearance 
order (i.e. dictionaries are ordered by key which was first inserted).

As is said in the Python standard, a 'set' is by definition unordered. 
Yet, internally they must be stored in some order, and when iterated 
upon, converted to string, etc, some ordering must be used. Right now, 
it is unspecified, which can lead to interesting results I noticed:

>>> print ({1, 2, 3}, {3, 2, 1})
{1, 2, 3} {1, 2, 3}
>>> print ({1, 5, 9}, {9, 5, 1})
{1, 5, 9} {9, 5, 1}

While, obviously, things like `A == B` are not affected by this, many 
algorithms may affect their output if sets are treated as iterables 
(again, the argument could be made, as it was for 'dict' as well, that 
they should not treat the order as relevant at all). Further, I 
believe that having a specification regarding the order and some 
guarantees could be useful and important to cohesiveness of Python as 
a whole.

Despite the obvious non-ordered nature of sets, I still think it is 
worth making them behave like `dict` objects (which are also, in some 
sense, 'unordered' by nature, and yet Python still specifies the order 
for 3.7+).

I would like to suggests that `set` objects are ordered by insertion, 
so that:
  * Sets have a defined, repeatable order for maximum reproducibility 
(assuming the code generates the set in a stable way)
  * Tests which are outside of Python can do string comparisons and 
expect the same output each time (as with `dict` objects generated in 
a predictable way).
  * On a high-level note, Python specifies more exact behavior. It is 
my belief (and I'm sure many others share this as well) that 
unspecified/implementation-dependent/otherwise-undependable features 
should be eliminated and replaced with exact semantics that do not 
suprise users.

Thoughts?

Thanks,
~
Cade Brown
Working on MAGMA 
http://cade.site
http://chemicaldevelopment.us

___
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/JEMEOMEPR65PDSSCOULKU2K2S7NUIGRL/
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/WSPDX2WHKOUBHNSYLUJHE554X4KIMMHF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Thu, Jul 2, 2020 at 10:33 PM Alex Hall  wrote:

> On the other hand, `list.get` seems very doable to me. It's not new
> syntax. It would be extremely easy to learn for anyone familiar with
> `dict.get`, which is pretty much essential knowledge. You'd probably have
> some people guessing it exists and using it correctly without even seeing
> it first in other code or documentation. I haven't seen anyone in this
> thread suggesting any cost or downside of adding the method, just people
> asking if it would be useful. I feel like I answered that question pretty
> thoroughly, then the thread went quiet.
>

I just had a coworker ask if there was something akin to `list.get(0)`,  so
I'd like to try to revive this.

I propose that:

1. There is basically no cost in terms of mental capacity, learnability, or
API bloat in adding list.get because of the similarity to dict.get.
2. There are plenty of times it would be useful, as seen in
https://mail.python.org/archives/list/python-ideas@python.org/message/7W74OCYU5WTYFNTKW7PHONUCD3U2S3OO/
3. If the above two points are true, we should go ahead and add this.

I think that the discussion here simply fizzled away because:

1. People got distracted by talking about PEP 505 which really isn't very
relevant and would solve a different problem.
2. There are no major objections, so there isn't much left to talk about,
which seems like a silly way for a proposal to die. The only decent
objection I saw was skepticism about valid and frequent use cases but once
I answered that no one pursued the matter.
___
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/OMMRKVRCRR4BAXLG2ATRJT5ZWOMQBTPB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Tue, Aug 25, 2020, 2:09 AM Christopher Barker 
wrote:

> On Mon, Aug 24, 2020 at 11:10 AM Ricky Teachey  wrote:
>
>> \The interpreter wouldn't. I'm talking about adding this knowledge of
>> signature dependent semantics to `type`.
>>
>> To implement this, under the hood `type` would detect the signatures with
>> different semantics, and choose to wrap the functions with those
>> signatures in a closure based on the intended semantic meaning. Then
>> everything proceeds as it does today.
>>
>
> but it would still not know that:
>
> t = (1,2,3)
> something[t]
>
> is the same as:
>
> something[1,2,3]
>
> would it?
>

Definitely not. But I'm not sure that poses any kind of problem unless a
person is trying to abuse the subscript operator to be some kind of
alternative function call syntax, and they are wanting/expecting d[t] and
d(t) to behave the same way.

If I were to imagine myself explaining this to a beginner:

1. If you provide an item related dunder method that only accepts a single
argument for the index or key, the index or key will be passed as a single
object to that argument no matter how many "parameters" were passed to the
subscript operator. This is because you are not passing positional
parameters like a function call, you are passing an index. This is why, unlike
a regular function call, you cannot unpack a list or tuple in an subscript
operation. There would be no purpose.

2. Sometimes it is convenient to write item dunder methods that partially
mimic a function call, breaking up an index into positional parameters in a
similar way. When this is needed, just provide the desired number of
positional arguments in the signature for it to be broken up. But this
isn't intended to be a real function call. So there's no difference between
these no matter how many arguments are in your dunder method signatures:

d[1,2,3]
d[(1,2,3)]

But maybe I'm not a great teacher.

>
___
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/PT4ZQKGSPYXTLKRFVRSR6R7PW6RZ6D75/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

2020-08-25 Thread Jonathan Fine

Hi Todd

You wrote:

> Why would that be the case?  d[1:3] is allowed but d(1:3) isn't.  The
> interpreter replaces "1:3" with "slice(1, 3)" behind-the-scenes.
>

>>> s ='hello'
>>> s[1:3]
'el'

>>> s[(1:3)]
SyntaxError: invalid syntax

>>> f(x=1:3)
SyntaxError: invalid syntax

My understanding is that the syntax errors arise because the parser is
expecting, but not getting, an expression. (The conversion of "1:3" to a
slice is semantics, not syntax.)

My understanding is that if we make "1:3" an expression, as described in my
previous post, then it will also follow that
   >>> { :: :: :}
is valid syntax.

To allow
>>> d[x=1:3]
while forbidding
>>> { :: :: :}
will I think require changes in several places to Python.asdl.

I think it reasonable to require the PEP to explicitly state what those
changes are. If not you then perhaps some supporter of this change can
provide such changes, to be included in the PEP.

By the way, Python.asdl is included verbatim in the docs page

https://docs.python.org/3/library/ast.html#abstract-grammar
https://github.com/python/cpython/blob/3.8/Doc/library/ast.rst#abstract-grammar

-- 
Jonathan
___
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/W6XWJJURH7XHDAKLB7ZVJ3TPNRREZNCD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Fwd: Re: PEP 472 - slices in keyword indices, d[x=1:3]

2020-08-25 Thread Todd

On Tue, Aug 25, 2020, 05:10 Steven D'Aprano  wrote:

> I attempted to send this yesterday, but used the wrong sender email
> address and it got rejected.
>
> I think this is still relevent, just to confirm I understand the
> proposal correctly.
>
>
> - Forwarded message from Steven D'Aprano 
> -
>
> Date: Mon, 24 Aug 2020 11:46:02 +1000
> From: Steven D'Aprano 
> To: python-ideas@python.org
> Subject: Re: [Python-ideas] PEP 472 - slices in keyword indices, d[x=1:3]
>
> On Sun, Aug 23, 2020 at 09:40:53PM -0400, Todd wrote:
>
> > I think it is worth directly discussing the availability of slices in PEP
> > 472-style keyword indices, since we seem to have mostly converged on a
> > dunder method signature.  This is an issue that has been alluded to
> > regarding keyword-based (labelled) indices but not directly addressed.
> The
> > basic syntax would be something like d[x=1:3].
>
> I read that as equivalent to `d[x=slice(1, 3)]`. Is that your intention?
>
> If that is your intention, then a big +1.
>

Yes, this was my intention.  The same as with current slices, just passed
to the keyword argument.

>
___
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/SHL2QKEH6TV4AOY5E22N5GIQBZUDZ2ZS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reliable Ordering Of Sets

2020-08-25 Thread M.-A. Lemburg

On 24.08.2020 22:43, Cade Brown wrote:
> I would like to suggests that `set` objects are ordered by insertion, so that:
>   * Sets have a defined, repeatable order for maximum reproducibility 
> (assuming
> the code generates the set in a stable way)
>   * Tests which are outside of Python can do string comparisons and expect the
> same output each time (as with `dict` objects generated in a predictable way).
>   * On a high-level note, Python specifies more exact behavior. It is my 
> belief
> (and I'm sure many others share this as well) that
> unspecified/implementation-dependent/otherwise-undependable features should be
> eliminated and replaced with exact semantics that do not suprise users.

Why don't you simply use dicts instead of sets in case you want to
benefit from the insert order feature ?

Note that there were good reasons for having dict come closer to
OrderedDict - dicts are used by the interpreter to manage
namespaces and namespace definitions are ordered in Python code
(they are read top to bottom, or left to right).

It was desirable to have access to this order to reduce the number of
hacks necessary to gain this information before Python 3.7.

Sets aren't used in such a way. Their main purpose is to make
membership tests fast, even when the set content changes
frequently.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Aug 25 2020)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/
___
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/SXAWISPKK2IKNCIWKCHENPUU6P6ZNIQC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

On Mon, Aug 24, 2020 at 10:58:13AM +0200, Alex Hall wrote:

> {a:b} is a dict, {(a:b)} is a set containing one slice.

What's `{a: b: c: d, x: y}`? Typo or key with a slice value?

I know that any syntax can contain typos, but we generally try to avoid 
syntax which silently swallows such syntactic typos. The only one I can 
think of is implicit string concatenation:

values = ['spam', 'eggs' 'NOBODY expects the Spanish Inquisition',
  'Ethel the Aardvark Goes Quantity Surveying']

is probably supposed to have four items, not three :-)

But implicit string concatentation is useful enough that (in my opinion) 
it is worth keeping it around despite the occasional whoops moment.

Admittedly slicing is already vulnerable to that:

obj[a:b,c]  # two items or typo for an extended slice?

but I'm not sure that slice literals outside of subscripts is useful at 
all, let alone useful enough to allow this sort of silent error outside 
of subscripts.


-- 
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/BOFVUJU4NAHUPVXWUW2JDZZJP33WN7M6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

On Sun, Aug 23, 2020 at 09:43:14PM -0700, Christopher Barker wrote:

> Why not allow slice syntax as an expression everywhere? Everywhere I’ve
> tried, it’s a syntax error now, but is there any technical reason that it
> couldn’t be used pretty much anywhere?

When do you use slices outside of a subscript?

More importantly, when do you need slices outside of a subscript where 
they would benefit from being written in compact slice syntax rather 
than function call syntax?

I think I've done something like this once or twice:

chunk = slice(a, b, step)
for seq in sequences:
do_something_with(seq[chunk])

but I don't even remember why :-)

I'm not convinced that the first line would be better written as:

chunk = a:b:step

But this definitely wouldn't be:

chunk = ::

So apart from "but it looks cool" why do you want this?

(I agree that slices look cool inside subscripts, I'm just not so sure 
about outside of them.)

-- 
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/WRD3S6TSHFFJOWNBA7ZZ7W5RKXSZQYF3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Fwd: Re: PEP 472 - slices in keyword indices, d[x=1:3]

I attempted to send this yesterday, but used the wrong sender email 
address and it got rejected.

I think this is still relevent, just to confirm I understand the 
proposal correctly.


- Forwarded message from Steven D'Aprano  -

Date: Mon, 24 Aug 2020 11:46:02 +1000
From: Steven D'Aprano 
To: python-ideas@python.org
Subject: Re: [Python-ideas] PEP 472 - slices in keyword indices, d[x=1:3]

On Sun, Aug 23, 2020 at 09:40:53PM -0400, Todd wrote:

> I think it is worth directly discussing the availability of slices in PEP
> 472-style keyword indices, since we seem to have mostly converged on a
> dunder method signature.  This is an issue that has been alluded to
> regarding keyword-based (labelled) indices but not directly addressed.  The
> basic syntax would be something like d[x=1:3].

I read that as equivalent to `d[x=slice(1, 3)]`. Is that your intention?

If that is your intention, then a big +1.

If your intention was `d[slice(x=1, 3)]` then I think you would have to 
justify what it means and why you want it.



-- 
Steven

- End forwarded message -
___
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/R5EVLDHWYMPROFVWXJROASTFXNH3VRD3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

On Mon, 24 Aug 2020 at 02:42, Todd  wrote:
> So I think any revision to PEP 472 or new PEP should directly and explicitly 
> support the use of slices.

Duly noted (I am revisiting the PEP in light of all your comments
starting from 2019) but yes, I fully agree that slicing should be
supported for keyed arguments.


-- 
Kind regards,

Stefano Borini
___
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/EJEYN7XKI6NF62PYXCAL46CZZKTKYBIP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic

On Tue, Aug 25, 2020 at 8:11 AM Christopher Barker 
wrote:

> After, of course, looking and seeing what's already out there. (though a
> quick search in PyPi turns up, surprisingly, nothing. Lots of packages that
> have to do with logging, but nothing that looks like a Pythonic API -- at
> least not anything that looks the least bit documented or maintained.
>

I haven't tried it myself but https://github.com/Delgan/loguru looks
promising.
___
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/ULUZM5VJEVMWCWJZPJ6I2OIPYSIZYYN3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

On Mon, Aug 24, 2020 at 9:26 AM Sebastian Kreft  wrote:

> As I mentioned in another thread, I think the syntax in which the initial
> argument of the slice is missing may be visually confusing, as it is too
> similar to the walrus operator.
>
> d[x=:3] or d[x=:]
>

which I suppose is the point mentioned: "what if we want to use colons for
other things"?

However, the second case will be usually formatted as x = +3, as per PEP 8

>
>
> So unless PEP8 is updated to require/suggest spaces around a keyword index
> (which I'm not proposing), then I am -1 for the suggested feature, at least
> when the initial element is missing.
>

PEP8 can't require, and of course it could be updated -- that seems a non
issue.

As for "why not" not being a motivator -- I agree, I posted it that easy
because this conversation has brought up a number of examples where slice
syntax is nice to use. And David Mertz pointed out, both numpy and pandas
have a utility to make easier slices -- yes, that's an argument for why you
don't need them, but it's also an argument for why there IS a need for
slice objects outside of the square brackets, and if we need slice objects,
then slice syntax is nice.

But rather than suggesting one or two places where we might use sloce
syntax: e.g. function calls:

object.get_subset(x=a:b, y=c:d), or itertools,islice(it, 2:20:2)

Once you allow them anywhere outside  [], then the question does become
"why not?", because having an expression that is only valid in some small
fraction of contexts gets even more confusing.

Of course, as has been pointed out here -- dict displays are one good
reason NOT to support it.

Which is too bad -- I'd really like to see it more broadly available -- I
think it's a very nice syntax.

I am strongly in favor of having slices.  The main motivating factor for
>> me, labelled dimensions in xarray, would be much, much less useful without
>> support for slices.  In fact, as PEP 472 currently mentions, the big
>> benefit of indexing over method calls is that indexing supports slice
>> syntax while method calls don't.
>>
>
so maybe the solution is to have method calls support slices :-)

-CHB

>
>> In a more general sense, I feel not allowing slices would create an
>> artificial distinction between labelled and positional indices that I don't
>> think is justified.  They would work the same, except for slices where
>> labelled indices behave differently.  It would be a strange gotcha.
>>
>> So I think any revision to PEP 472 or new PEP should directly and
>> explicitly support the use of slices.
>> ___
>> 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/TOABKD7A5X653BTTU3MZICWURNGPMY47/
>> 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/IQJNOQS2LKHWSSYAJX7KDNWJ5ZFZ25N4/
> 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/4H5SKCZH6WUPX6SXPSTKOCYLTCSO3SR3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Mon, Aug 24, 2020 at 11:10 AM Ricky Teachey  wrote:

> \The interpreter wouldn't. I'm talking about adding this knowledge of
> signature dependent semantics to `type`.
>
> To implement this, under the hood `type` would detect the signatures with
> different semantics, and choose to wrap the functions with those
> signatures in a closure based on the intended semantic meaning. Then
> everything proceeds as it does today.
>

but it would still not know that:

t = (1,2,3)
something[t]

is the same as:

something[1,2,3]

would it?



> All of this is possible today, of course, using a metaclass, or using a
> regular class and the __init_subclass__ method, or using decorators. But my
> suggestion is to roll it into type.
>
> ---
> Ricky.
>
> "I've never met a Kentucky man who wasn't either thinking about going home
> or actually going home." - Happy Chandler
>
>
>

-- 
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/Q6O4JTEHD2S3P5DBHKEET4E5A2NF6YND/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic