[Python-Dev] PEP 575 (Unifying function/method classes) update

[Jeroen Demeyer]

Hello all,

I have updated PEP 575 in response to some posts on this mailing list 
and to some discussions in person with the core Cython developers.

See https://www.python.org/dev/peps/pep-0575/

The main differences with respect to the previous version are:

* "builtin_function" was renamed to "cfunction". Since we are changing 
the name anyway, "cfunction" looked like a better choice because the 
word "built-in" typically refers to things from the builtins module.


* defined_function now only defines an API (it must support all 
attributes that a Python function has) without specifying the 
implementation.


* The "Two-phase Implementation" proposal for better backwards 
compatibility has been expanded and now offers 100% backwards 
compatibility for the classes and for the inspect functions.



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

[Nick Coghlan]

On 5 May 2018 at 11:58, Nathaniel Smith  wrote:

> What are the obstacles to including "preloaded" objects in regular .pyc
> files, so that everyone can take advantage of this without rebuilding the
> interpreter?
>
> Off the top of my head:
>
> We'd be making the in-memory layout of those objects part of the .pyc
> format, so we couldn't change that within a minor release. I suspect this
> wouldn't be a big change though, since we already commit to ABI
> compatibility for C extensions within a minor release? In principle there
> are some cases where this would be different (e.g. adding new fields at the
> end of an object is generally ABI compatible), but this might not be an
> issue for the types of objects we're talking about.
>

I'd frame this one a bit differently: what if we had a platform-specific
variant of the pyc format that was essentially a frozen module packaged as
an extension module? We probably couldn't quite do that for arbitrary
Python modules *today* (due to the remaining capability differences between
regular modules and extension modules), but multi-phase initialisation gets
things *much* closer to parity, and running embedded bytecode instead of
accessing the C API directly should avoid the limitations that exist for
classes defined in C.

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

[Nick Coghlan]

On 5 May 2018 at 07:59, Terry Reedy  wrote:

> On 5/2/2018 5:11 AM, Victor Stinner wrote:
>
> As a follow-up to the "[Python-Dev] (Looking for) A Retrospective on
>> the Move to Python 3" thread, I will like to clarify how a feature
>> should be removed from Python.
>>
>
> Would it be possible (and sensible) to use the 2to3 machinery to produce
> 36to37.py, etc., to do mechanical replacements when possible and flag other
> things when necessary?
>

That capability actually exists in the python-future project (in the form
of their "pasteurize" script, which takes idiomatic Python 3 code and turns
it into Python 2.7 compatible code).

One major issue though is that without a JIT compiler to speed things back
up, the polyfills needed to target old versions in the general case (rather
than when restricting yourself to a "backport friendly Python subset") are
often either going to be unacceptably slow, or else unacceptably irritating
to maintain, so folks have invested their time into figuring out how to
ship their own runtimes in order to avoid being restricted by
redistributors with slow runtime update cycles, and in being able to rely
on PyPI packages rather than standard library packages. (That's very
different from the incentives for browser vendors, who have users that
expect them to be able to make arbitrary websites work, and blame the
browser rather than the site when particular sites they want to use don't
work properly)

The other thing worth keeping in mind is that one of the core assumptions
of JavaScript tooling is that debugging tools will be able to reach out to
the internet and download additional files (most notably source maps) to
help make sense of the currently running code. Without that ability to
trace from compiled code back to the preferred source form for editing,
making sense of an otherwise straightforward traceback can become a complex
debugging exercise.

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] Dealing with tone in an email (was: Drop/deprecate Tkinter?)

[Antoine Pitrou]

On Sat, 5 May 2018 01:43:00 +1000
Steven D'Aprano  wrote:
> On Thu, May 03, 2018 at 06:31:03PM +, Brett Cannon wrote:
> 
> > 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.  
> 
> Certainly!
> 
> I'm not defending Ivan's initial email. His tantrum *was* annoying, 
> unreasonable, and unfair to those who do care about tkinter. He could 
> have done better.
> 
> But *we* should be better too. Our response to Ivan has not been 
> welcoming, and as a community we haven't lived up to our own standards, 
> as we have piled onto him to express our rightous indignation: [...]

