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
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
> 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
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:
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
> 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 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
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
>
__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)] ==
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
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
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
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
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 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/typing-...@python.org/thread/SWAY6V7WZLVPGYQEMHXJROT2747OXSRX/
I think this would conflict with https:/
There's already a proposal. See
https://gist.github.com/MaggieMoss/c848cb3a581979f445d075c15629c950 and
https://mail.python.org/archives/list/typing-...@python.org/thread/SWAY6V7WZLVPGYQEMHXJROT2747OXSRX/
On Wed, Oct 7, 2020 at 9:50 AM Sebastian Noel Lübke
wrote:
> Hey,
> python 3.9 introduced
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
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 -- python-ideas@python.org
T
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
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
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, 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 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, 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 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
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 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
27 matches
Mail list logo
