Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

On Thu, Sep 13, 2018 at 8:33 PM Jonathan Fine wrote: > > > To be beautiful means to be yourself. You don't need > to be accepted by others. You need to accept yourself. > > I wonder if this is related to the beauty in "The Zen of Python". > > Different people may need different advice.

Re: [Python-ideas] A cute Python implementation of itertools.tee

On Sun, Apr 15, 2018 at 11:55 PM, Chris Angelico <ros...@gmail.com> wrote: > On Mon, Apr 16, 2018 at 6:46 AM, Koos Zevenhoven <k7ho...@gmail.com> > wrote: > > Anyway, the whole linked list is unnecessary if the iterable can be > iterated > > over multiple times

Re: [Python-ideas] A cute Python implementation of itertools.tee

On Mon, Apr 16, 2018 at 12:06 AM, Tim Peters <tim.pet...@gmail.com> wrote: > [Koos Zevenhoven <k7ho...@gmail.com>] > > It's definitely possible to write the above in a more > > readable way, and FWIW I don't think it involves "assignments as > > express

Re: [Python-ideas] A cute Python implementation of itertools.tee

t thought hard enough > about the problem ;-) > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- + Koos Ze

[Python-ideas] generator vs iterator etc. (was: How assignment should work with generators?)

nt is that the naming is suboptimal.​ SOLUTION: Maybe (a) all iterators should be called iterators or (b) all iterators should be called generators, regardless of whether they are somehow a result of a generator function having been called in the past. (I'm not going into the distinction between

Re: [Python-ideas] How assignment should work with generators?

t maybe you mean *fully consuming*. I think you are proposing partial or incremental consumption of the rhs. —Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org

Re: [Python-ideas] Star assignment in iterator way?

__ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___

Re: [Python-ideas] Consider (one day) adding an inheritance order class precedence mechanism

ne wanting that, but it still doesn't allow customizing the *whole* MRO, AFAICT. Regarding the inheritance trees of B and R that is. Or at least trying to somehow achieve that without introducing a metaclass would probably become a terrible hack (if not just impossible). ––Koos ​ -- + Koos Zevenhoven +

Re: [Python-ideas] Consider (one day) adding an inheritance order class precedence mechanism

On Thu, Nov 16, 2017 at 5:28 AM, Neil Girdhar <mistersh...@gmail.com> wrote: > On Wednesday, November 15, 2017 at 5:32:00 PM UTC-5, Koos Zevenhoven wrote: >> >> On Wed, Nov 15, 2017 at 11:49 PM, Neil Girdhar <miste...@gmail.com> >> wrote: >> >>> So

Re: [Python-ideas] Terminology of types / typing [was: PEP 560 (second post)]

analysis time, all types are static--including normal classes. But those correspond to concepts at runtime--abstract or concrete. -- Koos > -- > Ivan > > > > On 15 November 2017 at 17:54, Koos Zevenhoven <k7ho...@gmail.com> wrote: > >> On Wed, Nov 15, 2017

Re: [Python-ideas] Consider (one day) adding an inheritance order class precedence mechanism

sorting a graph that has additional edges according to the base lists of each class involved? In this case those edges would be E->C, S->E, B->R. Is this what your talking about, or do I misinterpret the problem? ​​-- Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven +

Re: [Python-ideas] Terminology of types / typing [was: PEP 560 (second post)]

On Wed, Nov 15, 2017 at 1:41 PM, Koos Zevenhoven <k7ho...@gmail.com> wrote: [..] > What do we call such a "type"? Maybe we have both "concrete" and "strictly > concrete" types. Perhaps we also have both "abstract" and "strictly > abstra

Re: [Python-ideas] PEP 560 (second post)

o, I'm still wondering about __bases__ and __orig_bases__. Could we call these __concrete_bases__ and __bases__ instead (respectively)? For an explanation of why I think this might be a good idea, see this new thread: https://mail.python.org/pipermail/python-ideas/2017-November/047896.html ​––Ko

Re: [Python-ideas] PEP 560 (second post)

On Fri, Nov 10, 2017 at 8:33 PM, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > On 10 November 2017 at 18:39, Koos Zevenhoven <k7ho...@gmail.com> wrote: > >> On Wed, Sep 27, 2017 at 12:28 PM, Ivan Levkivskyi <levkivs...@gmail.com> >> wrote: >> &

Re: [Python-ideas] Importance of noticing new signals

On Thu, Nov 2, 2017 at 2:57 PM, Koos Zevenhoven <k7ho...@gmail.com> wrote: > On Thu, Nov 2, 2017 at 2:22 PM, Antoine Pitrou <solip...@pitrou.net> > wrote: > >> On Wed, 1 Nov 2017 20:29:56 +0200 >> Koos Zevenhoven <k7ho...@gmail.com> wrote: >

Re: [Python-ideas] Importance of noticing new signals

On Thu, Nov 2, 2017 at 2:22 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Wed, 1 Nov 2017 20:29:56 +0200 > Koos Zevenhoven <k7ho...@gmail.com> wrote: > > > > ​From a correctness point of view, that is absolutely great: if > > PyErr_CheckSignals() is call

Re: [Python-ideas] Membership of infinite iterators

On Thu, Nov 2, 2017 at 1:41 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Thu, 2 Nov 2017 13:27:17 +0200 > Koos Zevenhoven <k7ho...@gmail.com> wrote: > > ​There's a limit to how cheap the call to PyErr_CheckSignals() can be. > As I > > mentioned earlier,

Re: [Python-ideas] Membership of infinite iterators

On Thu, Nov 2, 2017 at 3:39 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 2 November 2017 at 04:29, Koos Zevenhoven <k7ho...@gmail.com> wrote: > >> SPOILER ALERT! At the moment, Nick's statement is in fact **always** >> true in **all** cases (at least when ign

Re: [Python-ideas] Python-ideas Digest, Vol 131, Issue 106

On Tue, Oct 31, 2017 at 11:24 AM, Petr Viktorin <encu...@gmail.com> wrote: > On 10/31/2017 09:54 AM, Koos Zevenhoven wrote: >> >> >> ​I wonder if that's more easily understood if you write it along these >> line(s): >> >>(the_bob,) = ​(

Re: [Python-ideas] Python-ideas Digest, Vol 131, Issue 106

values from a larger collection, and the students are already coming into the lecture hall. Or should it be (a, b,) = find_complex_roots(polynomial_of_second_order) ? ––Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing list

Re: [Python-ideas] Add single() to itertools

that looks seriously weird. Oh wait, I know, it must be a regular expression! Perhaps mixed with Perl? To figure out what it does, we could try compiling it and throwing input at it, or perhaps more simply by just reverse engineering the implementation. ––Koos​ ​​ -- + Koos Zevenhoven +

Re: [Python-ideas] IMAP4.__exit__ counterintuitive for with blocks

/mailman/listinfo/python-ideas >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >>> >> >> >> -- >> --Guido van Rossum ( python.org/~guido) >> > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Defining an easily installable "Recommended baseline package set"

diately into > domain-specific answers, and it becomes tricky fast. > ​If the list is otherwise not be long enough, maybe it will contain something that is now in the stdlib?-) -- Koos​ -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python

