, "write"):
> self._fp = filename
> self._mode = mode_code
> else:
> raise TypeError(
> "filename must be a path-like or file-like object"
> )
>
> I *don't* think it makes sense to weaken the gua
>> 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
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
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&
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 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
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
` 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.
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
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 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
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 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
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
; 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
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
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
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 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
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 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
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
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
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 +
_
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
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
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
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
>
--
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
.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
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
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 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
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
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
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
>&
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 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
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 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
&
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
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
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
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
> 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
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.
>>
>
>
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
;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
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
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
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 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
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
101 - 153 of 153 matches
Mail list logo
