Re: [Python-Dev] "Micro-optimisations can speed up CPython"

[Glenn Linderman]

On 5/30/2017 2:18 PM, Guido van Rossum wrote:
On Tue, May 30, 2017 at 11:49 AM, David Wilson > wrote:


On Tue, May 30, 2017 at 09:38:55PM +0300, Serhiy Storchaka wrote:

> > In early ages of C structures didn't create namespaces, and member
> > names were globals.

> >That's nonsense. The reason is greppability.

> Good reason!

The first time I heard about prefixing struct members was to allow
tricks like this:

x86_64-linux-gnu/bits/stat.h
94:# define st_atime st_atim.tv_sec /* Backward
compatibility.  */
95:# define st_mtime st_mtim.tv_sec
96:# define st_ctime st_ctim.tv_sec

Which is relatively safe thanks to the prefix.


Believe me that is not why the prefix convention was introduced.


Sure, but grepping was not the reason either. Serhiy had the right 
explanation.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

[Jonathan Cronin]

On May 30, 2017, at 11:38 AM, Guido van Rossum  wrote:On Mon, May 29, 2017 at 11:16 PM, Serhiy Storchaka  wrote: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 helped readability.


In early ages of C structures didn't create namespaces, and member names were globals.That's nonsense. The reason is greppability. Nonsense is a little harsh :).  Global member names aren’t why you used prefixes, but early C has them.I burned my fingers on them as a small programmer on this.  Sometime before 1980.
Jonathan Croninjcro...@egh.com


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

[Guido van Rossum]

But I do stand corrected. I had forgotten that.

On May 30, 2017 3:49 PM, "Greg Ewing"  wrote:

> Serhiy Storchaka wrote:
>
>> In early ages of C structures didn't create namespaces, and member names
>> were globals.
>>
>
> That would certainly explain the origins of it, but I'm
> pretty sure it wasn't the case by the time Python was
> invented. So Guido must have liked it for other reasons.
>
> --
> Greg
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
> 40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 544: Protocols - second round

[Guido van Rossum]

[I added some blank lines to separate the PEP quotes from Kevin's
responses.]

On Mon, May 29, 2017 at 7:51 AM, Kevin Conway 
wrote:

> 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 registered.
>
> Neither of these statements are entirely true. The semantics of `abc`
> allow for exactly the kind of detached interfaces this PEP is attempting to
> provide. The `abc.ABCMeta` provides the `__subclasshook__` which allows a
> developer to override the default check of internal `abc` registry state
> with virtually any logic that determines the relationship of a class with
> the interface. The prior art I linked to earlier in the thread uses this
> feature to generically support `issubclass` and `isinstance` in such a way
> that the PEPs goal is achieved.
>

But that doesn't help a static type checker. You can't expect a static
checker to understand the implementation of a particular
`__subclasshook__`. In practice, except for a few "one-trick ponies" such
as Hashable, existing ABCs rely on subclassing or registration to make
isinstance() work, and for statically checking code that uses duck typing
those aren't enough.


> > The intention of this PEP is to solve all these problems by allowing
> users to write the above code without explicit base classes in the class
> definition
>
> As I understand this goal, you want to take what some of us in the
> community have been building ourselves and make it canonical via the
> stdlib.
>

Not really. The goal is to suggest implementation a frequently requested
feature in static checkers based on the type system laid out in PEP 484,
namely checks for duck types. To support this the type system from PEP 484
needs to be extended, and that's what PEP 544 is about.


> What strikes me as odd is that the focus is on 3rd party type checkers
> first rather than introducing this as a feature of the language runtime and
> then updating the type checker contract to make use of it.
>

This seems to be a misunderstanding, or at least an attempt to change the
agenda for PEP 544. The primary goal of the PEP is not to support runtime
checking but static checking. This is not new -- PEP 484 and PEP 526 before
it have also focused on features that are useful primarily for static
checkers. (Also, a bit of history: PEP 484 intentionally focused on static
checking support because there was widespread skepticism about the need for
more runtime checking, but there was a subset of the community that was
very interested in static checking.)


> I see a mention of the `isinstance` check support in the
> postponed/rejected ideas, but the only rationale given for it being in that
> category is, generally, "there are edge cases". For example, the PEP lists
> this as an edge case:
>
> >The problem with this is instance checks could be unreliable, except for
> situations where there is a common signature convention such as Iterable
>
> However, the sample given demonstrates precisely the expected behavior of
> checking if a concrete implements the protocol. It's unclear why this
> sample is given as a negative.
>

I assume we're talking about this example:

  class P(Protocol):
  def common_method_name(self, x: int) -> int: ...

  class X:
  
  def common_method_name(self) -> None: ... # Note different signature

  def do_stuff(o: Union[P, X]) -> int:
  if isinstance(o, P):
  return o.common_method_name(1)  # oops, what if it's an X