Re: [Python-ideas] Composition over Inheritance

(looks like you forgot to reply to the list) On Sun, Oct 29, 2017 at 7:47 AM, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > Koos Zevenhoven wrote: > >> It looks like you can just as easily drive the car without having the key >> > > That's been found to be a pro

Re: [Python-ideas] Dollar operator suggestion

y be used for function composition too: > > > > foo = len $ set $ > > in the same as > > foo = lambda *as,**kas : len(set(*as, **kas)) > > in current syntax > > > > Regards, > > Yan > > > -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Composition over Inheritance

hat the public API of the car is. It looks like you can just as easily drive the car without having the key: just call car.ignition.start(). ​ -- Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing list Python-ideas@pyth

Re: [Python-ideas] Membership of infinite iterators

he consumer ends up iterating over pure-Python objects, there are no concerns about the overhead. But if it *does* call a C-implemented __next__, then that's the case where we actully need the whole thing. Adding the check in both places would double the (small) overhead. And nested (wrapped) it

Re: [Python-ideas] Membership of infinite iterators

On Wed, Oct 18, 2017 at 10:30 PM, Serhiy Storchaka <storch...@gmail.com> wrote: > 18.10.17 22:21, Koos Zevenhoven пише: > >> ​Nice! Though I'd really like a general ​solution that other code can >> easily adopt, even third-party extension libraries. >> > &g

Re: [Python-ideas] Membership of infinite iterators

