3 ms·

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

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.

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.