(original) (raw)
On Wed, 6 Apr 2016 at 10:41 Wes Turner <wes.turner@gmail.com> wrote:
\* +1 for \_\_path\_\_, \_\_fspath\_\_
(though I don't know what each does)
Returns a string representing a file system path.
\* why not Text(basestring / bytestring) and pathlib.Path(Text)?
See the points about next() vs \_\_next\_\_()
\* are there examples of cases where this cannot be?
I don't understand what you think "cannot be".
\* if not, +1 for subclassing str/Text
\* where are the examples of method collisions between the str interface and the pathlib.Path interface?
There aren't any and that's partially why some people wanted the str subclass to begin with.
Please consider this thread a str-subclass-free zone. This line of discussion is to flesh out the proposal for a path protocol as a proposal against subclassing str, not to settle the whole discussion outright. If you want to continue to debate the subclassing-str side of this please use the other thread.
-Brett
\* str.\_\_div\_\_ is nonsensical
\* pathlib.Path.\_\_div\_\_ is super-useful
On Apr 6, 2016 10:10 AM, "Ethan Furman" <ethan@stoneleaf.us> wrote:\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_On 04/05/2016 11:57 PM, Nick Coghlan wrote:
On 6 April 2016 at 16:53, Nathaniel Smith <njs@pobox.com> wrote:
On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
I'd missed the existing precedent in DirEntry.path, so simply taking
that and running with it sounds good to me.
This makes me twitch slightly, because NumPy has had a whole set of
problems due to the ancient and minimally-considered decision to
assume a bunch of ad hoc non-namespaced method names fulfilled some
protocol -- like all .sum methods will have a signature that's
compatible with numpy's, and if an object has a .log method then
surely that computes the logarithm (what else in computing could "log"
possibly refer to?), etc. This experience may or may not be relevant,
I'm not sure -- sometimes these kinds of twitches are good guides to
intuition, and sometimes they are just knee-jerk responses to an old
and irrelevant problem :-)
But you might want to at least think about
how common it might be to have existing objects with unrelated
attributes that happen to be called "path", and the bizarro problems
that might be caused if someone accidentally passes one of them to a
function that expects all .path attributes to be instances of this new
protocol.
sys.path, for example.
That's why I'd actually prefer the implicit conversion protocol to be
the more explicitly named "\_\_fspath\_\_", with suitable "\_\_fspath\_\_ =
path" assignments added to DirEntry and pathlib. However, I'm also not
offering to actually \*do\* the work here, and the casting vote goes to
the folks pursuing the implementation effort.
If we decide upon \_\_fspath\_\_ (or \_\_path\_\_) I will do the work on pathlib and scandir to add those attributes.
\--
\~Ethan\~
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
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/brett%40python.org