
Alice in Python projectland - dsr12
https://veekaybee.github.io/2017/09/26/python-packaging/
======
pmoriarty
Python's package management makes a mockery of the famous Zen of Python: _"
There should be one--and preferably only one--obvious way to do it."_

[https://en.wikipedia.org/wiki/Zen_of_Python](https://en.wikipedia.org/wiki/Zen_of_Python)

~~~
sigmonsays
There are two reasons I am not in favor of python. First and foremost its
packaging sucks.

I have wasted far too much time wrangling pythons packaging systems.
Incompatibilities between pip, setuputils, distutils, virtualenv, eggs, C
modules, and wheels I have literally given up. I love and use python but I no
longer package it and deploy it for others to consume. Try to package a
protobuf3/grpc system these days into a .deb, its a nightmare. Even the grpcio
devs use docker containers to build packages because python has such a
nightmare of a system.

I'll leave the second reason out for the sake of context

~~~
xapata
Do you think that's easier, harder, or about the same as Make, Maven, Rake,
etc.?

~~~
halostatue
Ruby has one packaging format that is essentially unchanged since 2004:
RubyGems. There have been improvements in making it easier to convert a gem to
a native package since then (even though I think that’s a fool’s errand), but
the fundamental packaging system hasn’t changed (although indexing and serving
has).

~~~
xapata
I'm not a Rubyist, but in my experience there are few Ruby packages with non-
Ruby dependencies. That makes packaging much easier.

------
thinkling
Funny to see the name Alice in the context of Python. Alice [1][2] is a
Python-based environment for creating animated, interactive 3D scenes, created
by Randy Pausch and his students. They picked python intentionally for its
simplicity at a time when it wasn't yet well known.

[1] [http://www.alice.org](http://www.alice.org) [2]
[https://en.m.wikipedia.org/wiki/Alice_(software)](https://en.m.wikipedia.org/wiki/Alice_\(software\))

~~~
neuronexmachina
Yep, playing around with Alice in the early 2000s was actually the first time
I ever encountered Python.

------
ainiriand
Very good article. It is really astounding the amount of work that needs to be
done in the python ecosystem!

~~~
monkmartinez
What do you mean by; "astounding the amount of work that needs to be done in
the python ecosystem!"?

Can you provide examples of different ecosystems that would compare favorably
in your opinion?

~~~
danharaj
I write both python and haskell for my day job. I think the latter has much
better project management when it's paired with Nix. Even without Nix,
stackage and even just dealing with Cabal is much easier than the mess in the
Python ecosystem.

~~~
marcosdumay
The stability of the Haskell ecosystem is something I just can not understand.

It's not enforced by policies, the tooling isn't much more helpful than in any
other language, and it is not more mature than any widely used ecosystem. It
feels like Haskell libraries just need less changes.

~~~
jdormit
(I've never seriously used Haskell) I wonder if the strong static typing has
something to do with that. That eliminates many if the common bugs found in
Python programs.

~~~
xapata
In my experience, type errors in Python get discovered during testing. So, I
doubt that's the reason.

Perhaps the nature of Haskell discourages changes, making the community more
stable.

~~~
yen223
> In my experience, type errors in Python get discovered during testing

That would be the optimistic view. In reality, `NoneType has no attribute Foo`
errors happen in production all the time.

~~~
xapata
Perhaps because someone got into the (bad) habit of returning Nones instead of
raising errors. Errors should never pass silently, etc. The older Python APIs
have that C habit of sentinel values, but more modern style is to raise an
error on failure.

~~~
yen223
Functions implicitly returns None if you forget to provide a return value on
any of the branches. This is an error that can easily slip past eyeball
reviews, since this is caused by the _absence_ of something.

~~~
xapata
Shouldn't unit tests be exploring all the code paths? I know that's tough to
enforce, but it's ideal. Regardless of whether you use a static analyzer.

And Python does have static analyzers, including for typing.

------
PleaseHelpMe
Very good writing indeed. However, the metaphor here gives me the feeling of
"enough internet today"... Btw, the anchor link to #project-structure don't
work. Hope you (if you are the author) fix that soon.

------
kd5bjo
In the refactoring section, it says:

    
    
      Note that if you don’t have if __name__ == '__main__',
      the code won’t run anything since the function is
      initialized but not executed
    

Isn't this backwards? That test isn't required to make the code run, it
prevents the code from running if the file _is imported as a module_.

~~~
cup-of-tea
Yeah, it's written slightly badly, but it means if you don't include that
_block_ then nothing will run. The way it's written makes it seem like using
the ifmain construct isn't optional, which isn't a terrible thing to teach.

------
flavor8
The "python hides the hurt" example isn't great. First, he's missing the
imports on the python side (which can be just as verbose as java imports).
Second, he's talking 10 lines of code in java (plus closing braces) vs 6 in
python, but with a little bit of tweaking you could easily drop 2 of those
lines in Java. Third, if you were to import guava or some other library that
makes handling files more streamlined, you could get to an equivalent number
of lines in the Java example.

~~~
jpeanuts
1\. The Python in that example requires no imports. 2\. I think the author
(Vicki) is a she.

------
tibbon
This was really helpful for me, someone who does Ruby most of the time. The
programming parts of Python aren't hard, but I'm simply unfamiliar with the
layout of things.

------
el3ctron
i learn about good practices testing some python cookiecutters where you can
find a lot of practical project clues :)

