On 26/08/20 1:59 pm, Steven D'Aprano wrote:
Most existing uses of subscripts already don't fit that key:value
mapping idea, starting with lists and tuples.
Not sure what you mean by that.
Given `obj[spam]`, how does the interpreter know whether to call
`__getitem__` or `__getindex__`? What
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
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
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
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.
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
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
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
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
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
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?
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
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
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:
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?
>
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
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
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
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
>
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
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.
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
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 (
>
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
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
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 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
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)
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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
On Mon, Aug 24, 2020 at 7:39 PM Adam Hendry
wrote:
> In the spirit of CHB's recommendation, this is my proposal:
>
> Would an update/addition/alternative API to the logging module be
> considered for inclusion in the stdlib?
>
These look like good ideas to me. And whether or not it would be
45 matches
Mail list logo