On Wed, Oct 18, 2017 at 10:21 PM, Koos Zevenhoven <k7ho...@gmail.com> wrote: > On Wed, Oct 18, 2017 at 10:13 PM, Serhiy Storchaka <storch...@gmail.com> > wrote: > >> 18.10.17 17:48, Nick Coghlan пише: >> >>> 1. It will make those loops slower, due to the

Re: [Python-ideas] Membership of infinite iterators

ugs.python.org/issue31815 > > ​Nice! Though I'd really like a general ​solution that other code can easily adopt, even third-party extension libraries. -- Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing

Re: [Python-ideas] Membership of infinite iterators

or signals when it wraps around to 0. > Then I​'d say that's a great solution, except that `regex` probably over-exaggerates the overhead of checking for signals, and that `re` module for some strange reason wants to make an additional bitwise and. -- Koos -- + Koos Zevenhoven +

Re: [Python-ideas] Membership of infinite iterators

different ideas about that. My most recent point was that __contains__ already has to allow Python code to run on each iteration, so it is not the kind of code that Nick was referring to, and which I'm not convinced even exists. ––Koos > On 18 October 2017 at 16:40, Koos Zevenhoven &

Re: [Python-ideas] Membership of infinite iterators

On Wed, Oct 18, 2017 at 6:36 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 18 October 2017 at 16:27, Koos Zevenhoven <k7ho...@gmail.com> wrote: > > So you're talking about code that would make a C-implemented Python > iterable > > of strictly C-implemente

Re: [Python-ideas] Membership of infinite iterators

On Wed, Oct 18, 2017 at 5:48 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 18 October 2017 at 22:36, Koos Zevenhoven <k7ho...@gmail.com> wrote: > >> On Wed, Oct 18, 2017 at 2:08 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> >>> That one can o

Re: [Python-ideas] Memory limits [was Re: Membership of infinite iterators]

On Wed, Oct 18, 2017 at 2:38 PM, Steven D'Aprano <st...@pearwood.info> wrote: > On Wed, Oct 18, 2017 at 01:39:28PM +0300, Koos Zevenhoven wrote: > > > I'm writing from my phone now, cause I was dumb enough to try > list(count()) > > You have my sympathies -- I once, du

Re: [Python-ideas] Membership of infinite iterators

On Wed, Oct 18, 2017 at 2:08 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 18 October 2017 at 20:39, Koos Zevenhoven <k7ho...@gmail.com> wrote: > >> On Oct 18, 2017 13:29, "Nick Coghlan" <ncogh...@gmail.com> wrote: >> >> On 18 October 2017

Re: [Python-ideas] Membership of infinite iterators

On Oct 18, 2017 13:29, "Nick Coghlan" <ncogh...@gmail.com> wrote: On 18 October 2017 at 19:56, Koos Zevenhoven <k7ho...@gmail.com> wrote: > I'm unable to reproduce the "uninterruptible with Ctrl-C"​ problem with > infinite iterators. At least itertools d

Re: [Python-ideas] Membership of infinite iterators

hen you could skip the Maybe ones on the first pass, because if you find one that's plain True, you already have the answer. Regarding `x in y`, where y is an infinite iterable without well defined contents, that would return an instance of MaybeType, but .__bool__() would raise an exce

Re: [Python-ideas] Membership of infinite iterators

__ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Why not picoseconds?

Replying to myself again here, as nobody else said anything: On Mon, Oct 16, 2017 at 5:42 PM, Koos Zevenhoven <k7ho...@gmail.com> wrote: > > > ​Indeed. And some more on where the precision loss comes from: > > When you measure time starting from one point, like 1970, the

Re: [Python-ideas] Add time.time_ns(): system clock with nanosecond resolution

v anyway. > On Mon, Oct 16, 2017 at 1:56 AM, Koos Zevenhoven <k7ho...@gmail.com> > wrote: > >> On Mon, Oct 16, 2017 at 2:44 AM, Guido van Rossum <gu...@python.org> >> wrote: >> >>> Sorry, that's an in-joke. Koos is expressing his disappointment in the

Re: [Python-ideas] Why not picoseconds?

o a number like that. You then need log2(10**9) ~ 30 bits of precision just to get a one-second resolution in your timer. A double-precision (64bit) floating point number has 53 bits of precision in the mantissa, so you end up with 23 bits of precision left for fractions of a second, which means you get a

Re: [Python-ideas] Add time.time_ns(): system clock with nanosecond resolution