Well summed up.

Regards

Antoine.


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

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

[Toshio Kuratomi]

On Fri, May 4, 2018, 7:00 PM Nathaniel Smith  wrote:

> What are the obstacles to including "preloaded" objects in regular .pyc
> files, so that everyone can take advantage of this without rebuilding the
> interpreter?
>

Would this make .pyc files arch specific?

-Toshio
___
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)

[Eric Fahlgren]

On Sat, May 5, 2018 at 10:30 AM, Toshio Kuratomi  wrote:

> On Fri, May 4, 2018, 7:00 PM Nathaniel Smith  wrote:
>
>> What are the obstacles to including "preloaded" objects in regular .pyc
>> files, so that everyone can take advantage of this without rebuilding the
>> interpreter?
>>
>
> Would this make .pyc files arch specific?
>

Or have parallel "pyh" (Python "heap") files, that are architecture
specific... (But that would cost more stat calls.)
___
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)

[Toshio Kuratomi]

On Sat, May 5, 2018, 10:40 AM Eric Fahlgren  wrote:

> On Sat, May 5, 2018 at 10:30 AM, Toshio Kuratomi 
> wrote:
>
>> On Fri, May 4, 2018, 7:00 PM Nathaniel Smith  wrote:
>>
>>> What are the obstacles to including "preloaded" objects in regular .pyc
>>> files, so that everyone can take advantage of this without rebuilding the
>>> interpreter?
>>>
>>
>> Would this make .pyc files arch specific?
>>
>
> Or have parallel "pyh" (Python "heap") files, that are architecture
> specific... (But that would cost more stat calls.)
>

I ask because arch specific byte code files are a big change in consumers
expectations.  It's not necessarily a bad change but it should be
communicated to downstreams so they can decide how to adjust to it.

Linux distros which ship byte code files will need to build them for each
arch, for instance.  People who ship just the byte code as an obfuscation
of the source code will need to decide whether to ship packages for each
arch they care about or change how they distribute.

-Toshio

>
___
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)

[Nathaniel Smith]

On Sat, May 5, 2018, 11:34 Toshio Kuratomi  wrote:

>
>
> On Sat, May 5, 2018, 10:40 AM Eric Fahlgren 
> wrote:
>
>> On Sat, May 5, 2018 at 10:30 AM, Toshio Kuratomi 
>> wrote:
>>
>>> On Fri, May 4, 2018, 7:00 PM Nathaniel Smith  wrote:
>>>
 What are the obstacles to including "preloaded" objects in regular .pyc
 files, so that everyone can take advantage of this without rebuilding the
 interpreter?

>>>
>>> Would this make .pyc files arch specific?
>>>
>>
>> Or have parallel "pyh" (Python "heap") files, that are architecture
>> specific... (But that would cost more stat calls.)
>>
>
> I ask because arch specific byte code files are a big change in consumers
> expectations.  It's not necessarily a bad change but it should be
> communicated to downstreams so they can decide how to adjust to it.
>
> Linux distros which ship byte code files will need to build them for each
> arch, for instance.  People who ship just the byte code as an obfuscation
> of the source code will need to decide whether to ship packages for each
> arch they care about or change how they distribute.
>

That's a good point.

One way to minimize the disruption would be to include both the old and new
info in the .pyc files, so at load time if the new version is incompatible
then you can fall back on the old way, even if it's a bit slower.

I think in the vast majority of cases currently .pyc files are built on the
same architecture where they're used? Pip and Debian/Ubuntu and the
interpreter's automatic compilation-on-import all build .pyc files on the
computer where they'll be run.

It might also be worth double checking much the memory layout of these
objects even varies. Obviously it'll be different for 32- and 64-bit
systems, but beyond that, most ISAs and OSes and compilers use pretty
similar struct layout rules AFAIK... we're not talking about actual machine
code.

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

