4 ms·

> One thing I forgot to mention in my previous post is paths in Python, which has this whole fun page on it in the Python documentation: https://docs.python.org

by m45t3r 7y ago

> One thing I forgot to mention in my previous post is paths in Python, which has this whole fun page on it in the Python documentation: https://docs.python.org/3/library/os.path.html https://docs.python.org/3/library/os.path.html. Part of the reason for this in the first place is because pathing is handled differently between Unix and Windows systems, so you're supposed to use this library to navigate (or something completely different, glob, which is another thing to look up and understand) instead of just using a open("c:/blah/blah.txt") so that it can be compatible for either OS. There is pathlib nowadays that allows you to navigate in very complex situations using a quite nice OOP API.

cableshaft 7y ago
Good to know, thanks :) I've only ever used Python for my own tinkering purposes so I haven't been too aware of any new developments. But I assume the old ways are still valid code, so if you're working with Python code you may encounter any of now 3 different systems of just navigating paths for file i/o, what the parent claims should be dirt simple.
- dmitriid 7y ago
  Yes. It is dirt simple, for dirt simple things. It's quite easy and discoverable from documentation for more complex things. The method in my link (which changed rather drastically between versions): - is very much iOS and MacOS specific - requires knowledge of quite a few iOS/MacOS-related things (FileManager.SearchPathDirectory is probably 80% Apple-specific) - even though it's a "FileManager", it doesn't even let you access/open a file. You have to perform additional operations on the resulting Directory type (.appendingPathComponent) - even that doesn't give you a means of opening a file, because in order to read a file, you have to invoke a String constructor. In order to write to a file, you need to invoke a method on a String type. Talk about coupling entirely unrelated things That is an example of objectively bad API design. And it's clear from API evolution that it's not even Swift APIs. These are very thin wrappers for OS's existing Obj-C APIs. I think it's the first among languages: to provide OS APIs and call them a standard library for a language. I don't think even MS did that when they were creating .NET.
  - pjmlp 7y ago
    Microsoft does it all the time with .NET, after all the future of Windows was going to be all .NET. It just did not worked out that way, as WinDev tanked Longhorn efforts and now we have UWP (aka COM) instead of .NET for OS APIs. Which are anyway easily accessible from .NET given its COM support.
- m45t3r 7y ago
  It is still relatively simple because the conversion between Pathlib<->str is literally one method call (from pathlib, just call `str(pathlib_object)`, from string, just call `pathlib.Path(str_object)`. I know this because I started a project using only strings and `os.path`, however when testing it started to become complicate to mock the correct paths so in tests I use `pathlib` (with conversions back to string when I finish path manipulation) and the code still works.

by m45t3r 7y ago

cableshaft 7y ago

Good to know, thanks :) I've only ever used Python for my own tinkering purposes so I haven't been too aware of any new developments. But I assume the old ways are still valid code, so if you're working with Python code you may encounter any of now 3 different systems of just navigating paths for file i/o, what the parent claims should be dirt simple.

dmitriid 7y ago
Yes. It is dirt simple, for dirt simple things. It's quite easy and discoverable from documentation for more complex things. The method in my link (which changed rather drastically between versions): - is very much iOS and MacOS specific - requires knowledge of quite a few iOS/MacOS-related things (FileManager.SearchPathDirectory is probably 80% Apple-specific) - even though it's a "FileManager", it doesn't even let you access/open a file. You have to perform additional operations on the resulting Directory type (.appendingPathComponent) - even that doesn't give you a means of opening a file, because in order to read a file, you have to invoke a String constructor. In order to write to a file, you need to invoke a method on a String type. Talk about coupling entirely unrelated things That is an example of objectively bad API design. And it's clear from API evolution that it's not even Swift APIs. These are very thin wrappers for OS's existing Obj-C APIs. I think it's the first among languages: to provide OS APIs and call them a standard library for a language. I don't think even MS did that when they were creating .NET.
- pjmlp 7y ago
  Microsoft does it all the time with .NET, after all the future of Windows was going to be all .NET. It just did not worked out that way, as WinDev tanked Longhorn efforts and now we have UWP (aka COM) instead of .NET for OS APIs. Which are anyway easily accessible from .NET given its COM support.
m45t3r 7y ago
It is still relatively simple because the conversion between Pathlib<->str is literally one method call (from pathlib, just call `str(pathlib_object)`, from string, just call `pathlib.Path(str_object)`. I know this because I started a project using only strings and `os.path`, however when testing it started to become complicate to mock the correct paths so in tests I use `pathlib` (with conversions back to string when I finish path manipulation) and the code still works.