Earlier quoted context omitted.
That's really not recommended. A lot of behaviors are subtly affected by failing to have init files.
Like what?
Structuring Your Project
21–30 of 40 posts
Re: Structuring Your Project
#22Nitpick: I'd rather use the python -m pytest way than modify sys.path (AKA "the django way"). Modifying sys.path is an ugly hack which makes python look like some... idk. matlab?
You're requiring contributors to install dependencies anyway.
If you're using pytest (I think the article assumes you're only using the standard library unittest which I wouldn't personally recommend) there is pytest-pythonpath which at least makes this invisible to the user.
Re: Structuring Your Project
#23 foo += 'ooo' # This is bad, instead you should do:
foo = ''.join([foo, 'ooo'])
This seems like such a silly micro-optimization. I also have to question its validity, even in scenarios where you're working with huge strings.Re: Structuring Your Project
#24Re: Structuring Your Project
#25Most of the advice here seems okay but this stuck out to me: foo += 'ooo' # This is bad, instead you should do: foo = ''.join([foo, 'ooo']) This seems like such a silly micro-optimization. I also have to question its validity, even in scenarios where you're working with huge strings.
Re: Structuring Your Project
#26Most of the advice here seems okay but this stuck out to me: foo += 'ooo' # This is bad, instead you should do: foo = ''.join([foo, 'ooo']) This seems like such a silly micro-optimization. I also have to question its validity, even in scenarios where you're working with huge strings.
The only reason I can see for the advice is that the first line does not handle that foo (#) might be other than a string - for example if foo was [1,2,3] you just got [1,2,3,'ooo']. the second line would barf on that. But if that was the case it is waaaay more readable to explicitly test for that
so yeah, generally not great advice
(#) Holy moly how many times will autocorrect change foo to too!!! stop it!
Re: Structuring Your Project
#27When I'm just learning a new programming language or framework, I prefer to have something like create-react-app [0], django-admin startproject [1], cargo new [2], or lein new [3]. Guides like these are just full of (the wrong type of) rabbit holes. Just give new people something that lets them work productively as soon as possible and refer them to language documentation to understand how features of the language or…
mkrepo reponame .
will get a fairly decent skeleton created (been using a lot for my own stuff recently)
Re: Structuring Your Project
#28Most of the advice here seems okay but this stuck out to me: foo += 'ooo' # This is bad, instead you should do: foo = ''.join([foo, 'ooo']) This seems like such a silly micro-optimization. I also have to question its validity, even in scenarios where you're working with huge strings.
Re: Structuring Your Project
#29Re: Structuring Your Project
#30When I'm just learning a new programming language or framework, I prefer to have something like create-react-app [0], django-admin startproject [1], cargo new [2], or lein new [3]. Guides like these are just full of (the wrong type of) rabbit holes. Just give new people something that lets them work productively as soon as possible and refer them to language documentation to understand how features of the language or…
The reason is probably related to the perennial python packaging problem; many of the projects offering solutions to that problem have their own project generator bundled.