What surprised me is that after a long time with string based path libs, Java and Python are now moving onto oo based ones. I wonder how many other languages already had abstractions for this (smalltalk ? ruby?).

Perl comes with File::Spec since 1999 (perl 5.004_05) - http://perldoc.perl.org/File/Spec.html

NB. And there are more full featured alternatives on CPAN like Path::Class (https://metacpan.org/pod/Path::Class), IO::All (https://metacpan.org/release/IO-All) and Path::Tiny (https://metacpan.org/pod/Path::Tiny).

Rebol has its own file datatype which works seamlessly across platforms - http://www.rebol.com/r3/docs/datatypes/file.html | http://www.rebol.com/docs/core23/rebolcore-12.html

What I'm glad is that apparently they did a good job in converting it, and not converting it to OO just for the sake of it and resulting in a crappy API "but it's OO"

Do the docs worry you?

"Note This module has been included in the standard library on a provisional basis. Backwards incompatible changes (up to and including removal of the package) may occur if deemed necessary by the core developers."

http://docs.python.org/3.4/library/pathlib.html

Actually, there are incompatible changes ALREADY that affect all my projects.

pathlib in python3 has ".parent" property that returns parent-directory, and pathlib in master has ".parent(n)" method that returns n levels UP.

That sucks so much.

Most new modules in the standard library come with that warning. It's pragmatic.

Python has a relatively large standard library (one of its selling points), and not everything in the standard library can be right the first time. No matter how long a Python release spends in beta, there are probably flaws that will only be discovered when people start using new modules to do their actual jobs (where they won't be using a beta version of Python).

In Python 1 and 2, if a standard library module had a flaw that required a backwards-incompatible change to fix, the flaw would have to remain there. In Python 3 they acknowledge that the first version may require backwards-incompatible changes.

It had been proposed various times in the past and it was rejected.

I don't remember the semantics of the reasons it was rejected, but if you search about 'pep' and object paths you ll find more info

Common Lisp has had object-based pathnames, as well as namestrings for over two decades now.

> I wonder how many other languages already had abstractions for this (smalltalk ? ruby?).

I remember VBScript/JScript with FileSystemObject decades ago. It's from COM

FSO is more a Class wrapping the usual FS functions, it still pass around raw string IIUC.

C#/.NET/PowerShell has some decent path abstractions. You still usually create the initial object via a string at some point though...

As far as I know it's always a string. You just have a bunch of helper methods to handle "path strings". But they're still strings, not Path objects (or File, like in Java).