Yep. DictRreader is better for my simple example. Just pointing out that
encountering attributes in different orders isn't uncommon.
On Jul 30, 2017 10:55 PM, "Chris Angelico" wrote:
On Mon, Jul 31, 2017 at 3:41 PM, David Mertz wrote:
>> But most of the time you always have the same attributes
On Mon, Jul 31, 2017 at 3:41 PM, David Mertz wrote:
>> But most of the time you always have the same attributes in the same order
>> (think of reading a CSV for example), and this would be just a normal tuple,
>> but with custom names for the indexes.
>
>
> You apparently live in a halcyon world o
>
> But most of the time you always have the same attributes in the same order
> (think of reading a CSV for example), and this would be just a normal
> tuple, but with custom names for the indexes.
>
You apparently live in a halcyon world of data cleanliness where CSV data
is so well behaved.
In
On 31 July 2017 at 04:31, Paul Moore wrote:
> On 30 July 2017 at 16:24, Nick Coghlan wrote:
>> Rather than being about any changes on that front, these threads are
>> mostly about making it possible to write that first line as:
>>
>> MyNT = type(implicitly_typed_named_tuple_factory(foo=None,
On Sun, Jul 30, 2017 at 09:57:19PM +0300, Markus Meskanen wrote:
> So yeah, the order of the keyword arguments would matter in my case, and
> I've found it to work the best. How often do you get the keywords in a
> random order?
"Random" order? Never.
*Arbitrary* order? All the time. That's the
On 7/30/2017 2:57 PM, Markus Meskanen wrote:
I've been experimenting with this:
class QuickNamedTuple(tuple):
def __new__(cls, **kwargs):
inst = super().__new__(cls, tuple(kwargs.values()))
inst._names = tuple(kwargs.keys())
return inst
def __getattr__(self
I've been experimenting with this:
class QuickNamedTuple(tuple):
def __new__(cls, **kwargs):
inst = super().__new__(cls, tuple(kwargs.values()))
inst._names = tuple(kwargs.keys())
return inst
def __getattr__(self, attr):
if attr in self._names:
On 30 July 2017 at 16:24, Nick Coghlan wrote:
> Rather than being about any changes on that front, these threads are
> mostly about making it possible to write that first line as:
>
> MyNT = type(implicitly_typed_named_tuple_factory(foo=None, bar=None))
Is that really true, though? There's a
On 30 July 2017 at 20:03, Alex Walters wrote:
>> -Original Message-
>> From: Python-ideas [mailto:python-ideas-bounces+tritium-
>> list=sdamon@python.org] On Behalf Of Michel Desmoulin
>> Sent: Sunday, July 30, 2017 4:19 AM
>> To: python-ideas@python.org
>> Subject: Re: [Python-ideas]
> -Original Message-
> From: Python-ideas [mailto:python-ideas-bounces+tritium-
> list=sdamon@python.org] On Behalf Of Michel Desmoulin
> Sent: Sunday, July 30, 2017 4:19 AM
> To: python-ideas@python.org
> Subject: Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]
>
>
Le 29/07/2017 à 18:14, Alex Walters a écrit :
> My $0.02 on the entire series of nametuple threads is… there **might**
> be value in an immutable namespace type, and a mutable namespace type,
> but namedtuple’s promise is that they can be used anywhere a tuple can
> be used. If passing in kwargs
11 matches
Mail list logo
