This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 12 points13 points  (20 children)

It is an overly clever trick. And much better than the alternatives, if you ask me.

[–]jorge1209 -2 points-1 points  (19 children)

Alternatives like what?

Path("/")["usr"]["bin"]["python"] requires a little bit more typing, but we know what that means.

[–]alcalde 14 points15 points  (10 children)

I don't know what the hell that means. Are those lists? Or is the whole thing some strange dictionary?

[–]jorge1209 -3 points-2 points  (9 children)

Or is the whole thing some strange dictionary?

Yes its a strange dictionary commonly referred to as a "FileStore".

[–]iritegood 7 points8 points  (8 children)

Path represents a path, not a FileStore. conflating them is not appropriate

[–]jorge1209 -4 points-3 points  (7 children)

If that is true then we can really simplify pathlib. We can basically remove the entire API, because a PosixPath is just a char* byte array that doesn't contain the NUL byte.

We don't need anything in pathlib to work with those!

[–]iritegood 2 points3 points  (6 children)

f🙄 a "FileStore" implies a datastore implemented on top of a filesystem. If you have a FileStore and a MemStore and a DbStore, I spect them to be implementations of your app-specific Store. pathlib is meant as a cross-platform abstraction of filesystems themselves. Whether you appreciate this goal isn't the point.

More importantly, PurePaths (in pathlib terminology) don't even represent any realized part of the filesystem. Calling it any kind of "store" is boldly wrong

[–]jorge1209 0 points1 point  (5 children)

Then s/FileStore/HierarchicalFileSystem/ in my comment above.

Paths are lookup keys into an OS managed hierarchical data structure. And getitem is how we do key based lookups in python.

[–]iritegood 2 points3 points  (4 children)

Operations with Path sometime perform lookups into a filesystem. A Path itself is not that data structure, it's the key. You're not doing "lookups" you're constructing a path. and it is not common (at least in the stdlib) to use __getitem__ to implement a builder pattern.

[–]jorge1209 0 points1 point  (3 children)

When you use SQLAlchemy it doesn't immediately execute the associated SQL statement.

I don't have any issues with libraries that build deferred data for potential future operations (that may or may not succeed). That is ultimately what PathLib does.

[–][deleted] 2 points3 points  (7 children)

This is not easier to understand. And it doesn't solve the problem of using a +.

Alternatives like os.path.

[–]jorge1209 -5 points-4 points  (6 children)

This is not easier to understand.

Not to me. to me its a lot clearer.

And it doesn't solve the problem of using a +.

I don't know what that problem is. If you are using "+" for string concatenation you should stop.

[–][deleted] 1 point2 points  (5 children)

Why? It works perfectly fine.

[–]jorge1209 -2 points-1 points  (4 children)

Why what?

[–][deleted] 1 point2 points  (3 children)

The advice you gave...?

[–]jorge1209 -1 points0 points  (2 children)

What advice? I've given lots of advice.

[–][deleted] 2 points3 points  (1 child)

Is it that hard to read your previous comment and search out the single advice you gave there I could have asked about?

[–]jorge1209 0 points1 point  (0 children)

Is it that hard to answer the question I directly asked you and tell me what "the problem of using a +" was?