Re: [Python-Dev] PEP 492: async/await in Python; version 4

tds333 at gmail.com tds333 at gmail.com writes: Hi, still watching progress here. Read all posts and changes. Everything improved and I know it is a lot of work. Thx for doing this. But I still think this PEP goes to far. [...] We forget to address the major problems here. How

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On Tue, Jun 7, 2016 at 11:28 PM, Ethan Furman wrote: > > Minor changes: updated version numbers, add punctuation. > > The current text seems to take into account Guido's last comments. > > Thoughts before asking for acceptance? > > PEP: 467 > Title: Minor API improvements for

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On Wed, Jun 8, 2016 at 12:57 AM, Barry Warsaw wrote: > On Jun 07, 2016, at 09:40 PM, Brett Cannon wrote: > >>On Tue, 7 Jun 2016 at 14:38 Paul Sokolovsky wrote: >>> What's wrong with b[i:i+1] ? >>It always succeeds while indexing can trigger an IndexError. > >

Re: [Python-Dev] proposed os.fspath() change

;): > 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 guarantees on os.fspath >

Re: [Python-Dev] proposed os.fspath() change

> Traceback (most recent call last): >> File "", line 1, in >> TypeError: __bool__ should return bool, returned str >> >> Arguments in favor or against? >> >> -- >> ~Ethan~ >> _

Re: [Python-Dev] proposed os.fspath() change

On Wed, Jun 15, 2016 at 10:15 PM, Brett Cannon <br...@python.org> wrote: > > > On Wed, 15 Jun 2016 at 12:12 Koos Zevenhoven <k7ho...@gmail.com> wrote: >> >> >> if isinstance(filename, os.PathLike): >> >> By the way, regarding the line of cod

Re: [Python-Dev] proposed os.fspath() change

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

Re: [Python-Dev] proposed os.fspath() change

On Wed, Jun 15, 2016 at 11:00 PM, Ethan Furman <et...@stoneleaf.us> 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 re

Re: [Python-Dev] pathlib - current status of discussions

On Tue, Apr 12, 2016 at 7:19 PM, Chris Barker wrote: > > One more though came up just now: there are different level sof abstractions > and representations for paths. We don't want to make Path a subclass of > string, because Path is supposed to be a higher level

Re: [Python-Dev] pathlib - current status of discussions

On Tue, Apr 12, 2016 at 11:56 AM, Nick Coghlan wrote: > One possible way to address this concern would be to have the > underlying protocol be bytes/str (since boundary code frequently needs > to handle the paths-are-bytes assumption in POSIX), but offer an > "os.fspathname"

Re: [Python-Dev] pathlib - current status of discussions

