5 ms·

Funny, the pathlib functionality is really similar to a saturday morning hack that I was playing with a few months ago. Pathlib, asyncio, unicode default, bund

Funny, the pathlib functionality is really similar to a saturday morning hack that I was playing with a few months ago. Pathlib, asyncio, unicode default, bundled pip and venv... I do like the look of Python3. It's looking a lot more interesting, the further along it gets. I still haven't really done anything with it, due to python2 being bundled with our OSX and Linux workstations, which means painless installs. This year, however, I do want to start porting my projects over to Python3 (well, making them run on both, at least...)

agumonkey 13y ago
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?).
- rjbwork 13y ago
  C#/.NET/PowerShell has some decent path abstractions. You still usually create the initial object via a string at some point though...
  - ygra 13y ago
    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).
- est 13y ago
  > 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
  - agumonkey 13y ago
    FSO is more a Class wrapping the usual FS functions, it still pass around raw string IIUC.
- draegtun 13y ago
  Perl comes with File::Spec since 1999 (perl 5.004_05) - http://perldoc.perl.org/File/Spec.html 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 https://metacpan.org/pod/Path::Class), IO::All (https://metacpan.org/release/IO-All https://metacpan.org/release/IO-All) and Path::Tiny (https://metacpan.org/pod/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/r3/docs/datatypes/file.html | http://www.rebol.com/docs/core23/rebolcore-12.html http://www.rebol.com/docs/core23/rebolcore-12.html
- raverbashing 13y ago
  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"
- rnnr 13y ago
  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
- brownbat 13y ago
  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 http://docs.python.org/3.4/library/pathlib.html
  - k_bx 13y ago
    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.
  - rspeer 13y ago
    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.
- wtbob 13y ago
  Common Lisp has had object-based pathnames, as well as namestrings for over two decades now.

agumonkey 13y ago

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?).

rjbwork 13y ago
C#/.NET/PowerShell has some decent path abstractions. You still usually create the initial object via a string at some point though...
- ygra 13y ago
  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).
est 13y ago
> 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
- agumonkey 13y ago
  FSO is more a Class wrapping the usual FS functions, it still pass around raw string IIUC.
draegtun 13y ago
Perl comes with File::Spec since 1999 (perl 5.004_05) - http://perldoc.perl.org/File/Spec.html 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 https://metacpan.org/pod/Path::Class), IO::All (https://metacpan.org/release/IO-All https://metacpan.org/release/IO-All) and Path::Tiny (https://metacpan.org/pod/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/r3/docs/datatypes/file.html | http://www.rebol.com/docs/core23/rebolcore-12.html http://www.rebol.com/docs/core23/rebolcore-12.html
raverbashing 13y ago
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"
rnnr 13y ago
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
brownbat 13y ago
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 http://docs.python.org/3.4/library/pathlib.html
- k_bx 13y ago
  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.
- rspeer 13y ago
  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.
wtbob 13y ago
Common Lisp has had object-based pathnames, as well as namestrings for over two decades now.