Hacker News Reader

Comment by coppolaemilio | Hacker News Reader

the Path thing is incredible! I wasn't aware of it. I'll definitively be replacing my os.path.join calls for a more readable version of it.

View on HN

The read_bytes() and read_text() methods are particularly useful. They're new in Python 3.5.

Path(__file__).absolute().parent.glob('/*.py') is just wonderful.

Wow, I switched to Python 3 really early on and never knew about pathlib.

I have been conditioned to write code that is 2/3 compatible, that even when I am writing specifically for the PY3 interpreter the code turns out to be a __future__ import away from being valid PY2. I did not think much of them at first, but very recently, f-strings have changed that.

I think many people get imprinted with writing the PY3 code using only the features available at the time they switched over.

You can use some backports of libraries though, surely? `pathlib` is in pip.

Back-ports are an option but they are an extra dependency. When you have not used a new feature, the cost of an extra dependency out weighs the unknown benefits that would be realised by using a back-port.

And the multiprocessing and threading pools.

And collections.ChainMap.

And f-strings.

And yield from.

And type hints.

And statistics.

And ipadress.

And secrets.

And matmul.

And subprocess.run.

Come on, Python 3 is packed with awesomeness !

Every time somebody mentions how awsome f-strings are makes me laugh. It was around ten years ago when Python community was looking down at Perl and shell with their string interpolation, but now that Python got pretty much the same it's suddenly not considered a misfeature.

We were wrong. We aknowledged it and improved. It's a good thing.

Have you considered that maybe the language had not evolved enough for them to be appealing. With b'' and u'' string syntax coming into the language, there is a realisation that string interpolation can be an opt-in feature among other reasons.

What you have is decision making analogous to the function

    evaluate(string_interpolation, python_ecosystem)

which is different from

    evaluate(string_interpolation)

> With b'' and u'' string syntax coming into the language, there is a realisation that string interpolation can be an opt-in feature among other reasons.

This argument won't fly. Did you know that string interpolation in Perl and shell was always an opt-in feature? And despite that it was frowned upon by Python community.

multiprocessing and threading pools

While certainly awesome, these are in python 2.7 as well. Although I don't remember if they where in 2.7 first of back-ported to 2.7 from 3.

__Reliable__ pools are only in 3.

Cool. What's changed?

> test_path = datasets_root / dataset / 'test'

> Previously it was always tempting to use string concatenation (concise, but obviously bad), now with pathlib the code is safe, concise, and readable.

This is the kind of feature that I'm wary to use even in scripts: questionable benefit, and probably too clever.

Benefit is huge: it's readable, easy to type, and takes care of joining with proper "/" or "\" depending of the plateform.

I'll challenge you: You shouldn't have many paths, should keep them at a centralized location in the code, and there you could just use a normal function with a proper self-documenting name.

It's not like programs consist of path operations to a significant degree, so using fancy syntactic sugar doesn't seem like a worthwhile optimization to me. At all.

You say that because you are not a sysadmin. Python user base is very rich.

I don't have a machine available right now, but I wonder what happens if two adjacent path elements are integers? Does it perform division instead of path/string concatenation?

You can't concatenate a path with an integer:

  >>> Path.cwd() / 1
  TypeError: argument should be a path or str object, not <class 'int'>

Also, note that the '/' operator is left-associative, so even if you have two adjacent numbers when joining paths, there will be no division.

  TypeError: expected str, bytes or os.PathLike object, not int

This probably means that you put a path to the left, not ints on both sides.

Well, I put a path and then two ints... if you don't start with a path it's obviously just going to be division.

The Path object won't construct a path from an integer.

    >>> from pathlib import Path
    >>> p=Path(1)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/lib/python3.6/pathlib.py", line 979, in __new__
        self = cls._from_parts(args, init=False)
      File "/usr/lib/python3.6/pathlib.py", line 654, in _from_parts
        drv, root, parts = self._parse_args(args)
      File "/usr/lib/python3.6/pathlib.py", line 638, in _parse_args
        a = os.fspath(a)
    TypeError: expected str, bytes or os.PathLike object, not int
    >>>

So what happens if the paths are numbers? They are treated like any other characters.

p=Path(str(1))

Python is strongly typed.

Yes, that's pretty much the question metaobject was asking.

Should I have said "numeric characters" or "numeric strings" in my last paragraph instead of numbers?

Reply on news.ycombinator.com