On Tue, Apr 12, 2016 at 6:52 PM, Stephen J. Turnbull wrote: > > (A) Why does anybody need bytes out of a pathlib.Path (or other > __fspath__-toting, higher-level API) *inside* the boundary? Note > that the APIs in os (etc) *don't need* bytes because they are >

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, Apr 11, 2016 at 9:27 AM, Nick Coghlan wrote: > On 11 April 2016 at 02:16, Ethan Furman wrote: >> >> I guess I don't see the point of this. Either DirEntry's [1] only get >> partial support (which is only marginally better than the no support

Re: [Python-Dev] Defining a path protocol

On Sat, Apr 9, 2016 at 12:53 AM, Brett Cannon <br...@python.org> wrote: > On Fri, 8 Apr 2016 at 14:23 Koos Zevenhoven <k7ho...@gmail.com> wrote: > > At this point no one wants to touch bytes paths. If you need that level of > control because of multiple encodings wit

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

Nick Coghlan wrote: > On 7 April 2016 at 03:26, Brett Cannon wrote: >> >> Name: __path__, __fspath__, or something else? > > __fspath__ > I think I might like this dunder name because it does not clutter the list of regular methods and attributes, and is perhaps more pythonic.

Re: [Python-Dev] Defining a path protocol

On Fri, Apr 8, 2016 at 8:34 PM, Brett Cannon wrote: > On Fri, 8 Apr 2016 at 09:39 Ethan Furman wrote: >> > I thought the whole point off all this is that not any old string can be >> > a path! (whereas any int can be an index). Unless we go with Chris A's >>

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

On Sat, Apr 9, 2016 at 10:16 AM, Ethan Furman wrote: > On 04/09/2016 12:07 AM, Victor Stinner wrote: >> >> os.DirEntry doesn't support bytes: os.scandir() only accept str. It's a >> deliberate choice. > > > 3.5.0 scandir supports bytes: > > --> huh = list(scandir(b'.')) > -->

Re: [Python-Dev] Pathlib enhancments - method name only

On Sat, Apr 9, 2016 at 10:48 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 9 April 2016 at 04:25, Brett Cannon <br...@python.org> wrote: >> On Fri, 8 Apr 2016 at 11:13 Ethan Furman <et...@stoneleaf.us> wrote: >>> On 04/08/2016 10:46 AM, Koos Zevenhoven wrote

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker <chris.bar...@noaa.gov> wrote: > On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven <k7ho...@gmail.com> wrote: >> >> I'm still thinking a little bit about 'pathname', which to me sounds >> more like a string than fspath

Re: [Python-Dev] Pathlib enhancments - method name only

On Fri, Apr 8, 2016 at 9:20 PM, Chris Barker wrote: > > we rejected plain old __path__ because this is already ued in another > context, but if we add "str" on the end, that's not longer an issue, so do > we need the "fs"? > > __pathstr__ # pathstring > Or perhaps

Re: [Python-Dev] Pathlib enhancments - method name only

, 2016 at 5:03 AM, Chris Barker <chris.bar...@noaa.gov> >> > wrote: >> > > On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven <k7ho...@gmail.com> >> > wrote: >> > >> >> > >> > >> > >> > __pathstr__ # pathstring &

Re: [Python-Dev] Removing the provisional label from pathlib

On Mon, May 23, 2016 at 10:38 PM, Chris Barker wrote: > On Mon, May 23, 2016 at 10:13 AM, Brett Cannon wrote: >> >> 3.5 is still getting bugfixes: >> https://docs.python.org/devguide/#status-of-python-branches >> >> As for backporting __fspath__() for

Re: [Python-Dev] Removing the provisional label from pathlib

On Tue, May 24, 2016 at 4:56 PM, Barry Warsaw <ba...@python.org> wrote: > On May 24, 2016, at 02:03 PM, Koos Zevenhoven wrote: > >>I guess we might consider adding __fspath__ in maintenance releases, >>and make open() support it? That would cover a significant share

Re: [Python-Dev] file system path protocol PEP

**another deep, calming breath** On Wed, May 11, 2016 at 7:43 PM, Brett Cannon wrote: > Open Issues > === > > Should os.fspath() return bytes? > > In most cases, it of course should not. The section (or the title) do not represent my

Re: [Python-Dev] file system path protocol PEP

On Thu, May 12, 2016 at 12:15 AM, Ethan Furman wrote: > On 05/11/2016 01:51 PM, Ethan Furman wrote: >> >> On 05/11/2016 01:44 PM, Serhiy Storchaka wrote: > > os.path ''' The various path-manipulation functions of ``os.path`` [#os-path]_ will be

Re: [Python-Dev] file system path protocol PEP

On Wed, May 11, 2016 at 11:04 PM, Brett Cannon wrote: > A quick comment about sending me fixes. While I do appreciate them, sending > them as a pull request is much easier for me as (a) I don't have to hunt the > changes down in the text, and (b) you will see the fixes others

Re: [Python-Dev] file system path protocol PEP

On Thu, May 12, 2016 at 12:28 AM, Nikolaus Rath wrote: > On May 11 2016, Brett Cannon wrote: >> This PEP proposes a protocol for classes which represent a file system >> path to be able to provide a ``str`` or ``bytes`` representation. > [...] > > As I said

Re: [Python-Dev] file system path protocol PEP

On Thu, May 12, 2016 at 3:04 PM, Nick Coghlan wrote: > > I'd still like to see this exposed to Python code as os._raw_fspath() > (with the leading underscore just meaning "this probably isn't the API > you want" rather than indicating a private or unstable API), and then >

Re: [Python-Dev] file system path protocol PEP

On Thu, May 12, 2016 at 4:20 PM, Nick Coghlan wrote: > > It's not unusual for me to encounter "POSIX oughtta be enough for > anyone" folks that are not yet entirely convinced that > bytes-are-not-text, so I'm actually in favour of making the default > Python-level API str-only

Re: [Python-Dev] file system path protocol PEP

On Thu, May 12, 2016 at 2:53 AM, Koos Zevenhoven <k7ho...@gmail.com> wrote: > On Thu, May 12, 2016 at 2:49 AM, Koos Zevenhoven <k7ho...@gmail.com> wrote: >> On Thu, May 12, 2016 at 2:05 AM, Ethan Furman <et...@stoneleaf.us> wrote: >>> On 05/11/2016 03:13 PM, Bre

Re: [Python-Dev] file system path protocol PEP

On Thu, May 12, 2016 at 2:05 AM, Ethan Furman wrote: > On 05/11/2016 03:13 PM, Brett Cannon wrote: > >> If [...] I would drop os.path changes and make os.fspath() do what > >> Ethan and Koos have suggested and simply pass through without checks >> >> whatever path.__fspath__()

Re: [Python-Dev] file system path protocol PEP

On Thu, May 12, 2016 at 1:13 AM, Brett Cannon wrote: > > > On Wed, 11 May 2016 at 13:45 Serhiy Storchaka wrote: >> >> On 11.05.16 19:43, Brett Cannon wrote: >> > os.path >> > ''' >> > >> > The various path-manipulation functions of ``os.path``

Re: [Python-Dev] file system path protocol PEP

On Thu, May 12, 2016 at 2:49 AM, Koos Zevenhoven <k7ho...@gmail.com> wrote: > On Thu, May 12, 2016 at 2:05 AM, Ethan Furman <et...@stoneleaf.us> wrote: >> On 05/11/2016 03:13 PM, Brett Cannon wrote: >> >>> If [...] I would drop os.path changes and make os.fs

Re: [Python-Dev] file system path protocol PEP

On Thu, May 12, 2016 at 7:24 PM, Guido van Rossum wrote: > I am glad this is finally happening. There's quite a bit of noise in the > thread which I have to ignore. The two issues that I want to respond to are > speed and whether os.fspath() can return bytes. > > - Speed: We

Re: [Python-Dev] file system path protocol PEP

On Thu, May 12, 2016 at 8:22 PM, Sjoerd Job Postmus wrote: > I would like to make just 1 comment regarding the question of accepting > (or not) bytes as output of `os.fspath`. > > The whole point of adding `os.fspath` is to make it easier to use Path > objects. This is in

Re: [Python-Dev] file system path protocol PEP

This has just been discussed very recently in this thread (and earlier too). It may make sense, but it's not among our current worries. Besides, we already added the new fspath semantics to the PEP. While I hope Brett is asleep in his time zone, I'm guessing he will agree (just saying this

Re: [Python-Dev] file system path protocol PEP

On Fri, May 13, 2016 at 12:24 PM, Sven R. Kunze <srku...@mail.de> wrote: > On 13.05.2016 10:36, Koos Zevenhoven wrote: >> >> This has just been discussed very recently in this thread (and earlier >> too). > > > Could you point me to that? It seems I missed tha

Re: [Python-Dev] File system path PEP, part 2

defending the PEP regardless). Anyway, especially now that my main worry regarding the open questions has been resolved, I would be more than happy to have my name on it. So Brett, could you add me as author? (Koos Zevenhoven and k7ho...@gmail.com will be fine) It looks like this is finally

Re: [Python-Dev] File system path PEP, part 2

On Fri, May 13, 2016 at 2:00 PM, Steven D'Aprano wrote: > Counter suggestion: > > - __fspath__() method may return either bytes or str (no change > from the PEP as it stands now); > > - but os.fspath() will only return str; > > - and os.fspathb() will only return bytes; > >

Re: [Python-Dev] file system path protocol PEP

On Fri, May 13, 2016 at 7:06 PM, Sven R. Kunze <srku...@mail.de> wrote: > On 13.05.2016 11:48, Koos Zevenhoven wrote: >> >> This issue is coupled with the future optimization questions. >> > > AFAIC coupling API design to optimization is called premat

Re: [Python-Dev] File system path PEP, 3rd draft

FYI, I recently sent a couple of emails in my earlier type hinting thread on -ideas. What I wrote now is about the path ABC regarding type hints. -- Koos On Sat, May 14, 2016 at 12:48 AM, Brett Cannon wrote: > > > On Fri, 13 May 2016 at 14:30 Philip Jenvey

Re: [Python-Dev] file system path protocol PEP

On Thu, May 12, 2016 at 11:31 AM, Sven R. Kunze wrote: > On 11.05.2016 18:43, Brett Cannon wrote: >> >> Rationale >> = >> >> Historically in Python, file system paths have been represented as >> strings or bytes. This choice of representation has stemmed from C's >> own

Re: [Python-Dev] file system path protocol PEP

On Thu, May 12, 2016 at 11:14 AM, Serhiy Storchaka wrote: > > This is cheap in C, but os.path functions are implemented in Python. They > have to make at least one function call (os.fspath(), hasattr() or > isinstance()), not counting a bytecode for retrieving arguments,

Re: [Python-Dev] File system path PEP, part 2

On Fri, May 13, 2016 at 8:52 PM, Steven D'Aprano wrote: > On Fri, May 13, 2016 at 03:43:29PM +, Brett Cannon wrote: >> On Fri, 13 May 2016 at 04:00 Steven D'Aprano wrote: > > [...] >> > I think it is a bit confusing to refer to "path objects", as

Re: [Python-Dev] file system path protocol PEP

On Fri, May 13, 2016 at 7:43 PM, Chris Angelico wrote: [...] > "Check" accepts subclasses; "CheckExact" doesn't (it's like "type(x) > is str"). The question is, which one SHOULD be being done? Indeed it should do "Check", so that path libraries that do inherit from str will

