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 namedtuple(?, 'x
y'), but
20.07.17 23:17, 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 https://github
>
> 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,
`__isabstra
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, I am not very happy with addition of a new special class.
>> > Imagine that the PEP 544 will
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 Java's interface only wants (
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 https://github.com/python/cpython/blob/master/Includ
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 compressio
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 new code, there is no such
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).
> > Then we would have, abstract classes, abstract
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 think users will be over
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
> timings:
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 provides:
>
> a) Prohibit inst
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 simplify
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.
Additionall
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 anything else, whi
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 implementation.
I don't
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, types.Nam
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?
>>>
>>> Agreed. Now that key
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 dictionaries retain their order,
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 is already arguabl
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 fee
23 matches
Mail list logo
