Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

2017-07-20 Thread Serhiy Storchaka
20.07.17 04:35, Alexander Belopolsky пише: On Wed, Jul 19, 2017 at 9:08 PM, Guido van Rossum wrote: The proposal in your email seems incomplete The proposal does not say anything about type((x=1, y=2)). I assume it will be the same as the type currently returned by

Re: [Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

2017-07-20 Thread INADA Naoki
> > I wonder if it would make sense to go further and merge *both* of these > features into regular classes. > > Checking for @abstractmethod in type.__new__ surely can't be that expensive, > can it? > But it affects startup time. It iterate all of the namespace and tries `getattr(obj,

Re: [Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

2017-07-20 Thread INADA Naoki
INADA Naoki On Fri, Jul 21, 2017 at 2:59 AM, Ivan Levkivskyi wrote: > On 20 July 2017 at 19:51, INADA Naoki wrote: >> >> On Fri, Jul 21, 2017 at 12:12 AM, Ivan Levkivskyi >> wrote: >> > To be honest,

Re: [Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

2017-07-20 Thread Nathaniel Smith
On Jul 20, 2017 05:39, "INADA Naoki" wrote: Hi, Victor. > Why not making abc faster instead of trying to workaround abc for perf > issue? Current ABC provides: a) Prohibit instantiating without implement abstract methods. b) registry based subclassing People want

[Python-ideas] namedtuple from ordereddict

2017-07-20 Thread Jim J. Jewett
Several of the replies seemed to suggest that re-using the current dict structure for a tuple wouldn't work. Since I'm not sure whether people are still thinking of the old structure, or I'm missing something obvious, I'll be more explicit. Per

Re: [Python-ideas] HTTP compression support for http.server

2017-07-20 Thread Terry Reedy
On 7/20/2017 3:15 AM, Pierre Quentel wrote: I have reported an issue in the tracker (https://bugs.python.org/issue30576) and proposed a Pull Request on the Github CPython repository (https://github.com/python/cpython/pull/2078) to make http.server in the standard library support HTTP

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

2017-07-20 Thread Lucas Wiman
On Thu, Jul 20, 2017 at 5:19 AM, Victor Stinner wrote: > For me, namedtuple was first used to upgrade an old API from returning a > tuple to a "named" tuple. There was a hard requirement on backward > compatibility: namedtuple API is a superset of the tuple API. > > For

Re: [Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

2017-07-20 Thread Ivan Levkivskyi
On 20 July 2017 at 19:51, INADA Naoki wrote: > On Fri, Jul 21, 2017 at 12:12 AM, Ivan Levkivskyi > wrote: > > To be honest, I am not very happy with addition of a new special class. > > Imagine that the PEP 544 will be accepted (and I hope so). > >

Re: [Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

2017-07-20 Thread INADA Naoki
On Fri, Jul 21, 2017 at 12:12 AM, Ivan Levkivskyi wrote: > To be honest, I am not very happy with addition of a new special class. > Imagine that the PEP 544 will be accepted (and I hope so). > Then we would have, abstract classes, abstract base classes, and protocols. > I

Re: [Python-ideas] a new namedtuple

2017-07-20 Thread Steven D'Aprano
On Tue, Jul 18, 2017 at 06:06:00PM -0300, Joao S. O. Bueno wrote: > In the other thread, I had mentioned my "extradict" implementation - it > does have quite a few differences as it did not try to match namedtuple > API, but it works nicely for all common use cases - these are the timeit >

Re: [Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

2017-07-20 Thread Ivan Levkivskyi
To be honest, I am not very happy with addition of a new special class. Imagine that the PEP 544 will be accepted (and I hope so). Then we would have, abstract classes, abstract base classes, and protocols. I think users will be overwhelmed by having three similar concepts instead of one. I think

Re: [Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

2017-07-20 Thread Neil Girdhar
Good discussion so far. Please let me know if I can help with implementation or documentation. On Thu, Jul 20, 2017 at 8:40 AM INADA Naoki wrote: > Hi, Victor. > > > Why not making abc faster instead of trying to workaround abc for perf > > issue? > > Current ABC

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

2017-07-20 Thread Ivan Levkivskyi
Something probably not directly related, but since we started to talk about syntactic changes... I think what would be great to eventually have is some form of pattern matching. Essentially pattern matching could be just a "tagged" unpacking protocol. For example, something like this will

Re: [Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

2017-07-20 Thread INADA Naoki
Hi, Victor. > Why not making abc faster instead of trying to workaround abc for perf > issue? Current ABC provides: a) Prohibit instantiating without implement abstract methods. b) registry based subclassing People want Java's interface only wants (a). (b) is unwanted side effect.

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

2017-07-20 Thread Koos Zevenhoven
On Thu, Jul 20, 2017 at 9:58 AM, Nathaniel Smith wrote: > > The problem with namedtuple's semantics are that they're perfect for > its original use case (replacing legacy tuple returns without breaking > backwards compatibility), but turn out to be sub-optimal for pretty > much

Re: [Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

2017-07-20 Thread Victor Stinner
Le 20 juil. 2017 3:49 AM, "INADA Naoki" a écrit : > I'm +1 with your idea in performance point of view. (...) But ABC is too heavy to use only for checking abstract methods. It uses three inefficient WeakSet [1] and it overrides isinstance and issubclass with slow Python

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

2017-07-20 Thread Victor Stinner
For me, namedtuple was first used to upgrade an old API from returning a tuple to a "named" tuple. There was a hard requirement on backward compatibility: namedtuple API is a superset of the tuple API. For new code, there is no such backward compatibility issue. If you don't need a type,

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

2017-07-20 Thread Clément Pit-Claudel
On 2017-07-20 11:30, Paul Moore wrote: > On 20 July 2017 at 10:15, Clément Pit-Claudel wrote: >> On 2017-07-20 11:02, Paul Moore wrote: Also, what's the advantage of (x=1, y=2) over ntuple(x=1, y=2)? I.e., why does this need to be syntax instead of a library? >>>

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

2017-07-20 Thread Paul Moore
On 20 July 2017 at 10:15, Clément Pit-Claudel wrote: > On 2017-07-20 11:02, Paul Moore wrote: >>> Also, what's the advantage of (x=1, y=2) over ntuple(x=1, y=2)? I.e., >>> why does this need to be syntax instead of a library? >> >> Agreed. Now that keyword argument

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

2017-07-20 Thread Clément Pit-Claudel
On 2017-07-20 11:02, Paul Moore wrote: >> Also, what's the advantage of (x=1, y=2) over ntuple(x=1, y=2)? I.e., >> why does this need to be syntax instead of a library? > > Agreed. Now that keyword argument dictionaries retain their order, > there's no need for new syntax here. In fact, that's one

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

2017-07-20 Thread Paul Moore
On 20 July 2017 at 07:58, Nathaniel Smith wrote: > From the above it sounds like this ntuple literal idea would be giving > us a third independent way to solve this niche use case (ntuple, > namedtuple, structseq). This seems like two too many? Especially given > that namedtuple

[Python-ideas] HTTP compression support for http.server

2017-07-20 Thread Pierre Quentel
I have reported an issue in the tracker (https://bugs.python.org/issue30576) and proposed a Pull Request on the Github CPython repository ( https://github.com/python/cpython/pull/2078) to make http.server in the standard library support HTTP compression (gzip). I have been suggested to require

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

2017-07-20 Thread Nathaniel Smith
On Wed, Jul 19, 2017 at 9:06 PM, Nick Coghlan wrote: > A question worth asking will be whether or not > "collections.namedtuple" will implicitly participate in the use of the > type cache, and I think the answer needs to be "No". The problem is > twofold: > > 1.

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

2017-07-20 Thread Brice PARENT
If the type is a data, it probably belongs to the inside of the tuple: smart = (type="Car", cost=18_900, hp=89, weight=949) harley = (type="Motorcycle", cost=18_900, hp=89, weight=949) both_vehicles = (type(smart) == type(harley)) # True - type+cost+hp+weight on both sides same_vehicles =