On 25 July 2017 at 11:57, Nick Coghlan wrote:
> Having such a builtin implictly create and cache new namedtuple type
> definitions so the end user doesn't need to care about pre-declaring
> them is still fine, and remains the most straightforward way of
> building a capability
On 25 July 2017 at 02:46, Michel Desmoulin wrote:
> Le 24/07/2017 à 16:12, Nick Coghlan a écrit :
>> On 22 July 2017 at 01:18, Guido van Rossum wrote:
>>> Honestly I would like to declare the bare (x=1, y=0) proposal dead. Let's
>>> encourage the use
On Fri, Jul 21, 2017 at 8:18 AM, Guido van Rossum wrote:
> Honestly I would like to declare the bare (x=1, y=0) proposal dead. Let's
> encourage the use of objects rather than tuples (named or otherwise) for
> most data exchanges. I know of a large codebase that uses dicts
On 24 July 2017 at 17:37, Michel Desmoulin wrote:
> You are in the wrong thread. This thread is specifically about
> namedtupels literal.
In which case, did you not see Guido's post "Honestly I would like to
declare the bare (x=1, y=0) proposal dead."? The namedtuple
On Sun, Jul 23, 2017 at 8:54 PM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> C Anthony Risinger writes:
>
> > A tuple is a tuple is a tuple. No types. Just convenient accessors.
>
> That's not possible, though. A *tuple* is an immutable collection
> indexed by the
Le 24/07/2017 à 13:45, Ethan Furman a écrit :
> [redirecting back to list]
>
> On 07/24/2017 04:19 AM, Michel Desmoulin wrote:
>> Le 24/07/2017 à 13:02, Ethan Furman a écrit :
>>> On 07/23/2017 10:47 AM, Michel Desmoulin wrote:
>
I'm not sure why everybody have such a grip on the type.
On Mon, Jul 24, 2017 at 6:31 AM, Steven D'Aprano
wrote:
> > I'm not sure why everybody have such a grip on the type.
> >
> > When we use regular tuples, noone care, it's all tuples, no matter what.
>
> Some people care.
>
> This is one of the serious disadvantages of
Le 24/07/2017 à 16:12, Nick Coghlan a écrit :
> On 22 July 2017 at 01:18, Guido van Rossum wrote:
>> Honestly I would like to declare the bare (x=1, y=0) proposal dead. Let's
>> encourage the use of objects rather than tuples (named or otherwise) for
>> most data exchanges. I
Le 24/07/2017 à 15:31, Steven D'Aprano a écrit :
> On Sun, Jul 23, 2017 at 07:47:16PM +0200, Michel Desmoulin wrote:
>
>> I'm not sure why everybody have such a grip on the type.
>>
>> When we use regular tuples, noone care, it's all tuples, no matter what.
>
> Some people care.
>
> This is
On Tue, Jul 25, 2017 at 2:20 AM, Chris Barker wrote:
> On Thu, Jul 20, 2017 at 12:15 AM, Pierre Quentel
> wrote:
>> - if so, should it be supported by default ? It is the case in the PR,
>> where a number of content types, eg text/html, are
The opinion of some random guy on the list...
On Thu, Jul 20, 2017 at 12:15 AM, Pierre Quentel
wrote:
> I have been suggested to require feedback from core devs :
> - should HTTP compression be supported ?
>
Yes. You are quite right, it's pretty standard stuff these
On 22 July 2017 at 01:18, Guido van Rossum wrote:
> Honestly I would like to declare the bare (x=1, y=0) proposal dead. Let's
> encourage the use of objects rather than tuples (named or otherwise) for
> most data exchanges. I know of a large codebase that uses dicts instead of
>
On Sun, Jul 23, 2017 at 07:47:16PM +0200, Michel Desmoulin wrote:
> I'm not sure why everybody have such a grip on the type.
>
> When we use regular tuples, noone care, it's all tuples, no matter what.
Some people care.
This is one of the serious disadvantages of ordinary tuples as a
On 07/23/2017 10:47 AM, Michel Desmoulin wrote:
> I'm not sure why everybody have such a grip on the type.
If I understand the goal of "a new namedtuple" correctly, it is not to come up with yet another namedtuple type -- it is
to make the existing collections.namedtuple a faster experience,
14 matches
Mail list logo