[*] Although right now different people still have slightly different ideas about what that conclusion is. ​ > On Sun, Oct 15, 2017 at 3:16 PM, Steven D'Aprano <st...@pearwood.info> > wrote: > >> On Sun, Oct 15, 2017 at 08:04:25PM +0300, Koos Zevenhoven wrote: >> > O

Re: [Python-ideas] Why not picoseconds?

time.time' > 't()' > > > > Linux (Mean +- std dev): > > > > * time.time(): 45.4 ns +- 0.5 ns > > * time.time_ns(): 47.8 ns +- 0.8 ns > > * time.perf_counter(): 46.8 ns +- 0.7 ns > > * time.perf_counter_ns(): 46.0 ns +- 0.6 ns > > &g

Re: [Python-ideas] Add time.time_ns(): system clock with nanosecond resolution

All joking aside, I actually like it that Python also allows one to interact with lower-level concepts when needed. Maybe there could be even more of this? -- Koos On Sun, Oct 15, 2017 at 8:04 PM, Koos Zevenhoven <k7ho...@gmail.com> wrote: > On Sun, Oct 15, 2017 at 6:58 PM, Guido van R

Re: [Python-ideas] Add time.time_ns(): system clock with nanosecond resolution

in the long run. -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] (PEP 555 subtopic) Propagation of context in async code

