Re: [Python-Dev] Drop/deprecate Tkinter?

[Paul Moore]

On 3 May 2018 at 03:26, Steven D'Aprano  wrote:

>> Will all due respect, it's sometimes unpredictable what kind of wording
>> Anglo-Saxons will take as an insult, as there's lot of obsequiosity
>> there that doesn't exist in other cultures. To me, "not give a damn"
>> reads like a familiar version of "not care about something", but
>> apparently it can be offensive.
>
> I'm Anglo-Saxon[1], and honestly I believe that it is thin-skinned to
> the point of ludicrousness to say that "no-one gives a damn" is an
> insult. This isn't 1939 when Clark Gable's famous line "Frankly my dear,
> I don't give a damn" was considered shocking. Its 2018 and to not give a
> damn is a more forceful way of saying that people don't care, that they
> are indifferent.

Sigh. That's not what I was saying at all. I was trying to point out
that Antoine's claim that people should ignore the rhetoric and that
complaining about the attitude was unreasonable, was in itself unfair.
People have a right to point out that a mail like the OP's was badly
worded.

> With respect to Paul, I literally cannot imagine why he thinks that
> *anyone*, not even the tkinter maintainers or developers themselves,
> ought to feel *offended* by Ivan's words.

Personally, they didn't offend me. I don't pretend to know how others
might take them. But they *did* annoy me. I'm frankly sick of people
(not on this list) complaining that people who work on projects in
their own time, free of charge, "don't care enough" or "are ignoring
my requirement". We all do it, to an extent, and it's natural to get
frustrated, but the onus is on the person asking for help to be polite
and fair. And maybe this response was the one where I finally let that
frustration show through. I may read less email for a week or two,
just to get a break.

> But I think a clue might be his subsequent use of the word *annoyed*. Is
> it annoying to be told that "no-one cares" when in fact you care? Of
> course it can be. It is a perfectly reasonable to feel annoyed. But it
> isn't reasonable to lash out at every little annoyance.

Correct, I'm personally annoyed rather than offended. And maybe I
reacted strongly (although my reaction was mainly a defense of
people's right to be annoyed or offended, not a direct response to the
OP). I *hope* it wasn't "lashing out", but I concede that others may
view it differently than I do. It *certainly* isn't against "every
little annoyance" though - I've been dealing politely and calmly with
*many* entitled and misguided complaints recently (in many lists and
fora - no point in trying to go hunting down what I'm referring to
;-))  and this was one too many. I should probably have just shut up
and deleted the thread. I *will* stop at this point and not respond
again on this thread.

> All interpersonal interactions can involve annoyances. And none of us
> are purely on the receiving end, we all also cause them. None of us are
> so perfect that we can afford to lash out each time somebody causes some
> tiny little annoyance. We ought to gloss over the little ones, just as
> we hope others will swallow *their* annoyance at the things we do.
>
> If we're going to be open, respectful and considerate, we have a duty
> not to have a hair-trigger "I'm offended" response at tiny annoyances.

While true, this is biased in favour of people who start new threads,
allowing them the freedom to not consider other's feelings or
situations while expecting the recipients to be forgiving of hyperbole
and overstated rhetoric. Relevant xkcd: https://xkcd.com/1984/

> "That's offensive!", in this day and age, is the nuclear weapon of
> interpersonal conflict, and nothing Ivan said was so terrible that it
> deserved such an attack. Not if we are to be open, considerate and
> respectful. We ought to start by respecting the clear emotional pain in
> his email and not responding by going on the attack. "A soft answer
> turns away wrath".

If that's directed at me, it's unfair. Personally, I consider "it's
offensive" to be a mild expression of distaste at what someone says -
often used somewhat jokingly, in reference to "political correctness"
style jokes. Antoine clearly took it otherwise - his mention of "Anglo
Saxon" suggests to me that he feels it's a cultural thing - although
if so, he's misinterpreted the relevant cultures as far as I can see.
British informal culture in my experience tends to be similar to what
I describe above as my view. Or maybe he's just thinking of "people
taking too much care to stick within the letter of codes of conduct",
I don't know. I'm happy to try to avoid the word "offensive" in my
future posts - it clearly has connotations that don't match what I
intend.

I've said my piece, so I'll leave it at that. I don't want mailing
lists to become sterile places where everyone feels unable to speak
their mind for fear of upsetting others, but I do think we *all* need
to consider the other person's perspective. And I *particularly* think
that people who

Re: [Python-Dev] PEP 575: Unifying function/method classes

[Stefan Behnel]

Hi,

let me start by saying that I'm much in favour of this change. It cleans up
a lot of the function implementation and makes it much easier to integrate
efficiently with external wrapper tools.


Guido van Rossum schrieb am 14.04.2018 um 23:14:
> On Sat, Apr 14, 2018 at 2:17 AM, Jeroen Demeyer wrote:
>> On 2018-04-13 21:30, Raymond Hettinger wrote:
>>
>>> It would be nice to have a section that specifically discusses the
>>> implications with respect to other existing function-like tooling:
>>> classmethod, staticmethod, partial, itemgetter, attrgetter, methodgetter,
>>> etc.
>>>
>>
>> My hope is that there are no such implications. An important design goal
>> of this PEP (which I believe I achieved) is that as long as you're doing
>> duck typing, you should be safe. I believe that the tools in your list do
>> exactly that.
>>
>> It's only when you use inspect or when you do type checks that you will
>> see the difference with this PEP.
> 
> That actually sounds like a pretty big problem. I'm sure there is lots of
> code that doesn't *just* duck-type nor calls inspect but uses isinstance()
> to decide how to extract the desired information.

After some discussion, it seems that we can avoid the backwards
incompatibility by going half of the way first. We can keep the existing
"builtin_function_or_method" type for now, and mostly just add the common
base function type at the top. That provides most of the benefits,
including fast integration with native external function implementations
and most of the cleanup, while not requiring changes to type tests in user
code.

The final split could then be done later, e.g. for Py4.0, where people
would be less surprised about minor breakages. The problem is that this
change does not really fit into the deprecation cycle since there is no
specific use case to warn about. Most code will simply keep working, and
there is no specific code pattern that would break. It really depends on
the exact reasons why some piece of code (thinks it) needs to do a type
check. Such code is usually easy to fix, and also improve along the way,
probably even by reducing the type checking or by starting to use "inspect"
instead of direct (fragile) type checks. Much of the code that could
potentially break probably only exists to work around the quirks of the
current function types implementation in CPython, which this PEP
specifically aims to clean up.

Stefan

___
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 575: Unifying function/method classes

[Victor Stinner]

2018-05-03 11:22 GMT+02:00 Stefan Behnel :
> The final split could then be done later, e.g. for Py4.0, where people
> would be less surprised about minor breakages.

Please don't queue backward incompatible changes for Python 4.0. You
should use the regular deprecation process.

(I didn't read the full thread, sorry :-p)

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] PEP 575: Unifying function/method classes

[Jeroen Demeyer]

On 2018-05-03 11:30, Victor Stinner wrote:

Please don't queue backward incompatible changes for Python 4.0. You
should use the regular deprecation process.


I don't really see how that can be done here. As Stefan said


The problem is that this
change does not really fit into the deprecation cycle since there is no
specific use case to warn about.


The PEP proposes to change an implementation detail. It's really hard to 
determine at runtime whether code is relying on that implementation 
detail. We could insert a DeprecationWarning in some places, but those 
would mostly be false positives (a DeprecationWarning is shown but the 
code won't break).


On top of that, there is no way to show a DeprecationWarning for code 
like "type(x) is foo".



Jeroen.
___
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] Drop/deprecate Tkinter?

[Skip Montanaro]

One other small bit... There is some precedent for retaining modules where
the underlying library was known to be buggy. The dearly departed bsddb
module exposed libdb 1.85 (as I recall) which had an unfixable bug. Still,
bsddb supported that broken version of the library for quite awhile before
itself being deprecated, then removed, from the stdlib. I believe it was
the sole persistent key/value store for most of the early years.

So, bugs or not (& fixable or not) it's not like we haven't encountered
this kind of case before.

Skip
___
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] Drop/deprecate Tkinter?

[Steve Holden]

On Thu, May 3, 2018 at 12:12 AM, Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

> On 03.05.2018 1:01, Antoine Pitrou wrote:
>
>> On Wed, 2 May 2018 22:54:04 +0100
>> Paul Moore  wrote:
>>
>>> On 2 May 2018 at 22:37, Antoine Pitrou  wrote:
>>>
 To elaborate a bit: the OP, while angry, produced both a detailed
 analysis *and* a PR.  It's normal to be angry when an advertised
 feature doesn't work and it makes you lose hours of work (or, even,
 forces you to a wholesale redesign). Producing a detailed analysis and a
 PR is more than most people will ever do.

>>> His *other* email seems reasonable, and warrants a response, yes. But
>>> are we to take the suggestion made here (to drop tkinter) seriously,
>>> based on the fact that there's a (rare - at least it appears that the
>>> many IDLE users haven't hit it yet) race condition that causes a crash
>>> in Python 2.7? (It appears that the problem doesn't happen in the
>>> python.org 3.x builds, if I understand the description of the issue).
>>>
>> In 3.x, Tkinter+threads is broken too, albeit in a different way -- see
> https://bugs.python.org/issue33412 (this should've been the 2nd link in
> the initial message, sorry for the mix-up).
>

