Re: [Python-Dev] PEP 509: Add a private version to dict (version 3)

[Victor Stinner]

Hi,

Guido van Rossum and Jim J. Jewett suggested me to *not require* to
always increase the dict version if a dict method does not modify its
content. I modified the Changes section to only require that the
version is increased when the dictionary content is modified.

I also explained the nice side effect of having an unique identifier
for two empty dictionaries: it avoids a strong reference when checking
if a namespace (dictionary) was replaced. Yury Selivanov's opcode
cache uses this property to avoid a strong refence on builtin and
global namespaces. It's also a written reply to Armin Rigo's
suggestion to use the version 0 for empty dictionaries (new empty dict
or for dict.clear()).

The modified Changes section:

Changes
===

Add a ``ma_version_tag`` field to the ``PyDictObject`` structure with
the C type ``PY_UINT64_T``, 64-bit unsigned integer. Add also a global
dictionary version.

Each time a dictionary is created, the global version is incremented and
the dictionary version is initialized to the global version.

Each time the dictionary content is modified, the global version must be
incremented and copied to the dictionary version. Dictionary methods
which can modify its content:

* ``clear()``
* ``pop(key)``
* ``popitem()``
* ``setdefault(key, value)``
* ``__delitem__(key)``
* ``__setitem__(key, value)``
* ``update(...)``

The choice of increasing or not the version when a dictionary method
does not change its content is left to the Python implementation. A
Python implementation can decide to not increase the version to avoid
dictionary lookups in guards. Examples of cases when dictionary methods
don't modify its content:

* ``clear()`` if the dict is already empty
* ``pop(key)`` if the key does not exist
* ``popitem()`` if the dict is empty
* ``setdefault(key, value)`` if the key already exists
* ``__delitem__(key)`` if the key does not exist
* ``__setitem__(key, value)`` if the new value is identical to the
  current value
* ``update()`` if called without argument or if new values are identical
  to current values

Setting a key to a new value equals to the old value is also considered
as an operation modifying the dictionary content.

Two different empty dictionaries must have a different version to be
able to identify a dictionary just by its version. It allows to verify
in a guard that a namespace was not replaced without storing a strong
reference to the dictionary. Using a borrowed reference does not work:
if the old dictionary is destroyed, it is possible that a new dictionary
is allocated at the same memory address. By the way, dictionaries don't
support weak references.

The version increase must be atomic. In CPython, the Global Interpreter
Lock (GIL) already protects ``dict`` methods to make changes atomic.

Example using an hypothetical ``dict_get_version(dict)`` function::

>>> d = {}
>>> dict_get_version(d)
100
>>> d['key'] = 'value'
>>> dict_get_version(d)
101
>>> d['key'] = 'new value'
>>> dict_get_version(d)
102
>>> del d['key']
>>> dict_get_version(d)
103

The field is called ``ma_version_tag``, rather than ``ma_version``, to
suggest to compare it using ``version_tag == old_version_tag``, rather
than ``version <= old_version`` which becomes wrong after an integer
overflow.

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

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

[Brett Cannon]

On Wed, 20 Apr 2016 at 10:51 Koos Zevenhoven  wrote:

> 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 PEP in case there turns out to be one. This was when
> Guido had asked if there is going to be a PEP, in response to my "Type
> hinting for path-related functions" email. That offer is certainly
> still valid.
>

I'm going to host the draft PEP at
https://github.com/brettcannon/path-pep/blob/master/pep-0NNN.rst . Let me
get a basic first draft done so there is something to work off of and if
you still want to be co-author I'll be more than happy to add you as a
co-author to help me finish it!

-Brett


>
> >> luckily my firefighter gear is well-worn:
> >> https://goo.gl/photos/R8oWdLE45d99ebaw8
> >
> > LOL, it seems appropriate for this topic...
>
> It sure has been flammable XD
>
> >> I'll try to get a PEP draft written and posted prior to PyCon US. I will
> >> reply to any dangling comments/issues that have appeared overnight to
> close
> >> those threads, but otherwise I will start ignoring all discussions so I
> can
> >> focus on the PEP. Everyone can now consider themselves spared from any
> >> further path-related discussions. :)
>
> Yes, going from endless discussion to PEP seems like a very healthy
> direction at this point.
>
> > I hesitated to propose to create a fspath-sig mailing list, but I suck
> > at humor and so I skipped this joke in my email ;-)
>
> You did not have to tell that joke, the joke was present all the time ;).
>
> > Victor
> > ___
> > 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
>
___
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

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

