Live data from Hacker News

Structuring Your Project

docs.python-guide.org

21–30 of 40 posts

Re: Structuring Your Project

#21

Earlier quoted context omitted.

That's really not recommended. A lot of behaviors are subtly affected by failing to have init files.

Like what?

Not op but I have personally noticed that doing a ‘python setup.py install’ doesn’t correctly import modules unless you have an __init__.py file. It’s possible I could be doing something wrong however.

Re: Structuring Your Project

#22
post #7

Nitpick: 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?

I don't understand what the author has against requiring a pip install -e .

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
Most 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

#25

Most 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.

[deleted]

Re: Structuring Your Project

#26

Most 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.

I would agree with you.

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

#27

When 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…

Tooting my own horn try: https://github.com/mikadosoftware/mkrepo

mkrepo reponame .

will get a fairly decent skeleton created (been using a lot for my own stuff recently)

Re: Structuring Your Project

#28

Most 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.

It's not so much large strings as lots of concatenation; aggregating all the substrings into a list and joining saves allocations and at least at one point in time it gave a huge speedup on a number of large systems. While Python's overall performance has improved since then, my understanding is that creating lots of strings and incrementally assembling the allocating and dropping lots of progressively-larger items is still often a significant performance hit.

Re: Structuring Your Project

#30

When 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…

> It's surprising to me that Python, as focused as its philosophy is on providing canonical solutions to problems, doesn't have a "python -m newproject". There must be a good reason.

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.

Post reply on HN