tds333 gmail.com 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
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
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
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
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
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 +
_
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
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 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
>&
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 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:
>
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 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
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 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
>
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 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
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 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
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,
-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
...
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
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
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
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
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
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 +
__
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
> .. [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
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
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 +
__
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
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
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 +
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
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
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
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
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-
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
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
; 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
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?
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
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
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
--
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
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.
>> Method or attri
On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote:
> On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote:
>>
>> I'm still thinking a little bit about 'pathname', which to me sounds
>> more like a string than fspath does [1].
>
>
> I like that a l
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 __pathstring__ in case it may be
On Fri, Apr 8, 2016 at 11:39 PM, R. David Murray wrote:
> On Fri, 08 Apr 2016 19:24:44 -, Brett Cannon wrote:
>> On Fri, 8 Apr 2016 at 12:10 Chris Angelico wrote:
>>
>> > On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker
>> > wrote:
>> > > On
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
>> > suggestion that this be a more gener
On Sat, Apr 9, 2016 at 12:53 AM, Brett Cannon wrote:
> On Fri, 8 Apr 2016 at 14:23 Koos Zevenhoven wrote:
>
> At this point no one wants to touch bytes paths. If you need that level of
> control because of multiple encodings within a single file system then you
> will probably hav
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'.'))
> --> huh
> [, , b'__MACOS
On Sat, Apr 9, 2016 at 10:48 AM, Nick Coghlan wrote:
> On 9 April 2016 at 04:25, Brett Cannon wrote:
>> On Fri, 8 Apr 2016 at 11:13 Ethan Furman wrote:
>>> On 04/08/2016 10:46 AM, Koos Zevenhoven wrote:
>>> > On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote:
&g
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 pathlib
>> currently has), or stdlib code will
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" API that rejected byte
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 abstraction -- good.
>
> then at t
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
> already polymorphic.
>
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
> unsubscribed from these lists, a
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 asking for data from th
On Thu, Apr 14, 2016 at 9:35 PM, Random832 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 instance
>> choose to deal wit
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 a pain.
>
> It *shou
On Sun, Apr 17, 2016 at 9:14 PM, Ethan Furman 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(...),
>> the conclusion is tha
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 fspath(pathlike) -> st
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 supporting bytes paths. So
a
On Wed, Apr 20, 2016 at 6:11 AM, Stephen J. Turnbull wrote:
> Koos Zevenhoven writes:
> > 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 a
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
> consumers using os.fs
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 eveŕyone wants or has to
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 more.
> We even had multip
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 this on python-ideas, I offered
to work on the P
**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 view on the topic, bu
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 have done
> already t
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 updated to accept path o
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 before, to me this seems like a lot of
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`` [#os-path]_
>> > will be updated to accept path o
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__() returned if the argu
On Thu, May 12, 2016 at 2:49 AM, Koos Zevenhoven wrote:
> 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
On Thu, May 12, 2016 at 2:53 AM, Koos Zevenhoven wrote:
> On Thu, May 12, 2016 at 2:49 AM, Koos Zevenhoven wrote:
>> 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.pa
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, resolving
> attributes, co
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 decision to represe
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
> fspath() defined as a wr
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 as a healthy nudge a
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 should trust our abili
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 an effort to gain greater
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 because
On Fri, May 13, 2016 at 12:24 PM, Sven R. Kunze 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 that part. I only found
been 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 fi
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;
>
> - there is no os func
On Fri, May 13, 2016 at 7:06 PM, Sven R. Kunze 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 premature optimization.
>
I suppose so
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 that seems
>> > like you are referring only to
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 wrote:
>>
>>
>> On May 13, 2016, at 11
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 still work (see also b
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 pathlib, you can easily write your own
>> sub
On Tue, May 24, 2016 at 4:56 PM, Barry Warsaw 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 of
>>use cases, altho
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
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 binary sequences
> Ve
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.
>
> Right. You want a method with the se
bytes)
>>
>> --> bool(h)
>> Traceback (most recent call last):
>> File "", line 1, in
>> TypeError: __bool__ should return bool, returned str
>>
>> Arguments in favor or against?
>>
>> --
>> ~Ethan~
>> ___
1 - 100 of 153 matches
Mail list logo