Re: [Python-Dev] pathlib - current status of discussions

On Thu, Apr 14, 2016 at 9:35 PM, Random832 <random...@fastmail.com> wrote: > On Thu, Apr 14, 2016, at 13:56, Koos Zevenhoven wrote: >> (1) Code that has access to pathname/filename data and has some level >> of control over what data type comes in. This code may for insta

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Tue, Apr 19, 2016 at 2:55 PM, Stephen J. Turnbull wrote: > > AFAICS bytes return from __fspath__ is just YAGNI. Show me something > that actually wants it. It might be, but as long as bytes paths are supported polymorphicly all over the stdlib, we won't get rid of

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Sun, Apr 17, 2016 at 11:03 AM, Stephen J. Turnbull wrote: > Nick Coghlan writes: > > > str and bytes aren't going to implement __fspath__ (since they're > > only *sometimes* path objects), so asking people to call the > > protocol method directly for any purpose would be

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Sun, Apr 17, 2016 at 9:14 PM, Ethan Furman <et...@stoneleaf.us> wrote: > On 04/17/2016 06:58 AM, Koos Zevenhoven wrote: > >> So, as a summary: With a str+bytes-polymorphic __fspath__, with the >> above argumentation and the rough implementation of os.fspath

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, Apr 20, 2016 at 6:11 AM, Stephen J. Turnbull <step...@xemacs.org> wrote: > Koos Zevenhoven writes: > > On Tue, Apr 19, 2016 at 2:55 PM, Stephen J. Turnbull <step...@xemacs.org> > wrote: > > > > > > AFAICS bytes return from __

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, Apr 20, 2016 at 6:16 AM, Stephen J. Turnbull wrote: > > (1) some really attractive producer of pathlib.Paths will be > published, and > Yes, pathlib is str-only, so this sounds just right. > (2) people will want to plug that producer into their bytes paths >

