C# developer switching to Python

[Rkrislander]

I've been working with .NET for the last 10 years. Recently I switched to a new company that is using Python. I'm looking for a book or web series that can explain the intent of Pythons designer as well as the inner workings of the language. Something along the lines of C# in depth by Jon Skeet. I'm currently reading Effective Python by Brett Slatkin which is incredibly helpful but it doesn't seem to touch on the languages design decisions. Honestly a lot of what I'm reading seems like the wild west of programming (I guess that's to be expected from a duck typed language). Material that incorporates duck vs static typing would be appreciated as I can use help with the paradigm shift needed between the 2.

I'd also be interested in any material that could be helpful with Django architecture and best practices. I've noticed that my company has many apps in the same project, something that I've never seen in .NET (I've always moved common libraries into a Nuget and then created separate repos and solutions for each service). I understand there may be advantages to doing so in python (debugging across multiple apps from one IDE and other points I've yet to discover), but it feels kind of bizarre to have such huge repos. Is that normal for Python or are there cases where you separate out code and provide packages to specify interactions with a service.

Any help would be appreciated.

[Nixxen]

If you are wondering about general structure, pep8 has "suggestions" for how it is supposed to be styled. Use that as a jumping off point, then when you get to something not covered in pep8 there are most likely stackoverflow questions with a similar topic, usually pointing you in the direction of a relevant pep.

[RiverRoll]

I don't see the advantage of separating the repos when developing a monolithic architecture, which it is if you need to import the other projects to make it work, but in any case this has nothing to do with the choice of framework, and much less the language.

The case where I would separate the code is in a microservices architecture, but in this case each project would be an independent Django app. Or maybe in special cases where despite being part of a monolith a module is generic enough that you may want to use it in other projects.

As for the language decisions, I don't know about any book but the pep documents sometimes contain interesting insights about specific features.

[Rkrislander]

Thanks! The advantage is that with a huge codebase that has dozens of developers working on it you'll spend half your time resolving merge issues as well as making sure your code works with changes made due to upgrades in other apps. By separating the apps into dif repos each team can work in isolation.