​The observation in t​hat issue that tkinter and threads should be handled
in specific ways is certainly a given for old hands, who have long put the
GUI code in one thread with one or more concurrent worker threads typically
communicating through queues. But I haven't built anything like that
recently, so I couldn't say how helpful the current documenation might be.

The 2.x bug also shows in 3.x if it's linked with a nonthreaded version of
> Tcl (dunno how rare that is, but the code still supports this setup).
>
>> I and others actually suggested it seriously in the past.  Now,
>> admittedly, at least IDLE seems better maintained than it used to
>> be -- not sure about Tkinter itself.
>>
>> Nor do I think the tone of his message here is acceptable - regardless
>>> of how annoyed he is, posting insults ("no-one gives a damn") about
>>> volunteer contributors in a public mailing list isn't reasonable or
>>> constructive. Call that "playing speech police" if you want, but I
>>> think that being offended or annoyed and saying so is perfectly
>>> reasonable.
>>>
>> Will all due respect, it's sometimes unpredictable what kind of wording
>> Anglo-Saxons will take as an insult, as there's lot of obsequiosity
>> there that doesn't exist in other cultures. To me, "not give a damn"
>> reads like a familiar version of "not care about something", but
>> apparently it can be offensive.
>>
> Confirm, never meant this as an insult.
>
> I had to use emotional language to drive the point home that it's not some
> nitpick, it really causes people serious trouble (I lost a source of
> income, for the record).
> Without the emotional impact, my message could easily be ignored as some
> noise not worth attention. This time, it's just too damn important to allow
> this possibility.
>
> With respect, I would say you CHOSE to use emotional language. I don't see
that much indication that its absence had failed to produce responses,
though they may not have been the responses you wanted.

Unfortunately the developers are rather too used to this kind of gratuitous
abuse and so many of them may have overlooked your detailed analysis of the
issues you were experiencing, since constructive contributions don't
normally accompany such rants.

The module being abandoned and unused is truly the only explanation I could
> think of when seeing that glaring bugs have stayed unfixed for 15 years (an
> infinity in IT), in an actively developed and highly used software.
> This may be flattering for my ego, but if the module really is in any
> production use to speak of, then in all these years, with all this
> humongous user base, someone, somewhere in the world, at some point, should
> have looked into this. I don't even program in C professionally, yet was
> able to diagnose it and make a PR!
>
> ​I think the fact that alarm bells haven't clanged is likely a product of
​tkinter's relatively small user base, perhaps amplified by dwindling
availability of "GYU in one thread" lore. Anyway they have certainly
clanged now.

---
>
> I'll make a PR with the doc warning as Guido suggested unless there are
> any better ideas.
>
> ​In the absence of other actions this would be a good first step. Thank
you.
​


> Meanwhile, I'd really appreciate any response to my other message -- it is
> about actually fixing the issue, and I do need feedback to be able to
> proceed.
> No need to delve all the way in and give an official authorization or
> something. I'm only looking for an opinion poll on which redesign option
> (if any) looks like the most reasonable way to proceed and/or in line with
> the big picture (the last one -- to provide a unifying vision -- is _the_
> job of a BDFL IIRC).
>

​I wouldn't presume to tell Guido his job, give

Re: [Python-Dev] PEP 575: Unifying function/method classes

[Eric V. Smith]

On 5/3/2018 6:22 AM, Jeroen Demeyer wrote:

On 2018-05-03 11:30, Victor Stinner wrote:

Please don't queue backward incompatible changes for Python 4.0. You
should use the regular deprecation process.


I don't really see how that can be done here. As Stefan said


The problem is that this
change does not really fit into the deprecation cycle since there is no
specific use case to warn about.


The PEP proposes to change an implementation detail. It's really hard to 
determine at runtime whether code is relying on that implementation 
detail. We could insert a DeprecationWarning in some places, but those 
would mostly be false positives (a DeprecationWarning is shown but the 
code won't break).


On top of that, there is no way to show a DeprecationWarning for code 
like "type(x) is foo".


Deprecating doesn't necessarily involve a DeprecationWarning, although 
if possible it should, of course. It could just be a documented 
deprecation. We've done this before, although I can't think of an 
example off the top of my head (which I realize is not exactly helpful).


"If you're doing a type check involving C functions, and you're doing it 
, change it to  because we're going to deprecate the 
old way in version x.y". Of course this assumes both  and way> can coexist for several versions, which itself might not be possible.


Eric

___
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] Python startup time

[Ryan Gonzalez]

I'm hardly an expert, but AFAIK CPython's start-up issues are more due to a 
mix of architectural issues and the fact that it's hard to optimize imports 
while maintaining backwards compatibility with Python's dynamism.


--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/



On May 3, 2018 1:37:57 AM Glenn Linderman  wrote:


On 5/2/2018 8:56 PM, Gregory Szorc wrote:

Nobody in the project is seriously talking about a complete rewrite in
Rust. Contributors to the project have varying opinions on how
aggressively Rust should be utilized. People who contribute to the C
code, low-level primitives (like storage, deltas, etc), and those who
care about performance tend to want more Rust. One thing we almost
universally agree on is that we want to rewrite all of Mercurial's C
code in Rust. I anticipate that figuring out the balance between Rust
and Python in Mercurial will be an ongoing conversation/process for
the next few years.

Have you considered simply rewriting CPython in Rust?

And yes, the 4th word in that question was intended to produce peals of
shocked laughter. But why Rust? Why not Go? http://esr.ibiblio.org/?p=7724



--
___
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/rymg19%40gmail.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] Python startup time

[Nick Coghlan]

On 3 May 2018 at 15:56, Glenn Linderman  wrote:

> On 5/2/2018 8:56 PM, Gregory Szorc wrote:
>
> Nobody in the project is seriously talking about a complete rewrite in
> Rust. Contributors to the project have varying opinions on how aggressively
> Rust should be utilized. People who contribute to the C code, low-level
> primitives (like storage, deltas, etc), and those who care about
> performance tend to want more Rust. One thing we almost universally agree
> on is that we want to rewrite all of Mercurial's C code in Rust. I
> anticipate that figuring out the balance between Rust and Python in
> Mercurial will be an ongoing conversation/process for the next few years.
>
> Have you considered simply rewriting CPython in Rust?
>

FWIW, I'd actually like to see Rust approved as a language for writing
stdlib extension modules, but actually ever making that change in policy
would require a concrete motivating use case.


> And yes, the 4th word in that question was intended to produce peals of
> shocked laughter. But why Rust? Why not Go?
>

Trying to get two different garbage collection engines to play nice with
each other is a recipe for significant pain, since you can easily end up
with uncollectable cycles that neither GC system has complete visibility
into (all it needs is a loop from PyObject A -> Go Object B -> back to
PyObject A).

Combining Python and Rust can still get into that kind of trouble when
using reference counting on the Rust side, but it's a lot easier to avoid
than it is in runtimes with mandatory GC.

Cheers,
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] Drop/deprecate Tkinter?

[Tim Peters]

[Matěj Cepl ]
> It absolutely impossible to remove Tkinter IMHO (it has been
> part of stdlib since like forever and people expect it there;
> its removal would be betrayal on the level of switching = to
> :=), I have my doubts about IDLE though. I know, the same
> argument applies, but really, does anybody use IDLE for
> development for long time, what is its real value for the
> community? Although, even this argument is questionable, because
> Python has some affinity with the learning, and IDLE is a nice
> for first steps nibbling into Python.

IDLE isn't just for eager beginners, but also for those so old &
senile they're incapable of learning anything new ever again.  As
proof, IDLE is still _my_ primary Python development environment, used
multiple times every day, and I'm so old & out-of-it that I'm +1 on
the binding expressions PEP ;-)
___
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] Drop/deprecate Tkinter?

[MRAB]

On 2018-05-03 13:24, Steve Holden wrote:
On Thu, May 3, 2018 at 12:12 AM, Ivan Pozdeev via Python-Dev 
mailto:python-dev@python.org>> wrote:


On 03.05.2018 1:01, Antoine Pitrou wrote:

On Wed, 2 May 2018 22:54:04 +0100
Paul Moore mailto:p.f.mo...@gmail.com>> wrote:

On 2 May 2018 at 22:37, Antoine Pitrou mailto:solip...@pitrou.net>> wrote:

To elaborate a bit: the OP, while angry, produced both a
detailed
analysis *and* a PR.  It's normal to be angry when an
advertised
feature doesn't work and it makes you lose hours of work
(or, even,
forces you to a wholesale redesign). Producing a
detailed analysis and a
PR is more than most people will ever do.

His *other* email seems reasonable, and warrants a response,
yes. But
are we to take the suggestion made here (to drop tkinter)
seriously,
based on the fact that there's a (rare - at least it appears
that the
many IDLE users haven't hit it yet) race condition that
causes a crash
in Python 2.7? (It appears that the problem doesn't happen
in the
python.org  3.x builds, if I understand
the description of the issue).

In 3.x, Tkinter+threads is broken too, albeit in a different way --
see https://bugs.python.org/issue33412
 (this should've been the 2nd
link in the initial message, sorry for the mix-up).


​The observation in t​hat issue that tkinter and threads should be 
handled in specific ways is certainly a given for old hands, who have 
long put the GUI code in one thread with one or more concurrent worker 
threads typically communicating through queues. But I haven't built 
anything like that recently, so I couldn't say how helpful the current 
documenation might be.


