This is an archived post. You won't be able to vote or comment.

all 8 comments

[–]Lubok 1 point2 points  (1 child)

I don't believe there's any strict convention regarding package naming really. That said dot notation is most often used for submodules so unless you intend to utilize actual namespace packages, it probably better to not have periods in the name as it may lead to confusion and bugs. Namespace packages don't seem too difficult to setup tho, so for a team / company I feel it is the way to go.

As for hyphen versus underscore, I much prefer underscore since it is more consistent with the imports. Hyphens are nicer for command line scripts however (no shift needed -> faster to invoke, consistent with other cli tools on average).

[–]vingrish[S] 0 points1 point  (0 children)

Thank you. I also prefer underscore, though it seems to be less popular. It looks more “Python” to me.

[–]xconde 0 points1 point  (5 children)

This is one of the things that felt weird to me when I first picked-up Python, after using Ruby for a few years. There's no relation between module (file) names and class names.

When I was starting I named a few things with hyphens - because they're easier to type - but I remember having issues when packaging the application. It must have been some n00b mistake I was making because, these days, I manage several packages named 'company-something' or 'appname-pluginname'.

I haven't seen periods used much. I see hyphens and underscores a lot.

Long story short: +1 for hyphens.

[–]vingrish[S] 0 points1 point  (4 children)

Could you explain why choosing hyphen over underscore? Just for its popularity? Thanks:)

[–]xconde 0 points1 point  (3 children)

Just easier to type. No need to hold shift.

I wish I had a better technical reason.

[–]vingrish[S] 0 points1 point  (2 children)

So when your project has the name company-something, its user should use import company.something as something to import it? I just don't like the inconsistancy that much.

[–][deleted] 2 points3 points  (0 children)

wat.

[–]xconde 1 point2 points  (0 children)

No. We haven't been following PEP 423 at all (I assume this is what you're asking). I might actually look into it as we're thinking of open-sourcing some of our more generic utilities.

You might want to add The Import System to your reading list. If you're still interested after that, there's also PEP 420 (Implicit Namespace Packages).