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
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
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 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: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
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
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
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
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
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
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
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
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:
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 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 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 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
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 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 (
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
>
> 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
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
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
23 matches
Mail list logo
