My suggestion to solve this would be to use a similar rule to the walrus
operator; only allow slice literals within either `()` brackets or `[]` square
brackets; thus `{a: b: c: d, x: y}` becomes illegal and would need to be
`{(a:b): (c:d), x: y}`
___
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. A
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 uti
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 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
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 su
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 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 men
On Mon, Aug 24, 2020 at 12:23 PM Jonathan Fine wrote:
> Christopher wrote: Why not allow slice syntax as an expression everywhere?
>
> In reply, Todd wrote: That is a very different discussion, and not
> directly related to keyword indexes. Would it be possible to start a new
> email thread to d
On Sun, Aug 23, 2020 at 9:42 PM 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 (labelle
Christopher wrote: Why not allow slice syntax as an expression everywhere?
In reply, Todd wrote: That is a very different discussion, and not directly
related to keyword indexes. Would it be possible to start a new email
thread to discuss it?
I think they are closely related matters, at least in
On Mon, Aug 24, 2020 at 12:43 AM 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?
>
How often do you do this?
>>> class Slice:
On Mon, Aug 24, 2020, 00:43 Christopher Barker wrote:
> But thus brings up a broader question:
>
> 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?
>
That i
On Mon, 24 Aug 2020 at 09:59, Alex Hall wrote:
>
> On Mon, Aug 24, 2020 at 9:54 AM Random832 wrote:
>>
>> On Mon, Aug 24, 2020, at 00:43, Christopher Barker wrote:
>> > But thus brings up a broader question:
>> >
>> > Why not allow slice syntax as an expression everywhere? Everywhere I’ve
>> > tr
On Mon, Aug 24, 2020 at 9:54 AM Random832 wrote:
> On Mon, Aug 24, 2020, at 00:43, Christopher Barker wrote:
> > But thus brings up a broader question:
> >
> > Why not allow slice syntax as an expression everywhere? Everywhere I’ve
> > tried, it’s a syntax error now, but is there any technical re
On Mon, Aug 24, 2020 at 6:27 PM Christopher Barker wrote:
> but {a:b:1} is now a syntax error, so we could make only the three-part form
> allowable.
>
But is that a set containing a:b:1, or a dict mapping a to b:1, or a
dict mapping a:b to 1? I don't like it.
ChrisA
___
On Mon, Aug 24, 2020 at 12:54 AM Random832 wrote:
> > Why not allow slice syntax as an expression everywhere?
>
> is {a:b} a set containing a slice, or a dict? obviously it's a dict, but
> are there any other places that might be affected?
should we support {a, b:c} as a set containing a slic
On Mon, Aug 24, 2020, at 00:43, Christopher Barker wrote:
> But thus brings up a broader question:
>
> 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?
is
On Sun, Aug 23, 2020 at 6:42 PM Todd wrote:
> I think it is worth directly discussing the availability of slices in PEP
> 472-style keyword indices,
>
+1 on slices in all indexing.
But thus brings up a broader question:
Why not allow slice syntax as an expression everywhere? Everywhere I’ve
tr
19 matches
Mail list logo
