Re: [Python-Dev] Slow down...

[Nick Coghlan]

On 7 May 2018 at 11:30, Dan Stromberg  wrote:

> I'd very much like a live in a world where Jython and IronPython and
> MicroPython and Cython and Pyjamas can all catch up and implement
> Python 3.7, 3.8, and so forth.
>

I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003
language moratorium could be a very good idea. Between matrix
multiplication, enhanced tuple unpacking, native coroutines, f-strings, and
type hinting for variable assignments, we've had quite a bit of syntactic
churn in the past few releases, and the rest of the ecosystem really hasn't
caught up on it all yet (and that's not just other implementations - it's
training material, online courses, etc, etc).

If we're going to take such a step, now's also the time to do it, since 3.8
feature development is only just getting under way, and if we did decide to
repeat the language moratorium, we could co-announce it with the Python 3.7
release.

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

[Python-Dev] Slow down...

[Dan Stromberg]

When I think of why Python is so far ahead of Perl in language design,
I think it's simply that Python is the result of cautious design, and
Perl is the result of exuberant design.

I think Python is in danger of becoming a large language - which isn't
a good thing.

A great language, like Scheme or Python or even C, is a language that
has a small, very useful core, and large _libraries_.

I'd very much like a live in a world where Jython and IronPython and
MicroPython and Cython and Pyjamas can all catch up and implement
Python 3.7, 3.8, and so forth.
___
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] Windows 10 build agent failures

[Paul Goins]

Thanks for the heads-up; I skimmed python-dev but did not check bpo.  - Paul

On Sun, May 6, 2018, 11:35 AM Zachary Ware 
wrote:

> On Sun, May 6, 2018 at 3:05 AM, Paul Goins  wrote:
> > Hi,
> >
> > Just kind of "looking around" at stuff I can help with, and I noticed a
> few
> > days ago that Windows 10 AMD64 builds of Python 3.6/3.7/3.x are generally
> > failing.
> >
> > It seems like the failures started April 16th around 1am per BuildBot and
> > went from consistently passing to consistently failing.  The errors
> appear
> > to be timeouts; the test runs are going over 15 minutes.
> >
> > I can run the tests locally and things seem fine.
> >
> > The one thing which seems to have changed is, under the "10 slowest
> tests"
> > header, test_io has shot up in terms of time to complete:
> >
> > 3.6: 2 min 13 sec to 9 min 25 sec
> > 3.7: 2 min 10 sec to 9 min 26 sec
> > 3.x: 3 min 39 sec to 9 min 17 sec
> >
> > Locally this test suite runs in around 36 seconds.  I see no real change
> > between running one of the last "good" changesets versus the current
> head of
> > master.  I'm suspecting an issue on the build agent perhaps?  Thoughts?
>
> We have an open issue for this at https://bugs.python.org/issue33355.
>
> --
> Zach
> ___
> 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/general%40vultaire.net
>
___
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] Windows 10 build agent failures

[Ivan Pozdeev via Python-Dev]

For me, Tcl/Tk failed to build with SDK 10.0.16299.0 , I had to 
expicitly fall back to 10.0.15063.0 ( 
https://stackoverflow.com/questions/48559337/error-when-building-tcltk-in-visual-studio-2017 
). May be related if VS was (auto)updated on the builders.||


On 06.05.2018 11:05, Paul Goins wrote:
||

Hi,

Just kind of "looking around" at stuff I can help with, and I noticed 
a few days ago that Windows 10 AMD64 builds of Python 3.6/3.7/3.x are 
generally failing.


It seems like the failures started April 16th around 1am per BuildBot 
and went from consistently passing to consistently failing.  The 
errors appear to be timeouts; the test runs are going over 15 minutes.


I can run the tests locally and things seem fine.

The one thing which seems to have changed is, under the "10 slowest 
tests" header, test_io has shot up in terms of time to complete:


3.6: 2 min 13 sec 
 
to 9 min 25 sec 

3.7: 2 min 10 sec 
 
to 9 min 26 sec 

3.x: 3 min 39 sec 
 
to 9 min 17 sec 



Locally this test suite runs in around 36 seconds.  I see no real 
change between running one of the last "good" changesets versus the 
current head of master.  I'm suspecting an issue on the build agent 
perhaps?  Thoughts?


Best Regards,
Paul Goins


___
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

[Chris Angelico]

On Mon, May 7, 2018 at 6:04 AM, Terry Reedy  wrote:
> On 5/6/2018 10:03 AM, Chris Angelico wrote:
>> If it were up to me, I would deprecate non-threaded mode immediately,
>
>
> Given that 99% of tkinter users do not need threaded tcl, why cut some of
> them off?

"Non-threaded" really just means "non-thread-safe". There's nothing
wrong with using thread-safe APIs when you're using only a single
thread, other than the performance overhead. Is that significant
enough to require the distinction?

