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

> On May 7, 2018, at 9:57 AM, Brett Cannon wrote: > > > > On Mon, 7 May 2018 at 09:55 Ivan Levkivskyi > wrote: > On 7 May 2018 at 17:32, Brett Cannon > wrote: > On Mon, 7 May 2018 at 08:18 João Santos > wrote: > H

Re: [Python-Dev] Python startup time

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

Re: [Python-Dev] Boundaries between numbers and identifiers

> On Apr 26, 2018, at 11:37 AM, Serhiy Storchaka wrote: > > I propose to change the Python syntax by adding a requirement that there > should be a whitespace or delimiter between a numeric literal and the > following keyword. -1 This would make Python 3.8 reject code due to stylistic prefere

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

> On Apr 26, 2018, at 11:00 AM, Fatty Morgan wrote: > > I would like to urge you to reconsider the use of the token ':=' > for assignment expressions. > > The natural interpretation of 'name := expr' is a PEP 526 > type-annotated variable initialization 'name : T = expr' with the > type annotat

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Uncle T] > So, to match your sarcasm, here's mine: try using a feature for what > it's good at instead of for what it's bad at ;-) Yes, this is the fundamental wisdom. Judging which is which is left as an exercise to the programmer. With this, I'm leaving the discussion. With Guido and you on

Re: [Python-Dev] Why is pickle.DEFAULT_PROTOCOL still 3?

> On Apr 2, 2018, at 2:13 PM, Antoine Pitrou wrote: > > On Mon, 2 Apr 2018 13:48:46 -0700 > Lukasz Langa wrote: >> Pickle protocol version 4.0 was originally defined back in PEP 3154 and >> shipped as part of Python 3.4 back in 2011. Yet it's still not the

[Python-Dev] Why is pickle.DEFAULT_PROTOCOL still 3?

Pickle protocol version 4.0 was originally defined back in PEP 3154 and shipped as part of Python 3.4 back in 2011. Yet it's still not the default. There's a number of things that would run faster with it like multiprocessing. This is too late for 3.7 which is a shame but can we at least bump it

Re: [Python-Dev] Dataclasses and correct hashability

To add a counter-example that I'm painfully familiar with: the old Thrift for Python makes its (mutable) structures hashable. This is "useful" because you can memoize functions that take Thrift structures as arguments. You can key dictionaries with them. And so on. Unfortunately, more often the

Re: [Python-Dev] Guido's Python 1.0.0 Announcement from 27 Jan 1994

> On 27 Jan, 2018, at 5:10 PM, Dan Stromberg wrote: > > We probably should (if possible) create an archive (with dates) of > very old (or all, actually) versions of CPython, analogous to what The > Unix Heritage Society does for V5, V7, etc., but for CPython... > > Or is there one already? I f

Re: [Python-Dev] Guido's Python 1.0.0 Announcement from 27 Jan 1994

> On 27 Jan, 2018, at 12:52 PM, Simon Cross > wrote: > > Python Party Proposal! Oh, that's okay then. For a second there I got reminded of the dreadful days of trying to get dial-up to work on Linux with a winmodem. PPP. Shudder. - Ł signature.asc Description: Message signed with OpenPGP _

[Python-Dev] Merging the implementation of PEP 563

Hi all, Serhiy looks busy these days. I'd appreciate somebody looking at and hopefully merging https://github.com/python/cpython/pull/4390 . Everything there was reviewed by Serhiy except for the latest commit. This should be ready to merge and maybe

Re: [Python-Dev] HP-UX pr not feeling the love

Hi Rob, thanks for your patch. CPython core developers, as volunteers, have limited resources available to maintain Python. Those resources are not only time, they are also mental resources necessary to make a change in Python as well as actual physical resources. Supporting a platform requires

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

+1 to (3), I like the type error idea, too. I don't care much about naming... but if I were to bikeshed this, I'd go for isdataclass (like issubclass) isdatainstance (like isinstance) - Ł > On Nov 30, 2017, at 12:35 PM, Carl Meyer wrote: > > On 11/29/2017 05:02 PM, Guido van Rossum wrote: >>

[Python-Dev] What's the status of PEP 505: None-aware operators?

Hi Mark, it looks like the PEP is dormant for over two years now. I had multiple people ask me over the past few days about it though, so I wanted to ask if this is moving forward. I also cc python-dev to see if anybody here is strongly in favor or against this inclusion. If the idea itself is

[Python-Dev] PEP 563: Postponed Evaluation of Annotations (Draft 3)