instance?

The problem there is that the "state of the art" for runtiming checking
isinstance(o, P) boils down to hasattr(o, 'common_method_name') while the
type checker takes the method signatures into account, so it will consider
X objects not to be instances of P.

The other case given is:
>
> > Another potentially problematic case is assignment of attributes after
> instantiation
>
> Can you elaborate on how type checkers would not encounter this same
> issue? If there is a solution to this problem for type checkers, would that
> same solution not work at runtime? Also, it seems odd to use a custom
> initialize function rather than `__init__`. I don't think it was
> intentional, but this makes it seem like a bit of a strawman that doesn't
> represent typical Python code.
>

Lots of code I've seen initializes variables in a separate function
(usually called from `__init__`). Mypy, at least, considers instance
variables assigned through `self` in all methods of a class to be potential
instance variable declarations, otherwise a lot of code could not be
type-checked.

Again, the example is problematic given that the runtime check for
isinstance(c, P) can't do better than hasattr(c, 'x').  (I think there's a
typo in the PEP here, 'c1' should be 'c'.)

The need to use an 

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

[Greg Ewing]

Serhiy Storchaka wrote:
In early ages of C structures didn't create namespaces, and member names 
were globals.


That would certainly explain the origins of it, but I'm
pretty sure it wasn't the case by the time Python was
invented. So Guido must have liked it for other reasons.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

[Jeff Allen]

On 30/05/2017 16:38, Guido van Rossum wrote:
On Mon, May 29, 2017 at 11:16 PM, Serhiy Storchaka 
> wrote:


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 helped readability.


In early ages of C structures didn't create namespaces, and member
names were globals.


That's nonsense. The reason is greppability.

It does seem that far enough back, struct member names were all one 
space, standing for little more than their offset and type:


"Two structures may share a common initial sequence of members; that is, 
the same member may appear in two different structures if it has the 
same type in both and if all previous members are the same in both. 
(Actually, the compiler checks only that a name in two different 
structures has the same type and offset in both, ... )" -- The C 
Programming Language, K 1978 (p197).


With these Python name spaces, you're really spoiling us, Mr BDFL.

Jeff Allen
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

[Guido van Rossum]

On Tue, May 30, 2017 at 11:49 AM, David Wilson 
wrote:

> On Tue, May 30, 2017 at 09:38:55PM +0300, Serhiy Storchaka wrote:
>
> > > In early ages of C structures didn't create namespaces, and member
> > > names were globals.
>
> > >That's nonsense. The reason is greppability.
>
> > Good reason!
>
> The first time I heard about prefixing struct members was to allow
> tricks like this:
>
> x86_64-linux-gnu/bits/stat.h
> 94:# define st_atime st_atim.tv_sec /* Backward compatibility.  */
> 95:# define st_mtime st_mtim.tv_sec
> 96:# define st_ctime st_ctim.tv_sec
>
> Which is relatively safe thanks to the prefix.
>

Believe me that is not why the prefix convention was introduced.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 484 update proposal: annotating decorated declarations

[Guido van Rossum]

> On 15 May 2017 at 10:48, Koos Zevenhoven  wrote:
>
>> Would __annotations__ be set by the decorator? To me, not setting them
>> would seem weird, but cases where the result is not a function could
>> be weird. I also don't see a mention of this only working in stubs.
>>
>
It took me a while to realize which annotations we're talking about here.

I like Jukka's version, as it has a clear distinction between
>> functions and other attributes. But that might require a language
>> change to provide __annotations__ in a clean manner? Maybe that
>> language change would be useful elsewhere.
>
>
I'm not interesting in language changes to solve this problem.

On Mon, May 15, 2017 at 6:20 AM, Ivan Levkivskyi 
wrote:

> With original syntax it is possible to overwrite annotations without
> language changes.
> However with Jukka's syntax it looks difficult. A possible pure-Python way
> could be
> to insert an item in an enclosing __annotations__, if an enclosing scope
> is a class or module scope.
>

I assume we're talking about `session.__annotations__`, which will be
overwritten by the last definition (i.e. the "implementation"). This is
only a runtime problem, and we're actually still a bit better off here than
for @overload -- for @overload, the implementation is often un-annotated or
has very vague annotations (e.g. `*args: Any`), while here the annotations
are in principle preserved by the decorators on the implementation
function. (The main premise of the proposal under discussion is to clarify
the type for the *human* reader, although in some edge cases the explicit
annotation may provide a constraint for the naturally inferred type of the
decorated function.)

But in either case the annotations on the overload variants or the
"declaration" are lost at runtime by the trick of using multiple
definitions, since at runtime the last definition wins. (And we don't want
to go through the contortions used by e.g. @property for collecting getters
and setters belonging to a single attribute.)