Re: [Python-Dev] Discussion on fspath: please wait for a PEP

On Wed, Apr 20, 2016 at 2:52 PM, Victor Stinner wrote: > Hi, > > I'm unable to count the number of threads about the fspath protocol. > It's even more difficult to count the total number of emails. IMHO > everyone had enough time to give him/her opinion. Couldn't agree

Re: [Python-Dev] Pathlib enhancements - improve fsdecode and fsencode

On Thu, Apr 14, 2016 at 9:55 AM, Stephen J. Turnbull wrote: > Please please please, junk both "filter out bytes" proposals. If you were referring to some of the fspath versions, I think we will need a bytes-rejecting version, for reasons explained in [1-2]. Of course not

Re: [Python-Dev] Discussion on fspath: please wait for a PEP

On Wed, Apr 20, 2016 at 7:34 PM, Victor Stinner wrote: > > 2016-04-20 18:12 GMT+02:00 Brett Cannon : >> >> I thought Chris and I w/ Ethan helping with coding, but if it's just me for >> the PEP then that's fine; Well, just in case you didn't notice

Re: [Python-Dev] List posting custom [was: current status of discussions]

On Wed, Apr 13, 2016 at 5:56 AM, Stephen J. Turnbull wrote: > The following is my opinion, as will become obvious, but it's based on > over a decade of observing these lists, and other open source > development lists. In a context where some core developers have >

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, Apr 18, 2016 at 5:03 PM, Ethan Furman wrote: > On 04/18/2016 12:41 AM, Nick Coghlan wrote: > >> Given the variant you [Koos] suggested, what if we defined the API >> semantics >> like this: >> >> # Offer the simplest possible API as the public vesion >> def

