On Tue, Oct 6, 2020, at 23:13, Guido van Rossum wrote:
> A. New syntax is way too high a bar for a questionable feature. Classes
> full of static or class methods were a pattern at my last employer and
> it was unpleasant to work with. (Others at the company agreed but it
> was too late to chang
07.10.20 06:04, Guido van Rossum пише:
> Ironically, complex numbers have a `__float__`
> method that always fails, and floats don't have a `__complex__` method
> but complex(x) succeeds if x is a float...
I wonder why not remove complex.__float__ (and complex.__int__,
complex.__floordiv__, etc)?
On Tue, Oct 06, 2020 at 10:25:01PM -0700, Guido van Rossum wrote:
> On Tue, Oct 6, 2020 at 18:16 Steven D'Aprano wrote:
>
> > For `__advance__` to be an official Python protocol, it would almost
> > certainly have to be of use for *general purpose iterators*, not just
> > specialised ones -- and
On Wed, Oct 07, 2020 at 01:59:24PM +1100, Chris Angelico wrote:
> On Wed, Oct 7, 2020 at 1:46 PM Steven D'Aprano wrote:
> > > Recall that we already have literal expressions such as
> > > >>> [1, 2, 3] # List literal
> > > >>> (1, 2, 3) # Tuple literal
> > > >>> {1, 2, 3} # Set literal
On Wed, Oct 7, 2020 at 9:20 PM Steven D'Aprano wrote:
>
> On Wed, Oct 07, 2020 at 01:59:24PM +1100, Chris Angelico wrote:
> > Complex numbers and frozen sets don't technically have literals, but
> > thanks to compiler magic, they can appear to. (Also, raw string
> > literals are a thing, but in th
On Wed, Sep 30, 2020 at 11:03:28AM -0300, Sebastian Kreft wrote:
> Have you considered using matrix[row=3], matrix[col=3]? In that case it
> would be a keyword only access. What advantages do you see with your
> current API?
Yes I have considered it.
One possible advantage is that with axis='row
On Wed, Oct 7, 2020, 3:43 AM Serhiy Storchaka wrote:
> 07.10.20 06:04, Guido van Rossum пише:
> > Ironically, complex numbers have a `__float__`
> > method that always fails, and floats don't have a `__complex__` method
> > but complex(x) succeeds if x is a float...
>
> I wonder why not remove co
On Wed, 7 Oct 2020 at 11:39, Steven D'Aprano wrote:
> One possible advantage is that with axis='row', I don't have to
> worry about, or test for, mutually exclusive keywords:
>
> matrix[row=2, col=3]
> # can't get both a row and a column at the same time
Well, they are not mutually exclus
Hi all,
Something that's on many of our wishlists is support for variadic generics.
Here's a first draft of a PEP detailing how they might work.
https://docs.google.com/document/d/1oXWyAtnv0-pbyJud8H5wkpIk8aajbkX-leJ8JXsE318/edit
(Attached is also an HTML render of the RST for easier reading.)
T
Hey,
python 3.9 introduced the | operator for union types. it would be nice
to have something like that for optional types. maybe like
name: ? int
or
name: int ?
best regards
Sebastian Lübke
___
Python-ideas mailing list -- [email protected]
T
On Wed, Oct 7, 2020 at 11:46 PM Matthew Rahtz via Python-ideas
wrote:
>
> Hi all,
>
> Something that's on many of our wishlists is support for variadic generics.
> Here's a first draft of a PEP detailing how they might work.
>
Does the "many" there include any core devs who would sponsor your
PE
There's already a proposal. See
https://gist.github.com/MaggieMoss/c848cb3a581979f445d075c15629c950 and
https://mail.python.org/archives/list/[email protected]/thread/SWAY6V7WZLVPGYQEMHXJROT2747OXSRX/
On Wed, Oct 7, 2020 at 9:50 AM Sebastian Noel Lübke
wrote:
> Hey,
> python 3.9 introduced
On 10/7/2020 10:29 AM, Sebastian Kreft wrote:
There's already a proposal. See
https://gist.github.com/MaggieMoss/c848cb3a581979f445d075c15629c950
and
https://mail.python.org/archives/list/[email protected]/thread/SWAY6V7WZLVPGYQEMHXJROT2747OXSRX/
I think this would conflict with https:/
On Wed, Oct 7, 2020 at 2:13 AM Steven D'Aprano wrote:
> [about `__setstate__`]
> (Aside: I'm actually rather surprised that it's exposed as a dunder.)
>
It's used for pickling. Someone long ago must have complained that list
iterators weren't picklable, and we complied.
I'm not sure that either
On Wed, Oct 7, 2020 at 12:41 AM Serhiy Storchaka
wrote:
> 07.10.20 06:04, Guido van Rossum пише:
> > Ironically, complex numbers have a `__float__`
> > method that always fails, and floats don't have a `__complex__` method
> > but complex(x) succeeds if x is a float...
>
> I wonder why not remove
If this receives positive feedback on typing-sig I would definitely sponsor
it. But I'd first like to have the discussion there (and the time to read
it).
(FWIW I would prefer the discussion to happen on typing-sig, not
python-ideas.)
On Wed, Oct 7, 2020 at 7:04 AM Chris Angelico wrote:
> On We
Could you explain how Maggie's proposal (writing 'int?') would conflict
with Pablo's proposal? IIUC Maggie's proposal would require 'int?' to
become a valid expression.
(As I expressed in the typing-sig thread, I'm lukewarm about 'int?' because
we will have 'int | None'. The same reasoning applies
On 10/7/2020 1:18 PM, Guido van Rossum wrote:
Could you explain how Maggie's proposal (writing 'int?') would
conflict with Pablo's proposal? IIUC Maggie's proposal would require
'int?' to become a valid expression.
(As I expressed in the typing-sig thread, I'm lukewarm about 'int?'
because we
__setstate__, a generic __getstate__, listiter.__setstate__, (typed) arrays
and memoryviews
```python
import collections.abc
from array import array
list_ = [0, 10, 20]
assert [list_[i] for i in range(len(list_))] == [0, 10, 20]
iterator = iter(list_)
assert [next(iterator) for n in range(2)] ==
I have also thought it would be nice to have a 'prev()' method to
compliment 'next()'
On Wed, Oct 7, 2020, 3:24 PM Wes Turner wrote:
> __setstate__, a generic __getstate__, listiter.__setstate__, (typed)
> arrays and memoryviews
>
> ```python
> import collections.abc
> from array import array
>
On 7/10/20 11:05 pm, Matthew Rahtz via Python-ideas wrote:
Something that's on many of our wishlists is support for variadic
generics. Here's a first draft of a PEP detailing how they might work.
https://docs.google.com/document/d/1oXWyAtnv0-pbyJud8H5wkpIk8aajbkX-leJ8JXsE318/edit
Generally lo
> For `__advance__` to be an official Python protocol, it would almost
> certainly have to be of use for *general purpose iterators*, not just
> specialised ones -- and probably not *hypothetical* iterators which may
> not even exist. Do you have concrete examples of your skip list and tree
> itera
On Wed, Oct 7, 2020 at 6:24 PM Caleb Donovick
wrote:
> Itertools.count was an example (hence the use of "e.g.") of an iterator
> which can be efficiently
> advanced without producing intermediate state. Clearly anyone can advance
> it manually.
> My point is that an iterator may have an efficient
Addendum to my example:
If my get_tcp_header was made a class it would also be possible for it to
support the `__advance__` protocol:
```
class TCPHeaderIter(Iterator[TCPHeader]):
def __init__(self, stream: Iterator[Byte]):
self.stream = stream
def __next__(self) -> TCPHeader:
> This is BARELY more plausible as a real-world case. Throwing away 28
bytes with a bunch of next() calls is completely trivial in time. A case
where some implementation could conceivably save measurable time would
require skipping 100s of thousands or millions of next() calls... and
probably cal
Yes on systems language. But also, why read IP packets as a bytes iterator?
Reading the whole 64k into a bytes object is trivial memory, and then it's
random access anyway.
I was trying to construct a scenario where this could be faster. Maybe the
network is VERY slow and the whole bigger isn't av
On Wed, Oct 7, 2020 at 12:06 AM Random832 wrote:
> I think a metaclass [well, "pseudo-metaclass", to use a term I made up for
> a metaclass that is not a subclass of type and/or does not return an
> instance of type] would be better in this case because the resulting object
> should not be a type
27 matches
Mail list logo