The question then is, do we care more about the runtime accessibility of
the type, or do we care more about ease of use in a context of static
analysis? In general with the design of PEP 484 I've tried to balance the
two (and several other constraints like no changes to the core Python
language).

I'm still not decided. Let's compare the two proposals quickly. In Naomi's
version you'd write

@decorated_type(Callable[[str], ContextManager[DbSession]])
@contextmanager
def session(url: str) -> Iterator[DbSession]:


while in Jukka's version you'd write

@declared_type
def session(url: str) -> ContextManager[DbSession]: ...

@contextmanager
def session(url: str) -> Iterator[DbSession]:


There's also a difference in power between the two: in Naomi's proposal,
session's type becomes exactly

Callable[[str], ContextManager[DbSession]]

which can only be called with positional arguments, whereas in Jukka's
proposal session will retain the name and clasiffication (e.g.
keyword-only, varargs) of the arguments. If those are important, in Naomi's
case this can be written using the new "argspecs" form of Callable, i.e.

@decorated_type(Callable[[Arg(str, 'url')], ContextManager[DbSession])
@contextmanager
def session 

which is definitely more verbose and uglier than Jukka's version. OTOH it
does mean that Naomi's proposal has all the *power* of Jukka's version --
and in simple cases it is actually less verbose than Jukka's proposal (in
cases where you want all that power -- if you're happy with a basic
callable it's actually *less* verbose).

Jukka's version also needs another special case where the decorator returns
something that's not a callable. In Naomi's proposal this would simply be

@decorated_type(SomeType)
@some_decorator
def my_thing(url: str) -> int:


Jukka's proposal *seems* to be to just allow overriding a variable
declaration with a function declararion:

my_thing: SomeType

@some_decorator
def my_thing 

This seems fragile to me (since it looks like an accidental redefinition,
although typically the static check would find a discrepancy between the
inferred type of the first and the second definition).

All in all I'm still leaning towards Naomi's original proposal -- it looks
simpler to implement as well.

-- 
--Guido van Rossum (python.org/~guido )
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

[David Wilson]

On Tue, May 30, 2017 at 09:38:55PM +0300, Serhiy Storchaka wrote:

> > In early ages of C structures didn't create namespaces, and member
> > names were globals.

> >That's nonsense. The reason is greppability.

> Good reason!

The first time I heard about prefixing struct members was to allow
tricks like this:

x86_64-linux-gnu/bits/stat.h
94:# define st_atime st_atim.tv_sec /* Backward compatibility.  */
95:# define st_mtime st_mtim.tv_sec
96:# define st_ctime st_ctim.tv_sec

Which is relatively safe thanks to the prefix.


David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

[Serhiy Storchaka]

30.05.17 18:38, Guido van Rossum пише:
On Mon, May 29, 2017 at 11:16 PM, Serhiy Storchaka > wrote:


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 helped readability.


In early ages of C structures didn't create namespaces, and member
names were globals.


That's nonsense. The reason is greppability.


Good reason!

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

[Guido van Rossum]

On Mon, May 29, 2017 at 11:16 PM, Serhiy Storchaka 
wrote:

> 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 helped readability.
>>
>
> In early ages of C structures didn't create namespaces, and member names
> were globals.
>

That's nonsense. The reason is greppability.


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Aligning the packaging.python.org theme with the rest of the docs

[Antoine Pitrou]

On Tue, 30 May 2017 21:49:19 +1000
Nick Coghlan  wrote:
> 
> Here's an alternate wording for the README that would focus on those
> considerations without explicitly asking folks not to use the theme:
> 
> "Note that when adopting this theme, you're also borrowing an element
> of the trust and credibility established by the CPython core
> developers over the years, as well as the legal credibility arising
> from their close association with the Python Software Foundation.

The statement about "legal credibility" sounds wishy-washy and could
lure users into thinking that they're doing something illegal by
borrowing the theme.

Also I'm not sure what is that "legal credibility" you're talking
about.  If it's about the PSF license and the Python CLA then
better to voice that explicitly, IMO.

> That's fine, and you're welcome to do so for other Python community
> projects if you so choose, but please keep in mind that in doing so
> you're also choosing to become a co-steward of that collective trust
> :)"

"Becoming a co-steward of that collective trust" sounds serious enough
(even though I don't understand what it means concretely), so why
the smiley?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Aligning the packaging.python.org theme with the rest of the docs

[M.-A. Lemburg]

On 30.05.2017 13:49, Nick Coghlan wrote:
> Here's an alternate wording for the README that would focus on those
> considerations without explicitly asking folks not to use the theme:
> 
> "Note that when adopting this theme, you're also borrowing an element
> of the trust and credibility established by the CPython core
> developers over the years, as well as the legal credibility arising
> from their close association with the Python Software Foundation.
> That's fine, and you're welcome to do so for other Python community
> projects if you so choose, but please keep in mind that in doing so
> you're also choosing to become a co-steward of that collective trust
> :)"