[Glenn Linderman]

On 5/5/2018 10:30 AM, Toshio Kuratomi wrote:
On Fri, May 4, 2018, 7:00 PM Nathaniel Smith > wrote:


What are the obstacles to including "preloaded" objects in regular
.pyc files, so that everyone can take advantage of this without
rebuilding the interpreter?


Would this make .pyc files arch specific?


Lots of room in the __pycache__ folder.

As compilation of the .py module proceeds, could it be determined if 
there is anything that needs to be architecture specific, and emit an 
architecture-specific one or an architecture-independent one as 
appropriate?  Data structures are mostly bitness-dependent, no?


But if an architecture-specific .pyc is required, could/should it be 
structured and named according to the OS conventions also:  .dll .so  .etc ?


Even if it doesn't contain executable code, the bytecode could be 
contained in appropriate data sections, and there has been talk about 
doing relocation of pointer in such pre-compiled data structures, and 
the linker _already_ can do that sort of thing...
___
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)

[Miro Hrončok]

On 5.5.2018 21:00, Nathaniel Smith wrote:
I think in the vast majority of cases currently .pyc files are built on 
the same architecture where they're used?


On Fedora (and by extension also on RHEL and CentOS) this is not rue. 
When the package is noarch (no extension module shipped, only pure 
Python) it is built and bytecompiled on a random architecture. 
Bytecompilation happens during build time.


If bytecode gets arch specific, we'd need to make all our Python 
packages arch specific or switch to install-time bytecompilation.



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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] (name := expression) doesn't fit the narrative of PEP 20

[Rob Cliffe via Python-Dev]

Reading this sub-thread, it struck me that a good way to make PEP 562 
more likely to be accepted is to launch an over-the-top attack on it.
Then more moderate people - who were/are not necessarily in favour of 
the PEP - feel pressurised into defending it.


Hah!
Watch this space for my vicious, vitriolic, withering attack on PEP 463 
(Exception-catching expressions)! :-)


Best wishes
Rob Cliffe
___
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)

[Terry Reedy]

On 5/5/2018 2:33 PM, Toshio Kuratomi wrote:



On Sat, May 5, 2018, 10:40 AM Eric Fahlgren > wrote:


On Sat, May 5, 2018 at 10:30 AM, Toshio Kuratomi mailto:a.bad...@gmail.com>>wrote:

On Fri, May 4, 2018, 7:00 PM Nathaniel Smith mailto:n...@pobox.com>> wrote:

What are the obstacles to including "preloaded" objects in
regular .pyc files, so that everyone can take advantage of
this without rebuilding the interpreter?


Would this make .pyc files arch specific?


Or have parallel "pyh" (Python "heap") files, that are architecture
specific... (But that would cost more stat calls.)


I ask because arch specific byte code files are a big change in 
consumers expectations.  It's not necessarily a bad change but it should 
be communicated to downstreams so they can decide how to adjust to it.


Linux distros which ship byte code files will need to build them for 
each arch, for instance.  People who ship just the byte code as an 
obfuscation of the source code will need to decide whether to ship 
packages for each arch they care about or change how they distribute.


It is an advertised feature that CPython *can* produce cross-platform 
version-specific .pyc files.  I believe this should continue, at least 
for a few releases.  They are currently named modname.cpython-xy.pyc, 
with optional '.opt-1', '.opt-2', and '.opt-4' tags inserted before  in 
__pycache__.  These name formats should continue to mean what they do now.


I believe *can* should not mean *always*.  Architecture-specific files 
will need an additional architecture tag anyway, such as win32 and 
win64, anyway.  Or would bitness and endianess be sufficient across 
platforms?   If we make architecture-specific the default, we could add 
startup and compile and compile_all options for the cross-platform 
format.  Or maybe add a recompile function that imports cross-platform 
.pycs and outputs local-architecture .pycs.


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

[Brett Cannon]

On Sat, 5 May 2018 at 10:41 Eric Fahlgren  wrote:

