On Thu, Dec 12, 2019 at 4:37 PM Eric V. Smith wrote:
> On 12/12/2019 8:50 AM, Arthur Pastel wrote:
>
> On 12/12/2019 8:07 AM, Arthur Pastel wrote:
>>
>> On Thu, Dec 12, 2019 at 2:03 AM Eric V. Smith wrote:
>>>
On 12/11/2019 6:36 PM, Arthur Pastel wrote:
>> Add an extra hidden attribute
On Fri, Dec 13, 2019 at 09:24:20AM +0200, Serhiy Storchaka wrote:
> 12.12.19 03:22, Stephen J. Turnbull пише:
> >I would prefer that it not be implemented at all, but
> >if it is implemented, its behavior should respect the intuition of the
> >majority of those who want it, which seems to me to be
On Fri, Dec 13, 2019 at 07:41:59AM -0400, Juancarlo Añez wrote:
> It was my omission in the OP that *default=* should be explicit, instead of
> an implicit *None.* The consistent semantics are those of *dict.get()* and
> *dict.pop()*.
py> {1:'a'}.get(999) is None
True
--
Steven
__
I think the simpler route to go there (allow the use of `self.attr=` until
after ___post_init__ is run is simply
to add another flag attribute, that tells wether "initialization is over",
and respect that flag
in the added `__setattr__`. The hook calling `__post_init__` would then set
that flag aft
>
> I think the simpler route to go there (allow the use of `self.attr=` until
> after ___post_init__ is run is simply
> to add another flag attribute, that tells wether "initialization is over",
> and respect that flag
>
We discussed this just before and having an extra instance attribute was
qu
[Steven D'Aprano]
...
> I don't recall who wants a version of first that raises,
I do, for one. But I want both (raising and non-raising) behaviors
at times, and the more-itertools version supplies both.
> or when that would be useful.
There is no practical way to assert than an iterable isn't
On Thu, Dec 12, 2019 at 11:35 PM Serhiy Storchaka
wrote:
> 11.12.19 10:45, Steven D'Aprano пише:
> > The thing is, we're fooled by the close similarity of iteration over
> > iterators and other iterables (sequences and containers). Destructive
> > iteration and non-destructive iteration is a big
[Andrew Barnert ]
> Sure, but you can also explain first just fine by saying it returns
> the first thing in its argument, and that will stick as well.
We have different meanings for "fine" in this context. "The first
thing in its argument" is English prose, and prone to
misunderstanding. I'm ab
> On 13 Dec 2019, at 14:57, Arthur Pastel wrote:
>
>
>> I think the simpler route to go there (allow the use of `self.attr=` until
>> after ___post_init__ is run is simply
>> to add another flag attribute, that tells wether "initialization is over",
>> and respect that flag
>
>
> We discu
On 14/12/19 6:44 am, Christopher Barker wrote:
I think we all agree that it does not belong in
__builtins__,
Do we? I'm not convinced. We already have all() and any()
in builtins, which are similar in that they operate on
iterators or iterables.
--
Greg
[Christopher Barker]
>> I think we all agree that it does not belong in __builtins__,
[Greg Ewing]
> Do we?
Nobody yet has argued in favor of it - or even suggested it.
> I'm not convinced.
And that remains true even now ;-) The new part here is that yours is
the first message to mention it th
On Fri, 13 Dec 2019 at 22:47, Tim Peters wrote:
>
> [Christopher Barker]
> >> I think we all agree that it does not belong in __builtins__,
>
> [Greg Ewing]
> > Do we?
>
> Nobody yet has argued in favor of it - or even suggested it.
>
> > I'm not convinced.
>
> And that remains true even now ;-)
Would the builtins import look like this:
if not hasattr(__builtins__, 'first'):
from more_itertools.more import first
Or this:
import sys
if sys.version_info[:2] < (3,9):
from more_itertools.more import first
Having the same argspec as more_itertools.more.first would get us a free
back
On Fri, Dec 13, 2019 at 06:27:41PM -0500, Wes Turner wrote:
> Would the builtins import look like this:
>
> if not hasattr(__builtins__, 'first'):
Not that.
`__builtins__` is a private CPython implementation detail, so the above
is always wrong in user code. Better:
import builtins
try:
b
14 matches
Mail list logo
