Hacker News Reader

Comment by iandanforth | Hacker News Reader

I have literally never seen a python project organized the way the maintainer does. This does not bode well.

The src directory is becoming a popular option. See https://blog.ionelmc.ro/2014/05/25/python-packaging/#the-str... for an enumeration of the reasons.

Another resource might be https://hynek.me/articles/testing-packaging/

My package has both Python code ("module") and a C extension ("_module"). The C extension code is under src/ following a long Unix tradition.

With the Python-module(s)-under-"src/" option, where do people usually place their C extension code?

It's clear that I could use any name, like "pysrc", and not just "src/" for the Python code. What I'm asking about is if there is a growing consensus about how to organize a package with both Python and C modules.

For C extensions, the most common layout I've seen is to put C code under lib/ (regardless of whether you are using a src/ layout).

Checking my local copies of different packages containing both C and Python:

  matplotlib: src/ contains C code while lib/ contains Python
  cffi: c/ contains C code, there is no lib/
  numpy: contains C code in many places, like numpy/core/src/ ; no lib/
  pyzmq: contains C code mostly under zmq/core/ ; no lib/
  python-cdb: contains C code under src/ ; no lib/

Checking a few other packages:

  pycuda: contains C code under src/ ; no lib/
  Pillow: contains C code under src/ ; no lib/
  tornado: the one C file is under tornado/ ; no lib/ or src/
  Caffe: C++ code under src/ ; no lib/

That is, I haven't found any packages which put C extension code under lib/ .

Which packages are you thinking of?

Ah, my mistake. I know that CPython and matplotlib both have a lib/ directory, but you're right that that's where they keep the Python code and they keep the C code in Modules/ and src/, respectively.

Also I may have confused this with the src/ layout in the past and put my own C extensions into lib/. Thanks for the survey, I think I've been harboring this misconception for a while now.

It's a fairly new paradigm, and I've noticed these things spread slowly in the Python ecosystem (Python 3 was released over 10 years ago). But I use it, and I've started seeing it in some other python packages lately.

Also keep in mind it is only for python packages, not applications--the primary benefit is that it is impossible for the tests to access files that are not part of the package build.

I think it's a great fit for applications too.

Having One Punch Man as tier 3 invalidates all your points. ;)

He explains the rationale behind his rankings here: https://alexcbecker.net/anime.html#puella-magi-madoka-magica

You can also just scroll down on the ranking page. Well worth reading. He laments that we as a society have lost our appetite for great media. Adroit exploration of a conceptual space, which is what One Punch Man does so incredibly well, is a feature of goodness, but it needs more to elevate it to true greatness. I agree with this.

My position however is that the economics of media production ensure that very little of it will ever be great. Greatness must be driven by vision, and placing mountains of resources at the sole command of one dictatorial visionary will always be a hard sell, and doesn't even ensure that you'll end up with actual greatness. For every Stanley Kubrick you have a dozen Michael Bays.

Best off-topic comment on HN.

I think using the src directory is a great idea. The tests can’t just reach over into the package anymore so you have to do an editable install, but the payoffs are big, as noted in the articles posted in a sibling comment.

Reply on news.ycombinator.com