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
>
> 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,
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,
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
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
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
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
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).
> >
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
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
>
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
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
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
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.
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
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
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,
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?
>>>
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
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
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
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
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.
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 =
24 matches
Mail list logo