Based on the feedback I gather in early November, I'm publishing the third draft for consideration on python-dev. I hope you like it! A nicely formatted rendering is available here: https://www.python.org/dev/peps/pep-0563/ The full list of changes between this version and the previous draft can

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

See my response to Mark's e-mail. I agree that special-casing outermost strings is not generic enough of a solution and will be removing this special handling from the PEP and the implementation. - Ł > On Nov 19, 2017, at 2:38 PM, Koos Zevenhoven wrote: > > On Mon, Nov 13, 2017 at 11:59 PM, B

Re: [Python-Dev] Comments on PEP 563 (Postponed Evaluation of Annotations)

I agree with you. The special handling of outermost strings vs. strings embedded inside annotations bugged me a lot. Now you convinced me that this functionality should be moved to `get_type_hints()` and the __future__ import shouldn't try to special-case this one instance, while leaving others

Re: [Python-Dev] Show DeprecationWarning in debug mode?

Merged. Thanks! ✨ 🍰 ✨ - Ł > On Nov 20, 2017, at 7:01 AM, Victor Stinner wrote: > > 2017-11-18 18:13 GMT+01:00 Brett Cannon : >> +1 from me as well. > > Ok, I created https://bugs.python.org/issue32088 and > https://github.com/python/cpython/pull/4474 to implement the proposed > change. > > Vi

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

> On 10 Nov, 2017, at 4:48 PM, Guido van Rossum wrote: > > On Fri, Nov 10, 2017 at 1:20 AM, Lukasz Langa <mailto:luk...@langa.pl>> wrote: > Alright, we're on bikeshed territory now. Finally! :-) > > I was always thinking about this as "static annotat

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

Alright, we're on bikeshed territory now. Finally! :-) I was always thinking about this as "static annotations". The fact they're strings at runtime is irrelevant for most people who will use this future. They don't want string annotations, they want them to not be evaluated on import time... t

[Python-Dev] Reminder: PEP 479's __future__ about to become the default behavior

This is according to https://www.python.org/dev/peps/pep-0479/#transition-plan but looking at Objects/genobject.c that hasn't been implemented yet. Is this as simple as removing the `else` clause here? https://github.com/python/cpython

Re: [Python-Dev] Remove typing from the stdlib

> On Nov 7, 2017, at 2:33 PM, Nick Coghlan wrote: > > On 8 November 2017 at 04:41, Lukasz Langa wrote: >> 4. How do we even version this library then? Probably like this: 3.7.0.0, >> 3.7.0.1, 3.7.1.0, and so on. But that depends on answers to the other >> question

Re: [Python-Dev] Remove typing from the stdlib

> On Nov 7, 2017, at 9:39 AM, Brett Cannon wrote: > > On Tue, 7 Nov 2017 at 03:34 Paul Moore > wrote: > > Because type annotations are a development-time feature, they should > *not* require a dependency in the final deployment (apart from Python > itself). However,

Re: [Python-Dev] Remove typing from the stdlib

> On Nov 6, 2017, at 8:01 PM, Nick Coghlan wrote: > > As I indicated in my comment there, I'm now wondering if there might > be an opportunity here whereby we could use the *dataclasses* module > to define a stable non-provisional syntactically compatible subset of > the typing module, and requi

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

> On Nov 5, 2017, at 11:28 PM, Nick Coghlan wrote: > > On 6 November 2017 at 16:36, Lukasz Langa wrote: > > - compile annotations like a small nested class body (but returning > the expression result, rather than None) > - emit MAKE_THUNK instead of the expressi

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

> On 5 Nov, 2017, at 9:55 PM, Nick Coghlan wrote: > > Python's name resolution rules are already ridiculously complicated, > and PEP 563 is proposing to make them *even worse*, purely for the > sake of an optional feature primarily of interest to large enterprise > users. Solving forward refere

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

> On 4 Nov, 2017, at 6:32 PM, Nick Coghlan wrote: > > The PEP's current attitude towards this is "Yes, it will break, but > that's OK, because it doesn't matter for the type annotation use case, > since static analysers will still understand it". Adopting such a > cavalier approach towards backw

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

> On 4 Nov, 2017, at 11:43 AM, Peter Ludemann via Python-Dev > wrote: > > If type annotations are treated like implicit lambdas, then that's a first > step to something similar to Lisp's "special forms". A full generalization of > that would allow, for example, logging.debug to not evaluate i

Re: [Python-Dev] Remove typing from the stdlib

> On 4 Nov, 2017, at 3:39 AM, Paul Moore wrote: > > Lukasz Langa said: >> So, the difference is in perceived usability. It's psychological. > > Please, let's not start the "not in the stdlib isn't an issue" debate > again. If I concede it

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

