Steering Council, g'day, Hawaii?
("copying" BDFL-emeritus, everyone)
I'm sorry you haven't heard from me in a while. Actually, neither have any
of my other "girl friends" heard from me. I was worried that they might be
sad. Then I found out that one of them was at some kind of party at a club
or
I've had some things going on, and I'm still trying to catch up with the
discussions here. Can someone tell me what would be the best place to look
at the most recent proposal? Is one of the PEPs up to date?
On Mon, Nov 16, 2020 at 7:02 PM Tobias Kohn wrote:
> Hi Mark,
>
> Thank you for your int
Hi everyone,
By what I'm about to write below, I've aimed at a design to meet needs
resembling those that PEP 622 deals with, although with some differences,
especially in emphasis.
I'm not writing a full introduction here; the intended audience of this
email is people somewhat familiar with PEP
On Sun, Jul 19, 2020 at 3:00 PM Tobias Kohn wrote:
> Quoting Koos Zevenhoven :
>
> > (1) Class pattern that does isinstance and nothing else.
> >
> > If I understand the proposed semantics correctly, `Class()` is
> equivalent to checking `isinstance(obj, Class)`, also
PEP 622 authors,
Overall, the PEP describes the proposal quite nicely. However, I do indeed
have concerns and questions, some of which I describe in this email.
(1) Class pattern that does isinstance and nothing else.
If I understand the proposed semantics correctly, `Class()` is equivalent
to c
On Sat, Jul 18, 2020 at 3:46 AM Terry Reedy wrote:
>
> A major points of Kohn's post is that 'case' is analogous to 'def' and
> match lists are analogous to parameter lists. In parameter lists,
> untagged simple names ('parameter names') are binding targets.
> Therefore, untagged simple names in
On Tue, Jan 23, 2018 at 2:23 AM, Victor Stinner
wrote:
> The PEP 555 looks a competitor PEP of the PEP 567. Since the Yury's
> PEP 567 was approved, I understand that Koos's PEP 555 should be
> rejected, no?
>
>
If Guido prefers to reject it, I assume he'll say so. Anyway, it's still
waiting for
kind of sad that after all this, contextvars still
would not make it into 3.7, I also thought that it might be the right
decision. As you may already know, I think there are several problems with
this PEP. Would it be worth it to write down some thoughts on this PEP in
the morning?
-- Koos
--
I'll quickly add a few things below just in case there's anyone that cares.
On Wed, Jan 10, 2018 at 2:06 AM, Koos Zevenhoven wrote:
>
> The idea was to always explicitly define the scope of contextvar values. A
> context manager / with statement determined the scope of .s
ssum wrote:
> I'm sorry, Koos, but based on your past contributions I am not interested
> in discussing this topic with you.
>
> On Wed, Jan 10, 2018 at 8:58 AM, Koos Zevenhoven
> wrote:
>
>> The status of PEP 555 is just a side track. Here, I took a step back
>&g
u'd rather see a decision from me I'll be
> happy to change it to "Rejected".
>
> On Tue, Jan 9, 2018 at 10:29 PM, Koos Zevenhoven
> wrote:
>
>> On Jan 10, 2018 07:17, "Yury Selivanov" wrote:
>>
>> Wasn't PEP 555 rejected by Guido?
; in the second paragraph
of course.
-- Koos (mobile)
Yury
On Wed, Jan 10, 2018 at 4:08 AM Koos Zevenhoven wrote:
> Hi all,
>
> I feel like I should write some thoughts regarding the "context"
> discussion, related to the various PEPs.
>
> I like PEP 567 (+ 567 ?) be
Hi all,
I feel like I should write some thoughts regarding the "context"
discussion, related to the various PEPs.
I like PEP 567 (+ 567 ?) better than PEP 550. However, besides providing
cvar.set(), I'm not really sure about the gain compared to PEP 555 (which
could easily have e.g. a dict-like i
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
to represent types, then this would be a
good moment to gently "enforce" it.
––Koos
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-
On Mon, Nov 13, 2017 at 11:59 PM, Brett Cannon wrote:
[..]
> On Sun, Nov 12, 2017, 10:22 Koos Zevenhoven, wrote:
>
>
>>
>> There's two thing I don't understand here:
>>
>> * What does it mean to preserve the string verbatim? No matter how I read
mic language.
—Koos
[1] As defined in the PEP 563 draft:
https://mail.python.org/pipermail/python-dev/2017-November/150062.html
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org
many C extensions and check how many extensions are broken
>
>
> My plan for Python 3.7 is to not touch the current API at all. There
> is no risk of backward incompatibility. You should only get issues if
> you opt-in for the new API without implementation details.
>
>
> F
On Fri, Nov 17, 2017 at 3:40 PM, Koos Zevenhoven wrote:
> On Thu, Nov 16, 2017 at 6:53 AM, Guido van Rossum
> wrote:
>
>> On Wed, Nov 15, 2017 at 6:50 PM, Guido van Rossum
>> wrote:
>>>
>>>
>>> Actually it linked to http://standards.iso.org/ittf
s that can be vulnerabilities but only
in some special situation. I think it's ok to call those vulnerabilities
too.
––Koos
PS. How come I haven't seen a proposal to remove the float type from
builtins yet?-)
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
t;
>> --
>> 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-d
On Wed, Nov 15, 2017 at 8:02 PM, Ethan Furman wrote:
> On 11/15/2017 04:55 AM, Koos Zevenhoven wrote:
>
>> On Tue, Nov 14, 2017 at 10:34 PM, Ivan Levkivskyi wrote:
>>
>
>
>> Rationale
>>> =
>>>
>>> [...] It would be convenient to
r
> each combination
>
>
Thanks, this might provide an answer to my question about multiple mro
entries here
https://mail.python.org/pipermail/python-ideas/2017-November/047897.html
––Koos
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
__
e
> # second one gets the same arguments as the first,
> # rather than an intermediate tuple with the first such
> # object already substituted out.
>
> -jJ
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> h
> .. [2] The reference implementation
>(https://github.com/ilevkivskyi/cpython/pull/3/files)
>
>
> Copyright
> =
>
> This document has been placed in the public domain.
>
>
>
> ..
>Local Variables:
> mode: indented-text
>indent-tabs-m
On Nov 12, 2017 19:10, "Guido van Rossum" wrote:
On Sun, Nov 12, 2017 at 4:14 AM, Koos Zevenhoven wrote:
> So actually my question is: What should happen when the annotation is
> already a string literal?
>
The PEP answers that clearly (under Implementation):
> If an an
that
those cases get ruthlessly converted into being equivalent to just
"ForwardReferencedThing".
So actually my question is: What should happen when the annotation is
already a string literal?
-- Koos
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
__
Oops, forgot to reply to the list.
On Nov 12, 2017 03:35, "Koos Zevenhoven" wrote:
On Nov 12, 2017 02:12, "Joao S. O. Bueno" wrote:
Ben, I have a small package which enables one to do:
with MapGetter(my_dictionary):
from my_dictionary import a, b, parameter3
I
d as strings, instead of something
> else.
>
>
Or a step further (longer), with annotations_as_strings.
––Koos
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mai
decide how the annotations are handled. See also this quote below:
(Quoted from the end of
https://mail.python.org/pipermail/python-ideas/2017-October/047311.html )
On Thu, Oct 12, 2017 at 3:59 PM, Koos Zevenhoven wrote:
>
> [*] Maybe somehow make the existing functionality a phantom e
list of slots be inferred from
> __annotations__ (Slot inference would conflict with setting class level
> default values, but that's a real conflict, as you'd be trying to use the
> same name on the class object for both the slot descriptor and the default
> value)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | nco
...
The easiest workaround at the moment is still pretty clumsy:
def import_SLLError():
from requests.exceptions import SLLError
return SLLError
...
except import_SLLError():
But what happens if that gives you an ImportError?
––Koos
--
+ Koos Zevenhoven + http://twitter.co
-150 ms, you
> can't do much in 0-50 ms.
>
>
Yes. OTOH, it can also happen that the *imports* are in fact what use the
network IO. At the office, I usually import from a network drive. For
instance, `import requests` takes a little less than a second, and `import
IPython` usually takes more than a second, with some variation.
––Koos
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
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
me is keeping things simple for Python
>> programmers. After that is ease-of-use for type authors. However, I
>> also want to put us in a good position in 3.7 to experiment
>> extensively with subinterpreters, so that's a big consideration.
>>
>> Consequently,
On Tue, Oct 3, 2017 at 1:11 AM, Koos Zevenhoven wrote:
> On Oct 3, 2017 01:00, "Guido van Rossum" wrote:
>
> Mon, Oct 2, 2017 at 2:52 PM, Koos Zevenhoven wrote
>
> I don't mind this (or Nathaniel ;-) being academic. The backwards
>> incompatibility issu
sarily
> exclusive to the solution I've proposed for Bytes.)
>
> -eric
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/
On Wed, Oct 4, 2017 at 4:04 PM, Nick Coghlan wrote:
> On 4 October 2017 at 22:45, Koos Zevenhoven wrote:
> > On Wed, Oct 4, 2017 at 3:33 PM, Nick Coghlan wrote:
> >> That's not a backwards compatibility problem, because the only way to
> >> encounter it is to
On Wed, Oct 4, 2017 at 3:33 PM, Nick Coghlan wrote:
> On 4 October 2017 at 20:22, Koos Zevenhoven wrote:
> > On Wed, Oct 4, 2017 at 8:07 AM, Nick Coghlan wrote:
> >>
> >> On 3 October 2017 at 03:13, Koos Zevenhoven wrote:
> >> > Well, it's not c
On Wed, Oct 4, 2017 at 8:07 AM, Nick Coghlan wrote:
> On 3 October 2017 at 03:13, Koos Zevenhoven wrote:
> > Well, it's not completely unrelated to that. The problem I'm talking
> about
> > is perhaps most easily seen from a simple context manager wrapper that
>
27;t* have is unimporting. What if I know that I'm only
going to need some particular module in this one initialization function.
Why should I keep it in memory for the whole lifetime of the program?
––Koos
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
On Oct 3, 2017 01:11, "Koos Zevenhoven" wrote:
On Oct 3, 2017 01:00, "Guido van Rossum" wrote:
Mon, Oct 2, 2017 at 2:52 PM, Koos Zevenhoven wrote
I don't mind this (or Nathaniel ;-) being academic. The backwards
> incompatibility issue I've just descr
On Oct 3, 2017 01:00, "Guido van Rossum" wrote:
Mon, Oct 2, 2017 at 2:52 PM, Koos Zevenhoven wrote
I don't mind this (or Nathaniel ;-) being academic. The backwards
> incompatibility issue I've just described applies to any extension via
> composition, if the unde
On Oct 3, 2017 00:02, "Guido van Rossum" wrote:
On Mon, Oct 2, 2017 at 10:13 AM, Koos Zevenhoven wrote:
> Hi all, It was suggested that I start a new thread, because the other
> thread drifted away from its original topic. So here, in case someone is
> interested:
>
Hi all, It was suggested that I start a new thread, because the other
thread drifted away from its original topic. So here, in case someone is
interested:
On Oct 2, 2017 17:03, "Koos Zevenhoven wrote:
On Mon, Oct 2, 2017 at 6:42 AM, Guido van Rossum wrote:
On Sun, Oct 1, 2017 at 1:52 PM,
On Mon, Oct 2, 2017 at 6:42 AM, Guido van Rossum wrote:
> On Sun, Oct 1, 2017 at 1:52 PM, Koos Zevenhoven wrote:
>
>> On Oct 1, 2017 19:26, "Guido van Rossum" wrote:
>>
>> Your PEP is currently incomplete. If you don't finish it, it is not even
>&
Koos
On Oct 1, 2017 9:13 AM, "Koos Zevenhoven" wrote:
> On Sep 29, 2017 18:21, "Guido van Rossum" wrote:
>
>
> PS. PEP 550 is still unaccepted, awaiting a new revision from Yury and
> Elvis.
>
>
> This is getting really off-topic, but I do have update
On Sep 29, 2017 18:21, "Guido van Rossum" wrote:
PS. PEP 550 is still unaccepted, awaiting a new revision from Yury and
Elvis.
This is getting really off-topic, but I do have updates to add to PEP 555
if there is interest in that. IMO, 555 is better and most likely faster
than 550, but on the
It would be helpful if at least the exception type could somehow be
preserved / restored / mimicked. Otherwise you need if-elif statements in
your try-excepts and other annoying stuff.
-- Koos
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
_
yet, but clearly noop() would
be duplication of functionality. So maybe the closest thing without
duplication would be to make "pass" an expression which evaluates to a
no-op function, but which the compiler could perhaps optimize away if it's
a statemen
ight
>> =
>>
>> This document has been placed in the public domain.
>>
>>
>> ..
>>Local Variables:
>>mode: indented-text
>>indent-tabs-mode: nil
>>sentence-end-double-space: t
>>fill-column: 70
>>cod
allow you to
> > > fully consider the gravity of the situation.
> >
> > Right, I needed to be reminded of how perilous the use of C globals is.
> > Perhaps I should contact the PSRT the next time I contemplate using a C
> > global.
>
> I
allow you to
> > > fully consider the gravity of the situation.
> >
> > Right, I needed to be reminded of how perilous the use of C globals is.
> > Perhaps I should contact the PSRT the next time I contemplate using a C
> > global.
>
> I
ment object returned by var.assign(1),
and as soon as foo() returns, there are no references to var, so everything
should get cleaned up nicely.
And regarding string keys, they have pros and cons, and they can be added
easily, so let's not go there now.
-- Koos
[*] (nit-picking) without closur
;hello"
def __dir__(self):
return ["hello"]
assuming it would be equivalent to setting __class__ afterwards.
--Koos
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
Python-Dev mailing list
Python-Dev@python.org
ht
pt the comparison to PEP 550 changes.
-- Koos
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/optio
On Wed, Sep 6, 2017 at 8:16 PM, Guido van Rossum wrote:
> On Wed, Sep 6, 2017 at 8:07 AM, Koos Zevenhoven wrote:
>
>> I think yield from should have the same semantics as iterating over the
>> generator with next/send, and PEP 555 has no issues with this.
>>
>
>
> why the same thing shouldn't apply to generators.
>
>
> It seems to me that it will be *more* confusing to give
> generators this magical ability to avoid with-statements.
>
>
>
Exactly. To state it clearly: PEP 555 does not have this issue.
––Koo
d radically between v1
> and v2 because of considerations around generator (not coroutine)
> semantics. I'm not sure what more it can do to dispel these feelings
> :-).
>
>
Just to mention that this is now closely related to the discussion on my
proposal on python-ideas. BTW
et
> about
> >> whether my approach has some fatal flaw compared to PEP 550 ;).
> >
> > We'll never know until you post it. Go ahead.
>
>
Anyway, thanks to these efforts, your proposal has become somewhat more
competitive compared to mine ;). I'll post mine as soon as
about it, partly because of
the PEP550-based workarounds that Nick, Nathaniel, Yury etc. have been
describing, and partly because that might be a major distraction from other
useful discussions, especially because I wasn't completely sure yet about
whether my approach has some fatal flaw compar
On Tue, Aug 22, 2017 at 12:44 AM, Yury Selivanov
wrote:
> On Mon, Aug 21, 2017 at 5:39 PM, Koos Zevenhoven
> wrote:
> [..]
> >> In the current version of the PEP, generators are initialized with an
> >> empty LogicalContext. When they are being iterated (star
On Tue, Aug 22, 2017 at 12:25 AM, Yury Selivanov
wrote:
> On Mon, Aug 21, 2017 at 5:14 PM, Koos Zevenhoven
> wrote:
> [..]
> >> This has consequences for the design in the PEP:
> >>
> >> * what we want to capture at generator creation time is the context
&
be dynamic
> * this means that "mutable context saved on the generator" and "entire
> dynamic context visible when the generator runs" aren't the same thing
>
> And hence the introduction of the LocalContext/LogicalContext
> terminology for the former, and the
On Jul 27, 2017 02:38, "MRAB" wrote:
On 2017-07-26 23:55, Koos Zevenhoven wrote:
>
> IMO,
>
> for item in sequence:
> # block
> nobreak: # or perhaps `if not break:`
> # block
>
> would be clearer (if the syntax is necessary at all).
>
Y
other "possibly in Python 5" changes, where there is no reason to expect
that the situation is somehow different years later.
-- Koos
>
> But not Python 4: Guido has already ruled that Python 4 will not include
> major backwards-incompatible changes. Going from 3 to 4 will not
On Fri, Jun 2, 2017 at 8:57 PM, Guido van Rossum wrote:
> On Fri, Jun 2, 2017 at 9:41 AM, Koos Zevenhoven wrote:
>>
>> I still don't understand what would happen with __annotations__. If
>> the decorator returns a non-function, one would expect the annotations
>&
I missed
something?
—Koos
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
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
e result is not a function could
be weird. I also don't see a mention of this only working in stubs.
I like Jukka's version, as it has a clear distinction between
functions and other attributes. But that might require a language
change to provide __annotations__ in a clean mann
On May 5, 2017 10:39 PM, "Chris Barker" wrote:
Sorry to come late to the game, It wasn't immediately clear to me what the
implications were of the "enhancement or bugfix" distinction...
On Thu, May 4, 2017 at 9:46 PM, Nick Coghlan wrote:
> That improved casting mechanism and the implicit suppo
On Thu, May 4, 2017 at 8:30 PM, Terry Reedy wrote:
> On 5/4/2017 10:43 AM, Koos Zevenhoven wrote:
>> On Thu, May 4, 2017 at 4:19 AM, Terry Reedy wrote:
>>> Enhancing public APIs in normal (non-provisional) modules in bugfix
>>> releases
>>> has turned out
On Thu, May 4, 2017 at 4:19 AM, Terry Reedy wrote:
> On 5/3/2017 7:13 PM, Koos Zevenhoven wrote:
>>
[...]
>> Shutil was among the most important to be updated, IMO.
>>
>> I had made some sort of list of affected modules elsewhere [1]:
>> ntpath, posixpath, os.sc
.unpack_archive
> need to be changed, with a note "Added in 3.6.2: filename can be any
> pathlike object"? If so, it is an enhancement.
Regardless of bugfix vs enhancement semantics, that seems like a good
thing to do.
-- Koos
[1] e.g. in this t
around for quite some time still.
-- Koos
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
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
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/k7hoven%40gmail.com
>
--
On Mon, Sep 5, 2016 at 6:06 AM, Nick Coghlan wrote:
> On 5 September 2016 at 06:42, Koos Zevenhoven wrote:
>> On Sun, Sep 4, 2016 at 6:38 PM, Nick Coghlan wrote:
>>>
>>> There are two self-consistent sets of names:
>>>
>>
>> Let me add a f
On Mon, Sep 5, 2016 at 3:30 AM, Random832 wrote:
> On Sun, Sep 4, 2016, at 16:42, Koos Zevenhoven wrote:
>> On Sun, Sep 4, 2016 at 6:38 PM, Nick Coghlan wrote:
>> >
>> > There are two self-consistent sets of names:
>> >
>>
>> Let me add a f
that the *variable* `x` has the type `Optional[int]`.
>> So what is the type of `x` in `return x`?
>> If it is `Optional[int]`, then a type checker is obliged to reject this
>> code. If it is `int` then what does "type of a variable" actually mean,
>> and why aren't
eryone agrees on. And
I hope you don't take this as a challenge -- I'm in the don't-panic
camp :).
-- Koos
> Cheers,
> Nick.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
--
+ Koos Zevenhoven + http://twitter.com/k7hoven +
_
ll be
posting my own remaining concerns regarding PEP 526 when I find the
time.
-- Koos
On Mon, Sep 5, 2016 at 4:46 PM, Nick Coghlan wrote:
> On 5 September 2016 at 21:46, Koos Zevenhoven wrote:
>> The thing I'm promoting here is to not add anything to PEP 526 that
>> says wh
It looks like you are trying to make sense of this, but unfortunately
there's some added mess and copy&paste-like errors regarding who said
what. I think no such errors remain in what I quote below:
On Mon, Sep 5, 2016 at 3:10 PM, Steven D'Aprano wrote:
>
> [Koos Zevenho
On Mon, Sep 5, 2016 at 1:04 PM, Nick Coghlan wrote:
> On 5 September 2016 at 18:19, Koos Zevenhoven wrote:
>> On Mon, Sep 5, 2016 at 5:21 AM, Nick Coghlan wrote:
>>> On 5 September 2016 at 04:40, Koos Zevenhoven wrote:
>>>> On Sun, Sep 4, 2016 at 9:13 PM, Ivan Lev
On Mon, Sep 5, 2016 at 5:21 AM, Nick Coghlan wrote:
> On 5 September 2016 at 04:40, Koos Zevenhoven wrote:
>> On Sun, Sep 4, 2016 at 9:13 PM, Ivan Levkivskyi wrote:
>>> On 4 September 2016 at 19:59, Nick Coghlan wrote:
>> [...]
>>>>
>>>> Sim
On Sun, Sep 4, 2016 at 6:38 PM, Nick Coghlan wrote:
>
> There are two self-consistent sets of names:
>
Let me add a few. I wonder if this is really used so much that
bytes.chr is too long to type (and you can do bchr = bytes.chr if you
want to):
bytes.chr (or bchr in builtins)
bytes.chr_at, byte
checker,
if the meaning may differ across checkers?
-- Koos
> --
> Ivan
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/
On Sun, Sep 4, 2016 at 7:43 PM, Nick Coghlan wrote:
> On 4 September 2016 at 21:32, Ivan Levkivskyi wrote:
>> The first form still could be interpreted by type checkers
>> as annotation for value (a cast to more precise type):
>>
>> variable = cast(annotation, value) # visually also looks similar
t all obvious that
everyone thinks that way. Hence, the "Semantics for type checking"
thread on python-ideas.
-- Koos
>
>
> --
> Steve
> _______
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.or
; Mark.
>
> ___
> 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/k7hoven%40gmail.com
--
+ Koos Zevenhoven
On Sun, Sep 4, 2016 at 12:51 PM, Nick Coghlan wrote:
> On 4 September 2016 at 08:11, Random832 wrote:
>> On Sat, Sep 3, 2016, at 18:06, Koos Zevenhoven wrote:
>>> I guess one reason I don't like bchr (nor chrb, really) is that they
>>> look just like a random sequ
On Sun, Sep 4, 2016 at 1:23 AM, Ivan Levkivskyi wrote:
> On 4 September 2016 at 00:11, Random832 wrote:
>>
>> On Sat, Sep 3, 2016, at 18:06, Koos Zevenhoven wrote:
>> > I guess one reason I don't like bchr (nor chrb, really) is that they
>> > look jus
s
py3bytes.chars[SOMETHING]
With the "c" memoryview there will be a distinction between slicing
and indexing.
And Random832 seems to be making some good points.
--- Koos
> --
> ~Ethan~
>
> ___
> Python-Dev mailing list
>
On Sat, Sep 3, 2016 at 7:59 PM, Nick Coghlan wrote:
> On 3 September 2016 at 03:54, Koos Zevenhoven wrote:
>> chrb seems to be more in line with some bytes versions in for instance os
>> than bchr.
>
> The mnemonic for the current name in the PEP is that bchr is to chr as
&g
ginal
> example, I would probably placate the typechecker. YMMV, of course.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mail
On Fri, Sep 2, 2016 at 9:04 PM, Steven D'Aprano wrote:
> On Fri, Sep 02, 2016 at 08:10:24PM +0300, Koos Zevenhoven wrote:
>
>> A good checker should be able to infer that x is a union type at the
>> point that it's passed to spam, even without the type annotation. Fo
` to accept ``'s'`` as a single-byte interpretation?
Or
> do we ignore memory for now and add it later?
>
>
> References
> ==
>
> .. [1] Initial March 2014 discussion thread on python-ideas
> (https://mail.python.org/pipermail/python-ideas/2014-March/027295.
e we need non-type-hinting
attribute declarations.
-- Koos
>
> The PEP overstates the existing use of static typing in Python
> ==
>
[...]
> Please don't turn Python into some sort of inferior Java.
> There is potent
On Thu, Sep 1, 2016 at 5:46 PM, Guido van Rossum wrote:
> On Thu, Sep 1, 2016 at 6:11 AM, Koos Zevenhoven wrote:
>> While a large amount of Python programmers may not be interested in
>> type hinting local variables inside functions, I can see other
>> potential benefits
out-for-now
>
>
> --
> --Guido van Rossum (python.org/~guido)
> _______
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/opt
On Wed, Jun 15, 2016 at 11:00 PM, Ethan Furman wrote:
> On 06/15/2016 12:24 PM, Koos Zevenhoven wrote:
>>
>> And the other question could be turned into whether to make str and
>> bytes also PathLike in __subclasshook__.
>
> No, for two reasons.
>
> - most str&
On Wed, Jun 15, 2016 at 10:15 PM, Brett Cannon wrote:
>
>
> On Wed, 15 Jun 2016 at 12:12 Koos Zevenhoven wrote:
>>
>> >> if isinstance(filename, os.PathLike):
>>
>> By the way, regarding the line of code above, is there a convention
>> regarding
>> if isinstance(filename, os.PathLike):
By the way, regarding the line of code above, is there a convention
regarding whether implementing some protocol/interface requires
registering with (or inheriting from) the appropriate ABC for it to
work in all situations. IOW, in this case, is it suff
1 - 100 of 153 matches
Mail list logo