Interacting with the GUI only in the main thread is something that I've 
had to do in other languages (it is/was the recommended practice), so I 
naturally do the same with Python and tkinter. It's also easier to 
reason about because you don't get elements of the GUI changing 
unexpectedly.


[snip]
___
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] Drop/deprecate Tkinter?

[Abdur-Rahmaan Janhangeer]

Maybe the only 1 thing needs an update : some nice ui

else,

i'm glad python has a gui library

as one interested in languages, py is just crazy (though i miss some
android apps using it). in a GPL, a gui library is one of those extra
goodies

if you would browse the source codes, you'd see good old compiler theories
being used (no ANTLR for example)

tkinter is pretty good. as one that still believes in tkinter and has as a
result of it explored many apps, what you can do with tkinter is crazy. as
to no one using it; did you consider production: installing a 3rd party
package for what is already integrated

ah just the docs, they are not as candy as python's docs

to drop it, we use what? maybe we'll all join punching some bags before we
get a stable gui package in production

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ

On Thu, 3 May 2018, 00:55 Ivan Pozdeev via Python-Dev, <
python-dev@python.org> wrote:

> As https://bugs.python.org/issue33257 and
> https://bugs.python.org/issue33316 showed, Tkinter is broken, for both
> Py2 and Py3, with both threaded and non-threaded Tcl, since 2002 at
> least, and no-one gives a damn.
>
> This seems to be a testament that very few people are actually
> interested in or are using it.
>
> If that's so, there's no use keeping it in the standard library -- if
> anything, because there's not enough incentive and/or resources to
> support it. And to avoid screwing people (=me) up when they have the
> foolishness to think they can rely on it in their projects -- nowhere in
> the docs it is said that the module is only partly functional.
>
> --
>
> Regards,
> Ivan
>
> ___
> 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/arj.python%40gmail.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] Drop/deprecate Tkinter?

[Ryan Gonzalez]

On May 3, 2018 11:56:24 AM MRAB  wrote:


On 2018-05-03 13:24, Steve Holden wrote:

On Thu, May 3, 2018 at 12:12 AM, Ivan Pozdeev via Python-Dev
mailto:python-dev@python.org>> wrote:

On 03.05.2018 1:01, Antoine Pitrou wrote:

On Wed, 2 May 2018 22:54:04 +0100
Paul Moore mailto:p.f.mo...@gmail.com>> wrote:

On 2 May 2018 at 22:37, Antoine Pitrou mailto:solip...@pitrou.net>> wrote:

To elaborate a bit: the OP, while angry, produced both a
detailed
analysis *and* a PR.  It's normal to be angry when an
advertised
feature doesn't work and it makes you lose hours of work
(or, even,
forces you to a wholesale redesign). Producing a
detailed analysis and a
PR is more than most people will ever do.

His *other* email seems reasonable, and warrants a response,
yes. But
are we to take the suggestion made here (to drop tkinter)
seriously,
based on the fact that there's a (rare - at least it appears
that the
many IDLE users haven't hit it yet) race condition that
causes a crash
in Python 2.7? (It appears that the problem doesn't happen
in the
python.org  3.x builds, if I understand
the description of the issue).

In 3.x, Tkinter+threads is broken too, albeit in a different way --
see https://bugs.python.org/issue33412
 (this should've been the 2nd
link in the initial message, sorry for the mix-up).


​The observation in t​hat issue that tkinter and threads should be
handled in specific ways is certainly a given for old hands, who have
long put the GUI code in one thread with one or more concurrent worker
threads typically communicating through queues. But I haven't built
anything like that recently, so I couldn't say how helpful the current
documenation might be.


Interacting with the GUI only in the main thread is something that I've
had to do in other languages (it is/was the recommended practice), so I
naturally do the same with Python and tkinter. It's also easier to
reason about because you don't get elements of the GUI changing
unexpectedly.


To add to this, most GUI frameworks disallow modifications outside the main 
thread altogether. IIRC both GTK+ and Qt require this, or else it's 
undefined altogether.




[snip]
___
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/rymg19%40gmail.com



--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.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] Python startup time

[Brett Cannon]

On Thu, 3 May 2018 at 07:31 Nick Coghlan  wrote:

> On 3 May 2018 at 15:56, Glenn Linderman  wrote:
>
>> On 5/2/2018 8:56 PM, Gregory Szorc wrote:
>>
>> Nobody in the project is seriously talking about a complete rewrite in
>> Rust. Contributors to the project have varying opinions on how aggressively
>> Rust should be utilized. People who contribute to the C code, low-level
>> primitives (like storage, deltas, etc), and those who care about
>> performance tend to want more Rust. One thing we almost universally agree
>> on is that we want to rewrite all of Mercurial's C code in Rust. I
>> anticipate that figuring out the balance between Rust and Python in
>> Mercurial will be an ongoing conversation/process for the next few years.
>>
>> Have you considered simply rewriting CPython in Rust?
>>
>
> FWIW, I'd actually like to see Rust approved as a language for writing
> stdlib extension modules, but actually ever making that change in policy
> would require a concrete motivating use case.
>

Eric Snow, Barry Warsaw, and I have actually discussed this as part of our
weekly open source office hours as work where we tend to talk about massive
ideas that would take multiple people full-time to accomplish. :)


>
>
>> And yes, the 4th word in that question was intended to produce peals of
>> shocked laughter. But why Rust? Why not Go?
>>
>
> Trying to get two different garbage collection engines to play nice with
> each other is a recipe for significant pain, since you can easily end up
> with uncollectable cycles that neither GC system has complete visibility
> into (all it needs is a loop from PyObject A -> Go Object B -> back to
> PyObject A).
>
> Combining Python and Rust can still get into that kind of trouble when
> using reference counting on the Rust side, but it's a lot easier to avoid
> than it is in runtimes with mandatory GC.
>

Rust supports RAII
 so it shouldn't
be that bad.
___
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] Drop/deprecate Tkinter?

[Ivan Pozdeev via Python-Dev]

On 03.05.2018 20:11, Ryan Gonzalez wrote:

On May 3, 2018 11:56:24 AM MRAB  wrote:


On 2018-05-03 13:24, Steve Holden wrote:

On Thu, May 3, 2018 at 12:12 AM, Ivan Pozdeev via Python-Dev
mailto:python-dev@python.org>> wrote:

    On 03.05.2018 1:01, Antoine Pitrou wrote:

    On Wed, 2 May 2018 22:54:04 +0100
    Paul Moore > wrote:


    On 2 May 2018 at 22:37, Antoine Pitrou mailto:solip...@pitrou.net>> wrote:

    To elaborate a bit: the OP, while angry, produced 
both a

    detailed
    analysis *and* a PR.  It's normal to be angry when an
    advertised
    feature doesn't work and it makes you lose hours of 
work

    (or, even,
    forces you to a wholesale redesign). Producing a
    detailed analysis and a
    PR is more than most people will ever do.

    His *other* email seems reasonable, and warrants a 
response,

    yes. But
    are we to take the suggestion made here (to drop tkinter)
    seriously,
    based on the fact that there's a (rare - at least it 
appears

    that the
    many IDLE users haven't hit it yet) race condition that
    causes a crash
    in Python 2.7? (It appears that the problem doesn't happen
    in the
    python.org  3.x builds, if I understand
    the description of the issue).

    In 3.x, Tkinter+threads is broken too, albeit in a different way --
    see https://bugs.python.org/issue33412
     (this should've been the 2nd
    link in the initial message, sorry for the mix-up).


​The observation in t​hat issue that tkinter and threads should be
handled in specific ways is certainly a given for old hands, who have
long put the GUI code in one thread with one or more concurrent worker
threads typically communicating through queues. But I haven't built
anything like that recently, so I couldn't say how helpful the current
documenation might be.


Interacting with the GUI only in the main thread is something that I've
had to do in other languages (it is/was the recommended practice), so I
naturally do the same with Python and tkinter. It's also easier to
reason about because you don't get elements of the GUI changing
unexpectedly.


To add to this, most GUI frameworks disallow modifications outside the 
main thread altogether. IIRC both GTK+ and Qt require this, or else 
it's undefined altogether.


You still need some facility (*cough*SendMessage*cough*) to send update 
commands to the GUI (the model->view link in MVC, presenter->view in MVP).
Who and how specifically carries out these commands is unimportant, an 
implementation detail.


Every GUI has an event/message queue exactly for that, that other 
threads can sent work requests into:
https://doc.qt.io/qt-5.10/qcoreapplication.html#postEvent , 
https://developer.gnome.org/gdk3/stable/gdk3-Threads.html#gdk3-Threads.description 
, 
https://en.wikipedia.org/wiki/Event_dispatching_thread#Submitting_user_code_to_the_EDT 
, the aforementioned WinAPI's SendMessage() and PostMessage() just to 
name a few.


Tcl/Tk, being arguably the oldest usable GUI toolkit in existence, has 
an event queue likewise but doesn't provide a complete event loop 
implementation, only the building blocks for it. Tkinter fills that gap 
with its `tk.mainloop()`.
It fails to provide a working means to send work into it though. Having 
to use a second, duplicating event queue and poll it (=busy loop) 
instead is an obvious crutch.


[snip]
___
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/rymg19%40gmail.com



--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.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/vano%40mail.mipt.ru


--
Regards,
Ivan

___
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

[Python-Dev] Dealing with tone in an email (was: Drop/deprecate Tkinter?)