[Koos Zevenhoven]

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 PEP in case there turns out to be one. This was when
Guido had asked if there is going to be a PEP, in response to my "Type
hinting for path-related functions" email. That offer is certainly
still valid.

>> luckily my firefighter gear is well-worn:
>> https://goo.gl/photos/R8oWdLE45d99ebaw8
>
> LOL, it seems appropriate for this topic...

It sure has been flammable XD

>> I'll try to get a PEP draft written and posted prior to PyCon US. I will
>> reply to any dangling comments/issues that have appeared overnight to close
>> those threads, but otherwise I will start ignoring all discussions so I can
>> focus on the PEP. Everyone can now consider themselves spared from any
>> further path-related discussions. :)

Yes, going from endless discussion to PEP seems like a very healthy
direction at this point.

> I hesitated to propose to create a fspath-sig mailing list, but I suck
> at humor and so I skipped this joke in my email ;-)

You did not have to tell that joke, the joke was present all the time ;).

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

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

[Victor Stinner]

Hi,

2016-04-20 18:12 GMT+02:00 Brett Cannon :
>> >> Can you please wait for a PEP? Brett Canon and Ethan Furman are
>> >> working on a PEP.
>
> I was actually going to send this email when I got in to work today, but
> Victor and timezones beat me to it. :)

Ha ha, bitten by the french connection!

> I thought Chris and I w/ Ethan helping with coding, but if it's just me for
> the PEP then that's fine; luckily my firefighter gear is well-worn:
> https://goo.gl/photos/R8oWdLE45d99ebaw8

LOL, it seems appropriate for this topic...

> I'll try to get a PEP draft written and posted prior to PyCon US. I will
> reply to any dangling comments/issues that have appeared overnight to close
> those threads, but otherwise I will start ignoring all discussions so I can
> focus on the PEP. Everyone can now consider themselves spared from any
> further path-related discussions. :)

I hesitated to propose to create a fspath-sig mailing list, but I suck
at humor and so I skipped this joke in my email ;-)

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

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

[Brett Cannon]

On Wed, 20 Apr 2016 at 07:07 Chris Angelico  wrote:

> On Wed, Apr 20, 2016 at 11:58 PM, Ethan Furman  wrote:
> > On 04/20/2016 04:52 AM, Victor Stinner wrote:
> >
> >> Can you please wait for a PEP? Brett Canon and Ethan Furman are
> >> working on a PEP.
>

I was actually going to send this email when I got in to work today, but
Victor and timezones beat me to it. :)


> >
> >
> > Actually, Brett Canon and Chris Angelico.
>
> I thought just Brett; my half of the proposal (the generic
> "string-like" protocol) was withdrawn as being too broad in scope for
> the justifying use-cases.
>
> Brett, your turn. :)
>

I thought Chris and I w/ Ethan helping with coding, but if it's just me for
the PEP then that's fine; luckily my firefighter gear is well-worn:
https://goo.gl/photos/R8oWdLE45d99ebaw8

I'll try to get a PEP draft written and posted prior to PyCon US. I will
reply to any dangling comments/issues that have appeared overnight to close
those threads, but otherwise I will start ignoring all discussions so I can
focus on the PEP. Everyone can now consider themselves spared from any
further path-related discussions. :)
___
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

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

[Ethan Furman]

On 04/20/2016 04:52 AM, Victor Stinner wrote:


FYI there is already an article about fspath/pathlib on LWN. Here is a
free link until the article is freely accessible:

"Python looks at paths" By Jake Edge (April 13, 2016)
https://lwn.net/SubscriberLink/683350/4f52334af09653c8/


Nice article, thanks for sharing!

--
~Ethan~

___
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

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

[Koos Zevenhoven]

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 multiple
> summaries :-)

I'm not quite as sure about this. Maybe the meaning of "summary" in
the subculture of python lists is different from the one I know.

