30.05.17 09:06, Greg Ewing пише:
Steven D'Aprano wrote:
What does "tp" stand for? Type something, I guess.
I think it's just short for "type". There's an old tradition
in C of giving member names a short prefix reminiscent of
the type they belong to. Not sure why, maybe someone thought
it help
29.05.17 17:15, Serhiy Storchaka пише:
29.05.17 15:13, Antoine Pitrou пише:
I hope readers won't get bothered by what is mostly a link to blogpost
(well, two of them :-)), but I suspect there at least 2 or 3 people
who might be interested in the following analysis:
https://www.corsix.org/content
Steven D'Aprano wrote:
What does "tp" stand for? Type something, I guess.
I think it's just short for "type". There's an old tradition
in C of giving member names a short prefix reminiscent of
the type they belong to. Not sure why, maybe someone thought
it helped readability.
--
Greg
_
David Wilson wrote:
They're referred to as slots throughout typeobject.c
That's probably where he got the term from. But it really refers
to C-level fields in the type object. Magic methods that don't
correspond to C-level type fields are not called slots.
--
Greg
_
tp_ stands for "type". I wrote all that in 1990 and indeed made up the term
slot -- it's like an entry in a C++ vtable, where apparently they are also
called slots by some folks. I also did a major update to the machinery here
in the early 2000s (when typeobject.c grew from 50 lines to 5000) but
On Mon, May 29, 2017 at 07:27:05PM -0700, Guido van Rossum wrote:
> > https://www.corsix.org/content/why-are-slots-so-slow
> >
>
> Is the author of that article using non-standard terminology? The article
> doesn't appear to be about __slots__ at all.
Quoting Armin Ronacher:
By far my bigge
On Mon, May 29, 2017 at 07:27:05PM -0700, Guido van Rossum wrote:
> Is the author of that article using non-standard terminology? The article
> doesn't appear to be about __slots__ at all.
They're referred to as slots throughout typeobject.c
___
Python-
On Mon, May 29, 2017 at 7:15 AM, Serhiy Storchaka
wrote:
> 29.05.17 15:13, Antoine Pitrou пише:
>
>> I hope readers won't get bothered by what is mostly a link to blogpost
>> (well, two of them :-)), but I suspect there at least 2 or 3 people
>> who might be interested in the following analysis:
This is a side issue, do I don't want to go too long with it. But *NO* we
can't always give permission. The problem isn't how permissive PSF might
like to be in the abstract, but trademark law itself. Trademark is "enforce
it or lose it" ... Even passively allowing dilutive derivatives would cause
On 5/29/2017 10:36 AM, Guyzmo via Python-Dev wrote:
On Mon, May 29, 2017 at 05:15:43PM +0300, Serhiy Storchaka wrote:
Interesting articles, thank you. I wonder why the author doesn't propose his
patches for CPython. Does he fear that CPython can become faster than Lua?
;-)
the author's answer:
That's very interesting -- thanks for sharing, Serhiy and Antoine. Very
relevant!
On Mon, May 29, 2017 at 10:15 AM, Serhiy Storchaka
wrote:
> 29.05.17 15:13, Antoine Pitrou пише:
>
>> I hope readers won't get bothered by what is mostly a link to blogpost
>> (well, two of them :-)), but I suspect
>From the PEP:
> The problem with them is that a class has to be explicitly marked to
support them, which is unpythonic and unlike what one would normally do in
idiomatic dynamically typed Python code.
> The same problem appears with user-defined ABCs: they must be explicitly
subclassed or register
On Mon, May 29, 2017 at 05:15:43PM +0300, Serhiy Storchaka wrote:
> Interesting articles, thank you. I wonder why the author doesn't propose his
> patches for CPython. Does he fear that CPython can become faster than Lua?
> ;-)
the author's answer: https://twitter.com/corsix/status/869200284261789
29.05.17 15:13, Antoine Pitrou пише:
I hope readers won't get bothered by what is mostly a link to blogpost
(well, two of them :-)), but I suspect there at least 2 or 3 people
who might be interested in the following analysis:
https://www.corsix.org/content/compilers-cpython-interpreter-main-loop
Hi,
Thank you for the links.
-PyObject *value = GETLOCAL(oparg);
+PyObject *value = GETLOCAL((unsigned)oparg);
Oh, I remember that I proposed to change oparg type to unsigned when
Demur wrote the WORDCODE change. I even wrote a patch, but I got a
segfault and was unable t
Hi,
I hope readers won't get bothered by what is mostly a link to blogpost
(well, two of them :-)), but I suspect there at least 2 or 3 people
who might be interested in the following analysis:
https://www.corsix.org/content/compilers-cpython-interpreter-main-loop
http://www.corsix.org/content/mi
On 28 May 2017 at 19:40, Guido van Rossum wrote:
> On Sun, May 28, 2017 at 8:27 AM, Ivan Levkivskyi
> wrote:
>
[...]
> Regarding the title, I'd like to keep the word Protocol in the title too,
> so I'd go with "Protocols: Structural subtyping (duck typing)" -- hope
> that's not too long to fit
M.-A. Lemburg wrote:
In my role as PSF TM committee member, it's often painful to have to
tell community members that they cannot use e.g. really nice looking
variants of the Python logo for their projects. Let's not add more
pain.
But it's always within the PSF's power to give that community
m
18 matches
Mail list logo