[Brett Cannon]

On Thu, 3 May 2018 at 01:27 Paul Moore  wrote:

> On 3 May 2018 at 03:26, Steven D'Aprano  wrote:
>
> >> Will all due respect, it's sometimes unpredictable what kind of wording
> >> Anglo-Saxons will take as an insult, as there's lot of obsequiosity
> >> there that doesn't exist in other cultures. To me, "not give a damn"
> >> reads like a familiar version of "not care about something", but
> >> apparently it can be offensive.
> >
> > I'm Anglo-Saxon[1], and honestly I believe that it is thin-skinned to
> > the point of ludicrousness to say that "no-one gives a damn" is an
> > insult. This isn't 1939 when Clark Gable's famous line "Frankly my dear,
> > I don't give a damn" was considered shocking. Its 2018 and to not give a
> > damn is a more forceful way of saying that people don't care, that they
> > are indifferent.
>
> Sigh. That's not what I was saying at all. I was trying to point out
> that Antoine's claim that people should ignore the rhetoric and that
> complaining about the attitude was unreasonable, was in itself unfair.
> People have a right to point out that a mail like the OP's was badly
> worded.
>
> > With respect to Paul, I literally cannot imagine why he thinks that
> > *anyone*, not even the tkinter maintainers or developers themselves,
> > ought to feel *offended* by Ivan's words.
>
> Personally, they didn't offend me. I don't pretend to know how others
> might take them. But they *did* annoy me. I'm frankly sick of people
> (not on this list) complaining that people who work on projects in
> their own time, free of charge, "don't care enough" or "are ignoring
> my requirement". We all do it, to an extent, and it's natural to get
> frustrated, but the onus is on the person asking for help to be polite
> and fair. And maybe this response was the one where I finally let that
> frustration show through. I may read less email for a week or two,
> just to get a break.
>

I had the same response as Paul: annoyed. And while Ivan thought he was
using "emotional language to drive the point home that it's not some
nitpick", it actually had the reverse effect on me and caused me not to
care because I don't need to invite annoyance into my life when putting in
my personal time into something.

No one is saying people can't be upset and if you are ever upset there's
something wrong; we're human beings after all. But those of us speaking up
about the tone are saying that you can also wait until you're not so upset
to write an email. This was never going to be resolved in an hour, so
waiting an hour until you're in a better place to write an email that
wasn't quite so inflammatory seems like a reasonable thing to ask.
___
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] Dealing with tone in an email

[Ivan Pozdeev via Python-Dev]

On 03.05.2018 21:31, Brett Cannon wrote:



On Thu, 3 May 2018 at 01:27 Paul Moore > wrote:


On 3 May 2018 at 03:26, Steven D'Aprano mailto:st...@pearwood.info>> wrote:

>> Will all due respect, it's sometimes unpredictable what kind of
wording
>> Anglo-Saxons will take as an insult, as there's lot of obsequiosity
>> there that doesn't exist in other cultures. To me, "not give a
damn"
>> reads like a familiar version of "not care about something", but
>> apparently it can be offensive.
>
> I'm Anglo-Saxon[1], and honestly I believe that it is
thin-skinned to
> the point of ludicrousness to say that "no-one gives a damn" is an
> insult. This isn't 1939 when Clark Gable's famous line "Frankly
my dear,
> I don't give a damn" was considered shocking. Its 2018 and to
not give a
> damn is a more forceful way of saying that people don't care,
that they
> are indifferent.

Sigh. That's not what I was saying at all. I was trying to point out
that Antoine's claim that people should ignore the rhetoric and that
complaining about the attitude was unreasonable, was in itself unfair.
People have a right to point out that a mail like the OP's was badly
worded.

> With respect to Paul, I literally cannot imagine why he thinks that
> *anyone*, not even the tkinter maintainers or developers themselves,
> ought to feel *offended* by Ivan's words.

Personally, they didn't offend me. I don't pretend to know how others
might take them. But they *did* annoy me. I'm frankly sick of people
(not on this list) complaining that people who work on projects in
their own time, free of charge, "don't care enough" or "are ignoring
my requirement". We all do it, to an extent, and it's natural to get
frustrated, but the onus is on the person asking for help to be polite
and fair. And maybe this response was the one where I finally let that
frustration show through. I may read less email for a week or two,
just to get a break.


I had the same response as Paul: annoyed. And while Ivan thought he 
was using "emotional language to drive the point home that it's not 
some nitpick", it actually had the reverse effect on me and caused me 
not to care because I don't need to invite annoyance into my life when 
putting in my personal time into something.


No one is saying people can't be upset and if you are ever upset 
there's something wrong; we're human beings after all. But those of us 
speaking up about the tone are saying that you can also wait until 
you're not so upset to write an email. This was never going to be 
resolved in an hour, so waiting an hour until you're in a better place 
to write an email that wasn't quite so inflammatory seems like a 
reasonable thing to ask.



Let me express things right from the horse's mouth.

The sole purpose of the tone was to not let the mesage be flat-out ignored.
I had my neutral-toned, to-the-point messages to mailing lists flat-out 
ignored one too many times for reasons that I can only guess about.

This time, the situation was too important to let that happen.

Whatever anyone may think of this, it worked. I got my message through, 
and got the feedback on the topic that I needed to proceed in resolving 
the problem that caused it.
I seriously doubt I could achieve that with a neutral-toned message just 
stating the facts: dry facts would not show ppl how this could be 
important ("ah, just another n00b struggling with Tkinter basics" or 
something).


___
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/vano%40mail.mipt.ru


--
Regards,
Ivan

___
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] Dealing with tone in an email

[Brian Curtin]

On Thu, May 3, 2018 at 2:45 PM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

> On 03.05.2018 21:31, Brett Cannon wrote:
>
>
>
> On Thu, 3 May 2018 at 01:27 Paul Moore  wrote:
>
>> On 3 May 2018 at 03:26, Steven D'Aprano  wrote:
>>
>> >> Will all due respect, it's sometimes unpredictable what kind of wording
>> >> Anglo-Saxons will take as an insult, as there's lot of obsequiosity
>> >> there that doesn't exist in other cultures. To me, "not give a damn"
>> >> reads like a familiar version of "not care about something", but
>> >> apparently it can be offensive.
>> >
>> > I'm Anglo-Saxon[1], and honestly I believe that it is thin-skinned to
>> > the point of ludicrousness to say that "no-one gives a damn" is an
>> > insult. This isn't 1939 when Clark Gable's famous line "Frankly my dear,
>> > I don't give a damn" was considered shocking. Its 2018 and to not give a
>> > damn is a more forceful way of saying that people don't care, that they
>> > are indifferent.
>>
>> Sigh. That's not what I was saying at all. I was trying to point out
>> that Antoine's claim that people should ignore the rhetoric and that
>> complaining about the attitude was unreasonable, was in itself unfair.
>> People have a right to point out that a mail like the OP's was badly
>> worded.
>>
>> > With respect to Paul, I literally cannot imagine why he thinks that
>> > *anyone*, not even the tkinter maintainers or developers themselves,
>> > ought to feel *offended* by Ivan's words.
>>
>> Personally, they didn't offend me. I don't pretend to know how others
>> might take them. But they *did* annoy me. I'm frankly sick of people
>> (not on this list) complaining that people who work on projects in
>> their own time, free of charge, "don't care enough" or "are ignoring
>> my requirement". We all do it, to an extent, and it's natural to get
>> frustrated, but the onus is on the person asking for help to be polite
>> and fair. And maybe this response was the one where I finally let that
>> frustration show through. I may read less email for a week or two,
>> just to get a break.
>>
>
> I had the same response as Paul: annoyed. And while Ivan thought he was
> using "emotional language to drive the point home that it's not some
> nitpick", it actually had the reverse effect on me and caused me not to
> care because I don't need to invite annoyance into my life when putting in
> my personal time into something.
>
> No one is saying people can't be upset and if you are ever upset there's
> something wrong; we're human beings after all. But those of us speaking up
> about the tone are saying that you can also wait until you're not so upset
> to write an email. This was never going to be resolved in an hour, so
> waiting an hour until you're in a better place to write an email that
> wasn't quite so inflammatory seems like a reasonable thing to ask.
>
> Let me express things right from the horse's mouth.
>
> The sole purpose of the tone was to not let the mesage be flat-out ignored.
> I had my neutral-toned, to-the-point messages to mailing lists flat-out
> ignored one too many times for reasons that I can only guess about.
> This time, the situation was too important to let that happen.
>
> Whatever anyone may think of this, it worked. I got my message through,
> and got the feedback on the topic that I needed to proceed in resolving the
> problem that caused it.
> I seriously doubt I could achieve that with a neutral-toned message just
> stating the facts: dry facts would not show ppl how this could be important
> ("ah, just another n00b struggling with Tkinter basics" or something).
>

As I said on the other thread, that doesn't make it any more acceptable as
over time it normalizes the behavior. If enough people want results—because
yes, sometimes things break, it's not fun, and sometimes things don't
receive response in the most timely fashion—they'll take that tone and
sometimes get what they want. Eventually it'll work enough that it becomes
more acceptable to behave that way, and eventually the people who are
willing to accept that type of behavior will be gone.
___
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] Python startup time

[Nathaniel Smith]

On Wed, May 2, 2018, 20:59 INADA Naoki  wrote:

> Recently, I reported how stdlib slows down `import requests`.
> https://github.com/requests/requests/issues/4315#issuecomment-385584974

[...]

> * Add faster and simpler http.parser (maybe, based on h11 [1]) and avoid
> using email module in http module.
>

It's always risky making predictions, but hopefully by the time 3.8 is out,
requests will have switched to using h11 directly instead of the http
module. (Kenneth wants the big headline feature for the next major requests
release to be async support, and that pretty much requires switching to
something like h11.)

I don't know how fast importing h11 is though... It does currently compile
a bunch of regexps at import time :-).

-n
___
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] Process to remove a Python feature

[Facundo Batista]

2018-05-02 14:24 GMT-03:00 Brett Cannon :

>> Maybe we should create a tool to list features scheduled for removal,
>> and open a discussion to check each removal?
>
> I don't know if a tool is necessary. We could have a meta issue or text file
> somewhere to track what's to be removed in a certain version.

Maybe a specific PEP that list all removals that happened, those that
will happen next version, and next ones after that?

IOW, a single point where one can see which features/details will fly
away and when.

Probably it's a good idea to see everything at once and evaluate if
"we're removing too many things at once", and have a better
deprecation/removal cadence.

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
Twitter: @facundobatista
___
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] Dealing with tone in an email

[Guido van Rossum]

EVENTUALLY WE'LL ALL BE SHOUTING ALL THE TIME. Sad.

On Thu, May 3, 2018, 11:57 Brian Curtin  wrote:

> On Thu, May 3, 2018 at 2:45 PM Ivan Pozdeev via Python-Dev <
> python-dev@python.org> wrote:
>
>> On 03.05.2018 21:31, Brett Cannon wrote:
>>
>>
>>
>> On Thu, 3 May 2018 at 01:27 Paul Moore  wrote:
>>
>>> On 3 May 2018 at 03:26, Steven D'Aprano  wrote:
>>>
>>> >> Will all due respect, it's sometimes unpredictable what kind of
>>> wording
>>> >> Anglo-Saxons will take as an insult, as there's lot of obsequiosity
>>> >> there that doesn't exist in other cultures. To me, "not give a damn"
>>> >> reads like a familiar version of "not care about something", but
>>> >> apparently it can be offensive.
>>> >
>>> > I'm Anglo-Saxon[1], and honestly I believe that it is thin-skinned to
>>> > the point of ludicrousness to say that "no-one gives a damn" is an
>>> > insult. This isn't 1939 when Clark Gable's famous line "Frankly my
>>> dear,
>>> > I don't give a damn" was considered shocking. Its 2018 and to not give
>>> a
>>> > damn is a more forceful way of saying that people don't care, that they
>>> > are indifferent.
>>>
>>> Sigh. That's not what I was saying at all. I was trying to point out
>>> that Antoine's claim that people should ignore the rhetoric and that
>>> complaining about the attitude was unreasonable, was in itself unfair.
>>> People have a right to point out that a mail like the OP's was badly
>>> worded.
>>>
>>> > With respect to Paul, I literally cannot imagine why he thinks that
>>> > *anyone*, not even the tkinter maintainers or developers themselves,
>>> > ought to feel *offended* by Ivan's words.
>>>
>>> Personally, they didn't offend me. I don't pretend to know how others
>>> might take them. But they *did* annoy me. I'm frankly sick of people
>>> (not on this list) complaining that people who work on projects in
>>> their own time, free of charge, "don't care enough" or "are ignoring
>>> my requirement". We all do it, to an extent, and it's natural to get
>>> frustrated, but the onus is on the person asking for help to be polite
>>> and fair. And maybe this response was the one where I finally let that
>>> frustration show through. I may read less email for a week or two,
>>> just to get a break.
>>>
>>
>> I had the same response as Paul: annoyed. And while Ivan thought he was
>> using "emotional language to drive the point home that it's not some
>> nitpick", it actually had the reverse effect on me and caused me not to
>> care because I don't need to invite annoyance into my life when putting in
>> my personal time into something.
>>
>> No one is saying people can't be upset and if you are ever upset there's
>> something wrong; we're human beings after all. But those of us speaking up
>> about the tone are saying that you can also wait until you're not so upset
>> to write an email. This was never going to be resolved in an hour, so
>> waiting an hour until you're in a better place to write an email that
>> wasn't quite so inflammatory seems like a reasonable thing to ask.
>>
>> Let me express things right from the horse's mouth.
>>
>> The sole purpose of the tone was to not let the mesage be flat-out
>> ignored.
>> I had my neutral-toned, to-the-point messages to mailing lists flat-out
>> ignored one too many times for reasons that I can only guess about.
>> This time, the situation was too important to let that happen.
>>
>> Whatever anyone may think of this, it worked. I got my message through,
>> and got the feedback on the topic that I needed to proceed in resolving the
>> problem that caused it.
>> I seriously doubt I could achieve that with a neutral-toned message just
>> stating the facts: dry facts would not show ppl how this could be important
>> ("ah, just another n00b struggling with Tkinter basics" or something).
>>
>
> As I said on the other thread, that doesn't make it any more acceptable as
> over time it normalizes the behavior. If enough people want results—because
> yes, sometimes things break, it's not fun, and sometimes things don't
> receive response in the most timely fashion—they'll take that tone and
> sometimes get what they want. Eventually it'll work enough that it becomes
> more acceptable to behave that way, and eventually the people who are
> willing to accept that type of behavior will be gone.
> ___
> 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] Process to remove a Python feature

[Brett Cannon]

On Thu, 3 May 2018 at 12:01 Facundo Batista 
wrote:

> 2018-05-02 14:24 GMT-03:00 Brett Cannon :
>
> >> Maybe we should create a tool to list features scheduled for removal,
> >> and open a discussion to check each removal?
> >
> > I don't know if a tool is necessary. We could have a meta issue or text
> file
> > somewhere to track what's to be removed in a certain version.
>
> Maybe a specific PEP that list all removals that happened, those that
> will happen next version, and next ones after that?
>

I don't know if we need a history section as the What's New docs cover
that. But having a PEP or some other file/doc that acts like a future
What's New but for removals seems like a reasonable idea.

-Brett


>
> IOW, a single point where one can see which features/details will fly
> away and when.
>
> Probably it's a good idea to see everything at once and evaluate if
> "we're removing too many things at once", and have a better
> deprecation/removal cadence.
>
> --
> .Facundo
>
> Blog: http://www.taniquetil.com.ar/plog/
> PyAr: http://www.python.org/ar/
> Twitter: @facundobatista
>
___
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

[Python-Dev] A fast startup patch (was: Python startup time)

[Carl Shapiro]

Hello,

Yesterday Neil Schemenauer mentioned some work that a colleague of mine
(CCed) and I have done to improve CPython start-up time.  Given the recent
discussion, it seems timely to discuss what we are doing and whether it is
of interest to other people hacking on the CPython runtime.

There are many ways to reduce the start-up time overhead.  For this
experiment, we are specifically targeting the cost of unmarshaling heap
objects from compiled Python bytecode.  Our measurements show this specific
cost to represent 10% to 25% of the start-up time among the applications we
have examined.

Our approach to eliminating this overhead is to store unmarshaled objects
into the data segment of the python executable.  We do this by processing
the compiled python bytecode for a module, creating native object code with
the unmarshaled objects in their in-memory representation, and linking this
into the python executable.

When a module is imported, we simply return a pointer to the top-level code
object in the data segment directly without invoking the unmarshaling code
or touching the file system.  What we are doing is conceptually similar to
the existing capability to freeze a module, but we avoid non-trivial
unmarshaling costs.

The patch is still under development and there is still a little bit more
work to do.  With that in mind, the numbers look good but please take these
with a grain of salt

Baseline

$ bench "./python.exe -c ''"
benchmarking ./python.exe -c ''
time 31.46 ms   (31.24 ms .. 31.78 ms)
 1.000 R²   (0.999 R² .. 1.000 R²)
mean 32.08 ms   (31.82 ms .. 32.63 ms)
std dev  778.1 μs   (365.6 μs .. 1.389 ms)

$ bench "./python.exe -c 'import difflib'"
benchmarking ./python.exe -c 'import difflib'
time 32.82 ms   (32.64 ms .. 33.02 ms)
 1.000 R²   (1.000 R² .. 1.000 R²)
mean 33.17 ms   (33.01 ms .. 33.44 ms)
std dev  430.7 μs   (233.8 μs .. 675.4 μs)


With our patch

$ bench "./python.exe -c ''"
benchmarking ./python.exe -c ''
time 24.86 ms   (24.62 ms .. 25.08 ms)
 0.999 R²   (0.999 R² .. 1.000 R²)
mean 25.58 ms   (25.36 ms .. 25.94 ms)
std dev  592.8 μs   (376.2 μs .. 907.8 μs)

$ bench "./python.exe -c 'import difflib'"
benchmarking ./python.exe -c 'import difflib'
time 25.30 ms   (25.00 ms .. 25.55 ms)
 0.999 R²   (0.998 R² .. 1.000 R²)
mean 26.78 ms   (26.30 ms .. 27.64 ms)
std dev  1.413 ms   (747.5 μs .. 2.250 ms)
variance introduced by outliers: 20% (moderately inflated)


Here are some numbers with the patch but with the stat calls preserved to
isolate just the marshaling effects

Baseline