> On Sat, May 5, 2018 at 10:30 AM, Toshio Kuratomi 
> wrote:
>
>> On Fri, May 4, 2018, 7:00 PM Nathaniel Smith  wrote:
>>
>>> What are the obstacles to including "preloaded" objects in regular .pyc
>>> files, so that everyone can take advantage of this without rebuilding the
>>> interpreter?
>>>
>>
>> Would this make .pyc files arch specific?
>>
>
> Or have parallel "pyh" (Python "heap") files, that are architecture
> specific...
>

.pyc files have tags to specify details about them (e.g. were they compiled
with -OO), so this isn't an "all or nothing" option, nor does it require a
different file extension. There just needs to be an appropriate finder that
knows how to recognize a .pyc file with the appropriate tag that can be
used, and then a loader that knows how to read that .pyc.


> (But that would cost more stat calls.)
>

Nope, we actually cache directory contents so file lookup existence is
essentially free (this is why importlib.invalidate_caches() exists
specifically to work around when the timestamp is too coarse for a
directory content mutation).

-Brett
___
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 04.05.2018 19:04, Guido van Rossum wrote:
Thank you Steven! I assume that Brian hadn't seen my response (such 
crossed messages due to delivery delays are very common in this 
mailing list).


I'd like to use your email (nearly) verbatim to start off the 
discussion about civility we're going to have at the Language Summit.


Since I won't be present at the summit to tell my side of the story, you 
can see it below.

It's up to you to judge it, but as least you need to know what to judge.

In a nutshell, this is an exceptional situation, and I saw no better way 
that was guaranteed to work.
I never meant or mean to use this as a standard tactic, this is only the 
second such case in my life.
On Fri, May 4, 2018 at 8:43 AM, Steven D'Aprano > wrote:


On Thu, May 03, 2018 at 06:31:03PM +, Brett Cannon wrote:

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

Certainly!

I'm not defending Ivan's initial email. His tantrum *was* annoying,
unreasonable, and unfair to those who do care about tkinter. He could
have done better.

But *we* should be better too. Our response to Ivan has not been
welcoming, and as a community we haven't lived up to our own
standards,
as we have piled onto him to express our rightous indignation:

1. Guido responded telling Ivan to calm down and work off his
   frustration elsewhere. And that's where things should have
   stopped, unless Ivan had persisted in his impoliteness.

2. Brian upped the ante by bringing the CoC into discussion.

3. Paul raised it again by describing Ivan's post as "offensive".

4. And now, Steve H has claimed that Ivan's initial post was
   bordering on "abusive".

We've gone from rightly treating Ivan's post as intemperate and
impolite, and telling him to chill, to calling his post
"offensive", to
"abusive". (Next, I presume, someone will claim to be traumatised by
Ivan's email.)

Just as Ivan should have waited until he had calmed down before
firing
off his rant, so we ought to resist the temptation to strike back
with
hostility at trivial social transgressions, especially from
newcomers.
This is what Ivan actually said:

- Tkinter is broken and partly functional (an opinion with only the
  most tenuous connection with fact, but hardly abusive);

- that nobody cares (factually wrong, but not abusive);

- that possibly nobody is using it (factually wrong, but not abusive);

- that if that's the case (it isn't), then it should be removed
  from the std lib (a reasonable suggestion if only the premise had
  been correct).

As I suspected. This is a classic scenario that is occasionally seen 
anywhere: "everyone is underestimating a problem until a disaster strikes".
The team's perception of Tkinter is basically: "well, there are slight 
issues, and the docs are lacking, but no big deal."


Well, this _is_ a big deal. As in, "with 15+ years of experience, 5+ 
with Python, I failed to produce a working GUI in a week; no-one on the 
Net, regardless of experience, (including Terry) is ever sure how to do 
things right; every online tutorial says: "all the industry-standard and 
expected ways are broken/barred, we have to resort to ugly workarounds 
to accomplish just about anything"" big deal. This is anything but 
normal, and all the more shocking in Python where the opposite is the norm.