Re: [Python-Dev] pathlib - current status of discussions

On Thu, Apr 14, 2016 at 7:46 PM, Ethan Furman wrote: > > What many folks seem to be missing is that *you* (generic you) have control > of your data. > > If you are not working at the bytes layer, you shouldn't be getting bytes > objects because: > > - you specified str when

Re: [Python-Dev] Please reject or postpone PEP 526

yping in Python > == > [...] > Please don't turn Python into some sort of inferior Java. > There is potential in this PEP, but in its current form I think it should be > rejected. > > Cheers, > Mark. > > > _

Re: [Python-Dev] PEP 467: last round (?)

hread on python-ideas > (https://mail.python.org/pipermail/python-ideas/2014-March/027295.html) > .. [2] Guido's initial feedback in that thread > (https://mail.python.org/pipermail/python-ideas/2014-March/027376.html) > .. [3] Issue proposing moving zero-initialised sequences to a dedicated A

[Python-Dev] What should a good type checker do? (was: Please reject or postpone PEP 526)

On Fri, Sep 2, 2016 at 9:04 PM, Steven D'Aprano <st...@pearwood.info> 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 wit

Re: [Python-Dev] Please reject or postpone PEP 526

On Mon, Sep 5, 2016 at 1:04 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 5 September 2016 at 18:19, Koos Zevenhoven <k7ho...@gmail.com> wrote: >> On Mon, Sep 5, 2016 at 5:21 AM, Nick Coghlan <ncogh...@gmail.com> wrote: >>> On 5 September 2016 at 04:40

Re: [Python-Dev] What should a good type checker do? (was: Please reject or postpone PEP 526)

rsion to float). But in the original > 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:

Re: [Python-Dev] PEP 467: last round (?)

On Sun, Sep 4, 2016 at 1:23 AM, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > On 4 September 2016 at 00:11, Random832 <random...@fastmail.com> wrote: >> >> On Sat, Sep 3, 2016, at 18:06, Koos Zevenhoven wrote: >> > I guess one reason I don't like bchr (nor

Re: [Python-Dev] PEP 467: last round (?)

On Sat, Sep 3, 2016 at 7:59 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 3 September 2016 at 03:54, Koos Zevenhoven <k7ho...@gmail.com> wrote: >> chrb seems to be more in line with some bytes versions in for instance os >> than bchr. > > The mnemoni

