> On 25 May 2019, at 18:56, Theron Luhn <[email protected]> wrote: > > You’ve organized the modules by sections of the website, and the relevant > views and models in each section. I usually do the inverse, split my app > into views, models, templates, etc. I’d be interested to see what “best > practice” is considered, I’ve always wondered how everybody else organizes > their apps.
We have one 5-year old project with 70k and one fairly recent project with 15k lines of Python code. Both Pyramid based. The old project uses the structure you described. And it is the structure I have used exclusively since last summer, when we started working on the new project. We had Domen Kozar helping us out and he suggested to try splitting up the codebase into sections. He claimed it worked well on his last Pyramid project. Initially, I was repulsed. But I imagined I could always refactor back to “my way” if I wanted, so it was a rather cheap experiment. And I’m glad I did it. The codebase of the new project (while ~4x smaller than the old) is vastly more readable and navigate-able. The only drawback that I found so far is that it is a bit harder to ask my editor, for example, “I forgot how to build an SQLAlchemy query to do X in tests, find me all tests that do it” because I I’ll get non-tests code in my “find in all files” results. This is a super minor drawback. Benefits far outweigh it. > What’s your experience with type hints/mypy? I was looking into using them > in my applications, but decided it wouldn’t be worth it because Pyramid does > not yet have support (there’s an open issue being discussed) and SQLAlchemy’s > support is nascent (but very exciting!). I am absolutely loving it. Having deep integration between mypy and my editor prevents me from introducing a whole class of bugs that I would previously only find much later, maybe in integration tests or even in production. The feeling is quite similar to January 2014 when I enforced 100% unit tests coverage in our big project that I talked about above. I remember suddenly feeling *much* more at ease when faced with a refactor. Before, there would always be that lingering “what if I break things” feeling when doing refactors so I’d rarely do them. And we all know that if you don’t regularly refactor, you get bit rot, and then the codebase becomes a burden to work with. I was surprised to get this exact feeling again this year, when enforcing 100% types coverage in our new project. Nowadays, when I have to work with code that does not have type hints, it feels icky. When I see an obvious eye sore I’m afraid to touch it, even if the code has 100% tests coverage, as we all know that the coverage does not guarantee the test suite will catch all problems. It won’t. Having types feels like having an additional, independent, test suite. And it makes me far more comfortable to touch parts of code I no longer remember writing. Does it take you longer to write code? Yes. Is there a learning curve? Sure. Will you be frustrated and annoyed because you will not understand mypy’s error messages? Absolutely. But it’s an investment your are making today that the future you will be very glad you did. z. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/EE43D873-04C5-4660-8F6F-056567257141%40gmail.com. For more options, visit https://groups.google.com/d/optout.