And now, a disaster striked. Not knowing this, I've relied on Tkinter 
with very much at stake (my income for the two following months, 
basically), and lost. If that's not a testament just how much damage 
Tkinter's current state actually does, I dunno what is.


Of course, it's up to me to write fixes and all since this is a 
volunteer project. But I can't do this alone, I must recruit the team's 
cooperation if I hope to ever be successful. Unless I shatter their 
current outlook on the matter first, any fixes I provide will likely be 
dismissed as unneeded or deferred indefinitely as unimportant. There are 
precedents of that, including with no response whatsoever, and the 
messages were written neutrally, with a thorough explanation, patch/PR 
etc. (I do believe the maintainers are doing their best. Still, the mere 
fact that they chose to work with other tickers over mine shows that 
they considered those more important. So it does matter if they 
underestimate a topic.)


That's why I had to resort to shock value. First, it would guarantee 
that my message won't fall 

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

[Nick Coghlan]

On 6 May 2018 at 05:34, Brett Cannon  wrote:

>
>
> On Sat, 5 May 2018 at 10:41 Eric Fahlgren  wrote:
>
>> On Sat, May 5, 2018 at 10:30 AM, Toshio Kuratomi 
>> wrote:
>>
>>> On Fri, May 4, 2018, 7:00 PM Nathaniel Smith  wrote:
>>>
 What are the obstacles to including "preloaded" objects in regular .pyc
 files, so that everyone can take advantage of this without rebuilding the
 interpreter?

>>>
>>> Would this make .pyc files arch specific?
>>>
>>
>> Or have parallel "pyh" (Python "heap") files, that are architecture
>> specific...
>>
>
> .pyc files have tags to specify details about them (e.g. were they
> compiled with -OO), so this isn't an "all or nothing" option, nor does it
> require a different file extension. There just needs to be an appropriate
> finder that knows how to recognize a .pyc file with the appropriate tag
> that can be used, and then a loader that knows how to read that .pyc.
>

Right, this is the kind of change I had in mind (perhaps in combination
with Diana Clarke's suggestion from several months back to make pyc tagging
more feature-flag centric, rather than the current focus on a numeric
optimisation level).

We also wouldn't ever generate this hypothetical format implicitly -
similar to the new deterministic pyc's in 3.7, they'd be something you had
to explicitly request via a compileall invocation. In the Linux distro use
case then, the relevant distro packaging helper scripts and macros could
generate traditional cross-platform pyc files for no-arch packages, but
automatically switch to the load-time optimised arch-specific format if the
package was already arch-specific.

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

[David Mertz]

The below is really just making this whole situation worse.

On Sat, May 5, 2018 at 8:22 PM, Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

> As I suspected. This is a classic scenario that is occasionally seen
> anywhere: "everyone is underestimating a problem until a disaster strikes".
> The team's perception of Tkinter is basically: "well, there are slight
> issues, and the docs are lacking, but no big deal."
>
Well, this _is_ a big deal. As in, "with 15+ years of experience, 5+ with
> Python, I failed to produce a working GUI in a week; no-one on the Net,
> regardless of experience, (including Terry) is ever sure how to do things
> right; every online tutorial says: "all the industry-standard and expected
> ways are broken/barred, we have to resort to ugly workarounds to accomplish
> just about anything"" big deal. This is anything but normal, and all the
> more shocking in Python where the opposite is the norm.
>

This is simply objectively wrong, and still rather insulting to the core
developers.

The real-world fact is that many people—including the authors of IDLE,
which is included with Python itself—use Tkinter to develop friendly,
working, GUIs.  Obviously, there *is* a way to make Tkinter work.  I
confess I haven't worked with it for a while, and even when I had, it was
fairly toy apps.  I never saw any terrible problems, but I confess I also
never pushed the edges of it.

