That's a good point.
It might be better to disallow the list and set versions all together. To
get a list or set you would instead have to explicitly unpack a range/slice
object:
[*(:5)] # [:5] no longer allowed
{*(1:6)} # {1:6} is a dict
That would also solve the misstep of the three-character
Overall, I agree with you. It is more intuitive to an experienced Python
user, and not so helpful to beginners. It decreases the ability to read out
code like English sentences and makes it harder to know what to search for
online. So it boosts facility after you know the language, but not when
sta
Interesting. I haven't looked at that package before. It looks like it
would work well for that.
On Sun, Nov 11, 2018 at 4:48 AM Robert Vanden Eynde
wrote:
> I'm wondering how your examples would go with from funcoperators import
> infix (https://pypi.org/project/funcoperators/)
>
> sum(1:6) # i
That's true. I should clarify what I was thinking a bit more. Maybe it's
better to say that the new syntax creates a slice object:
(::) # this creates slice(None, None, None)
It accepts any object into its arguments and they default to None when they
are left off. This can be passed into list ind
I mostly like the abstraction being proposed, but the syntactical edge
cases like `[::3]` (infinite list crashes) and {4:10} (a dict not a
slice/range set) tip the balance against it for me. Saying to add some
various stars and parens in various not-really-obvious places just makes
the proposal wa
For sake of completeness, here is another possible problem I've found with
it.
I was afraid of making something context-dependent, and therefore breaking
its consistency. Here is the use of slices in the current language that
breaks my rules:
my_array[:,2] # valid syntax, though I've typically on
On Sat, Nov 10, 2018 at 6:56 PM Jonathan Crall wrote:
> Sometimes there's a good, useful function than doesn't get added because
>> there's no reasonable place to put it. For example, a "flatten" function
>> has been talked about since Python 1.x days, and we still don't have a
>> standard soluti
Not to derail the conversation, but I've always been curious why the
itertools recipes are recipes and not ready-made goods (pre-baked?) that I
can just consume. They're great examples to draw from, but that shouldn't
preclude them from also being in the stdlib.
On Mon, Nov 12, 2018 at 7:41 PM Mic
My intuition has always been that the recipes, taking 'flatten' as an
excellent example, solve problems in a specific way that is not generally
considered to be the "right" way. For example, should 'flatten' perform
one-level flattening or deep recursive flattening? Should it handle
strings as si
On Mon, Nov 12, 2018 at 11:23:21AM -0500, David Mertz wrote:
> >>> import pandas as pd
> >>> import numpy as np
> >>> I = pd.IndexSlice
> >>> J = np.s_
> >>> I[4:10:3]
> slice(4, 10, 3)
I'm not entirely sure that I like the idea of conflating slice
*constructor* with slice *usage*. Slice objects
Are you aware of https://boltons.readthedocs.io/ (whose motto is
"Functionality that should be in the standard library.") ?
Or similar endeavours such as:
- https://pypi.org/project/auxlib/
- https://pypi.org/project/omakase/
- (And probably many others on PyPI with similar descriptions such as "
11 matches
Mail list logo