On Sun, Oct 15, 2017 at 5:34 PM, Amit Green <amit.mi...@gmail.com> wrote: > On Sun, Oct 15, 2017 at 9:44 AM, Koos Zevenhoven <k7ho...@gmail.com> > wrote: > >> So, see below for some more discussion between (it would be useful if >> some people could reply

Re: [Python-ideas] PEP draft: context variables

ink that would make it much more usable by those of us who are > not experts. > ​The semantics is not really dependent on __aenter__ and __aexit__. They can be used together with both semantic variants that I'm describing for PEP 555, and without any special casing. IOW, this is independ

Re: [Python-ideas] (PEP 555 subtopic) Propagation of context in async code

On Fri, Oct 13, 2017 at 7:38 PM, Yury Selivanov <yselivanov...@gmail.com> wrote: > On Fri, Oct 13, 2017 at 11:49 AM, Koos Zevenhoven <k7ho...@gmail.com> > wrote: > [..] > > This was my starting point 2.5 years ago, when Yury was drafting this > status > > quo (

Re: [Python-ideas] PEP draft: context variables

il/python-ideas/2017-October/047292.html In fact, I might want to add a another Py_INCREF and Py_DECREF per each call to next/send, because the hack to defer (and often avoid) the Py_INCREF of the outer stack would not be worth the performance gain. But that's it. ––Koos -- + Koos

[Python-ideas] (PEP 555 subtopic) Propagation of context in async code

context arguments​ and 2. execution context arguments ​Both of these would have their own​ stack of (argument, value) assignment pairs, explained in the implementation part of the first PEP 555 draft. While this is a complication, the performance overhead of these is so small, that doubling

Re: [Python-ideas] PEP draft: context variables

On Oct 12, 2017 9:03 PM, "Yury Selivanov" <yselivanov...@gmail.com> wrote: On Thu, Oct 12, 2017 at 8:59 AM, Koos Zevenhoven <k7ho...@gmail.com> wrote: > On Thu, Oct 12, 2017 at 6:54 AM, Nick Coghlan <ncogh...@gmail.com> wrote: [..] >> 1. Preserve the c

Re: [Python-ideas] PEP draft: context variables

On Thu, Oct 12, 2017 at 6:54 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 11 October 2017 at 21:58, Koos Zevenhoven <k7ho...@gmail.com> wrote: > >> On Wed, Oct 11, 2017 at 7:46 AM, Steve Dower <steve.do...@python.org> >> wrote: >> >&g

Re: [Python-ideas] PEP draft: context variables

don't want new use cases to copy the semantics from the old ones which currently have issues (because they were originally designed to work with traditional function and method calls, and using then-available techniques). ––Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 5:46 PM, Yury Selivanov <yselivanov...@gmail.com> wrote: > On Tue, Oct 10, 2017 at 10:22 AM, Koos Zevenhoven <k7ho...@gmail.com> > wrote: > > On Tue, Oct 10, 2017 at 5:01 PM, Nick Coghlan <ncogh...@gmail.com> > wrote: > >> > &g

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 5:40 PM, Yury Selivanov <yselivanov...@gmail.com> wrote: > On Tue, Oct 10, 2017 at 8:34 AM, Koos Zevenhoven <k7ho...@gmail.com> > wrote: > > On Tue, Oct 10, 2017 at 4:22 AM, Yury Selivanov <yselivanov...@gmail.com > > > > wrote: &

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 5:01 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 10 October 2017 at 22:51, Koos Zevenhoven <k7ho...@gmail.com> wrote: > >> ​I see no reason why these two should be equivalent. >> > > There is no "should"

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 3:34 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 10 October 2017 at 01:24, Guido van Rossum <gu...@python.org> wrote: > >> On Sun, Oct 8, 2017 at 11:46 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> >>> On 8 October 2017

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 4:22 AM, Yury Selivanov <yselivanov...@gmail.com> wrote: > On Mon, Oct 9, 2017 at 8:37 PM, Koos Zevenhoven <k7ho...@gmail.com> wrote: > > You can cause unbound growth in PEP 550 too. All you have to do is nest > an > > unbounded number of gen

Re: [Python-ideas] PEP draft: context variables

On Tue, Oct 10, 2017 at 1:55 AM, Yury Selivanov <yselivanov...@gmail.com> wrote: > On Mon, Oct 9, 2017 at 4:39 PM, Koos Zevenhoven <k7ho...@gmail.com> wrote: > > On Mon, Oct 9, 2017 at 6:24 PM, Guido van Rossum <gu...@python.org> > wrote: > [..] > >&

Re: [Python-ideas] PEP draft: context variables

On Mon, Oct 9, 2017 at 6:24 PM, Guido van Rossum <gu...@python.org> wrote: > On Sun, Oct 8, 2017 at 11:46 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > >> On 8 October 2017 at 08:40, Koos Zevenhoven <k7ho...@gmail.com> wrote: >> >>> On Sun

Re: [Python-ideas] PEP draft: context variables

On Mon, Oct 9, 2017 at 9:46 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 8 October 2017 at 08:40, Koos Zevenhoven <k7ho...@gmail.com> wrote: > >> On Sun, Oct 8, 2017 at 12:16 AM, Nathaniel Smith <n...@pobox.com> wrote: >> >>> On Oct 7, 2017 12:20

Re: [Python-ideas] PEP draft: context variables

On Sun, Oct 8, 2017 at 12:16 AM, Nathaniel Smith <n...@pobox.com> wrote: > On Oct 7, 2017 12:20, "Koos Zevenhoven" <k7ho...@gmail.com> wrote: > > > ​Unfortunately, we actually need a third kind of generator semantics, > something like this: > >

Re: [Python-ideas] PEP draft: context variables

the first draft and some things are still missing, > but the essential things should be there. > > -- Koos > > || > > PEP: 999 > Title: Context-local variables (contextvars) > Version: $Revision$ > Last-Mo

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Wed, Sep 13, 2017 at 6:14 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 13 September 2017 at 00:35, Koos Zevenhoven <k7ho...@gmail.com> wrote:> > > I don't see how the situation benefits from calling something the "main > > interpreter". Subinterpret

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Tue, Sep 12, 2017 at 6:30 PM, Koos Zevenhoven <k7ho...@gmail.com> wrote: > On Tue, Sep 12, 2017 at 5:53 PM, Stefan Krah <ste...@bytereef.org> wrote: > >> On Tue, Sep 12, 2017 at 05:35:34PM +0300, Koos Zevenhoven wrote: >> > I don't see how the situatio

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Mon, Sep 11, 2017 at 8:32 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 11 September 2017 at 00:52, Koos Zevenhoven <k7ho...@gmail.com> wrote: > > On Thu, Sep 7, 2017 at 9:26 PM, Eric Snow <ericsnowcurren...@gmail.com> > > wrote: > > [...] > &

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

s purpose at the time. -- Koos [*] For instance regarding the role of the glo... local interpreter locks (LILs) ;) -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/pyt

Re: [Python-ideas] PEP draft: context variables

On Tue, Sep 5, 2017 at 8:43 PM, Yury Selivanov <yselivanov...@gmail.com> wrote: > On Tue, Sep 5, 2017 at 10:31 AM, Koos Zevenhoven <k7ho...@gmail.com> > wrote: > > On Tue, Sep 5, 2017 at 8:24 PM, Yury Selivanov <yselivanov...@gmail.com> > > wrote: > &

Re: [Python-ideas] PEP draft: context variables

On Tue, Sep 5, 2017 at 8:24 PM, Yury Selivanov <yselivanov...@gmail.com> wrote: > On Tue, Sep 5, 2017 at 9:12 AM, Koos Zevenhoven <k7ho...@gmail.com> wrote: > > On Tue, Sep 5, 2017 at 6:53 PM, Yury Selivanov <yselivanov...@gmail.com> > > wrote: > >>

Re: [Python-ideas] PEP draft: context variables

On Tue, Sep 5, 2017 at 3:49 AM, Nathaniel Smith <n...@pobox.com> wrote: > On Mon, Sep 4, 2017 at 2:50 PM, Koos Zevenhoven <k7ho...@gmail.com> wrote: > > Hi all, > > > > as promised, here is a draft PEP for context variable semantics and > > implementation

Re: [Python-ideas] PEP draft: context variables

On Tue, Sep 5, 2017 at 1:20 AM, Oleg Broytman <p...@phdru.name> wrote: > Hi! > > On Tue, Sep 05, 2017 at 12:50:35AM +0300, Koos Zevenhoven < > k7ho...@gmail.com> wrote: > > cvar = contextvars.Var(default="the default value", > >

[Python-ideas] PEP draft: context variables

|| PEP: 999 Title: Context-local variables (contextvars) Version: $Revision$ Last-Modified: $Date$ Author: Koos Zevenhoven Status: Draft Type: Standards Track Content-Type: text/x-rst Created: DD-Mmm- Post-History: DD-Mmm- Abstract Sometimes, in special

Re: [Python-ideas] PEP 550 dumbed down

d value? But now we need to look up the key object from somewhere? [...] > > 4. Provides common APIs that will be used by asyncio, decimal, numpy, etc. > > Which APIs? The C API you mean? Something that is not in Jim's list? Something that is (not) in the PEP? People need to get

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

onvenient for the caller > >>> def spam(...): > ... [...] > ... return (eggs=eggs, ham=ham) > > ​Yes, but for the caller it's just as convenient without new namedtuple syntax. If there's new *syntax* for returning multiple values, it would indeed hopefully look more into the f

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

te names in the object shouldn't take up that much memory. And the tuples are probably often short-lived. Given all this, the syntax for creating anonymous namedtuples efficiently probably does not really need to be super convenient on the Python side, but having it available and unified with that st

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

need to be syntax instead of a library? > > Indeed, we might need the syntax (x=1, y=2) later for something different. However, I hope we can forget about 'ntuple', because it suggests a tuple of n elements. Maybe something like return tuple.named(x=foo, y=bar) which is backwards compati

Re: [Python-ideas] Arguments to exceptions

d be called) might stay the same. -- Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Runtime types vs static types

On Sun, Jul 2, 2017 at 2:16 PM, Steven D'Aprano <st...@pearwood.info> wrote: > On Sat, Jun 24, 2017 at 10:42:19PM +0300, Koos Zevenhoven wrote: > > [...] > > Clearly, there needs to be some sort of distinction between runtime > > classes/types and static types, becau

Re: [Python-ideas] + operator on generators

On Jun 30, 2017 2:23 PM, "Erik Bray" wrote: I actually really like this proposal, in additional to the original proposal of using '+' to chain generators--I don't think it necessarily needs to be extended to *all* iterables. But this proposal goes one better. I just have

Re: [Python-ideas] CPython should get...

On Jun 30, 2017 5:16 PM, "Oleg Broytman" wrote: On Fri, Jun 30, 2017 at 12:09:52PM -0300, "Soni L." wrote: > CPython should get a You're welcome to create one. Go on, send your pull requests! But if you are planning to do that, it is still a good

Re: [Python-ideas] Runtime types vs static types

A) # TypeError > > @runtime > class B(Protocol[T]): > y: T > isinstance(obj, B) # True or False depending on whether 'obj' has > attribute 'y' > isinstance(obj, B[int]) # Still TypeError > > -- > Ivan > > > -- + Koos Zevenhoven + http://twitter.com/k7hov