> When tkinter is import and a root is created, tkinter cannot know
> whether the user is going to later make failing calls from threads.  Tkinter
> has traditional been slow to remove support of old versions; it still
> supports 8.4.  It will eventually become a moot point, at least on Windows,
> as current Windows installers install threaded tcl.  I presume the same is
> true for the new Mac installers.  I have no idea what people have on linux.

That's what I'm hoping for, yes. Eventually threaded will be the only
way to do things.

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

[Terry Reedy]

On 5/6/2018 10:03 AM, Chris Angelico wrote:

On Sun, May 6, 2018 at 6:54 PM, Terry Reedy  wrote:

Is it ALL of Tkinter that fails in threaded mode?


No.  It is non-threaded tcl that fails in threaded mode, along with
tkinter's attempt to make non-thread tcl work anyway.  There are at least
two different cases.

Ivan has clarified the following.
1. Tcl has a 'threads' compile switch.
2. The default changed from 'off' for 8.5 and before to 'on' for 8.6.
3. When compiled with thread support, the resulting library file has t
suffix.


Okay, that makes a HUGE difference. Thank you for clarifying. So, in
theory, threads SHOULD be supported, which means that bug reports of
the nature of "this fails in threaded mode" are 100% valid.


If the reported code does not have bugs, including thread deadlock and 
shutdown bugs, which are non-trivial to avoid, yes.


I dug up more information.  Though he did not say so, Ivan's first 
issue, https://bugs.python.org/issue33257, reopens and continues 
https://bugs.python.org/issue11077, using a slightly modified version of 
the original ballistic launch example.  Ivan added discussion of the tcl 
thread-support compile switch, which was not mentioned in the original. 
Ditto for a patch.


The originator of the original, Scott M., taught new programmers how to 
display data from multiple sources, some blocking.  It seemed most 
natural to him and students to use threads to access sources and use the 
documented widget.method(*args) APIs to display data, rather than have 
to invent a protocol to pass such calls through a queue.  See the 
initial message.


In that older issue, I mentioned, as I did in response to Ivan, that 
'thread' does not appear in the tkinter docs.  Martin Löwis replied


"My claim is that Tkinter is thread-safe as it stands. A lot of thought 
has been put into making Tkinter thread-safe, so if there is any claim 
to the contrary, we would need more details: what exact Python version 
is being used, what exact operating system is being used, what exact 
code is run, and what exact output is produced."


and later said "It's supported on Unix since 1.5.1, and on Windows since 
2.3."



If it were up to me, I would deprecate non-threaded mode immediately,


Given that 99% of tkinter users do not need threaded tcl, why cut some 
of them off?  When tkinter is import and a root is created, tkinter 
cannot know whether the user is going to later make failing calls from 
threads.  Tkinter has traditional been slow to remove support of old 
versions; it still supports 8.4.  It will eventually become a moot 
point, at least on Windows, as current Windows installers install 
threaded tcl.  I presume the same is true for the new Mac installers.  I 
have no idea what people have on linux.


--
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] Windows 10 build agent failures

[Zachary Ware]

On Sun, May 6, 2018 at 3:05 AM, Paul Goins  wrote:
> Hi,
>
> Just kind of "looking around" at stuff I can help with, and I noticed a few
> days ago that Windows 10 AMD64 builds of Python 3.6/3.7/3.x are generally
> failing.
>
> It seems like the failures started April 16th around 1am per BuildBot and
> went from consistently passing to consistently failing.  The errors appear
> to be timeouts; the test runs are going over 15 minutes.
>
> I can run the tests locally and things seem fine.
>
> The one thing which seems to have changed is, under the "10 slowest tests"
> header, test_io has shot up in terms of time to complete:
>
> 3.6: 2 min 13 sec to 9 min 25 sec
> 3.7: 2 min 10 sec to 9 min 26 sec
> 3.x: 3 min 39 sec to 9 min 17 sec
>
> Locally this test suite runs in around 36 seconds.  I see no real change
> between running one of the last "good" changesets versus the current head of
> master.  I'm suspecting an issue on the build agent perhaps?  Thoughts?

We have an open issue for this at https://bugs.python.org/issue33355.

-- 
Zach
___
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] Use a queue in Tkinter (was: Dealing with tone in an email)

[Terry Reedy]

On 5/6/2018 8:51 AM, Stefan Krah wrote:


Steven D'Aprano wrote:

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


https://bugs.python.org/issue33412


Isn't the standard solution to use a queue for updating the GUI?

At least I didn't have any problems at all with my one TKinter app, I
think the method is described in the Python Cookbook.


The 2nd edition, Recipe 11.9 Combining GUIs and Asynchronous I/O with 
Threads gives an example that processes items in the queue 5 times a 
second.


I can understand the desire to avoid the put and get overhead and the 
poll wait by calling a gui method directly.  This works when one uses 
tcl/tk compiled with thread support and avoids inter-thread deadlocks. 
See my answer to Chris A. for details.


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

[Python-Dev] Windows 10 build agent failures

[Paul Goins]

Hi,

