On Sat, Mar 14, 2020 at 1:12 PM Inada Naoki wrote:
> I'm sorry, I meant (a) looks more consistent with PEP 560.
>
Sorry again, I meant PEP 585, not PEP 560 as Guido explained already.
--
Inada Naoki
___
Python-ideas mailing list --
On Sat, Mar 14, 2020 at 11:24 AM Inada Naoki wrote:
>
[snip]
> a) Add `|` to all types.
> b) Support it only statically (`from __future__ import annotations`).
>
[snip]
> But (b) seems more consistent with PEP 560.
>
I'm sorry, I meant (a) looks more consistent with PEP 560.
--
Inada Naoki
I think we should try to get PEP 604 accepted, with the runtime option (a),
since that's the way we've gone already.
PEP 604 proposes the right syntax, and I think mostly the right semantics
(one could quibble about whether isinstance()/issubclass() ought to accept
unions). Unfortunately it does
First of all, I am not so happy about typing is increasing
Python runtime complexity.
TypeScript is the most successful language with gradual typing.
It has almost zero-cost about typing. It doesn't make JavaScript
runtime complex. I hoped Python goes in same way.
But Python went the different
> If I could go back to 1995 or thereabouts when Python was first
> starting, I would make a clear distinction between scalar and vector
> operations, like Julia does.
>
> Borrowing Julia's syntax:
>
> a == b # compare a to b, returns True or False
> a .== b # elementwise comparison
>
>
These are coming in fine because they are not handled by Mailman's
filtering rules. And the reason for the holds is they are being flagged for
" Message has implicit destination".
On Fri, Mar 13, 2020 at 8:06 AM Marco Sulla <
python-id...@marco.sulla.e4ward.com> wrote:
> Well, probably it
Support for "| None" would be great to have.
+1.
https://github.com/python/peps/blob/master/pep-0604.rst
On Fri, Mar 13, 2020, 9:36 AM Chris Angelico wrote:
> On Sat, Mar 14, 2020 at 12:24 AM Noah Peter May wrote:
> >
> > Hello everyone,
> >
> > I'm not certain if this has been brought up
On Sat, Mar 14, 2020 at 12:24 AM Noah Peter May wrote:
>
> Hello everyone,
>
> I'm not certain if this has been brought up before, but I felt like bringing
> it to the table anyway.
>
> As the title says, it would be convenient to represent a union type with the
> or operator.
>
Yep! You're
Hello everyone,
I'm not certain if this has been brought up before, but I felt like
bringing it to the table anyway.
As the title says, it would be convenient to represent a union type with
the or operator.
While typing extra characters is not the end of the world, having a more
concise
On Thu, Mar 12, 2020 at 09:08:57AM -0700, Christopher Barker via Python-ideas
wrote:
> On Thu, Mar 12, 2020 at 5:50 AM Marco Sulla via Python-ideas <
> python-ideas@python.org> wrote:
>
> > Actually, this is the behaviour of ndarray with any dtype. And IMHO
> > ithis is quite terrible?
>
>
On Fri, Mar 13, 2020 at 7:10 PM Steven D'Aprano wrote:
>
> On Thu, Mar 12, 2020 at 03:02:28PM -, Eric Wieser wrote:
>
> > TL;DR: should we make `del x` an expression that returns the value of `x`.
>
> What would `del x, y, z` return?
>
A tuple of the former values of x, y, and z. I don't see
On 13/03/20 12:30 pm, Marco Sulla via Python-ideas wrote:
As you can see, Thing(abcd) has the same id of Thing(ab). So what Eric
Wieser wanted is already implemented in Python, for temporary objects.
This is probably an accident. It's not really re-using an object,
it's just that the object
On Thu, Mar 12, 2020 at 03:02:28PM -, Eric Wieser wrote:
> TL;DR: should we make `del x` an expression that returns the value of `x`.
What would `del x, y, z` return?
--
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To
I've realized that I've actually seen code use a trick to enable exactly this
optimization in the past, without needing language extensions (although I don't
remember where). Taking two of my motivating examples from elsewhere in the
thread:
bc = b*c
a = bc + d
f =
On 13/03/20 4:02 am, Eric Wieser wrote:
For consistency, `x = (del foo.attr)` and `x = (del foo[i])` could
also become legal expressions, and `__delete__`, `__delattr__`, and
`__delitem__` would now have return values. Existing types would be
free to continue to return `None`.
That would mean
15 matches
Mail list logo
