Re: [Python-Dev] Python startup time

On Wed, May 2, 2018 at 8:26 PM, Benjamin Peterson wrote: > > > On Wed, May 2, 2018, at 09:42, Gregory Szorc wrote: > > The direction Mercurial is going in is that `hg` will likely become a > Rust > > binary (instead of a #!python script) that will use an embedded Python > >

Re: [Python-Dev] Python startup time

On 5/2/2018 12:42 PM, Gregory Szorc wrote: I know this kinda/sorta exists with zipimporter. But zipimporter uses zlib (slow) and only allows .py/.pyc files. And I think some Python application distribution tools have also solved this problem. I'd *really* like to see a proper/robust solution

Re: [Python-Dev] Python startup time

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. * Add IntEnum and

Re: [Python-Dev] Python startup time

On Wed, May 2, 2018, at 09:42, Gregory Szorc wrote: > The direction Mercurial is going in is that `hg` will likely become a Rust > binary (instead of a #!python script) that will use an embedded Python > interpreter. So we will have low-level control over the interpreter via the > C API. I'd

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

On Thu, May 03, 2018 at 12:01:53AM +0200, Antoine Pitrou wrote: > On Wed, 2 May 2018 22:54:04 +0100 > Paul Moore wrote: > > 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 > >

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

On 5/2/2018 6:01 PM, Antoine Pitrou wrote: On Wed, 2 May 2018 22:54:04 +0100 Paul Moore wrote: 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

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

On 5/2/2018 4:51 PM, Ivan Pozdeev via Python-Dev wrote: As https://bugs.python.org/issue33257 As I report there, the 'crasher' does not crash on my Win 10 with either installed 3.7 or built 3.8. https://bugs.python.org/issue33316 showed, nothing about tkinter Tkinter is broken, for both

[Python-Dev] [RELEASE] Python 3.7.0b4, final 3.7 beta, now available for testing

Python 3.7.0b4 is the final beta preview of Python 3.7, the next feature release of Python. Beta releases are intended to give you the opportunity to test new features and bug fixes and to prepare your projects to support the new feature release. We strongly encourage you to test your projects

Re: [Python-Dev] bpo-33257: seeking advice & approval on the course of action

On 5/2/2018 4:38 PM, Ivan Pozdeev via Python-Dev wrote: The bottom line is: Tkinter is currently broken This is way over-stated. Many modules have bugs, somethings in features more central to their main purpose. -- as in, it's not thread-safe (in both Py2 and Py3) Meaning that tkinter

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

On 2018-05-02 22:56, Josh Stephens wrote: Hello list,   If I may voice my opinion I would like to say that I just built an application using Tkinter using python3. I used it because it was included in python by default and I didn't have to using something like PyQT or any other framework that

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

I still use it a bit, in simple contexts to be sure, but I do find it useful. Others think so as well. I think TkAgg is probably the most commonly used backend in Matplotlib. I wrote a single Matplotlib-using program which plots columns from CSV files. I use it almost daily with no problems.

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

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

Re: [Python-Dev] Python startup time

On May 2, 2018, at 15:24, Gregory Szorc wrote: > > FWIW, Google has a patched glibc that implements dlopen_with_offset(). > It allows you to do things like memory map the current binary and then > dlopen() a shared library embedded in an ELF section. > > I've seen the

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

Guido van Rossum wrote: So what do *you* think. Do you agree with the OP that Tkinter (and hence IDLE) should be scrapped? I don't have an opinion on that, but the issue of whether tkinter should be in the stdlib has been debated at least once before, and I took the OP as saying "maybe we

Re: [Python-Dev] Python startup time

On 5/2/18 2:24 PM, Barry Warsaw wrote: > On May 2, 2018, at 09:42, Gregory Szorc wrote: > >> As for things Python could do to make things better, one idea is for >> "package bundles." Instead of using .py, .pyc, .so, etc files as separate >> files on the filesystem,

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

> On 2 May 2018, at 22:51, Ivan Pozdeev via Python-Dev > 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

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

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

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

Hello list,   If I may voice my opinion I would like to say that I just built an application using Tkinter using python3. I used it because it was included in python by default and I didn't have to using something like PyQT or any other framework that was heavy. While I agree that the docs can

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

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

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

On Wed, May 2, 2018 at 5:37 PM Antoine Pitrou wrote: > On Wed, 2 May 2018 23:28:22 +0200 > Antoine Pitrou wrote: > > On Wed, 02 May 2018 21:24:07 + > > Brian Curtin wrote: > > > On Wed, May 2, 2018 at 16:55 Ivan Pozdeev via

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

I have no opinion about scrapping IDLE and Tkinter, but if we don't, I think his concerns deserve addressing instead of being dismissed by wielding the CoC magic wand. Regards Antoine. Le 02/05/2018 à 23:41, Guido van Rossum a écrit : > So what do *you* think. Do you agree with the OP that

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

So what do *you* think. Do you agree with the OP that Tkinter (and hence IDLE) should be scrapped? On Wed, May 2, 2018 at 2:37 PM, Antoine Pitrou wrote: > On Wed, 2 May 2018 23:28:22 +0200 > Antoine Pitrou wrote: > > On Wed, 02 May 2018 21:24:07 +

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

On Wed, 2 May 2018 23:28:22 +0200 Antoine Pitrou wrote: > On Wed, 02 May 2018 21:24:07 + > Brian Curtin wrote: > > On Wed, May 2, 2018 at 16:55 Ivan Pozdeev via Python-Dev < > > python-dev@python.org> wrote: > > > > > As

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

On Wed, 02 May 2018 21:24:07 + Brian Curtin wrote: > On Wed, May 2, 2018 at 16: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

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

On Wed, May 2, 2018 at 16: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

Re: [Python-Dev] Python startup time

On May 2, 2018, at 09:42, Gregory Szorc wrote: > As for things Python could do to make things better, one idea is for "package > bundles." Instead of using .py, .pyc, .so, etc files as separate files on the > filesystem, allow Python packages to be distributed as

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

This would be really useful for Cython, as well as a nice cleanup in general (e.g. replacing 4 special cases with one check). It seems the main concern is the user-visible change in types. If this is determined to be too backwards incompatible (I would be surprised if many projects are impacted,

Re: [Python-Dev] Python startup time

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,

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

Wow. I guess your code was broken and now you seem really upset. Go punch a bag or something, and then propose something a little more constructive, like adding a warning to the docs. I can assure you that there are many people using apps written using Tkinter (e.g. IDLE) and there's a mailing

[Python-Dev] Drop/deprecate Tkinter?

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

[Python-Dev] bpo-33257: seeking advice & approval on the course of action

The bottom line is: Tkinter is currently broken -- as in, it's not thread-safe (in both Py2 and Py3) despite being designed and advertizing itself as such. All the fix options require some redesign of either `_tkinter', or some of the core as well. So, I'd like to get some kind of core team's

Re: [Python-Dev] [RELEASE] Python 2.7.15

On 05/02/2018 11:14 AM, Nathaniel Smith wrote: I would guess that the folks who end up supporting python 2 past 2020 (either as distributors or as library authors) will have an easier time of it if python 2's ssl module gets resynced with python 3 before the eol. But I suppose it's up to

Re: [Python-Dev] Python startup time

Antoine: > The overhead of importing is not in trying too many names, but in > loading the module and executing its bytecode. That was my conclusion as well when I did some profiling last fall at the Python core sprint. My lazy execution experiments are an attempt to solve this:

Re: [Python-Dev] [RELEASE] Python 2.7.15

I would guess that the folks who end up supporting python 2 past 2020 (either as distributors or as library authors) will have an easier time of it if python 2's ssl module gets resynced with python 3 before the eol. But I suppose it's up to them to do the work... and probably other changes like

Re: [Python-Dev] Python startup time

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

Re: [Python-Dev] Process to remove a Python feature

On Wed, 2 May 2018 at 02:12 Victor Stinner wrote: > Hi, > > 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. > > We have multiple tools: > > * Emit a

Re: [Python-Dev] Python startup time

On Tue, May 1, 2018 at 11:55 PM, Ray Donnelly wrote: > Is your Python interpreter statically linked? The Python 3 ones from the anaconda distribution (use Miniconda!) are for Linux and macOS and that roughly halved our startup times. My Python interpreters use a shared

Re: [Python-Dev] [RELEASE] Python 2.7.15

The lack of movement for a year makes me wonder if PEP 546 should be moved to Withdrawn status. On Wed, May 2, 2018, at 02:35, Victor Stinner wrote: > Sadly, Python 2.7.15 still miss the implementation of the "PEP 546 -- > Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7": >

Re: [Python-Dev] Python startup time

On Wed, 2 May 2018 11:26:35 +0200 Victor Stinner wrote: > > Brett Cannon is also working on a standard solution for lazy imports > since many years: > https://pypi.org/project/modutil/ > https://snarky.ca/lazy-importing-in-python-3-7/ AFAIK, Mercurial already has its own

Re: [Python-Dev] Process to remove a Python feature

2018-05-02 11:17 GMT+02:00 Antoine Pitrou : > It's at least possible with gcc, clang and MSVC: > https://stackoverflow.com/questions/295120/c-mark-as-deprecated/295229#295229 > > You can even add a deprecation message. Aha, I opened an issue:

Re: [Python-Dev] [RELEASE] Python 2.7.15

Sadly, Python 2.7.15 still miss the implementation of the "PEP 546 -- Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7": https://www.python.org/dev/peps/pep-0546/ Last time I checked, the tests failed on Travis CI and I failed to reproduce the issue: https://bugs.python.org/issue22559 I

Re: [Python-Dev] Python startup time

What do you propose to make Python startup faster? As I wrote in my previous emails, many Python core developers care of the startup time and we are working on making it faster. INADA Naoki added -X importtime to identify slow imports and understand where Python spent its startup time. Recent

Re: [Python-Dev] Process to remove a Python feature

On Wed, 2 May 2018 11:11:16 +0200 Victor Stinner wrote: > > Removing a feature from the C API is more complex, since there is no > portable way to emit a deprecation warning at compilation. There is > Py_DEPRECATED() which seems to only be available on GCC (3.1 and > newer).

[Python-Dev] Process to remove a Python feature

Hi, 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. We have multiple tools: * Emit a PendingDeprecationWarning warning at runtime for *slow* deprecation (remove a feature in at

Re: [Python-Dev] Python startup time

On Wed, May 2, 2018, 4:53 AM Gregory Szorc wrote: > On 7/19/2017 12:15 PM, Larry Hastings wrote: > > > > > > On 07/19/2017 05:59 AM, Victor Stinner wrote: > >> Mercurial startup time is already 45.8x slower than Git whereas tested > >> Mercurial runs on Python 2.7.12.