Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-30 Thread Chris Barker - NOAA Federal
> > 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

Re: [Python-ideas] Suggest adding struct iter_unpack allowing mixed formats & add iter_pack

2018-01-30 Thread Greg Ewing
Steve Barnes wrote: It would be very nice if: a) iter_unpack.next produced an iterator that optionally took an additional parameter of a format string, (with endianness permitted), to replace the current format string in use. Hmmm, rather than screw around with the iterator protocol, it

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-30 Thread Barry Warsaw
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.

Re: [Python-ideas] Logging: a more perseverent version of the StreamHandler?

2018-01-30 Thread Chris Angelico
On Wed, Jan 31, 2018 at 6:43 AM, liam marsh wrote: > Hello, and sorry for the late answer, > > > Le 29/01/2018 à 01:41, Steven D'Aprano a écrit : > > [...] > I'll comment on the email: for some reason, the implementation you > give has extraneous pipes | at the start

[Python-ideas] Logging: a more perseverent version of the StreamHandler?

2018-01-30 Thread liam marsh
Hello, and sorry for the late answer, Le 29/01/2018 à 01:41, Steven D'Aprano a écrit : [...] I'll comment on the email: for some reason, the implementation you give has extraneous pipes | at the start and end of each line, e.g.: This is... unexpected, and doesn't even show on my version of

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-30 Thread Antoine Pitrou
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

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-30 Thread Brendan Barnwell
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

Re: [Python-ideas] Adding str.isascii() ?

2018-01-30 Thread Chris Barker
On Tue, Jan 30, 2018 at 12:00 AM, Steven D'Aprano wrote: > > But it's also a readability question: "is_ascii()" and > > "is_UCS2()/is_BMP()" just require knowing what 7-bit ASCII and UCS-2 > > (or the basic multilingual plane) *are*, whereas the current ways of > > checking

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-30 Thread Antoine Pitrou
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

Re: [Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

2018-01-30 Thread Chris Barker
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

[Python-ideas] Suggest adding struct iter_unpack allowing mixed formats & add iter_pack

2018-01-30 Thread Steve Barnes
In my work I make a lot of use of struct pack & unpack but sometimes find the fact that I either have to supply the whole format string or add position tracking mechanisms to my code explicitly so as to use pack_to or unpack_from if the structures that I am dealing with are not simple arrays

Re: [Python-ideas] Adding str.isascii() ?

2018-01-30 Thread Steven D'Aprano
On Mon, Jan 29, 2018 at 12:54:41PM -0800, Chris Barker wrote: > I'm confused -- isn't the way to do this to encode your text into the > encoding the other application accepts ? Its more about warning the user of *my* application that the data they're exporting could generate mojibake, or even

Re: [Python-ideas] Adding str.isascii() ?

2018-01-30 Thread Steven D'Aprano
On Tue, Jan 30, 2018 at 03:12:52PM +1000, Nick Coghlan wrote: [...] > So this is partly an optimisation question: > > - folks want to avoid allocating a bytes object just to throw it away > - folks want to avoid running the equivalent of "max(map(ord, text))" > - folks know that CPython (at