I agree that itertools shouldn't be a collection of vaguely useful functions. I
proposed that one because I have needed this one many times, often used
str.join instead which comes at a greater cost than iterating pieces of string.
I didn't know about more-itertools library (which already has
On Wed, Dec 09, 2020 at 12:05:17PM -, Mathew Elman wrote:
> Steven D'Aprano wrote:
> > On Tue, Dec 08, 2020 at 11:46:59AM -, Mathew Elman wrote:
> > > I would like to propose adding lazy types for casting
> > > builtins in a
> > > lazy fashion. e.g. lazy_tuple which creates a reference to
On 12/9/20 12:39 PM, Steven D'Aprano wrote:
I am against changing this behaviour before anyone has identified
*actual bugs* in code caused by it, and before anyone has addressed the
use-case MAL gave for the current behaviour.
+1
--
~Ethan~
___
On Wed, Dec 09, 2020 at 01:56:01PM +0200, Serhiy Storchaka wrote:
> Thank you for good explanation of the problem.
I'm sorry Serhiy, I disagree that this has been a "good explanation of
the problem".
Gregory has not identified any actual bugs caused by this. The only
problem he has identified
On Wed, 9 Dec 2020 at 09:27, Mathew Elman wrote:
> I agree that if you are using them as iterables, then the type is usually
> not important because you are treating their type as just iter-able. The
> lazy iterable would more or less just be the same as passing in
> `iter(sequence)`.
>
> This
I understand the concept, but no real use case comes to my mind, and
certainly I personally have not needed this. Itertools is kept extremely
minimal by design, containing only a small set of orthogonal primitives.
The recipes in its docs contain others, as does more-itertools. This feels
like
On Wed, Dec 9, 2020 at 11:08 AM Evpok Padding
wrote:
> Hey,
>
> You can always do `itertools.chain.from_iterable(zip(iterable,
> itertools.repeat(sep)))` but I agree that it is verbose.
>
> Cheers,
>
> E
>
Worth noting that implementation puts a terminal sep on the end of the
result, which
Hey,
You can always do `itertools.chain.from_iterable(zip(iterable,
itertools.repeat(sep)))` but I agree that it is verbose.
Cheers,
E
On Wed, 9 Dec 2020 at 04:16, wrote:
> Hi
>
> I like using itertools for creating long strings while not paying the cost
> of intermediate strings (by
On Thu, Dec 10, 2020 at 12:38 AM sam bland wrote:
>
> In response to the additional work required to convert the new python
> dataclass using the json encoder I propose an __encode__ method that will be
> included in the default dataclass attributes. This would then be picked up by
> the
Maybe you could start by writing this as a separate decorator, to be
applied on top of the data class decorator?
On Wed, Dec 9, 2020 at 05:38 sam bland wrote:
> In response to the additional work required to convert the new python
> dataclass using the json encoder I propose an __encode__
Stestagg wrote:
> That makes sense, so these are kind of 'views' over a sequence, but ones
> that implement a copy-on-write when the underlying object is modified in
> any way?
yes, a lazy sequence type would be exactly that, that is a nice way of putting
it
> I can see this being super
That makes sense, so these are kind of 'views' over a sequence, but ones
that implement a copy-on-write when the underlying object is modified in
any way?
I can see this being super hard/impossible to implement reliably, but would
be a pretty nice addition if it can be done.
On Wed, Dec 9, 2020
In response to the additional work required to convert the new python
dataclass using the json encoder I propose an __encode__ method that will
be included in the default dataclass attributes. This would then be picked
up by the default json encoder and called to encode the object. Using a
common
I agree that if you are using them as iterables, then the type is usually not
important because you are treating their type as just iter-able. The lazy
iterable would more or less just be the same as passing in `iter(sequence)`.
This is for other use cases where the use of the object is
On Wed, Dec 9, 2020 at 12:05 PM Mathew Elman wrote:
> Steven D'Aprano wrote:
> > On Tue, Dec 08, 2020 at 11:46:59AM -, Mathew Elman wrote:
> > > I would like to propose adding lazy types for casting
> > > builtins in a
> > > lazy fashion. e.g. lazy_tuple which creates a reference to the
> >
Steven D'Aprano wrote:
> On Tue, Dec 08, 2020 at 11:46:59AM -, Mathew Elman wrote:
> > I would like to propose adding lazy types for casting
> > builtins in a
> > lazy fashion. e.g. lazy_tuple which creates a reference to the
> > source iterable and a morally immutable sequence but only
08.12.20 21:47, Gregory Szorc пише:
> PyOxidizer's pure Rust implementation of a meta path importer
> (https://pyoxidizer.readthedocs.io/en/stable/oxidized_importer_oxidized_finder.html)
> has been surprisingly effective at finding corner cases and behavior
> quirks in Python's importing
On Wed, Dec 09, 2020 at 11:17:19AM +1100, Steven D'Aprano wrote:
> > "__init__ as a substring - as weird as that may be - should be allowed.
> > This is because it is only the exact "__init__" filename that is treated
> > specially by the filename resolver.
>
> Okay, that's what I thought you
18 matches
Mail list logo
