On Fri, Mar 8, 2019 at 11:25 AM João Matos wrote:
> I've just read your PEP 585 draft and have some questions.
> When you say
> "
>
> Like the merge operator and list concatenation, the difference operator
> requires both operands to be dicts, while the augmented version allows any
> iterable of
On Sat, Mar 09, 2019 at 05:19:50PM +1300, Greg Ewing wrote:
> If we were going to add a syntax for abbreviating lambdas, I would
> rather see something more generally useful, e.g.
>
>x -> x.method()
>
> as an abbrevation for
>
>lambda x: x.method()
Cocnut does this!
If we were going to add a syntax for abbreviating lambdas, I would
rather see something more generally useful, e.g.
x -> x.method()
as an abbrevation for
lambda x: x.method()
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
On Fri, Mar 08, 2019 at 03:43:10PM -0800, Chris Barker - NOAA Federal via
Python-ideas wrote:
> >
> > Rather than using map in this way, I would recommend a list comprehension:
>
> Exactly! I really don’t get why folks want to use map() so much when
> the comprehension syntax is often cleaner
On Fri, Mar 08, 2019 at 10:16:02PM +0100, Martin Bammer wrote:
> Hi,
>
> what about the idea that the interpreter preallocates and
> preinitializes the tuples and dicts for function calls where possible
> when loading a module?
That's an implementation detail. CPython may or may not use tuples
Guido van Rossum wrote:
I guess everybody's high school math(s) class was different. I don't
ever recall seeing + and * for boolean OR/AND; we used ∧ and ∨.
Boolean algebra was only touched on briefly in my high school
years. I can't remember exactly what notation was used, but it
definitely
Martin Bammer wrote:
what about the idea that the interpreter preallocates and preinitializes
the tuples and dicts for function calls where possible when loading a module?
This would not be thread-safe. Locking would be needed around uses
of the preallocated objects, and that might take away
I'm really old ... I remember thinking how clever attrgetter() was when it
was after to Python 2.4.
On Fri, Mar 8, 2019, 7:51 PM David Mertz wrote:
> You could use the time machine:
> https://docs.python.org/3/library/operator.html
>
> On Fri, Mar 8, 2019, 11:57 AM Samuel Li wrote:
>
>> Don't
You could use the time machine:
https://docs.python.org/3/library/operator.html
On Fri, Mar 8, 2019, 11:57 AM Samuel Li wrote:
> Don't know if this has been suggested before. Instead of writing something
> like
>
> >>> map(lambda x: x.upper(), ['a', 'b', 'c'])
>
> I suggest this syntax:
> >>>
francismb wrote:
It is may be how now it is, but means that it
needs to be always like this?
Yes, as long as you care about not breaking existing code. While
you may be in the habit of always leaving a space between '<'
and '-', others may have different styles. Do you really want
to tell them
On Fri, Mar 8, 2019 at 3:33 PM Greg Ewing
wrote:
> Guido van Rossum wrote:
> > I guess this explains the behavior of removing results <= 0; it makes
> > sense as multiset subtraction, since in a multiset a negative count
> > makes little sense. (Though the name Counter certainly doesn't seem to
Samuel Li wrote:
.attribute -> lambda x: x.attribute
.method(*args, **kwargs) -> lambda x: x.method(*args, **kwargs)
Leading dots can be hard to spot when reading code.
Also, I'm not convinced that use cases for this are frequent enough
to warrant new syntax.
Something akin to this can
>
> Rather than using map in this way, I would recommend a list comprehension:
Exactly! I really don’t get why folks want to use map() so much when
the comprehension syntax is often cleaner and easier. It was added for
a reason :-)
-CHB
___
Guido van Rossum wrote:
I guess this explains the behavior of removing results <= 0; it makes
sense as multiset subtraction, since in a multiset a negative count
makes little sense. (Though the name Counter certainly doesn't seem to
imply multiset.)
It doesn't even behave consistently as a
I just realized it doesn't work properly if the method takes some arguments,
so you would actually have to use two different magic objects or
something like that,
but I guess the point is clear.
Am 08.03.2019 um 23:08 schrieb Benedikt Werner:
This was actually quite interesting to code, thanks
On Sat, Mar 9, 2019 at 9:09 AM Benedikt Werner
<1benediktwer...@gmail.com> wrote:
>
> This was actually quite interesting to code, thanks for the idea Jonathan!
>
> You can even support "magic.upper()" and "magic.real" at the same time
> as well as "magic[0]":
>
> class MagicClass:
> NO_ARG =
This was actually quite interesting to code, thanks for the idea Jonathan!
You can even support "magic.upper()" and "magic.real" at the same time
as well as "magic[0]":
class MagicClass:
NO_ARG = object()
@staticmethod
def __getattribute__(attr):
def
Hi,
what about the idea that the interpreter preallocates and preinitializes
the
tuples and dicts for function calls where possible when loading a module?
Before calling a function then the interpreter would just need to update
the
items which are dynamic and then call the function.
Some
Hi Oleg,
On 3/3/19 4:06 PM, Oleg Broytman wrote:
>You cannot create operator ``<-`` because it's currently valid
> syntax:
>
> 3 <- 2
>
> is equivalent to
>
> 3 < -2
Yes, its a good point, but for me it's not the same '<-' and '< -' due
(n)blanks in between. It is may be how now it
Hi fhsxfhsx,
On 3/4/19 5:56 AM, fhsxfhsx wrote:
> Could you explain why do you prefer this operator than `+`?
Well yes, because of the asymmetric operation done underneath (merging
dicts is not symmetric). The asymmetry is explicit in the symbol. Not
implicit from the documentation you need to
Hi Calvin,
On 3/4/19 2:09 PM, Calvin Spealman wrote:
> I don't like the idea of arrows in both directions when you can just swap
> the operands instead
Well you saw just to examples of contexts (dict and bool). Could you
imagine a context where swapping cannot be done and thus there is a need
for
Hi Todd,
On 3/4/19 2:18 PM, Todd wrote:
> What is the operator supposed to do?
this should depend on what you want to do, the type, the context.
How to you would want to use it ? do you see a context where the symbols
make meaning to you?
Thanks in advance!
--francis
On 2019-03-08 16:55, Guido van Rossum wrote:
[snip]
If we were to use "|" and "&" for dict "union" and "intersection", the
mutual distributive properties will hold.
Since "|" (especially "|=") *is* suitable for "update", I think we
should reserve "+" for some future commutative
On Fri, Mar 8, 2019 at 8:57 AM Samuel Li wrote:
> Don't know if this has been suggested before. Instead of writing something
> like
>
> >>> map(lambda x: x.upper(), ['a', 'b', 'c'])
>
> I suggest this syntax:
> >>> map(.upper(), ['a', 'b', 'c'])
>
Do note you get the same results with
Hi Samuel
Interesting idea, and certainly addresses a real problem, if you find
yourself creating lots of lambda expressions. But in my first opinion,
not so useful that it merits adding to the syntax of Python.
(Even if I never use it, it puts an extra burden on me when scanning
Python code.
Don't know if this has been suggested before. Instead of writing something
like
>>> map(lambda x: x.upper(), ['a', 'b', 'c'])
I suggest this syntax:
>>> map(.upper(), ['a', 'b', 'c'])
This would also work for attributes:
>>> map(.real, [1j, 2, 3+4j])
Internally, this would require translating
On Thu, Mar 7, 2019 at 9:12 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Ka-Ping Yee writes:
> > On Wed, Mar 6, 2019 at 4:01 PM Chris Angelico wrote:
>
> > > But adding dictionaries is fundamentally *useful*. It is expressive.
> >
> > It is useful. It's just that +
Hello,
I've just read your PEP 585 draft and have some questions.
When you say
"
Like the merge operator and list concatenation, the difference
operator requires both operands to be dicts, while the augmented
version allows any iterable of keys.
> Counter also uses +/__add__ for a similar behavior.
>
> >>> c = Counter(a=3, b=1)
> >>> d = Counter(a=1, b=2)
> >>> c + d # add two counters together: c[x] + d[x]
> Counter({'a': 4, 'b': 3})
>
> At first I worried that changing base dict would cause confusion for the
>
I've just learnt something new. Look at
>>> from operator import iadd
>>> lst = [1, 2, 3]
>>> iadd(lst, 'hi')
[1, 2, 3, 'h', 'i']
>>> lst
[1, 2, 3, 'h', 'i']
This shows that the proposals dict.flow_update and dict.__iadd__ are
basically the same. (I think this is quite
30 matches
Mail list logo