Re: [Python-Dev] PEP 467: last round (?)

SOMETHING] becomes 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

Re: [Python-Dev] Please reject or postpone PEP 526

o list them all in a way that everyone 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/k7ho

Re: [Python-Dev] Please reject or postpone PEP 526

It looks like you are trying to make sense of this, but unfortunately there's some added mess and copy 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 <st...@pearwood.info> wrote: > > [Koos Zevenhove

Re: [Python-Dev] Please reject or postpone PEP 526

remaining concerns regarding PEP 526 when I find the time. -- Koos On Mon, Sep 5, 2016 at 4:46 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 5 September 2016 at 21:46, Koos Zevenhoven <k7ho...@gmail.com> wrote: >> The thing I'm promoting here is to not add anything to

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

ype `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 the other uses of `x` int as we

Re: [Python-Dev] Please reject or postpone PEP 526

On Mon, Sep 5, 2016 at 5:21 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 5 September 2016 at 04:40, Koos Zevenhoven <k7ho...@gmail.com> wrote: >> On Sun, Sep 4, 2016 at 9:13 PM, Ivan Levkivskyi <levkivs...@gmail.com> wrote: >>> On 4 September 2016 at 19:

Re: [Python-Dev] PEP 467: last round (?)

On Mon, Sep 5, 2016 at 3:30 AM, Random832 <random...@fastmail.com> wrote: > On Sun, Sep 4, 2016, at 16:42, Koos Zevenhoven wrote: >> On Sun, Sep 4, 2016 at 6:38 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> > >> > There are two self-consistent sets of names

Re: [Python-Dev] PEP 467: last round (?)

On Mon, Sep 5, 2016 at 6:06 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 5 September 2016 at 06:42, Koos Zevenhoven <k7ho...@gmail.com> wrote: >> On Sun, Sep 4, 2016 at 6:38 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >>> >>> There are two self-c

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

___ > 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 + http://twitter.com/k7hoven + _

Re: [Python-Dev] Please reject or postpone PEP 526

written* for type checking to work. It's not at 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.org/mailman/li

Re: [Python-Dev] Please reject or postpone PEP 526

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 =

Re: [Python-Dev] PEP 467: last round (?)

On Sun, Sep 4, 2016 at 12:51 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 4 September 2016 at 08:11, Random832 <random...@fastmail.com> wrote: >> On Sat, Sep 3, 2016, at 18:06, Koos Zevenhoven wrote: >>> I guess one reason I don't like bchr (nor chrb, really) i

Re: [Python-Dev] Please reject or postpone PEP 526

by 'annotation'. -- Koos > > Cheers, > 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-de

Re: [Python-Dev] PEP 467: last round (?)

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

Re: [Python-Dev] Please reject or postpone PEP 526

t within one 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

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On Thu, Sep 1, 2016 at 5:46 PM, Guido van Rossum <gu...@python.org> wrote: > On Thu, Sep 1, 2016 at 6:11 AM, Koos Zevenhoven <k7ho...@gmail.com> wrote: >> While a large amount of Python programmers may not be interested in >> type hinting local variables inside

Re: [Python-Dev] API design: where to add async variants of existing stdlib APIs?

tralia > > ___ > 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 + htt

Re: [Python-Dev] for...else

y to many 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-i

Re: [Python-Dev] for...else

On Jul 27, 2017 02:38, "MRAB" <pyt...@mrabarnett.plus.com> 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

Re: [Python-Dev] Is adding support for os.PathLike an enhancement or bugfix?

rchive > 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 thread somewhere: ht

Re: [Python-Dev] PEP 484 update proposal: annotating decorated declarations

ion 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 manner? Maybe that language change would be use

Re: [Python-Dev] PEP 484 update proposal: annotating decorated declarations

. Or have 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-

Re: [Python-Dev] PEP 484 update proposal: annotating decorated declarations

On Fri, Jun 2, 2017 at 8:57 PM, Guido van Rossum <gu...@python.org> wrote: > On Fri, Jun 2, 2017 at 9:41 AM, Koos Zevenhoven <k7ho...@gmail.com> wrote: >> >> I still don't understand what would happen with __annotations__. If >> the decorator returns

Re: [Python-Dev] Is adding support for os.PathLike an enhancement or bugfix?

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

Re: [Python-Dev] Is adding support for os.PathLike an enhancement or bugfix?

On Thu, May 4, 2017 at 8:30 PM, Terry Reedy <tjre...@udel.edu> wrote: > On 5/4/2017 10:43 AM, Koos Zevenhoven wrote: >> On Thu, May 4, 2017 at 4:19 AM, Terry Reedy <tjre...@udel.edu> wrote: >>> Enhancing public APIs in normal (non-provisional) modules in bugfix &

Re: [Python-Dev] Is adding support for os.PathLike an enhancement or bugfix?

On Thu, May 4, 2017 at 4:19 AM, Terry Reedy <tjre...@udel.edu> 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]: >> n

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

us in a good position in 3.7 to experiment >> extensively with subinterpreters, so that's a big consideration. >> >> Consequently, for PEP 554 my goal is to find a solution for object >> sharing that keeps things simple in Python while laying a basic >> foundation we can

Re: [Python-Dev] Investigating time for `import requests`

ile you can do a lot in python in 100-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,

Re: [Python-Dev] Investigating time for `import requests`

ts.exceptions.SLLError: ... 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

Re: [Python-Dev] Inheritance vs composition in backcompat (PEP521)

On Oct 3, 2017 01:11, "Koos Zevenhoven" <k7ho...@gmail.com> wrote: On Oct 3, 2017 01:00, "Guido van Rossum" <gu...@python.org> wrote: Mon, Oct 2, 2017 at 2:52 PM, Koos Zevenhoven <k7ho...@gmail.com> wrote I don't mind this (or Nathaniel ;-) being academic.

Re: [Python-Dev] Inheritance vs composition in backcompat (PEP521)

On Oct 3, 2017 01:00, "Guido van Rossum" <gu...@python.org> wrote: Mon, Oct 2, 2017 at 2:52 PM, Koos Zevenhoven <k7ho...@gmail.com> wrote I don't mind this (or Nathaniel ;-) being academic. The backwards > incompatibility issue I've just described applies to any ex

Re: [Python-Dev] Inheritance vs composition in backcompat (PEP521)

On Oct 3, 2017 00:02, "Guido van Rossum" <gu...@python.org> wrote: On Mon, Oct 2, 2017 at 10:13 AM, Koos Zevenhoven <k7ho...@gmail.com> wrote: > Hi all, It was suggested that I start a new thread, because the other > thread drifted away from its original top

Re: [Python-Dev] Inheritance vs composition in backcompat (PEP521)

On Wed, Oct 4, 2017 at 3:33 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 4 October 2017 at 20:22, Koos Zevenhoven <k7ho...@gmail.com> wrote: > > On Wed, Oct 4, 2017 at 8:07 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > >> > >> On 3 October 2017

Re: [Python-Dev] Inheritance vs composition in backcompat (PEP521)

On Wed, Oct 4, 2017 at 4:04 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 4 October 2017 at 22:45, Koos Zevenhoven <k7ho...@gmail.com> wrote: > > On Wed, Oct 4, 2017 at 3:33 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > >> That's not a backwards compati

Re: [Python-Dev] Inheritance vs composition in backcompat (PEP521)

On Wed, Oct 4, 2017 at 8:07 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 3 October 2017 at 03:13, Koos Zevenhoven <k7ho...@gmail.com> wrote: > > Well, it's not completely unrelated to that. The problem I'm talking > about > > is perhaps most easily seen from a

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

t; original interpreter. (I don't think this problem is necessarily > exclusive to the solution I've proposed for Bytes.) > > -eric > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/py

Re: [Python-Dev] What is the design purpose of metaclasses vs code generating decorators? (was Re: PEP 557: Data Classes)

(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 | ncogh...@

  1   2   >