> Can you please wait for a PEP? Brett Canon and Ethan Furman are
> working on a PEP. So please give them time to write it.

I wonder what happened there...

> The PEP should summarize the discussion and help a lot to make
> concrete progress on the design (avoid restarting to discuss the same
> points forever). I don't expect that more emails would add anything at
> the current state of the discussion.

Again, agreed, and this part makes me feel relieved. Personally, I got
tired of the discussion a long time ago, but felt it had to be
finished.

> I think that we have enough other topics to discuss in the meanwhile ;-)

No doubt about that.

> FYI there is already an article about fspath/pathlib on LWN. Here is a
> free link until the article is freely accessible:
>
> "Python looks at paths" By Jake Edge (April 13, 2016)
> https://lwn.net/SubscriberLink/683350/4f52334af09653c8/

Wow. Wasn't expecting that. A whole story about the notorious "path
discussions"! (well, up to some date). Anyway, the beginning seems
fairly accurate, but then, among other things, it fails to mention
this for example:

https://mail.python.org/pipermail/python-ideas/2016-March/039179.html
https://mail.python.org/pipermail/python-ideas/2016-April/039595.html

Since I did not get any responses to that suggestion, it felt like a
dead end, and I continued experimenting with other things and ended up
taking the approach of "subclassing path-types from str gives more
complete pathlib support, but the objects should not pretend to be
strings in every way". By the way, I even implemented this, which I
suppose I failed to mention. Admittedly, it became a little awkward in
the end, but the main point was to provide a smooth transition from a
str world to a PurePath-subclass world (as opposed to a discrete one
like Py3k).

While I was working on that, the discussions on -dev seemed to have
reopened the gate at exactly that 'dead end' I mentioned before, and
had started to step through it.

-Koos

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

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

[Chris Angelico]

On Wed, Apr 20, 2016 at 11:58 PM, Ethan Furman  wrote:
> On 04/20/2016 04:52 AM, Victor Stinner wrote:
>
>> Can you please wait for a PEP? Brett Canon and Ethan Furman are
>> working on a PEP.
>
>
> Actually, Brett Canon and Chris Angelico.

I thought just Brett; my half of the proposal (the generic
"string-like" protocol) was withdrawn as being too broad in scope for
the justifying use-cases.

Brett, your turn. :)

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

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

[Ethan Furman]

On 04/20/2016 04:52 AM, Victor Stinner wrote:


Can you please wait for a PEP? Brett Canon and Ethan Furman are
working on a PEP.


Actually, Brett Canon and Chris Angelico.

> So please give them time to write it.

Okay, I'll shut-up now.  ;)

--
~Ethan~
___
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

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

[Koos Zevenhoven]

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 use it.

> Since they involve an exception, they impose an unnecessary "try" on
> all text applications that fear death on bytes returns.  May as well
> just wrap all objects with __fspath__ in fsdecode, and all is
> happy.
>
> Counterproposal: make fsdecode and fsencode grok __fspath__.  Then:

Not being a native English speaker, I'm relying on a Wikipedia
explanation of "grok", but if you mean that fsdecode and fsencode
would accept objects that implement __fspath__, then I think we all
agree on this. Making the stdlib accept path objects, after all, is
the whole point of the pathlib discussions :).

Anyway, I am happy that Nick [3] (and you [4] ?) pointed out that
os.fsencode and os.fsdecode currently implement coercion, i.e., they
both accept both str and bytes, and return just one of them. This was
important for my conclusion in [1]. When these two functions are made
__fspath__ compatible using `fspath(patharg, output_types = (str,
bytes))`, like most os functions, they will indeed implement coercion
to bytes or str from "any pathlike object".

[Side note: One may, for instance, ask why os.fsdecode passes str
objects through silently, even if they can't be decoded. Well, that's
the way it is, and I'm not expecting that to change. But maybe
fsdecode should have an additional keyword-only argument to tell them
that it should strictly return something it actually did decode. (And
similarly for os.fsencode.) But this has nothing to do with the path
protocol we are discussing.]

> (1) Bytes-lovers and str-addicts are both safe.

I don't think everyone is safe if you cant say "I don't want implicit
encoding/decoding".

