Peter Otten wrote, on Saturday, April 15, 2017 12:44 AM
>
> Deborah Swanson wrote:
>
> > I know it's your "ugly" answer, but can I ask what the '**' in
> >
> > fix = {label: max(values, key=len)}
> > group[:] = [record._replace(**fix) for record in group]
> >
> > means?
>
> d = {"a": 1, "b": 2
Deborah Swanson wrote:
> I know it's your "ugly" answer, but can I ask what the '**' in
>
> fix = {label: max(values, key=len)}
> group[:] = [record._replace(**fix) for record in group]
>
> means?
d = {"a": 1, "b": 2}
f(**d)
is equivalent to
f(a=1, b=2)
so ** is a means to call a function w
Roel Schroeven wrote, on Thursday, April 13, 2017 5:26 PM
>
> Gregory Ewing schreef op 13/04/2017 9:34:
> > Deborah Swanson wrote:
> >> Peter Otten wrote, on Wednesday, April 12, 2017 1:45 PM
> >>
> >>> Personally I would immediately discard the header row
> once and for
> >>> all, not again and
Peter Otten wrote:
PS: Personally I would probably take the opposite direction and use dicts
throughout...
Yes, my suggestion to used namedtuples in the first place was
based on the assumption that you would mostly be referring to
fields using fixed names. If that's not true, then using
namedt
Gregory Ewing wrote, on Thursday, April 13, 2017 12:17 AM
>
> Deborah Swanson wrote:
> > But I think you got it right in your last sentence below.
defaultdict
> > copied them because they were immutable,
>
> No, definitely not. A defaultdict will never take it upon
> itself to copy an object yo
MRAB wrote, on Friday, April 14, 2017 2:19 PM
>
> In the line:
>
> values = {row[label] for row in group}
>
> 'group' is a list of records; row is a record (namedtuple).
>
> You can get the members of a namedtuple (also 'normal' tuple) by
numeric
> index, e.g. row[0], but the point of a n
fix = {label: max(values, key=len)}
group[:] = [record._replace(**fix) for record in group]
Peter Otten wrote, on Friday, April 14, 2017 2:16 PM
> > def complete(group, label):
> > values = {row[label] for row in group}
> > # get "TypeError: tuple indices must be integers, not str"
>
> Ye
On 2017-04-14 20:34, Deborah Swanson wrote:
Peter,
Retracing my steps to rewrite the getattr(row, label) code, this is what
sent me down the rabbit hole in the first place. (I changed your 'rows'
to 'records' just to use the same name everywhere, but all else is the
same as you gave me.) I'd lik
Deborah Swanson wrote:
> Peter,
>
> Retracing my steps to rewrite the getattr(row, label) code, this is what
> sent me down the rabbit hole in the first place. (I changed your 'rows'
> to 'records' just to use the same name everywhere, but all else is the
> same as you gave me.) I'd like you to l
Peter,
Retracing my steps to rewrite the getattr(row, label) code, this is what
sent me down the rabbit hole in the first place. (I changed your 'rows'
to 'records' just to use the same name everywhere, but all else is the
same as you gave me.) I'd like you to look at it and see if you still
think
Roel Schroeven wrote, on Thursday, April 13, 2017 5:26 PM
>
> Gregory Ewing schreef op 13/04/2017 9:34:
> > Deborah Swanson wrote:
> >> Peter Otten wrote, on Wednesday, April 12, 2017 1:45 PM
> >>
> >>> Personally I would immediately discard the header row
> once and for
> >>> all, not again and
Gregory Ewing wrote, on Thursday, April 13, 2017 1:14 AM
>
> Deborah Swanson wrote:
> > I don't exactly understand your point (2). If the
> namedtuple does not
> > have a label attribute, then getattr(record, label) will
> get the error
> > whether the name label holds the string 'label' or no
Gregory Ewing wrote, on Thursday, April 13, 2017 12:34 AM
>
> Deborah Swanson wrote:
> > Peter Otten wrote, on Wednesday, April 12, 2017 1:45 PM
> >
> >> Personally I would immediately discard the header row once and for
> >> all, not again and again on every operation.
> >
> > Well, perhaps, b
Gregory Ewing wrote, on Thursday, April 13, 2017 12:36 AM
>
> If you want to be able to update your rows, you may find
> this useful:
>
https://pypi.python.org/pypi/recordclass
It's very similar to a namedtuple, but mutable. Looks like it should be
a drop-in replacement.
--
Greg
Thanks Greg,
Gregory Ewing wrote, on Thursday, April 13, 2017 12:17 AM
>
> Deborah Swanson wrote:
> > But I think you got it right in your last sentence below.
> defaultdict
> > copied them because they were immutable,
>
> No, definitely not. A defaultdict will never take it upon
> itself to copy an object
Peter Otten wrote, on Thursday, April 13, 2017 12:17 AM
>
> Deborah Swanson wrote:
>
> > Peter Otten wrote, on Wednesday, April 12, 2017 11:35 PM
> >>
> >> Deborah Swanson wrote:
> >>
> >> > It's a small point, but I suspect getattr(record, label)
> >> would still
> >> > fail, even if label's v
Gregory Ewing schreef op 13/04/2017 9:34:
Deborah Swanson wrote:
Peter Otten wrote, on Wednesday, April 12, 2017 1:45 PM
Personally I would immediately discard the header row once and for
all, not again and again on every operation.
Well, perhaps, but I need the header row to stay in place to
Deborah Swanson wrote:
I don't exactly understand your point (2). If the namedtuple does not
have a label attribute, then getattr(record, label) will get the error
whether the name label holds the string 'label' or not.
You sound rather confused. Maybe the following interactive
session transcri
If you want to be able to update your rows, you may find
this useful:
https://pypi.python.org/pypi/recordclass
It's very similar to a namedtuple, but mutable. Looks like it
should be a drop-in replacement.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Deborah Swanson wrote:
Peter Otten wrote, on Wednesday, April 12, 2017 1:45 PM
Personally I would immediately discard the header row once and for
all, not again and again on every operation.
Well, perhaps, but I need the header row to stay in place to write the
list to a csv when I'm done
T
Deborah Swanson wrote:
But I think you got it right in your last sentence below. defaultdict
copied them because they were immutable,
No, definitely not. A defaultdict will never take it upon
itself to copy an object you give it, either as a key or a
value.
The copying, if any, must have occur
Deborah Swanson wrote:
> Peter Otten wrote, on Wednesday, April 12, 2017 11:35 PM
>>
>> Deborah Swanson wrote:
>>
>> > It's a small point, but I suspect getattr(record, label)
>> would still
>> > fail, even if label's value is 'label' and only 'label', but what's
>> > the point of having a varia
Peter Otten wrote, on Wednesday, April 12, 2017 11:35 PM
>
> Deborah Swanson wrote:
>
> > It's a small point, but I suspect getattr(record, label)
> would still
> > fail, even if label's value is 'label' and only 'label', but what's
> > the point of having a variable if it will only ever have
Deborah Swanson wrote:
> It's a small point, but I suspect getattr(record, label) would still
> fail, even if label's value is 'label' and only 'label', but what's the
> point of having a variable if it will only ever have just one value?
You are misunderstanding. Your getattr() call fails becaus
Deborah Swanson wrote, on Wednesday, April 12, 2017 4:29 PM
>
> Peter Otten wrote, on Wednesday, April 12, 2017 3:15 PM
> >
> > >> Indeed you cannot change the namedtuple's attributes. Like the
> > >> "normal" tuple it is designed to be immutable. If you want
changes in
> > >> one list (the grou
Peter Otten wrote, on Wednesday, April 12, 2017 3:15 PM
>
> Deborah Swanson wrote:
>
> >> >value = getattr(record, label)
> >>
> >> That should work.
> >
> > We may agree that it *should* work, by an intuitive grasp of how it
> > should work, but it doesn't. You get "object has no attribute
'la
Deborah Swanson wrote:
>> >value = getattr(record, label)
>>
>> That should work.
>
> We may agree that it *should* work, by an intuitive grasp of how it
> should work, but it doesn't. You get "object has no attribute 'label'.
Only if the namedtuple
(1) does not have a label attribute and
(2)
Peter Otten wrote, on Wednesday, April 12, 2017 1:45 PM
>
> Deborah Swanson wrote:
>
> > I won't say the following points are categorically true, but I
became
> > convinced enough they were true in this instance that I abandoned
the
> > advised strategy. Which was to use defaultdict to group th
> -Original Message-
> From: Python-list
> [mailto:python-list-bounces+python=deborahswanson.net@python.o
> rg] On Behalf Of MRAB
> Sent: Wednesday, April 12, 2017 1:42 PM
> To: python-list@python.org
> Subject: Re: Namedtuples: some unexpected inconveniences
>
Deborah Swanson wrote:
> I won't say the following points are categorically true, but I became
> convinced enough they were true in this instance that I abandoned the
> advised strategy. Which was to use defaultdict to group the list of
> namedtuples by one of the fields for the purpose of determi
On 2017-04-12 20:57, Deborah Swanson wrote:
I won't say the following points are categorically true, but I became
convinced enough they were true in this instance that I abandoned the
advised strategy. Which was to use defaultdict to group the list of
namedtuples by one of the fields for the purp
I won't say the following points are categorically true, but I became
convinced enough they were true in this instance that I abandoned the
advised strategy. Which was to use defaultdict to group the list of
namedtuples by one of the fields for the purpose of determining whether
certain other field
32 matches
Mail list logo