> On 5 Nov, 2017, at 6:29 PM, Oleg Broytman wrote: > > On Sun, Nov 05, 2017 at 09:20:12PM -0500, Yury Selivanov > wrote: >> Big +1 from me. The whole point of DeprecationWarnings is to be >> visible > > The whole point of DeprecationWarnings is to be visible to > developers while in reality

Re: [Python-Dev] Remove typing from the stdlib

> On 3 Nov, 2017, at 4:01 PM, Victor Stinner wrote: > > The question is if you would only need or pip install typing>. > > If typing is removed from the stdlib, you can still use it in your > application. It's "just" another dependency no? The ideal situation is that something is built-in a

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

> On Nov 2, 2017, at 1:13 PM, Stéfane Fermigier wrote: > > Another common use case is dependency injection / IoC: > > - Injector (https://github.com/alecthomas/injector > ): > - Flask-Injector (ok it's the same underlying injector): Pretty cool! This is

Re: [Python-Dev] Migrate python-dev to Mailman 3?

+1 committers > On Nov 1, 2017, at 7:54 PM, Barry Warsaw wrote: > > On Nov 1, 2017, at 19:42, Guido van Rossum wrote: >> >> Maybe we should try it on some other list too? I know it works "in >> principle" and I'd love for all Python mailing lists to migrate, but I'd >> like to have some more

Re: [Python-Dev] Migrate python-dev to Mailman 3?

> On Oct 30, 2017, at 4:00 AM, Victor Stinner wrote: > > Except of Antoine Pitrou, does everybody else like the new UI? :-) I also much prefer MM3 and HyperKitty. The old pipermail tree looks more inviting (I like the concise tree) but it's deceiving. When you actually start going through an

Re: [Python-Dev] PEP 530

The original poster is an elementary school student. To keep the list clean, I responded 1:1 in a more inviting manner. Hopefully the person will succeed installing and learning Python :-) - Ł > On Oct 28, 2017, at 2:33 PM, Terry Reedy wrote: > > On 10/27/2017 4:43 PM, London wrote: >> can yo

Re: [Python-Dev] PEP 511 (code transformers) rejected

I find this sad. In the JavaScript community the existence of Babel is very important for the long-term evolution of the language independently from the runtime. With Babel, JavaScript programmers can utilize new language syntax while being able to deploy on dated browsers. While there's always

[Python-Dev] PEP 563: Postponed Evaluation of Annotations

Based on positive feedback on python-ideas back in September, I'm publishing the second draft for consideration on python-dev. I hope you like it! A nicely formatted rendering is available here: https://www.python.org/dev/peps/pep-0563/ (Just make sure you're looking at the version that has "Post

Re: [Python-Dev] Generator objects and list comprehensions?

> On Feb 2, 2017, at 2:17 AM, Anders Munch wrote: > > Give Python 2 a little more credit. We are, it told you what your issue was: yield outside a function. Consider: >>> def f(): ... l = [(yield 1) for x in range(10)] ... print(l) >>> gen = f() >>> for i in range(11): ... ge

Re: [Python-Dev] re performance

> On Jan 31, 2017, at 11:40 AM, Wang, Peter Xihong > wrote: > > Regarding to the performance difference between "re" and "regex" and > packaging related options, we did a performance comparison using Python 3.6.0 > to run some micro-benchmarks in the Python Benchmark Suite > (https://github.

Re: [Python-Dev] re performance

> On Jan 30, 2017, at 6:26 AM, Barry Warsaw wrote: > > Actually, I think pkg_resources would make an excellent candidate. The > setuptools crew is working on a branch that would allow for setuptools and > pkg_resources to be split, which would be great for other reasons. Splitting > them may m

Re: [Python-Dev] Investigating Python memory footprint of one real Web application

> On Jan 23, 2017, at 12:10 PM, Brett Cannon wrote: > > > > On Mon, 23 Jan 2017 at 04:27 INADA Naoki > wrote: > On Mon, Jan 23, 2017 at 8:33 PM, Victor Stinner > mailto:victor.stin...@gmail.com>> wrote: > > 2017-01-23 12:25 GMT+01:00 INADA Naoki >

Re: [Python-Dev] Making the new dtrace support work on OS X

Looks like function-entry and function-return give you the C-level frame names for some reason. This was implemented on OS X 10.11 if that makes any difference. I will look at this in the evening, the laptop I'm on now is macOS Sierra with SIP which cripples dtrace. > On Jan 12, 2017, at 5:08 A