> (2) They can omit fspath, too!

I think having *one* additonal function for the
non-encoding/non-decoding cases is too much, and as shown in [1], one
is enough.

> No, that doesn't work if the bytes objects aren't in the file system
> encoding, but these are *bytes*, mon ami: you have no way to find out
> what that encoding is, so you either know already and you substitute
> that + fspath for fsdecode, or you're hosed.  And in the only concrete
> use case so far, fsdecode Just Works.

Well, as you say yourself, fsdecode indeed works if your bytes are in
the default fs encoding, and when you know they are, go for it, use
fsdecode. But I, for instance, rarely have my paths as bytes.
Therefore, I would be happy to get an exception if I'm accidentally
passing bytes to some non-bytes-supporting function because I've
forgotten to decode some input that I got in an encoding other than
the file system encoding.

> I suppose a similar argument holds for applications that want bytes
> and fsencode, but I leave that as an exercise for the reader.

A similar counterargument holds, too :).

Unrelated to this particular post, I believe these discussions are
almost done and I truly hope we at least won't have to keep addressing
the same questions that we have already gone through, unless there is
something new on the table.

I hope it takes a shorter time to read these emails than it takes to
write them :).

-Koos

[1] https://mail.python.org/pipermail/python-dev/2016-April/144239.html
[2] https://mail.python.org/pipermail/python-dev/2016-April/144290.html

And somewhat older ones:

[3] https://mail.python.org/pipermail/python-dev/2016-April/144101.html
[4] https://mail.python.org/pipermail/python-dev/2016-April/144107.html
___
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

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

[Victor Stinner]

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. We even had multiple
summaries :-)

Can you please wait for a PEP? Brett Canon and Ethan Furman are
working on a PEP. So please give them time to write it.

The PEP should summarize the discussion and help a lot to make
concrete progress on the design (avoid restarting to discuss the same
points forever). I don't expect that more emails would add anything at
the current state of the discussion.

I think that we have enough other topics to discuss in the meanwhile ;-)

FYI there is already an article about fspath/pathlib on LWN. Here is a
free link until the article is freely accessible:

"Python looks at paths" By Jake Edge (April 13, 2016)
https://lwn.net/SubscriberLink/683350/4f52334af09653c8/

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

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

[Koos Zevenhoven]

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.fspath(path) "and be done with it".
>

No, fspath can't know that is the the right thing to do.  There should
be *someone* that is aware of the encoding that happens, either the
provider or the consumer. That byte path consumer, assuming it wants
to support the behavior you describe, should use os.fsencode instead
of os.fspath, which will do exactly what you want, and just as easy
for the bytes path consumer to implement!

(Unless you want to explicitly reject plain str objects, which you
would then indeed do *explicitly*, but I'm not sure there is a point
in accepting plain bytes and str-based pathlib objects but not str).

To avoid further unnecessary discussion, please read [1] carefully,
where I already explained this, among other things.

-Koos

[1] https://mail.python.org/pipermail/python-dev/2016-April/144239.html
___
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

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

[Koos Zevenhoven]

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 actually wants it.
>  >
>  > It might be,
>
> May I take that as meaning you just jumped to the conclusion that
> extending polymorphism is useful on no actual evidence of usefulness?

No you may not! YAGNI almost never means "you are *never* going to
need it". And if you implement a feature, better implement it well. If
a variation of the feature is rarely used, that is perfectly fine. I
think leaving bytes out would complicate things. If os.fspath does its
job well, everyone should be happy.

I kept bringing up bytes paths, because that is already a feature in
Python 3. Then (already some time ago in these discussions) I briefly
visited the thought of 'can we deprecate bytes paths', and it then
quickly became clear to me that is not going to happen any time soon.

In other words: As long as bytes paths are supported, they should be
supported consistently. I don't want DirEntry to behave differently
when the underlying type is bytes, which is one of the things I've
been talking about all the time. That would just be broken. And as you
also understand, one point is to allow passing DirEntry to open. Or
any of the os.path functions.

