On 21 February 2018 at 08:40, Guido van Rossum wrote:
> On Tue, Feb 20, 2018 at 12:54 PM, Barnstone Worthy
> wrote:
>
> I'm pretty sure that's an alias for Barry Warsaw. :-)
Different Barry :)
I've expanded the existing issue at
https://github.com/pypa/python-packaging-user-guide/issues/355 to
On Tue, Feb 20, 2018 at 12:54 PM, Barnstone Worthy
wrote:
I'm pretty sure that's an alias for Barry Warsaw. :-)
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/pyt
> On 20 Feb 2018, at 13:12, Nick Coghlan wrote:
>
>> On 20 February 2018 at 16:17, Antoine Pitrou wrote:
>> On Mon, 19 Feb 2018 20:15:27 +0100
>> Stefan Behnel wrote:
>>> Nick Coghlan schrieb am 02.02.2018 um 06:47:
to make the various extension module authoring tools
easier to disc
On 20 February 2018 at 16:17, Antoine Pitrou wrote:
> On Mon, 19 Feb 2018 20:15:27 +0100
> Stefan Behnel wrote:
>> Nick Coghlan schrieb am 02.02.2018 um 06:47:
>> > to make the various extension module authoring tools
>> > easier to discover, rather than having folks assuming that handcrafted
>>
On Mon, 19 Feb 2018 20:15:27 +0100
Stefan Behnel wrote:
> Nick Coghlan schrieb am 02.02.2018 um 06:47:
> > to make the various extension module authoring tools
> > easier to discover, rather than having folks assuming that handcrafted
> > calls directly into the CPython C API is their only option.
Nick Coghlan schrieb am 02.02.2018 um 06:47:
> to make the various extension module authoring tools
> easier to discover, rather than having folks assuming that handcrafted
> calls directly into the CPython C API is their only option.
Or even a competitive option. Tools like Cython or pybind11 go
On 2 February 2018 at 06:15, Barry Scott wrote:
>
>
> On 30 Jan 2018, at 05:45, Nick Coghlan wrote:
>
> I'll also note that one of the things we (and others) *have* been
> putting quite a bit of time into is the question of "Why do people
> avoid using extension modules for code acceleration?".
>
> On 30 Jan 2018, at 05:45, Nick Coghlan wrote:
>
> I'll also note that one of the things we (and others) *have* been
> putting quite a bit of time into is the question of "Why do people
> avoid using extension modules for code acceleration?".
I think that is simple. Those that try give up bec
I'm not sure I understand Pau's question but I can assure that my
optimizations were fully backwards compatible and preserved all of
Python attribute lookup semantics. And they made some macrobenchmarks
up to 10% faster.
Unfortunately I failed at merging them in 3.7. Will do that for 3.8.
I wa
On Thu, Feb 1, 2018 at 12:55 PM, Brett Cannon wrote:
>
>
> On Thu, 1 Feb 2018 at 07:34 Pau Freixes wrote:
[..]
>> 2) Regarding the Yuris proposal to cache bultin functions, why this
>> strategy cant be used for objects and their attributes within the function
>> scope? Technically which is the re
On Thu, 1 Feb 2018 at 07:34 Pau Freixes wrote:
> Maybe it is happening but not in the way that you would expect
>
> https://mail.python.org/pipermail/python-dev/2018-January/152029.html
>
>
As one of the people who works at Microsoft and has Steve as a teammate I'm
well aware of what MS contribut
Maybe it is happening but not in the way that you would expect
https://mail.python.org/pipermail/python-dev/2018-January/152029.html
Anyway, do we conclude, or at least a significant part, that is something
desiderable but some constraints do not allow to work on that?
Also, more technically Iw
>
> It's easier to make a good language fast than it is to make a fast language
> good. It's easier to hack a compiler or an interpreter to run slow code
> faster than it is to hack the human brain to understand confusing code more
> easily. So I think the smart move is to take the languages
Antoine Pitrou wrote:
> Moore's Law doesn't really apply to semiconductors anymore either, and
> transistor size scaling is increasingly looking like it's reaching its
> end.
You forget about the quantum computing AI blockchain in the cloud.
OTOH, I still haven't perfected my clone army yet.
-Bar
On Mon, 29 Jan 2018 23:24:43 -0500
Barry Warsaw wrote:
>
> This is often undervalued, but shouldn't be! Moore's Law doesn't apply
> to humans, and you can't effectively or cost efficiently scale up by
> throwing more bodies at a project.
Moore's Law doesn't really apply to semiconductors anymor
On 2018-01-29 20:24, Barry Warsaw wrote:
But there's something else that's very important to consider, which
rarely comes up in these discussions, and that's the developer's
productivity and programming experience. One of the things that makes
Python so popular and effective I think, is that it
On Tue, 30 Jan 2018 09:14:06 -0800
Chris Barker wrote:
> On Sat, Jan 27, 2018 at 10:14 PM, Nick Coghlan wrote:
>
> > More broadly, the current lack of perceived commercial incentives for
> > large corporations to invest millions in offering a faster default
> > Python runtime, the way they have
On Mon, Jan 29, 2018 at 9:45 PM, Nick Coghlan wrote:
>
> I'll also note that one of the things we (and others) *have* been
> putting quite a bit of time into is the question of "Why do people
> avoid using extension modules for code acceleration?".
>
well, the scientific computing community does
On Sat, Jan 27, 2018 at 10:14 PM, Nick Coghlan wrote:
> More broadly, the current lack of perceived commercial incentives for
> large corporations to invest millions in offering a faster default
> Python runtime, the way they have for the other languages you
> mentioned in your initial post :)
>
On 30 January 2018 at 14:24, Barry Warsaw wrote:
> This is often undervalued, but shouldn't be! Moore's Law doesn't apply
> to humans, and you can't effectively or cost efficiently scale up by
> throwing more bodies at a project. Python is one of the best languages
> (and ecosystems!) that make
Just to add another perspective, I find many "performance" problems in
the real world can often be attributed to factors other than the raw
speed of the CPython interpreter. Yes, I'd love it if the interpreter
were faster, but in my experience a lot of other things dominate. At
least they do prov
On Sat, Jan 27, 2018, 23:36 Pau Freixes, wrote:
> > At a technical level, the biggest problems relate to the way we
> > manipulate frame objects at runtime, including the fact that we expose
> > those frames programmatically for the benefit of debuggers and other
> > tools.
>
> Shoudnt be somethi
On Sat, 27 Jan 2018 22:18:08 +0100
Pau Freixes wrote:
>
> Correct me if I'm wrong, but most of you argue that the proper Zen of
> Python - can we say it mutability [1]? as Victor pointed out - that
> allow the user have the freedom to mutate objects in runtime goes in
> the opposite direction of
On 28 January 2018 at 17:35, Pau Freixes wrote:
>> At a technical level, the biggest problems relate to the way we
>> manipulate frame objects at runtime, including the fact that we expose
>> those frames programmatically for the benefit of debuggers and other
>> tools.
>
> Shoudnt be something th
> At a technical level, the biggest problems relate to the way we
> manipulate frame objects at runtime, including the fact that we expose
> those frames programmatically for the benefit of debuggers and other
> tools.
Shoudnt be something that could be tackled with the introduction of a
kind of "
On 28 January 2018 at 07:18, Pau Freixes wrote:
> Regarding the cost of calling a function, that I can guess is not
> related with the previous stuff, what is an impediment right now to
> make it faster ?
At a technical level, the biggest problems relate to the way we
manipulate frame objects at
>
> def filter(rule, whatever):
> if rule.x in whatever.x:
> return True
>
> rules = get_rules()
> whatevers = get_whatevers()
> for rule in rules:
> for whatever in whatevers:
> if filter(rule, whatever):
> cnt = cnt + 1
>
> return cnt
>
This code seems almost
Hi,
Thanks to all of you for your responses, the points of view and the
information that you shared to back up your rationales, I had some
time to visit few of them but sure I will try to suit the proper time
to review all of them.
It's hard to try to keep the discussion organized responding at e
Hi all,
I would like to remark that, in my opinion, the question of CPython's
performance cannot
be decoupled from the extremely wide selection of packages which provide
optimized
code for almost any imaginable task.
For example: Javascript may be faster than (C)Python on simple benchmarks,
but
a
On 27 January 2018 at 07:35, Pau Freixes wrote:
> This could be considered an unimportant thing, but its more relevant
> than someone could expect, at least IMHO. If the default code that you
> can write in a language is by default slow and exists an alternative
> to make it faster, this language
On 26Jan2018 20:59, Soni L. wrote:
On 2018-01-26 08:18 PM, Chris Barker wrote:
If there are robust and simple optimizations that can be added to
CPython, great, but:
This mail is the consequence of a true story, a story where CPython
got defeated by Javascript, Java, C# and Go.
at leas
On Sat, Jan 27, 2018 at 10:07 AM, Steven D'Aprano wrote:
> On Sat, Jan 27, 2018 at 09:12:29AM +1100, Chris Angelico wrote:
>
>> Are you sure it's the language's fault? Failing to use a better data
>> type simply because some other language doesn't have it is a great way
>> to make a test that's "f
On Fri, Jan 26, 2018 at 02:18:53PM -0800, Chris Barker wrote:
[...]
> sure, but I would argue that you do need to write code in a clean style
> appropriate for the language at hand.
Indeed. If you write Java-esque code in Python with lots of deep chains
obj.attr.spam.eggs.cheese.foo.bar.baz expe
Hi,
Well, I wrote https://faster-cpython.readthedocs.io/ website to answer
to such question.
See for example https://faster-cpython.readthedocs.io/mutable.html
"Everything in Python is mutable".
Victor
2018-01-26 22:35 GMT+01:00 Pau Freixes :
> Hi,
>
> This mail is the consequence of a true sto
On Sat, Jan 27, 2018 at 09:12:29AM +1100, Chris Angelico wrote:
> Are you sure it's the language's fault? Failing to use a better data
> type simply because some other language doesn't have it is a great way
> to make a test that's "fair" in the same way that Balance and
> Armageddon are "fair" in
On 2018-01-26 08:18 PM, Chris Barker wrote:
If there are robust and simple optimizations that can be added to
CPython, great, but:
This mail is the consequence of a true story, a story where CPython
got defeated by Javascript, Java, C# and Go.
at least those last three are staticall
If there are robust and simple optimizations that can be added to CPython,
great, but:
This mail is the consequence of a true story, a story where CPython
> got defeated by Javascript, Java, C# and Go.
>
at least those last three are statically compiled languages -- they are
going to be faster th
On Sat, Jan 27, 2018 at 8:35 AM, Pau Freixes wrote:
> def filter(rule, whatever):
> if rule.x in whatever.x:
> return True
>
> rules = get_rules()
> whatevers = get_whatevers()
> for rule in rules:
> for whatever in whatevers:
> if filter(rule, whatever):
> cnt
There are several reasons for the issues you are mentioning.
1. Attribute look up is much more complicated than you would think.
(If you have the time, watch https://www.youtube.com/watch?v=kZtC_4Ecq1Y that
will explain things better than I can)
The series of operations that happen with every `
Hi,
This mail is the consequence of a true story, a story where CPython
got defeated by Javascript, Java, C# and Go.
One of the teams of the company where Im working had a kind of
benchmark to compare the different languages on top of their
respective "official" web servers such as Node.js, Aioht
40 matches
Mail list logo