Re: [Python-ideas] + operator on generators

hings with list() can be ok, but uses memory and is O(n). Generating lists from all kinds of iterables all the time is just a whole bunch of unnecessary overhead. But yes, it happens, because that's the convenient way of doing it now. That's like going back to Python 2, but with additional calls

Re: [Python-ideas] + operator on generators

On Wed, Jun 28, 2017 at 3:18 PM, Sven R. Kunze <srku...@mail.de> wrote: > On 28.06.2017 14:00, Koos Zevenhoven wrote: > > The programmer needs to be well aware of whether the resulting object is a > Sequence or 'just' a generator. > > > Could you elaborate more on **

Re: [Python-ideas] + operator on generators

bject is a Sequence or 'just' a generator. -- Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] + operator on generators

rom(genfunc): return genfunc() Except of course `from` is a keyword and it should probably just be `call`. ​ But this still doesn't naturally extend to allow indexing and slicing, like c[2] and c[1:3], for the case where the concatenated iterables are Sequences. -- Koos -- + Koos Zevenho

Re: [Python-ideas] Runtime types vs static types

On Sun, Jun 25, 2017 at 8:47 PM, Lucas Wiman wrote: > > ​Yes, but then `isinstance(tuple(range(100)), Tuple[int, ...])` > would be a difficult case. > > Yes, many methods on million-element tuples are slow. :-) > > Python usually chooses the more intuitive behavior

