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, an
[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.
If I understand the goal of "a new namedtuple" correctly, it is
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
record/st
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
> objects, and it's
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 days.
> - if so, should it
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 compressed if the user
>> agent accepts the gzip "encodi
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
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 know of a large co
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 ordinary tuples as a
> record
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 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 natural
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 literal
proposal that started
On 07/24/2017 09:49 AM, Michel Desmoulin wrote:
You are assuming a namedtuple litteral would mean collections.namedtuple
would lose the type hability. It's not the case. The litterals can be
complement, not a remplacement.
Accelerating namedtuple can be made by rewritting it in C. The litteral
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 instead of
> objects, a
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 of objects rather than tuples (named or otherw
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 like this atop the u
> So the only thing being ruled out is the dedicated syntax option,
> since it doesn't let us do anything that a new builtin can't do, it's
> harder to find help on (as compared to "help(ntuple)" or searching
> online for "python ntuple"), and it can't be readily backported to
> Python 3.6 as part
17 matches
Mail list logo