$ bench "./python.exe -c 'import difflib'"
benchmarking ./python.exe -c 'import difflib'
time 34.67 ms   (33.17 ms .. 36.52 ms)
 0.995 R²   (0.990 R² .. 1.000 R²)
mean 35.36 ms   (34.81 ms .. 36.25 ms)
std dev  1.450 ms   (1.045 ms .. 2.133 ms)
variance introduced by outliers: 12% (moderately inflated)


With our patch (and calls to stat)

$ bench "./python.exe -c 'import difflib'"
benchmarking ./python.exe -c 'import difflib'
time 30.24 ms   (29.02 ms .. 32.66 ms)
 0.988 R²   (0.968 R² .. 1.000 R²)
mean 31.86 ms   (31.13 ms .. 32.75 ms)
std dev  1.789 ms   (1.329 ms .. 2.437 ms)
variance introduced by outliers: 17% (moderately inflated)


(This work was done in CPython 3.6 and we are exploring back-porting to 2.7
so we can run the hg startup benchmarks in the performance test suite.)

This is effectively a drop-in replacement for the frozen module capability
and (so far) required only minimal changes to the runtime.  To us, it seems
like a very nice win without compromising on compatibility or complexity.
I am happy to discuss more of the technical details until we have a public
patch available.

I hope this provides some optimism around the possibility of improving the
start-up time of CPython.  What do you all think?

Kindly,

Carl
___
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] Dealing with tone in an email

[Brett Cannon]

On Thu, 3 May 2018 at 12:29 Guido van Rossum  wrote:

> EVENTUALLY WE'LL ALL BE SHOUTING ALL THE TIME. Sad.
>

Yep. And that leads to burn-out. So while Ivan may have lucked out in
getting the attention of people who are helped him (and given the wrong
kind of positive reinforcement that this approach is reasonable), this can
lead to people quitting open source and not being available to help you
next time (e.g. notice how it drove Paul Moore over the edge to pull back
for a week or so and he may have been the expert you needed for packaging
or me for imports; IOW I would say Ivan was lucky this time and may not be
so lucky next time).

-Brett


>
> On Thu, May 3, 2018, 11:57 Brian Curtin  wrote:
>
>> On Thu, May 3, 2018 at 2:45 PM Ivan Pozdeev via Python-Dev <
>> python-dev@python.org> wrote:
>>
>>> On 03.05.2018 21:31, Brett Cannon wrote:
>>>
>>>
>>>
>>> On Thu, 3 May 2018 at 01:27 Paul Moore  wrote:
>>>
 On 3 May 2018 at 03:26, Steven D'Aprano  wrote:

 >> Will all due respect, it's sometimes unpredictable what kind of
 wording
 >> Anglo-Saxons will take as an insult, as there's lot of obsequiosity
 >> there that doesn't exist in other cultures. To me, "not give a damn"
 >> reads like a familiar version of "not care about something", but
 >> apparently it can be offensive.
 >
 > I'm Anglo-Saxon[1], and honestly I believe that it is thin-skinned to
 > the point of ludicrousness to say that "no-one gives a damn" is an
 > insult. This isn't 1939 when Clark Gable's famous line "Frankly my
 dear,
 > I don't give a damn" was considered shocking. Its 2018 and to not
 give a
 > damn is a more forceful way of saying that people don't care, that
 they
 > are indifferent.

 Sigh. That's not what I was saying at all. I was trying to point out
 that Antoine's claim that people should ignore the rhetoric and that
 complaining about the attitude was unreasonable, was in itself unfair.
 People have a right to point out that a mail like the OP's was badly
 worded.

 > With respect to Paul, I literally cannot imagine why he thinks that
 > *anyone*, not even the tkinter maintainers or developers themselves,
 > ought to feel *offended* by Ivan's words.

 Personally, they didn't offend me. I don't pretend to know how others
 might take them. But they *did* annoy me. I'm frankly sick of people
 (not on this list) complaining that people who work on projects in
 their own time, free of charge, "don't care enough" or "are ignoring
 my requirement". We all do it, to an extent, and it's natural to get
 frustrated, but the onus is on the person asking for help to be polite
 and fair. And maybe this response was the one where I finally let that
 frustration show through. I may read less email for a week or two,
 just to get a break.

>>>
>>> I had the same response as Paul: annoyed. And while Ivan thought he was
>>> using "emotional language to drive the point home that it's not some
>>> nitpick", it actually had the reverse effect on me and caused me not to
>>> care because I don't need to invite annoyance into my life when putting in
>>> my personal time into something.
>>>
>>> No one is saying people can't be upset and if you are ever upset there's
>>> something wrong; we're human beings after all. But those of us speaking up
>>> about the tone are saying that you can also wait until you're not so upset
>>> to write an email. This was never going to be resolved in an hour, so
>>> waiting an hour until you're in a better place to write an email that
>>> wasn't quite so inflammatory seems like a reasonable thing to ask.
>>>
>>> Let me express things right from the horse's mouth.
>>>
>>> The sole purpose of the tone was to not let the mesage be flat-out
>>> ignored.
>>> I had my neutral-toned, to-the-point messages to mailing lists flat-out
>>> ignored one too many times for reasons that I can only guess about.
>>> This time, the situation was too important to let that happen.
>>>
>>> Whatever anyone may think of this, it worked. I got my message through,
>>> and got the feedback on the topic that I needed to proceed in resolving the
>>> problem that caused it.
>>> I seriously doubt I could achieve that with a neutral-toned message just
>>> stating the facts: dry facts would not show ppl how this could be important
>>> ("ah, just another n00b struggling with Tkinter basics" or something).
>>>
>>
>> As I said on the other thread, that doesn't make it any more acceptable
>> as over time it normalizes the behavior. If enough people want
>> results—because yes, sometimes things break, it's not fun, and sometimes
>> things don't receive response in the most timely fashion—they'll take that
>> tone and sometimes get what they want. Eventually it'll work enough that it
>> becomes more acceptable to behave that way, and eventually the people who
>> are willing to accept that type of be

Re: [Python-Dev] Drop/deprecate Tkinter?

[Matěj Cepl]

On 2018-05-03, 15:56 GMT, Tim Peters wrote:
> IDLE isn't just for eager beginners, but also for those so old 
> & senile they're incapable of learning anything new ever again.  As
> proof, IDLE is still _my_ primary Python development environment, used
> multiple times every day, and I'm so old & out-of-it that I'm +1 on
> the binding expressions PEP ;-)

Glad to find that such person exists! I thought that you are 
just a mythical legend, I am glad to be shown otherwise.

Best,

Matěj Cepl
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
To err is human, to purr feline.

___
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] Dealing with tone in an email

[Terry Reedy]

On 5/3/2018 2:45 PM, Ivan Pozdeev via Python-Dev wrote:


Let me express things right from the horse's mouth.


Ditto, as the only person who responded on the tracker before you posted 
here and the only person other that Guido to respond on the tracker 
since and the only person to collect data which mostly refute your claims.



The sole purpose of the tone was to not let the mesage be flat-out ignored.
I had my neutral-toned, to-the-point messages to mailing lists flat-out 
ignored one too many times for reasons that I can only guess about.


For 24 years, from 1994 to 2017, _tkinter.c has gotten 333 revisions at 
a steady rate, an average of about 1 patch per month.  Tkinter's .py 
files have gotten even more -- 426 -- including 5 in the first 4 months 
of this year.  I think at least 20 different core developers, including 
me, have been involved over the years.  Calling this 'indifference' is 
dog poo.


I believe these patches mostly or all happened from people making 
relatively calm reports, like you originally did.


Other people wait at least a month, or two or three, without *any* 
response to a patch.  If they care, they write a polite note to 
core-mentorship or pydev.  Then someone nearly always responds and 
reviews their patch.



This time, the situation was too important to let that happen.


The situation was that the tkinter maintainer, Serhiy Storchaka, and a 
tkinter user, me, had already given you initial responses.  I indecated 
that I considered the issue real and Serhiy promised a review of your patch.


The tkinter situation is that if one makes tk calls to the main thread 
from other threads when using non-thread tcl/tk, bad thinks can happen. 
No surprise.  It turns out that some of the people above have tried but 
only partly succeeded in making thread calls work even with non-thread 
tcl/tk.  This was generally known, but you added the fact that tcl has a 
thread compile switch. I do appreciate knowing a concrete reason why 
different people get different results with the same code.


If your patch improves the situation great, but very few people will be 
affected.  This is really not important to people who don't do the 
above, and not worth disrupting pydev.


You appear to claim that your 2nd example, sending fake events to the 
main thread, reposted to https://bugs.python.org/issue33412,
fails even with thread tcl/tk.  However, when I tested with 3.6 
repository, 3.7 installed, and 3.8 repository builds, it nearly finished 
rather than failing immediately.  When I fixed the deadlock bug, IT RAN 
TO COMPLETION.


TO EVERYONE ELSE: If you want to be helpful, ignore the pydev threads. 
If you have a tcl thread build, as indicated by the 't' in 'tcl86t.dll' 
in /dlls, test the example, with my fix, on your machine and report on 
the tracker.



Whatever anyone may think of this, it worked.


This makes me want to scream.  I was about to respond to msg316087 on
https://bugs.python.org/issue33257 when I saw the crap about removing 
tkinter.  I considered washing my hands of the issue then and there, to 
avoid 'rewarding' your nastiness.  But because I care about tkinter, I 
decided to continue on the tracker and then inform you in yesterday's 
response on the thread that I did so in spite of, not because of, 
'this'.  Since you ignored me and continue to defend 'this', I say it 
again, and request that you retract your 'delete tkinter' post.