Re: [Python-ideas] + operator on generators

g > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Runtime types vs static types

On Sun, Jun 25, 2017 at 7:13 PM, Lucas Wiman wrote: [...] > >>> from typing import * > >>> isinstance(0, Union[int, float]) > Traceback (most recent call last): > File "", line 1, in > File "/Users/lucaswiman/.pyenv/versions/3.6/lib/python3.6/typing.py", > line 767,

Re: [Python-ideas] Runtime types vs static types

On Sat, Jun 24, 2017 at 11:30 PM, Lucas Wiman <lucas.wi...@gmail.com> wrote: > ​ > On Sat, Jun 24, 2017 at 12:42 PM, Koos Zevenhoven <k7ho...@gmail.com> > wrote: > >> There has been some discussion here and there concerning the differences >> between runt

[Python-ideas] Runtime types vs static types

lready much longer than a single email should be ;) -- Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

On Thu, Jun 1, 2017 at 9:47 AM, Serhiy Storchaka wrote: > What you are think about adding Unicode aliases for some mathematic names in > the math module? ;-) > > math.π = math.pi > math.τ = math.tau > math.Γ = math.gamma > math.ℯ = math.e > > Unfortunately we can't use ∞, ∑

Re: [Python-ideas] tweaking the file system path protocol

>>> complex(MyComplex(10j)) > 5j > >>> class MyStr(str): > ... def __str__(self): > ... return "Hello" > ... > >>> str(MyStr("Not hello")) > 'Hello' > &g

Re: [Python-ideas] tweaking the file system path protocol

isallowed the use of str/bytes as > paths, but I don't think that is a prerequisite here. > Yes, I wrote that, and I stick with it: str and bytes subclasses that return something different from the str/bytes content should not be written. If Python ever disallows str/bytes as paths, such a thing becomes less harmful, and there is no need to have special treatment for str and bytes. Until then, I'm very happy with the decision to ignore __fspath__ on str and bytes. —Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] tweaking the file system path protocol

n mystr") return real_fspath(path) os.fspath = fspath try_something_with(mystr) Having __fspath__ on str and bytes by default would destroy the ability to distinguish between PathLike and non-PathLike, because all strings would appear to be PathLike. (Not to mention the important compatibi

Re: [Python-ideas] tweaking the file system path protocol

s, can people start writing such subclasses. I'm sure many would now say dropping str/bytes path support won't even happen in Python 4. -- Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing list Python-ideas@python.org http

Re: [Python-ideas] tweaking the file system path protocol

I noticed I had left out some of the details of the reasoning, sorry. I tried to fix that in my response to Steven. — Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mail

Re: [Python-ideas] tweaking the file system path protocol

sent as a response to the OP will appear if a subclass returns something other than str(self) or bytes(self). —Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven + ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailm

Re: [Python-ideas] tweaking the file system path protocol

r performance compensation. > b) user-defined classes that inherit from str or bytes could control their > path representation just like any other class Again, this would cause differences in behavior between different Python versions, and based on whether str(path) is used or not.

Re: [Python-ideas] Exploiting type-homogeneity in list.sort() (again!)

_hint__ is None: > process_slow(thelist) > else: > process_fast(thelist) > > > At the very least, I'd be interested in experimenting with this. > > Thoughts? > > > > -- > Steve > _____

  1   2   >