An some more: I don't want open(direntry_obj) to ever raise because it
is the bytes flavor of direntry, because, when they are created,
DirEntry objects always point to existing objects on the file system.
I also don't want implicit conversions between str and bytes paths,
because there are cases where they will produce strange results and
exceptions. [Yes, way back in the p-string thread, I did first suggest
a similiar thing that implied implicit conversion, but I soon
abandoned that part.]

Not that I will ever use these features---just to do this right.

>  > but as long as bytes paths are supported polymorphicly all over the
>  > stdlib, we won't get rid of supporting bytes paths. So are you
>  > proposing to deprecate bytes paths?
>
> You claim "almost always want str", Ethan claims "bias against bytes."
> Sorry, guys, you can't have it both ways.  Either bytes paths are
> discouraged (not "deprecated", not yet), or they aren't.
>
> I say, let's not encourage them.

It's all essentially the same thing:

"almost always want str":
Yes, I still claim this. This is the reason for str (and rejecting
bytes) being the default for third-party code. If we wanted to, we
could even leave bytes support out of the documentation, so no-one
will know about it unless they already deal with bytes paths. However,
I dont think we should do that---we should just strongly discourage
using the bytes version unless there is a reason to, and you know what
you are doing.

"bias against bytes":
I agree with this too. This is in line with making str (and rejecting
bytes) the default for third-party code.

"let's not encourage them":
And I even agree with this, as you may have noticed.

I just don't believe in deliberately making implementations awkward
for the bytes-based paths. Bytes paths already exist, not because of
Python 2 (as you know), but because not all operating systems
guarantee that paths make sense in any encoding, and people may need
to work at that level.

There is no need to make working with bytes-based paths awkward, and
we can support them with little additional work compared to supporting
str-based rich path objects. The additional work is mostly this
discussion.

> Ie, keep the status quo for bytes,
> and make things better for the preferred str.  Yes, that means
> discouraging bytes relative to str in this context.  That's a Python 3
> principle, one strong enough to justify the huge compatibility break
> involved in making str be Unicode.  That compatibility break has been
> extremely successful in my personal experience as a sometime Python
> teacher and Mailman developer, though the Mercurial developers have a
> different POV.

Yes. Luckily, people are already using str-based paths. We don't need
any more discrete transitions. If linux will start to enforce an
encoding, as Guido and Random832 may be suggesting on python-ideas,
these already obscure bytes paths will slowly fade away.

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

Re: [Python-Dev] Bytes path

[Philip Jenvey]

Yes, in the 3.2 time frame there was a consensus that only bytes and their 
subclasses should be accepted. buffer support crept back into the posix module 
with the major changes in 3.3, likely by mistake. A couple new issues are 
proposed to remove these inconsistencies/regressions:

http://bugs.python.org/issue26754 
http://bugs.python.org/issue26800 

--
Philip Jenvey

> On Apr 14, 2016, at 3:29 AM, Victor Stinner  wrote:
> 
> IMHO it's more a side effect of the implementation than a deliberate choice. 
> For new code which really want to support bytes paths, I suggest to only 
> accept bytes and bytes subclasses.
> 

___
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

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

[Stephen J. Turnbull]

Eric Snow writes:
 > On Tue, Apr 19, 2016 at 10:50 AM, Brett Cannon  wrote:
 > > Ah, but you see that doesn't make porting easy.

 > Perhaps I missed previous discussion on the point, but why not support
 > both __fspath__() -> str and __fssyspath__() -> bytes?

That's fine by me, I can live with that although I don't really like
it.  But the proponents of polymorphic __fspath__ think it's
unnecessary.

Why I don't like it: what's going to end up happening is that a
__fspath__- or __fssyspath__-bearing object of unknown provenance is
going to get passed to polymorphic os functions that won't complain,
and a few million cycles later something is going to access
fileobj.path expecting bytes and getting str, and blooey!

Also I just don't see a need for bytes when the original purpose of
this was to support passing pathlib.Path objects to open.  It's also
nice to pass DirEntry objects to open, but it's not obvious to me that
we need to support bytes since only new code can use this feature, and
there's a way to not-support them that doesn't cause any new problems.

It's not that I want bytes to go away[1], it's just that the playing
field will tilt a little more against them in new code.

Footnotes: 
[1]  I wouldn't weep, but I wouldn't laugh, either.

___
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