Re: [Python-Dev] Aligning the packaging.python.org theme with the rest of the docs
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 member permission to use that variant if they ask, is it not? So you don't actually have to tell anyone that they can't use anything. -- Greg ___ Python-Dev mailing list [email protected] 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
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 in a PEP title field. > OK, this looks reasonable. > > > Type-hints should not have runtime semantics, beyond those that they >>> have as classes >>> > lots of code uses isinstance(obj, collections.abc.Iterable) and >>> similar checks with other ABCs >>> Having interfaces defined as something extended from abc doesn't >>> necessitate their use at runtime, but it does open up a great deal of >>> options for those of us who want to do so. I've been leveraging abc for a >>> few years now to implement a lightweight version of what this PEP is >>> attempting to achieve >>> >> >> IIUC this is not the main goal of the PEP, the main goal is to provide >> support/standard for _static_ structural subtyping. >> Possibility to use protocols in runtime context is rather a minor bonus >> that exists mostly to provide a seamless transition >> for projects that already use ABCs. >> > > Is something like this already in the PEP? It deserves attention in one of > the earlier sections. > Yes, similar discussions appear in "Rationale and Goals", and "Existing approaches to structural subtyping". Maybe I need to polish the text there adding more focus on static typing. -- Ivan ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] "Micro-optimisations can speed up CPython"
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/micro-optimisations-can-speed-up-cpython Regards Antoine. ___ Python-Dev mailing list [email protected] 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"
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 to understand why. It seems like I should try again, it seems worth it ;-) Victor 2017-05-29 14:13 GMT+02:00 Antoine Pitrou : > > 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/micro-optimisations-can-speed-up-cpython > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com ___ Python-Dev mailing list [email protected] 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"
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)`. ___ Python-Dev mailing list [email protected] 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"
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/869200284261789696 😉 Cheers, -- zmo ___ Python-Dev mailing list [email protected] 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
>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. > 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. 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. 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. 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. > Also, extensive use of ABCs might impose additional runtime costs. I'd love to see some data around this. Given that it's a rationale for the PEP I'd expect to see some numbers behind it. For example, is memory cost of directly registering implementations to abc linear or worse? What is the runtime growth pattern of isinstance or issubclass when used with heavily registered or deeply registered abc graphs and is it different than those calls on concrete class hierarchies? Does the cost affect anything more than the initial evaluation of the code or, in the absence of isinstance/issubclass checks, does it continue to have an impact on the runtime? On Mon, May 29, 2017 at 5:41 AM Ivan Levkivskyi wrote: > 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 in a PEP title field. >> > > OK, this looks reasonable. > > >> >> > Type-hints should not have runtime semantics, beyond those that they have as classes > lots of code uses isinstance(obj, collections.abc.Iterable) and similar checks with other ABCs Having interfaces defined as something extended from abc doesn't necessitate their use at runtime, but it does open up a great deal of options for those of us who want to do so. I've been leveraging abc for a few years now to implement a lightweight version of what this PEP is attempting to achieve >>> >>> IIUC this is not the main goal of the PEP, the main goal is to provide >>> support/standard for _static_ structural subtyping. >>> Possibility to use protocols in runtime context is rather a minor bonus >>> that exists mostly to provide a seamless transition >>> for projects that already use ABCs. >>> >> >> Is something like this already in the PEP? It deserves attention in one >> of the earlier sections. >> > > Yes, similar discussions appear in "Rationale and Goals", and "Existing > approaches to structural subtyping". Maybe I need to polish the text there > adding more focus on static typing. > > -- > Ivan > > > ___ Python-Dev mailing list [email protected] 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"
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 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)`. > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/benhoyt% > 40gmail.com > ___ Python-Dev mailing list [email protected] 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"
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: https://twitter.com/corsix/status/869200284261789696 "Because getting patches merged is much effort", which is sometimes true. Peter Cawley is already bpo user 'Peter Cawley' with linked github account 'corsix', but no CLA. If one or more core developers were to commit to reviewing his patches, one of them (or someone else) could email him (see bpo user profile) conveying our interest and such commitment(s), and request that he sign the CLA, open an issue for one patch, and open a git PR for the patch. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] 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
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 us to lose control of the mark, i.e. we would not have legal authority to prohibit the misleading uses we actually care about preventing. On May 29, 2017 2:32 AM, "Greg Ewing" wrote: 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 member permission to use that variant if they ask, is it not? So you don't actually have to tell anyone that they can't use anything. -- Greg ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/mertz%40g nosis.cx ___ Python-Dev mailing list [email protected] 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"
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: >> 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 > Is the author of that article using non-standard terminology? The article doesn't appear to be about __slots__ at all. > The part of optimizations already are applied in 3.6 and 3.7, but `a + b` > still is slower than `a.__add__(b)`. > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] 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"
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-Dev mailing list [email protected] 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"
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 biggest problem with the language is the stupid slot
system. I do not mean the __slots__ but the internal type slots
for special methods.
http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/
Armin shows the history of these "slots" (or however they're called)
back to Python in 1990!
static number_methods int_as_number = {
intadd, /*tp_add*/
intsub, /*tp_subtract*/
intmul, /*tp_multiply*/
... etc
I don't know where the name "slot" comes for from the various tp_*
members (fields? attributes? slots?) but I'm pretty sure I've heard it
before. I don't normally pay attention to what happens in the C
implementation, but I'm fairly sure he's referring to these tp_*
thingies.
Oh yes, here you go:
https://docs.python.org/2/extending/newtypes.html#type-methods
refers to "tp_* slot" regularly. What does "tp" stand for? Type
something, I guess.
--
Steve
___
Python-Dev mailing list
[email protected]
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"
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
didn't update the terminology.
I feel a bit offended that Armin calls it "the stupid slot system" -- this
architecture an important part of what makes C extensions so flexible. I
will happily see it replaced by something better, if it can be found, but I
don't think it's fair to call it "stupid". However I no longer am
interested in maintaining that code myself, and I can't bear to read those
blog posts (they're rambling and sound like someone's research notes).
On Mon, May 29, 2017 at 7:47 PM, Steven D'Aprano
wrote:
> 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 biggest problem with the language is the stupid slot
> system. I do not mean the __slots__ but the internal type slots
> for special methods.
>
> http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/
>
> Armin shows the history of these "slots" (or however they're called)
> back to Python in 1990!
>
> static number_methods int_as_number = {
> intadd, /*tp_add*/
> intsub, /*tp_subtract*/
> intmul, /*tp_multiply*/
> ... etc
>
> I don't know where the name "slot" comes for from the various tp_*
> members (fields? attributes? slots?) but I'm pretty sure I've heard it
> before. I don't normally pay attention to what happens in the C
> implementation, but I'm fairly sure he's referring to these tp_*
> thingies.
>
> Oh yes, here you go:
>
> https://docs.python.org/2/extending/newtypes.html#type-methods
>
> refers to "tp_* slot" regularly. What does "tp" stand for? Type
> something, I guess.
>
>
> --
> Steve
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
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 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 ___ Python-Dev mailing list [email protected] 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"
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 [email protected] 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"
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 [email protected] 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"
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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
