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 mea
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 mechanisms
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 popul
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
> > >
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 specific
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 _
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 a
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 hard/imp
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__ method
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 defaul
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 eventual
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 isn't
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 so
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 is
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 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~
___
Pyth
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
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 an
18 matches
Mail list logo