--
Terry Jan Reedy

___
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] Python startup time

[Gregory P. Smith]

On Wed, May 2, 2018 at 2:13 PM, Barry Warsaw  wrote:

> Thanks for bringing this topic up again.  At $day_job, this is a highly
> visible and important topic, since the majority of our command line tools
> are written in Python (of varying versions from 2.7 to 3.6).  Some of those
> tools can take upwards of 5 seconds or more just to respond to —help, which
> causes lots of pain for developers, who complain (rightly so) up the
> management chain. ;)
>
> We’ve done a fair bit of work to bring those numbers down without super
> radical workarounds.  Often there are problems not strictly related to the
> Python interpreter that contribute to this.  Python gets blamed, but it’s
> not always the interpreter’s fault.  Common issues include:
>
> * Modules that have import-time side effects, such as network access or
> expensive creation of data structures.  Python 3.7’s `-X importtime` switch
> is a really wonderful way to identify the worst offenders.  Once 3.7 is
> released, I do plan to spend some time using this to collect data
> internally so we can attack our own libraries, and perhaps put automated
> performance testing into our build stack, to identify start up time
> regressions.
>
> * pkg_resources.  When you have tons of entries on sys.path, pkg_resources
> does a lot of work at import time, and because of common patterns which
> tend to use pkg_resources namespace package support in __init__.py files,
> this just kills start up times.  Of course, pkg_resources has other uses
> too, so even in a purely Python 3 world (where your namespace packages can
> omit the __init__.py), you’ll often get clobbered as soon as you want to
> use the Basic Resource Access API.  This is also pretty common, and it’s
> the main reason why Brett and I created importlib.resources for 3.7 (with a
> standalone API-compatible library for older Pythons).  That’s one less
> reason to use pkg_resources, but it doesn’t address the __init__.py use.
> Brett and I have been talking about addressing that for 3.8.
>
> * pex - which we use as our single file zipapp tool.  Especially the
> interaction between pex and pkg_resources introduces pretty significant
> overhead.  My colleague Loren Carvalho created a tool called shiv which
> requires at least Python 3.6, avoids the use of pkg_resources, and
> implements other tricks to be much more performant than pex.   Shiv is now
> open source and you can find it on RTD and GitHub.
>
> The switch to shiv and importlib.resources can shave 25-50% off of warm
> cache start up times for zipapp style executables.
>
> Another thing we’ve done, although I’m much less sanguine about them as a
> general approach, is to move imports into functions, but we’re trying to
> only use that trick on the most critical cases.
>
> Some import time effects can’t be changed.  Decorators come to mind, and
> click is a popular library for CLIs that provides some great features, but
> decorators do prevent a lazy loading approach.
>
> > On May 1, 2018, at 20:26, Gregory Szorc  wrote:
>
> >> You might think "what's a few milliseconds matter".  But if you run
> >> hundreds of commands in a shell script it adds up.  git's speed is one
> >> of the few bright spots in its UX, and hg's comparative slowness here is
> >> a palpable disadvantage.
>
> Oh, for command line tools, milliseconds absolutely matter.
>
> > As a concrete example, I recently landed a Mercurial patch [2] that
> > stubs out zope.interface to prevent the import of 9 modules on every
> > `hg` invocation.
>
> I have a similar dastardly plan to provide a pkg_resources stub :).
>
> > Mercurial provides a `chg` program that essentially spins up a daemon
> > `hg` process running a "command server" so the `chg` program [written in
> > C - no startup overhead] can dispatch commands to an already-running
> > Python/`hg` process and avoid paying the startup overhead cost. When you
> > run Mercurial's test suite using `chg`, it completes *minutes* faster.
> > `chg` exists mainly as a workaround for slow startup overhead.
>
> A couple of our developers demoed a similar approach for one of our CLIs
> that almost everyone uses.  It’s a big application with lots of
> dependencies, so particularly vulnerable to pex and pkg_resources
> overhead.  While it was just a prototype, it was darn impressive to see
> subsequent invocations produce output almost immediately.  It’s unfortunate
> that we have to utilize all these tricks to get even moderately performant
> Python CLIs.
>
>
Note that this kind of "trick" is not unique to Python.  I see it used by
large Java tools at work.  In effect emacs has done similar things for many
decades with its saved core-dump at build time. It saves a snapshot of
initialized elisp interpreter state and loads that into memory instead of
rerunning initialization to reproduce the state.

I don't know if anyone has looked at making a similar concept of saved
post-startup interpreter state for rapid loading as a memory image possible
in Python.

Re: [Python-Dev] Python startup time

[Ray Donnelly]

On Wed, May 2, 2018 at 6:55 PM, Nathaniel Smith  wrote:
> On Wed, May 2, 2018, 09:51 Gregory Szorc  wrote:
>>
>> Correct me if I'm wrong, but aren't there downsides with regards to C
>> extension compatibility to not having a shared libpython? Or does all the
>> packaging tooling "just work" without a libpython? (It's possible I have
my
>> wires crossed up with something else regarding a statically linked
Python.)
>
>
> IIRC, the rule on Linux is that if you build an extension on a statically
> built python, then it can be imported on a shared python, but not
> vice-versa. Manylinux wheels are therefore always built on a static python
> so that they'll work everywhere. (We should probably clean this up
upstream
> at some point, but there's not a lot of appetite for touching this stuff –
> very obscure, very easy to break things without realizing it, not much
> upside.)
>
> On Windows I don't think there is such a thing as a static build, because
> extensions have to link to the python dll to work at all. And on MacOS I'm
> not sure, though from knowing how their linker works my guess is that all
> extensions act like static extensions do on Linux.

Yes, on Windows there's always a python?.dll.

macOS is an interesting one. For Anaconda 5.0 I read somewhere (how's that
for a useless reference - and perhaps I got the wrong end of the stick)
that Python for all Unixen should use a statically linked interpreter so I
happily went ahead and did that. Of course I tested it against a good few
wheels at the time and everything seemed fine (well, no worse than the
usual binary compatibility woes at least) so I went ahead with it.

Now that Python 3.7 is around the corner we have a chance to re-evaluate
this decision. We have received no binary compat. bugs whatsoever due to
this change (we got a few bugs where people used python-config incorrectly
either directly or via swig or CMake), were we just lucky?

Anyway, it is obviously safer for us to do what upstream does and I will
try to post some benchmarks of static vs shared to the list so we can
discuss it. I guess it is a little late in the release schedule to propose
any such change for 3.7? If not I will try to prepare something. I will
discuss it in depth with the rest of the AD team soon too.

>
> ___
> 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/mingw.android%40gmail.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] Python startup time

[Lukasz Langa]

> On May 2, 2018, at 8:57 PM, INADA Naoki  wrote:
> 
> Recently, I reported how stdlib slows down `import requests`.
> https://github.com/requests/requests/issues/4315#issuecomment-385584974
> 
> For Python 3.8, my ideas for faster startup time are:
> 
> * Add lazy compiling API or flag in `re` module.  The pattern is compiled
> when first used.

How about go the other way and allow compiling at Python *compile*-time? That 
would actually make things faster instead of just moving the time spent around.

I do see value in being less eager in Python but I think the real wins are 
hiding behind ahead-of-time compilation.

- Ł
___
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] A fast startup patch (was: Python startup time)

[Gregory P. Smith]

+1 to the concept!

On Thu, May 3, 2018 at 1:13 PM, Carl Shapiro  wrote:

