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,
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 o
On 2018-05-02, 21:41 GMT, Guido van Rossum wrote:
> So what do *you* think. Do you agree with the OP that Tkinter (and hence
> IDLE) should be scrapped?
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
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
> > interpreter. So we wil
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 i
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
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 also
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
> > volunteer contributors in
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 (rare - at least it appear
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 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 with
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 ca
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 w
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. Again,
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 a
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 code in the branch at
> htt
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 shoul
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, allow Python packages to be
> 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 no-one gives a damn.
The se
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 wo
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 som
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). Producin
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 Python-Dev <
> > > python-dev@python.org> wrote:
> > >
> > > > As h
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 Tki
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 +
> > Brian Curtin wrote:
> > > On Wed, May
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 https://bugs.python.org/issue33257 and
> > > https://bugs.python.org/
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 and Py3, with both
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 gi
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 standalone "archive"
> files.
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, b
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, whic
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
list
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
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
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 them
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:
https://gith
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
tl
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
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 PendingDeprecationWarning
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 library. I'll definitely
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":
> https://www.pyt
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 lazy importer.
> Nick C
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: https://bugs.python.org/issue33407 "Implement
Py_DEPREC
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 exp
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 ex
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).
It's at least possib
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
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. Now try to sell Python 3 to
48 matches
Mail list logo
