On Wed, Oct 12, 2016 at 06:06:51PM +0200, Enguerrand Pelletier wrote:
> Hi all,
>
> It always bothered me to write something like this when i want to strip
> keys from a dictionnary in Python:
>
> a = {"foo": 1, "bar": 2, "baz": 3, "foobar": 42}
> interesting_keys = ["foo", "bar", "baz"]
> b = {
Oh, I forgot to mention...
On Wed, Oct 12, 2016 at 06:06:51PM +0200, Enguerrand Pelletier wrote:
> Hi all,
>
> It always bothered me to write something like this when i want to strip
> keys from a dictionnary in Python:
[snip]
You've started a completely new discussion on an unrelated topic, bu
On Thu, Oct 06, 2016 at 04:19:17PM -0700, Neil Girdhar wrote:
> Currently str(slice(10)) returns "slice(None, 10, None)"
>
> If the start and step are None, consider not emitting them. Similarly
> slice(None) is rendered slice(None, None, None).
>
> When you're printing a lot of slices, it's a
On 12 November 2016 at 10:26, Steven D'Aprano wrote:
> But let's make str() of a slice more suggestive of actual slicing, and
> as a bonus, make slices easier to create too.
>
> str(slice(None, None, None)) => "slice[:]"
>
> Let the slice type itself be sliceable, as an alternate constuctor:
Would it be helped by an explicit "free variable" marker? (I'm sure I've seen
someone demo a prototype of this):
>>> data_frame.subset($height > 100 and $age < 5)
Which essentially translates into:
>>> data_frame.subset(lambda **a: a["height"] > 100 and a["age"] < 5)
Maybe the generated thunk
I) Thank you for responding to my message because it makes me happy to
know that my message was read by your team.
II) The “.okular” file is an archive made by “Okular software” and
contains the “PDF” file with its annotations. “https://okular.kde.org/” this is
the link to the softwa
I like PEP-532. Given the opposition to non-Pythonic syntax like ?? (i.e.
PEP-505), Nick's proposal offers a Pythonic alternative that is protocol
based, more generalized, and uses built-ins and keywords to avoid
punctuation.
I agree with other posters that the terms "exists" and "missing" could l
Hi,
I looked around for a while but didn't see this proposed anywhere. I
apologize if I missed an existing discussion.
I do a fair amount of work with pandas and data munging. This means that
I'm often doing things like:
mydf = df[ ['field1', 'field2', 'field3' ] ]
This is a little ugly, so i
If recommend 'valued(foo)'. Without the final 'd' I think of "the value of
foo" rather than "does foo have a value?" Obviously, the value of foo is
just spelled 'foo' in Python, but it seems confusing.
'exists(foo)' is even more confusing since almost everyone will read it as
"is foo defined?" I k
Just spend the extra two characters to do this with existing syntax:
w('field1 field2 field3'). Implementation of the w() function is trivial.
On Nov 12, 2016 9:04 AM, "Gary Godfrey" wrote:
> Hi,
>
> I looked around for a while but didn't see this proposed anywhere. I
> apologize if I missed a
On Sat, Nov 12, 2016 at 05:01:00PM +, Gary Godfrey wrote:
> I do a fair amount of work with pandas and data munging. This means that
> I'm often doing things like:
>
> mydf = df[ ['field1', 'field2', 'field3' ] ]
>
> This is a little ugly, so if the list is long enough, I do:
>
> mydf=df[
+100
I like this idea of giving `slice` a metaclass that defines a
`.__getitem__()` allowing us to construct slices on the slice type itself.
FWIW, this is exactly what pandas.IndexSlice does. E.g., from
http://pandas.pydata.org/pandas-docs/stable/advanced.html:
In [51]: dfmi.loc[(slice('A1','A
On Sat, Nov 12, 2016 at 9:10 PM David Mertz wrote:
>
> dfmi.loc[slice[:,:,['C1','C3']], slice[:,'foo']]
>
>
> I like the change proposed to `str(slice(10))` also... and it would be way
> better if `slice[:10]` were actual "syntax." In fact, in that case it
> could even be the repr().
>
>
Indexin
On Sat, Nov 12, 2016 at 11:33 AM David Mertz wrote:
> Just spend the extra two characters to do this with existing syntax:
> w('field1 field2 field3'). Implementation of the w() function is trivial.
>
>
I've done that as well and see that done. Sometimes with s('field1
field2'), sometimes with
>
> > mydf = df[ ['field1', 'field2', 'field3' ] ]
> > mydf=df[ 'field1 field2 field3'.split() ]
>
> I consider the need for that to indicate a possibly poor design of
> pandas. Unless there is a good reason not to, I believe that any
> function that requires a list of strings should also accept a
On Sat, Nov 12, 2016 at 12:06 PM Steven D'Aprano
wrote:
> I consider the need for that to indicate a possibly poor design of
> pandas. Unless there is a good reason not to, I believe that any
> function that requires a list of strings should also accept a single
> space-delimited string instead.
I thought of the use of `.__getitem__()` in metaclasses in the typing
module. I feel like this use is more natural and more useful than that.
Should we someday need a slice generic type for PEP 484, the spelling would
naturally be `Slice[T]` instead, in my mind. But `slice[1:10,2]` should be
a co
On 12 November 2016 at 20:27, David Mertz wrote:
> I thought of the use of `.__getitem__()` in metaclasses in the typing
> module. I feel like this use is more natural and more useful than that.
> Should we someday need a slice generic type for PEP 484, the spelling would
> naturally be `Slice[T
Hello,
I would like to propose some reversed assignment operators.
Python already has some assignment operators:
a += c is the same as a = a + c
a -= c is the same as a = a - c
a *= c is the same as a = a * c
a /= c is the same as a = a / c
a //= c is the same as a = a // c
a %= c is the same as
On Sat, Nov 12, 2016 at 10:08 PM João Matos wrote:
>
> What I would like to propose is the creation of the reverse:
> a =+ c is the same as a = c + a
>
a =+5 already means a becomes 5
> a =- c is the same as a = c - a
>
a =-5 already means a becomes -5
Elazar
Hello,
What I propose is not
a = +5 (see the space between the = and + sign)
but
a =+ 5 (no space between the = and + sign, and there is a space between
+ and 5)
Exactly the same notation (only reversed) as the current assignment
operators.
Best regards,
JM
On 12-11-2016 20:15, אלעזר wr
On 2016-11-12 18:08, João Matos wrote:
a =- c is the same as a = c - a
This would break compatibility.
a =- c
is
a = -c
--
Bernardo Sulzbach
http://www.mafagafogigante.org/
mafagafogiga...@gmail.com
___
Python-ideas mailing list
Python-id
On 2016-11-12 12:18, João Matos wrote:> Hello,
>
> What I propose is not
> a = +5 (see the space between the = and + sign)
> but
> a =+ 5 (no space between the = and + sign, and there is a space between
> + and 5)
>
> Exactly the same notation (only reversed) as the current assignment
> operators.
Hello,
I understand that, but in my view a =- c and a = -c should not be same.
Maybe an ideia for Python 4.
Best regards,
JM
On 12-11-2016 20:19, Bernardo Sulzbach wrote:
On 2016-11-12 18:08, João Matos wrote:
a =- c is the same as a = c - a
This would break compatibility.
a =- c
is
Hi,
async/await syntax is a very nice recent feature, but there is something
that I miss for coroutines defined with async def, as compared to
generators. Coroutines represent an interesting mental model that goes
beyond only asynchronous IO, so that I play with them in REPL often. But
there is no
On other hand having builtin for making toy examples in interactive mode
looks very redundant.
On Sat, Nov 12, 2016 at 10:38 PM Ivan Levkivskyi
wrote:
> Hi,
>
> async/await syntax is a very nice recent feature, but there is something
> that I miss for coroutines defined with async def, as compar
I think there's a plan to add a run() function to asyncio, which would be
something akin to
def run(coro):
return get_event_loop().run_until_complete(coro)
(but perhaps with better cleanup).
Then you could start with `from asyncio import run` and from then on you'd
have your handy little fun
I think a stronger argument to reject this (even for Python 4, and even if
we could somehow get over the syntactic ambiguity) is that it's confusing.
`+=` and `=+` are just visually too close, and the distinction is not all
that intuitive. At least for `a += b` the expansion to `a = a + b` is a
sim
On Sat, Nov 12, 2016 at 11:41 AM, Ivan Levkivskyi
wrote:
> On 12 November 2016 at 20:27, David Mertz wrote:
>
>> I thought of the use of `.__getitem__()` in metaclasses in the typing
>> module. I feel like this use is more natural and more useful than that.
>> Should we someday need a slice gen
On Sat, Nov 12, 2016 at 11:10 AM, David Mertz wrote:
> +100
>
> I like this idea of giving `slice` a metaclass that defines a
> `.__getitem__()` allowing us to construct slices on the slice type itself.
>
> FWIW, this is exactly what pandas.IndexSlice does. E.g., from
> http://pandas.pydata.org/
The very common use case for creating slice objects is in Pandas and
similar libraries. Xarray certainly, or Blaze, to a lesser extent NumPy.
That said, it's very easy to define a suitable __getitem__, as Guido shows.
It's really a question simply of whether that object should be named
'slice' or
If we *do* want the name 'slice' as the spelling for the thing that can
either be called or indexed to create a slice object, we could probably use
some boilerplate like this:
In [1]: class Slice:
...: def __init__(self):
...: self.slice = slice
...: def __getitem__(self,
On Nov 12, 2016 5:46 PM, "David Mertz" wrote:
>
> If we *do* want the name 'slice' as the spelling for the thing that can
either be called or indexed to create a slice object, we could probably use
some boilerplate like this:
>
>> In [1]: class Slice:
>>...: def __init__(self):
>>...:
On Sat, Nov 12, 2016 at 5:46 PM, David Mertz wrote:
> If we *do* want the name 'slice' as the spelling for the thing that can
> either be called or indexed to create a slice object, we could probably use
> some boilerplate like this:
>
I can't stop you from doing that in your own session, but I
>
> But let's make str() of a slice more suggestive of actual slicing, and
> as a bonus, make slices easier to create too.
>
> str(slice(None, None, None)) => "slice[:]"
>
following all the later discussion, I'd like to come back to this initial
part of this thread:
An even briefer for for jus
Indeed. I mentioned up-thread that pandas names this IndexSlicer, so it
does exist. And maybe that's a perfectly fine spelling (users can always
give it a shorter name, like ndx)
On Nov 12, 2016 7:07 PM, "Guido van Rossum" wrote:
> On Sat, Nov 12, 2016 at 5:46 PM, David Mertz wrote:
>
>> If we
On 13 November 2016 at 02:57, David Mertz wrote:
> If recommend 'valued(foo)'. Without the final 'd' I think of "the value of
> foo" rather than "does foo have a value?" Obviously, the value of foo is
> just spelled 'foo' in Python, but it seems confusing.
>
> 'exists(foo)' is even more confusing
37 matches
Mail list logo