> Hello,
>
> Yesterday Neil Schemenauer mentioned some work that a colleague of mine
> (CCed) and I have done to improve CPython start-up time.  Given the recent
> discussion, it seems timely to discuss what we are doing and whether it is
> of interest to other people hacking on the CPython runtime.
>
> There are many ways to reduce the start-up time overhead.  For this
> experiment, we are specifically targeting the cost of unmarshaling heap
> objects from compiled Python bytecode.  Our measurements show this specific
> cost to represent 10% to 25% of the start-up time among the applications we
> have examined.
>
> Our approach to eliminating this overhead is to store unmarshaled objects
> into the data segment of the python executable.  We do this by processing
> the compiled python bytecode for a module, creating native object code with
> the unmarshaled objects in their in-memory representation, and linking this
> into the python executable.
>
> When a module is imported, we simply return a pointer to the top-level
> code object in the data segment directly without invoking the unmarshaling
> code or touching the file system.  What we are doing is conceptually
> similar to the existing capability to freeze a module, but we avoid
> non-trivial unmarshaling costs.
>
> The patch is still under development and there is still a little bit more
> work to do.  With that in mind, the numbers look good but please take these
> with a grain of salt
>
> Baseline
>
> $ bench "./python.exe -c ''"
> benchmarking ./python.exe -c ''
> time 31.46 ms   (31.24 ms .. 31.78 ms)
>  1.000 R²   (0.999 R² .. 1.000 R²)
> mean 32.08 ms   (31.82 ms .. 32.63 ms)
> std dev  778.1 μs   (365.6 μs .. 1.389 ms)
>
> $ bench "./python.exe -c 'import difflib'"
> benchmarking ./python.exe -c 'import difflib'
> time 32.82 ms   (32.64 ms .. 33.02 ms)
>  1.000 R²   (1.000 R² .. 1.000 R²)
> mean 33.17 ms   (33.01 ms .. 33.44 ms)
> std dev  430.7 μs   (233.8 μs .. 675.4 μs)
>
>
> With our patch
>
> $ bench "./python.exe -c ''"
> benchmarking ./python.exe -c ''
> time 24.86 ms   (24.62 ms .. 25.08 ms)
>  0.999 R²   (0.999 R² .. 1.000 R²)
> mean 25.58 ms   (25.36 ms .. 25.94 ms)
> std dev  592.8 μs   (376.2 μs .. 907.8 μs)
>
> $ bench "./python.exe -c 'import difflib'"
> benchmarking ./python.exe -c 'import difflib'
> time 25.30 ms   (25.00 ms .. 25.55 ms)
>  0.999 R²   (0.998 R² .. 1.000 R²)
> mean 26.78 ms   (26.30 ms .. 27.64 ms)
> std dev  1.413 ms   (747.5 μs .. 2.250 ms)
> variance introduced by outliers: 20% (moderately inflated)
>
>
> Here are some numbers with the patch but with the stat calls preserved to
> isolate just the marshaling effects
>
> Baseline
>
> $ bench "./python.exe -c 'import difflib'"
> benchmarking ./python.exe -c 'import difflib'
> time 34.67 ms   (33.17 ms .. 36.52 ms)
>  0.995 R²   (0.990 R² .. 1.000 R²)
> mean 35.36 ms   (34.81 ms .. 36.25 ms)
> std dev  1.450 ms   (1.045 ms .. 2.133 ms)
> variance introduced by outliers: 12% (moderately inflated)
>
>
> With our patch (and calls to stat)
>
> $ bench "./python.exe -c 'import difflib'"
> benchmarking ./python.exe -c 'import difflib'
> time 30.24 ms   (29.02 ms .. 32.66 ms)
>  0.988 R²   (0.968 R² .. 1.000 R²)
> mean 31.86 ms   (31.13 ms .. 32.75 ms)
> std dev  1.789 ms   (1.329 ms .. 2.437 ms)
> variance introduced by outliers: 17% (moderately inflated)
>
>
> (This work was done in CPython 3.6 and we are exploring back-porting to
> 2.7 so we can run the hg startup benchmarks in the performance test suite.)
>
> This is effectively a drop-in replacement for the frozen module capability
> and (so far) required only minimal changes to the runtime.  To us, it seems
> like a very nice win without compromising on compatibility or complexity.
> I am happy to discuss more of the technical details until we have a public
> patch available.
>
> I hope this provides some optimism around the possibility of improving the
> start-up time of CPython.  What do you all think?
>
> Kindly,
>
> Carl
>
>
> ___
> 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/
> greg%40krypto.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] Python startup time

[Gregory P. Smith]

On Thu, May 3, 2018 at 5:22 PM, Lukasz Langa  wrote:

>
> > On May 2, 2018, at 8:57 PM, INADA Naoki  wrote:
> >
> > Recently, I reported how stdlib slows down `import requests`.
> > https://github.com/requests/requests/issues/4315#issuecomment-385584974
> >
> > For Python 3.8, my ideas for faster startup time are:
> >
> > * Add lazy compiling API or flag in `re` module.  The pattern is compiled
> > when first used.
>
> How about go the other way and allow compiling at Python *compile*-time?
> That would actually make things faster instead of just moving the time
> spent around.
>
> I do see value in being less eager in Python but I think the real wins are
> hiding behind ahead-of-time compilation.
>

Agreed in concept.  We've got a lot of unused letters that could be new
string prefixes... (ugh)

I'd also like to see this concept somehow extended to decorators so that
the results of the decoration can be captured in the compiled pyc rather
than requiring execution at import time.  I realize that limits what
decorators can do, but the evil things they could do that this would
eliminate are things they just shouldn't be doing in most situations.
meaning: there would probably be two types of decorators... colons seem to
be all the rage these days so we could add an @: operator for that. :P ...
Along with a from __future__ import to change the behavior or all
decorators in a file from runtime to compile time by default.

from __future__ import compile_time_decorators  # we'd be unlikely to ever
change the default and break things, __future__ seems wrong

@this_happens_at_compile_time(3)
def ...

@:this_waits_until_runtime(5)
def ...

Just a not-so-wild idea, no idea if this should become a PEP for 3.8.  (the
: syntax is a joke - i'd prefer @@ so it looks like eyeballs)

If this were done to decorators, you can imagine extending that concept to
something similar to allow compile time re.compile calls as some form of
assignment decorator:

GREGS_RE = @re.compile(r'A regex compiled at compile time\. number = \d+')

-gps


> - Ł
> ___
> 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/
> greg%40krypto.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] Python startup time

[Chris Angelico]

On Fri, May 4, 2018 at 10:43 AM, Gregory P. Smith  wrote:
> I'd also like to see this concept somehow extended to decorators so that the
> results of the decoration can be captured in the compiled pyc rather than
> requiring execution at import time.  I realize that limits what decorators
> can do, but the evil things they could do that this would eliminate are
> things they just shouldn't be doing in most situations.  meaning: there
> would probably be two types of decorators... colons seem to be all the rage
> these days so we could add an @: operator for that. :P ... Along with a from
> __future__ import to change the behavior or all decorators in a file from
> runtime to compile time by default.
>
> from __future__ import compile_time_decorators  # we'd be unlikely to ever
> change the default and break things, __future__ seems wrong
>
> @this_happens_at_compile_time(3)
> def ...
>
> @:this_waits_until_runtime(5)
> def ...
>
> Just a not-so-wild idea, no idea if this should become a PEP for 3.8.  (the
> : syntax is a joke - i'd prefer @@ so it looks like eyeballs)

At this point, we're squarely in python-ideas territory, but there are
some possibilities. Imagine popping this line of code at the bottom of
your file:

import importlib; importlib.freeze_module()

as a declaration that the dictionary for this module is now locked in
and can be dumped out in whatever form is most efficient. Effectively,
you're stating that you do not need any sort of dynamism (that call
could be easily disabled for testing), and that, if the optimization
breaks anything, you accept responsibility for it.

How this would be implemented, I'm not sure, but that's no different
from the @: idea.

ChrisA
___
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] Drop/deprecate Tkinter?

[Wes Turner]

On Thursday, May 3, 2018, Steven D'Aprano  wrote:

> On Thu, May 03, 2018 at 07:39:05AM +0200, Matěj Cepl wrote:
>
> > I have my doubts about IDLE though. I know, the same
> > argument applies, but really, does anybody use IDLE for
> > development for long time
>
> Yes, tons of beginners use it. On the tutor and python-list mailing
> lists, there are plenty of questions from people using IDLE.


Turtle is built with Tkinter:
https://docs.python.org/3/library/turtle.html

IIRC, I used IDLE when first learning Python.
Dive Into Python 3 recommends IDLE.
http://www.diveintopython3.net/installing-python.html#idle

Hopefully this bug is fixed by someone.

PyQt and PySide:
- are more accessible to screen readers
- support QThread, QThreadPool, QRunnable
- quamash is an asyncio event loop with/for Qt
- PyQtGraph



>
> --
> Steve
> ___
> 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/
> wes.turner%40gmail.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] Python startup time

[Chris Jerdonek]

FYI, a lot of these ideas were discussed back in September and October of
2017 on this list if you search the subject lines for "startup" e.g.
starting here and here:
https://mail.python.org/pipermail/python-dev/2017-September/149150.html
https://mail.python.org/pipermail/python-dev/2017-October/149670.html

At the end Guido kicked (at least part of) the discussion back to
python-ideas.

--Chris


On Thu, May 3, 2018 at 5:55 PM, Chris Angelico  wrote:

> On Fri, May 4, 2018 at 10:43 AM, Gregory P. Smith  wrote:
> > I'd also like to see this concept somehow extended to decorators so that
> the
> > results of the decoration can be captured in the compiled pyc rather than
> > requiring execution at import time.  I realize that limits what
> decorators
> > can do, but the evil things they could do that this would eliminate are
> > things they just shouldn't be doing in most situations.  meaning: there
> > would probably be two types of decorators... colons seem to be all the
> rage
> > these days so we could add an @: operator for that. :P ... Along with a
> from
> > __future__ import to change the behavior or all decorators in a file from
> > runtime to compile time by default.
> >
> > from __future__ import compile_time_decorators  # we'd be unlikely to
> ever
> > change the default and break things, __future__ seems wrong
> >
> > @this_happens_at_compile_time(3)
> > def ...
> >
> > @:this_waits_until_runtime(5)
> > def ...
> >
> > Just a not-so-wild idea, no idea if this should become a PEP for 3.8.
> (the
> > : syntax is a joke - i'd prefer @@ so it looks like eyeballs)
>
> At this point, we're squarely in python-ideas territory, but there are
> some possibilities. Imagine popping this line of code at the bottom of
> your file:
>
> import importlib; importlib.freeze_module()
>
> as a declaration that the dictionary for this module is now locked in
> and can be dumped out in whatever form is most efficient. Effectively,
> you're stating that you do not need any sort of dynamism (that call
> could be easily disabled for testing), and that, if the optimization
> breaks anything, you accept responsibility for it.
>
> How this would be implemented, I'm not sure, but that's no different
> from the @: idea.
>
> ChrisA
> ___
> 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/
> chris.jerdonek%40gmail.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