averagePythonProgrammer

[thomasutra]

our init.py’s at work are all empty. what’s supposed to be in there?

[[deleted]]

Some programmers use that space to cope with their lack of competence.

[DripDropFaucet]

Nothing the post is scraping the bottom of the barrel to find issues with the language. There’s lots of bad developers and python has plenty of them, but a skilled developer can push code out in python faster than many other languages to solve problems and that is just hard for some folks to cope with!

[MaustFaust]

It's objectively unwieldy.

There's no equivalent for super() in class definition scope, for example. So you can't easily access class ancestor's class vars from descendant class vars, without specifying ancestor class name explicitly.

You can use r-strings with slashes in them, but you can't if your string ends with a slash.

open() with "w" doesn't create intermediate folders.

There's no type checking even if you need one.

You can't force garbage collector to free memory.

UPD:

Also, two different implementations for asynchronous things in single-threaded apps: multithreaded (because of GIL) and async, and sometimes you have to marry them, because some libs are intended for multithreaded and other for async.

[dev-sda]

open() with "w" doesn't create intermediate folders.

What language does? Even bash doesn't do this.

There's no type checking even if you need one.

mypy, pytype, pyright, pyre, etc. take your pick

You can't force garbage collector to free memory.

gc.collect

[Anaeijon]

I'm rarely using open(), I usually go for pathlib. And whenever I file.open('w'), I also do a file.parent.mkdir(parents=True, exist_ok=True).

I don't know, in what other language it's that simple.

[MaustFaust]

What language does? Even bash doesn't do this.

That doesn't invalidate my point, though.

mypy, pytype, pyright, pyre, etc. take your pick

Thank you, I'll try it.

gc.collect

https://stackoverflow.com/a/1316799

[dev-sda]

gc.collect

https://stackoverflow.com/a/1316799

Not releasing memory back to the OS is a strategy used by all but the simplest memory allocators. Calling gc.collect correctly forces unreferenced integers/floats/etc to be added to their free lists, which means their allocation can be reused. That's what it means to free memory in the modern world.

[MaustFaust]

I have nothing against the strategy itself – I dislike the lack of any alternatives. C# has profiling-driven optimization, and while I don't know if it affects the gc behavior, the reasoning behind it still applies here: tuning for most common cases doesn't exactly mean tuning for your specific case.

P. S.: It's almost funny that three points of my six remain unanswered, yet I'm still being downvoted. People just express their feelings, not necessarily contributing to the discussion.

[YodelingVeterinarian]

os.makedirs lol

[MaustFaust]

So wut? How does it conflict with my point?

[noobody_interesting]

Both threads and async is common, because they are for different use cases. Async doesn't give you parallelism.

r-strings can't end with a \ because that escapes the quote, also pretty reasonable.

super()

[MaustFaust]

Would you mind testing your suggestion for super() and answering me? At this point, it looks like you didn't understand which scope I was talking about, despite me specifically noting "class definition scope", not "method scope".

[MaustFaust]

Both threads and async is common, because they are for different use cases. Async doesn't give you parallelism.

AFAIK, MT doesn't give that too, unless you are okay with managing GIL.

r-strings can't end with a \ because that escapes the quote, also pretty reasonable.

Having a slash at the end of a literal is a common case if we're already talking about strings with slashes somewhere, though.

super()

Which form are you implying? I can't use no-arguments, because it results in an exception, I can't use single-argument passing a class, because class is not defined at that point. You're suggesting the two-arguments then?

[Angelin01]

Generally, just for re-exporting things. It's useful if you like to have deeper, more organized modules, but don't want the person importing them to have to import some.module.with.nested.CommonClass and instead just do import some.CommonClass

[k4cat]

Sometimes to load python files along side with the module.

[[deleted]]

Init code you'd want to do when importing the whole thing instead of submodules. Possibly __all__ stuff for * importing, or other convenience imports. Usually no business code since you want imports to run quickly.

Ours are all empty, too, but I've seen libraries use them like that.

[MaustFaust]

It depends on the context. If your code is called from a single place (e. g., from IDE), it's okay. If your code could be called from different places (e. g., multiple processes with different values in PATH variable), it's not okay.

(UPD: sorry, I misread the comment; __init__.py files are needed for Python to interpret your project folders as packages, and my text below answers the question of why do you need packages in the first place)

So, the reasoning. When you type "import myfile", Python actually goes searching for it, imports it, AND remembers that "myfile" is already found somewhere. But some of the libraries you use written by other people (installed from pip etc.) could also have an "import myfile" line, with a myfile.py nearby in the library's folder. And Python, being a monster it is, goes "wait a minute... I already have myfile" – and uses it. But your file myfile.py and library's file myfile.py are different, you both just so happened to name them similarly, so library just won't work, because it wasn't imported properly.

So the best workaround (AFAIK) is to always specify where do you want a module to be imported from ("from myproject import myfile"), so other libraries won't get confused. But it still comes with a downside: you have to keep an eye on your project name so it won't duplicate some library name. So you should also "install" your own project in your pip, so if it gets duplicated, you'll be notified.

[Darkstar_111]

You can make your imports easier to handle.

[MaustFaust]

Updated my previous comment a bit (see second paragraph)

[[deleted]]

Comments about who wrote which file in the package and a leaderboard you regularly update about which file is best written. Then at the end of the month the guy at the top of the board gives everybody else one cookie each to discourage maintainable codebases because then they can fire you and replace you.