It's quite possible, even likely, that some sufficiently complicated GUI
apps are better off eschewing Tkinter and using a different GUI library.
It's also quite possible that the documentation around Tkinter could be
improved to convey more accurate messaging around this (and to convey the
common pattern of "GUI in one thread, workers in other threads."


> And now, a disaster striked. Not knowing this, I've relied on Tkinter with
> very much at stake (my income for the two following months, basically), and
> lost. If that's not a testament just how much damage Tkinter's current
> state actually does, I dunno what is.
>

I've sunk two months each into trying to wrestle quite a large number of
frameworks or libraries to do what I want.  Sometimes I finally made it
work, other times not.  That's the reality of software development.
Sometimes the problems were bugs per se, other times limits of my
understanding.  Often the problems were with extremely widely used and
"solid" libraries (not just in Python, across numerous languages).

There are a few recurring posters here and on python-ideas of whom I roll
my eyes when I see a post is from them... I think most actual core
contributors simply have them on auto-delete filters by now.  I don't know
where the threshold is exactly, but I suspect you're getting close to that
with this post.

Yours, David...


-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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

[Chris Angelico]

On Sun, May 6, 2018 at 10:22 AM, Ivan Pozdeev via Python-Dev
 wrote:
> Well, this _is_ a big deal. As in, "with 15+ years of experience, 5+ with
> Python, I failed to produce a working GUI in a week; no-one on the Net,
> regardless of experience, (including Terry) is ever sure how to do things
> right; every online tutorial says: "all the industry-standard and expected
> ways are broken/barred, we have to resort to ugly workarounds to accomplish
> just about anything"" big deal. This is anything but normal, and all the
> more shocking in Python where the opposite is the norm.
>
> And now, a disaster striked. Not knowing this, I've relied on Tkinter with
> very much at stake (my income for the two following months, basically), and
> lost. If that's not a testament just how much damage Tkinter's current state
> actually does, I dunno what is.

What exactly didn't work? I don't understand. What online tutorials
are telling you that everything is broken, and how can you lose two
months' income because things are exactly as broken as everything
tells you?

As far as I can tell, you ran into problems when you tried to put GUI
operations onto a thread other than the main thread. Okay, so maybe
that's a limitation that bit you, but I can't accept that this is
"industry-standard". In fact, I would be much more inclined to say
that the industry standard is single-threaded code, given how
terrified a lot of people are of concurrency in general. (Not
everyone, but a lot of people.) As long as your GUI operations happen
on your main thread, you should be fine. I told my brother about that
consideration recently, and the solution was simple: instead of doing
socket operations on the main thread and GUI operations on a secondary
thread, just switch them around. It's really that simple. So what
actually went wrong when you tried, and how did you manage to get so
far into it before disaster that you lost two months' income?

Tkinter is an important part of Python's ecosystem. It isn't the
greatest GUI toolkit (and it isn't trying to be), and it isn't
stopping people from using GTK or Qt or wxWindows, but Tk and Tkinter
can be depended on much more easily, since that's part of the standard
library. If they were "broken" or "unusable", people would have
figured that out by now. so that part is very definitely exaggeration.
So if your words are not just empty hyperbole, be specific: what is
broken? If I'm considering using Tkinter for something, what
*precisely* do I need to be aware of? Is it just using Tkinter from
threads other than the main thread?

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

[Steven D'Aprano]

On Sun, May 06, 2018 at 11:09:21AM +1000, Chris Angelico wrote:

> What exactly didn't work? I don't understand.

https://bugs.python.org/issue33412



-- 
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/archive%40mail-archive.com

Re: [Python-Dev] Dealing with tone in an email

[Chris Angelico]

On Sun, May 6, 2018 at 11:39 AM, Steven D'Aprano  wrote:
> On Sun, May 06, 2018 at 11:09:21AM +1000, Chris Angelico wrote:
>
>> What exactly didn't work? I don't understand.
>
> https://bugs.python.org/issue33412
>

I've read it and I still don't fully understand the problem. Is it ALL
of Tkinter that fails in threaded mode? Is it just certain specific
calls? Are there calls that fail in single-threaded programs? If the
given test-case is the only thing that fails, it's a horrific
exaggeration to say that Tkinter is broken. But I don't know how far
it can be generalized.

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