Just kind of "looking around" at stuff I can help with, and I noticed a few
days ago that Windows 10 AMD64 builds of Python 3.6/3.7/3.x are generally
failing.

It seems like the failures started April 16th around 1am per BuildBot and
went from consistently passing to consistently failing.  The errors appear
to be timeouts; the test runs are going over 15 minutes.

I can run the tests locally and things seem fine.

The one thing which seems to have changed is, under the "10 slowest tests"
header, test_io has shot up in terms of time to complete:

3.6: 2 min 13 sec

to 9 min 25 sec

3.7: 2 min 10 sec

to 9 min 26 sec

3.x: 3 min 39 sec

to 9 min 17 sec


Locally this test suite runs in around 36 seconds.  I see no real change
between running one of the last "good" changesets versus the current head
of master.  I'm suspecting an issue on the build agent perhaps?  Thoughts?

Best Regards,
Paul Goins
___
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 6:54 PM, Terry Reedy  wrote:
>> Is it ALL of Tkinter that fails in threaded mode?
>
> No.  It is non-threaded tcl that fails in threaded mode, along with
> tkinter's attempt to make non-thread tcl work anyway.  There are at least
> two different cases.
>
> Ivan has clarified the following.
> 1. Tcl has a 'threads' compile switch.
> 2. The default changed from 'off' for 8.5 and before to 'on' for 8.6.
> 3. When compiled with thread support, the resulting library file has t
> suffix.

Okay, that makes a HUGE difference. Thank you for clarifying. So, in
theory, threads SHOULD be supported, which means that bug reports of
the nature of "this fails in threaded mode" are 100% valid.

If it were up to me, I would deprecate non-threaded mode immediately,
with a view to just paying whatever price threaded mode incurs
(presumably performance) starting in Python 3.9 or thereabouts.
Supporting threads is a Good Thing.

Thank you for that explanation.

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

[Python-Dev] Use a queue in Tkinter (was: Dealing with tone in an email)

[Stefan Krah]

Steven D'Aprano wrote:
>> What exactly didn't work? I don't understand.
>
> https://bugs.python.org/issue33412

Isn't the standard solution to use a queue for updating the GUI?

At least I didn't have any problems at all with my one TKinter app, I
think the method is described in the Python Cookbook.



Stefan Krah



___
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/5/2018 9:45 PM, Chris Angelico wrote:

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.


Chris this is an excellent series of questions.  I think I have enough 
knowledge to answer somewhat adequately.  This is partly thanks to 
things people like you and Steven have posted on python-list abouts 
threads, deadlocks, and volatile conditions, and partly thanks to Ivan's 
contribution on the thread above and https://bugs.python.org/issue33257.



Is it ALL of Tkinter that fails in threaded mode?


No.  It is non-threaded tcl that fails in threaded mode, along with 
tkinter's attempt to make non-thread tcl work anyway.  There are at 
least two different cases.


Ivan has clarified the following.
1. Tcl has a 'threads' compile switch.
2. The default changed from 'off' for 8.5 and before to 'on' for 8.6.
3. When compiled with thread support, the resulting library file has t 
suffix.
4. The Windows installer for 2.7 installs tcl85.dll while at least 3.6 
and later install tcl86t.dll.  Hence things work that did not work before.
5. Changing 2.7 to tcl85t.dll and tk85t.dll could break 3rd code that 
interfaces to the .dlls.  _tkinter is written with #ifdefs to 
accommodate thread or no thread compiles, but any code written just for 
the no-t version would could fail with the t version.


Is it just certain specific calls? 


33257 is about calling widget modification methods from threads.  The 
_tkinter code to make this work with non-t tcl fails haphazardly in 
maybe 1 in 1 calls.  Ivan signed the CA and submitted a PR which he 
claims fixes the Python and Tcl locking.  Serhiy has not reviewed this yet.


33412 is about calling event_generate from threads.  For non-t tcl and 
more than one thread making such calls, the example fails immediately. 
With thread tcl, the same example ran until it deadlocked during 
shutdown cleanup.  I found one way to almost certainly avoid it.  Ivan 
found a better way, which I am thinking about making part of a new doc 
section on tkinter and threads.



Are there calls that fail in single-threaded programs?


This is a different issue.  I don't know of much of anything except a 
few things on MacOS, due to tcl/tk bugs or Apple changing the graphics 
system.



If the given test-case is the only thing that fails,
Neither fails with properly written code when using the thread build of 
tcl.


>  it's a horrific exaggeration to say that Tkinter is broken.

Yep.  But I don't care any more what Ivan writes here.  I am sorry he 
lost a job bid or whatever.  I appreciate what he has contributed on the 
tracker, in his more rational mode.


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

[Nick Coghlan]

On 5 May 2018 at 18:55, Jeroen Demeyer  wrote:

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

Thanks for this update Jeroen! If it doesn't come up otherwise, I'll try to
claim one of the lightning talk slots at the Language Summit to discuss
this with folks in person :)

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