Much better. Thanks :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 30 2017)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backport ssl.MemoryBIO on Python 2.7?

[Victor Stinner]

I wrote a first PEP draft:
https://github.com/python/peps/pull/272

Victor

2017-05-24 2:46 GMT+02:00 Victor Stinner :
> Hi,
>
> Would you be ok to backport ssl.MemoryBIO and ssl.SSLObject on Python
> 2.7? I can do the backport.
>
>   https://docs.python.org/dev/library/ssl.html#ssl.MemoryBIO
>
> Cory Benfield told me that it's a blocking issue for him to implement
> his PEP 543 -- A Unified TLS API for Python 2.7:
>
>   https://www.python.org/dev/peps/pep-0543/
>
> And I expect that if a new cool TLS API happens, people will want to
> use it on Python 2.7-3.6, not only on Python 3.7. Security evolves
> more quickly that the current Python release process, and people wants
> to keep their application secure.
>
> From what I understood, he wants to first implement an abstract
> MemoryBIO API (http://sans-io.readthedocs.io/ like API? I'm not sure
> about that), and then implement a socket/FD based on top of that.
> Maybe later, some implementations might have a fast-path using
> socket/FD directly.
>
> He described me his PEP and I strongly support it (sorry, I missed it
> when he posted it on python-dev), but we decided (Guido van Rossum,
> Christian Heimes, Cory Benfield and me, see the tweet below) to not
> put this in the stdlib right now, but spend more time on testing it on
> Twisted, asyncio, requests, etc. So publishing an implementation on
> PyPI was proposed instead. It seems like we agreed on a smooth plan
> (or am I wrong, Cory?).
>
>   https://twitter.com/VictorStinner/status/865467388141027329
>
> I'm quite sure that Twisted will love MemoryBIO on Python 2.7 as well,
> to implement TLS, especially on Windows using IOCP. Currently,
> external libraries (C extensions) are required.
>
> I'm not sure if the PEP 466 should be amended for that? Is a new PEP
> really needed? MemoryBIO/SSLObject are tiny. Nick (Coghlan): what do
> you think?
>
>   https://www.python.org/dev/peps/pep-0466/
>
> Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Aligning the packaging.python.org theme with the rest of the docs

[Nick Coghlan]

On 29 May 2017 at 01:15, David Mertz  wrote:
> I agree with MAL and have also been on the Trademarks Committee for 8-9
> years. Protecting an actual Mark like the logo is fine, as painful as it is
> to someone's say no to an attractive derived logo. But trying to protect a
> look-and-feel is way too far down the path of evil (it's what some
> proprietary companies we want to be different from do). Moreover, when when
> that's done it's not generally as trademark but as "trade dress"
> copyright... which is a concept I opposed ethically, but know it's the usual
> legal instrument.

I'm also fine with leaving the trade dress aspect completely
unenforced - the main question is whether or not folks are OK with
PyPA using a derivative of the CPython docs theme to make PyPA-related
documentation look more like the CPython docs, and hence more
official.

I do think it's appropriate for us to ask that question, as going down
this path means we're deliberately trading on the community trust
earned by the CPython core development team over the past 20+ years
specifically in order to help make PyPA's own documentation seem more
trustworthy to others.

If we're going to borrow somebody else's reputation like that, then it
seems reasonable to me for us to offer the people whose reputation
we're borrowing the courtesy of *asking first*, regardless of what the
law says we're technically allowed to do.

Here's an alternate wording for the README that would focus on those
considerations without explicitly asking folks not to use the theme:

"Note that when adopting this theme, you're also borrowing an element
of the trust and credibility established by the CPython core
developers over the years, as well as the legal credibility arising
from their close association with the Python Software Foundation.
That's fine, and you're welcome to do so for other Python community
projects if you so choose, but please keep in mind that in doing so
you're also choosing to become a co-steward of that collective trust
:)"

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

[Serhiy Storchaka]

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 helped readability.


In early ages of C structures didn't create namespaces, and member names 
were globals.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

[Serhiy Storchaka]

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/compilers-cpython-interpreter-main-loop
http://www.corsix.org/content/micro-optimisations-can-speed-up-cpython


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? ;-)


And the following article should be especially interesting for Victor:

https://www.corsix.org/content/why-are-slots-so-slow

The part of optimizations already are applied in 3.6 and 3.7, but `a + 
b` still is slower than `a.__add__(b)`.


See https://bugs.python.org/issue30509. All optimizations already are 
applied in 3.7 by Victor. In these microbenchmarks 3.7 is much faster 
than 2.7 and 3.5. But still there is some overhead due to excess 
intermediate levels.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

[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 helped readability.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com