On Wed, Dec 11, 2019 at 05:20:13PM +1100, Chris Angelico wrote:
> On Wed, Dec 11, 2019 at 5:14 PM Steven D'Aprano wrote:
> >
> > On Tue, Dec 10, 2019 at 07:21:13PM -0600, Tim Peters wrote:
> > > While the meaning of `first()` is clear for any iterable argument.
> >
> > Sorry Tim, I have to disagre
On Wed, 11 Dec 2019 at 01:15, Tim Peters wrote:
> It's fair enough, although rather than "wrong" I'd say more that it's
> inappropriately applying design principles that work well in most of
> Python's libraries to an area where they don't. The very fact that
> half the itertools docs are devoted
On Wed, Dec 11, 2019 at 7:46 PM Steven D'Aprano wrote:
> There's a difference between the first day of *the rest* of your life
> and the first day of your life.
>
> There's a difference between the first item of *the rest* of the
> iterator and the first item of the iterator.
>
> Cliches and plati
Consider these two examples:
>>> {0} == {0.0} == {False}
True
>>> hash(0) == hash(0.0) == hash(False)
True
>>> 0.0 in {False}
True
>>> class mystr(str): pass
>>> 'hi' in {mystr('hi')}
True
The original poster want a way to obtain the actual object that is in the
set, rather than just a truth val
On 11/12/19 9:45 pm, Steven D'Aprano wrote:
But that's not what happens if you call `first(iterable)` multiple
times. Calling it once is fine, but people will call it multiple times.
Would it help if it were called "one" instead of "first"?
--
Greg
_
On 2019-12-11 7:40 a.m., Jonathan Fine wrote:
Consider these two examples:
>>> {0} == {0.0} == {False}
True
>>> hash(0) == hash(0.0) == hash(False)
True
>>> 0.0 in {False}
True
>>> class mystr(str): pass
>>> 'hi' in {mystr('hi')}
True
The original poster want a way to obtain the actual objec
On Thu, Dec 12, 2019 at 12:53:26AM +1300, Greg Ewing wrote:
> On 11/12/19 9:45 pm, Steven D'Aprano wrote:
> >But that's not what happens if you call `first(iterable)` multiple
> >times. Calling it once is fine, but people will call it multiple times.
>
> Would it help if it were called "one" inste
I think a solution nobody has proposed in this thread is relaxing the next
builtin, so it calls iter() on the argument when it doesn't implement the
iterator protocol. That would make next([1, 2]) == 1, and also make next([],
"missing") == "missing". After that all that is needed is educating the
u
When creating frozen dataclasses, attribute initialization must be done using
`object.__setattr__()` it would be nice to allow attribute assignment in the
`__init__` and `__post_init__`.
Currently we have to do this :
```python
@dataclasses.dataclass(frozen=True)
class Person:
name: str
On Dec 11, 2019, at 03:57, Greg Ewing wrote:
>
> On 11/12/19 9:45 pm, Steven D'Aprano wrote:
>> But that's not what happens if you call `first(iterable)` multiple
>> times. Calling it once is fine, but people will call it multiple times.
>
> Would it help if it were called "one" instead of "fir
> On Dec 11, 2019, at 07:43, Daniel Moisset wrote:
> I think a solution nobody has proposed in this thread is relaxing the next
> builtin, so it calls iter() on the argument when it doesn't implement the
> iterator protocol. That would make next([1, 2]) == 1, and also make next([],
> "missing")
[Steven D'Aprano ]
> It wasn't :-) but we're talking about adding a function to **itertools**
> not "container tools", one which will behave subtly different with
> containers and iterators. Your use-case ("first item in a container") is
> not the same as the semantics "next element of an iterator"
On Dec 11, 2019, at 08:56, Arthur Pastel wrote:
>
> When creating frozen dataclasses, attribute initialization must be done
> using `object.__setattr__()` it would be nice to allow attribute assignment
> in the `__init__` and `__post_init__`.
But how would you implement that?
Frozen means th
On Tue, Dec 10, 2019 at 1:50 PM Tim Peters wrote:
> [Brett Cannon ]
> > Thinking out loud here...
> >
> > What idiom are we trying to replace with one that's more obviously and
> whose
> > semantics are easy to grasp?
>
> For me, most of the time, it's to have an obvious, uniform way to
> spell "
On 12/11/2019 1:23 PM, Andrew Barnert via Python-ideas wrote:
On Dec 11, 2019, at 08:56, Arthur Pastel wrote:
When creating frozen dataclasses, attribute initialization must be done using
`object.__setattr__()` it would be nice to allow attribute assignment in the
`__init__` and `__post_init
On 12/12/19 4:39 am, Daniel Moisset wrote:
I think a solution nobody has proposed in this thread is relaxing the
next builtin, so it calls iter() on the argument when it doesn't
implement the iterator protocol.
> Do you think this fails to cover the > original problems in any way?
It would sti
[]Brett Cannon ]
> ...
> Sorry, "needed" was too strong of a word. It's more about justification for
> including in the stdlib and deciding to support it for a decade or more
> versus the answer we give for simple one-liners of "put in your personal
> toolbox if you don't want to type it out every
> I agree with Andrew: it's a great idea, but I couldn't come up with a
> way to implement it, so I followed attrs lead instead. Maybe someone can
> come up with a good way to implement it
It seems like this could be solved if a general way could be created to
allow dataclasses to handle descript
bah, I forgot the underscore in the setter. Corrected for clarity:
@dataclasses.dataclass(frozen=True)
class Person:
name: str
surname: str
fullname: str = dataclasses.field(property=True) # fullname is now a
field descriptor
@fullname.getter
def fullname_getter(self):
> If dataclass handled freezeable types (the objects are mutable until you call
> freeze,
> after which they’re not), this would be easy (frozen now just means
> freezable, plus freeze
> is called by the generated __init__ right after the __post_init__). But it
> doesn’t,
> because freezing is c
On Dec 11, 2019, at 15:10, Ricky Teachey wrote:
>
>
> bah, I forgot the underscore in the setter. Corrected for clarity:
>
> @dataclasses.dataclass(frozen=True)
> class Person:
> name: str
> surname: str
> fullname: str = dataclasses.field(property=True) # fullname is now a
> fie
On Dec 11, 2019, at 15:40, Arthur Pastel wrote:
>
>> If dataclass handled freezeable types (the objects are mutable until you
>> call freeze,
>> after which they’re not), this would be easy (frozen now just means
>> freezable, plus freeze
>> is called by the generated __init__ right after the _
On 12/11/2019 6:36 PM, Arthur Pastel wrote:
If dataclass handled freezeable types (the objects are mutable until you call
freeze,
after which they’re not), this would be easy (frozen now just means freezable,
plus freeze
is called by the generated __init__ right after the __post_init__). But it
Otherwise, maybe it could be possible to rewrite assignment done in
__post_init__ . However, I'm not sure that it will be generic enough.
Arthur Pastel,
On Thu, Dec 12, 2019 at 1:10 AM Andrew Barnert wrote:
> On Dec 11, 2019, at 15:40, Arthur Pastel wrote:
> >
> >> If dataclass handled freeze
Chris Angelico writes:
> And ordered vs unordered is also a big difference. Should first()
> raise an error with sets because there's no real concept of "the first
> element"?
Probably not. I would prefer that it not be implemented at all, but
if it is implemented, its behavior should respect
Greg Ewing writes:
> On 11/12/19 9:45 pm, Steven D'Aprano wrote:
> > But that's not what happens if you call `first(iterable)` multiple
> > times. Calling it once is fine, but people will call it multiple times.
>
> Would it help if it were called "one" instead of "first"?
That would be my p
>> Does that mean that first() and next() are undefined for sets?
[Stephen J. Turnbull ]
> first() is undefined. next() is defined by reference to iterating
> over the set (that's why I don't have a problem with iterating over a
> set).
Every suggestion here so far has satisfied that, if S is a
Stephen J. Turnbull wrote:
> Worse, running the same program again with the *same* set can change
> which element is first, I believe.
Yes, this is correct. For example, if you had a minimal Python file named
"some_set.py" with only the following:
```
s = set('abcdefg')
```
and then run somethin
Tim Peters writes:
> Every suggestion here so far has satisfied that, if S is a non-empty set,
>
> assert next(iter(S)) is first(S)
>
> succeeds. That is, `first()` is _defined_ by reference to iteration
> order. It's "the first" in that order (hence the name).
The problem I'm conce
[Tim]
>> Every suggestion here so far has satisfied that, if S is a non-empty set,
>>
>> assert next(iter(S)) is first(S)
>>
>> succeeds. That is, `first()` is _defined_ by reference to iteration
>> order. It's "the first" in that order (hence the name).
[Stephen J. Turnbull ]
> The problem
30 matches
Mail list logo
