I’m in the #python IRC channel on Freenode a lot. The people there are often quite opinionated. Julian had the idea of processing the logs to see what we thought was good, and what was bad, using sophisticated sentiment analysis.

Finding out what I liked and didn’t like wasn’t hard, since the “sophisticated sentiment analysis” was two regexes: “<nedbat>.* is good” and “<nedbat>.* is bad”!

Without further commentary, here is a sampling of things that I said were bad:

• vertical alignment is bad because it means you might have to change many lines just because one of them got wider.
• eval(input()) is bad.
• blindly following stuff is bad.
• trolling is bad. Find a way to use your brains for good.
• floats for currency is bad.
• any class that you can only instantiate once is bad.
• that sounds like a singleton, which is bad.
• some people say, “you should start by learning assembler,” and i think that is bad advice.
• del is fine. __del__ is bad
• implicit copying is bad
• texture (repetition you can see when you squint) is bad in code
• aligning indents with the opening delimiter is bad.
• this is bad: def main(nums=[1,2,3]).
• monkeypatching is bad
• it is bad to modify a list you are iterating.
• __import__ is bad
• import * is bad stuff
• the python doc search is bad
• and-or is bad
• singletons are hidden global state, and global state is bad
• checking types is bad
• that “:type myparam:” syntax is bad, it’s not readable. use google style instead: https://www.sphinx-doc.org/en/master/usage/extensions/napoleon.html#google-vs-numpy
• python is bad at recursion deeper than 1000
• there is a package on pypi called time, which is bad.

And here are some things I said were good:

• “python -m app_name” is good, but recent.
• endswith is good
• xpath is good at selecting nodes in an xml dom tree.
• recursion is good for recursive structures. Iteration is good for iterative structures
• madlibs is good because you can do string manipulation with puerile humor
• learning is good! :)
• python is good for full applications.
• re.sub is good.
• mock(spec=thing) is good
• excitement is good :)
• pip will know how to install into virtualenvs, which is good.
• gist.github.com is good
• argparse is good for simple things
• it is good to cover your tests, though others disagree with me
• textwrap.dedent is good
• requirements.txt is good for recreating environments.
• the csv module is good at writing out dicts as rows.
• this is good for seeing how rst will be formatted: http://rst.ninjs.org/
• colorama is good
• yaml is good
• setUp is good. tearDown is better done as addCleanup
• yield from is good for when you want one generator to produce all the values from another generator.
• duck typing is good when there’s an operation supported across a number of types, and you can just use the operation without worrying about the type.
• learning is good! :)
• Django is good if you like having lots of things handled for you. Flask is good if you like to put together all the pieces yourself.
• tox is good for testing against multiple environments
• for validating email addresses, this is good: [^@ ]+@[^@ ]+\.[^@ ]+ https://nedbatchelder.com/blog/200908/humane_email_validation.html
• the python.org tutorial is good if you have programmed in other languages before.
• “pip install -e .” is good
• the interactive interpreter is good for experimentation, but isn’t good for real development.
• bpaste.net is good
• Think Python is good
• atexit is good.
• python is good, and we are helpful and friendly :)
• pandas is good if you need to manipulate tables of data. If you don’t, then don’t use pandas
• you want to do something for each thing in a list, that’s what a for loop is good for :)
• there’s an old habit of using “:type:blah:” or whatever, which is horrible. Sphinx now supports the “napoleon” style natively, which is good: http://www.sphinx-doc.org/en/1.4.8/ext/napoleon.html
• pytest does cool assert rewriting, which 99.9999% of the time is good magic.
• pudb is good in the terminal
• trying to be efficient is good.
• sql is good for some kinds of data. nosql is good for others.
• .format is good
• a decorator is good for wrapping functions in new functionality.
• the pytest -k option is good at that.
• i would not try to jam everything into setup.py. this feels like something a makefile is good at.
• pytest is good at parameterized tests.
• “if not list:” is good python
• @classmethod is good for alternate constructors, yes.
• rg is good: https://github.com/BurntSushi/ripgrep
• the prompt is good for doing small experiments. Once you have larger programs, put them in .py files, and run them: python myprog.py
• low tech is good tech
• Learning is good.
• numpy is good when you can do whole-matrix operations at once. If you need to iterate over elements and do individual operations, it doesn’t provide any benefit.
• any is good when you have an iterable of true/false
• choice is good. Why should there be only one implementation?
• gist.github.com is good, or paste.pound-python.org
• click is good
• you’re not using a shell, which is good.
• whatever helps you learn is good
• numpy is good when you are doing matrix and array operations. lists are good for ordered collections of things
• obfuscation isn’t something Python is good at.
• the ast module is good for one thing: representing python programs as a tree of nodes. It provides tools for parsing source text into that tree.
• python is good as a first language
• isolation is good, but doing it with mocks can be a problem in itself
• subclassing is good for when SubClass, by its essence is a ParentClass.
• talking is good :)
• coverage.py is good.
• recursion is good for recursive structures (trees). iteration is better for linear structures (lists)
• Jupyter is good for visualizations, graphing, tables, etc. interactive experimentation
• lxml.html is good
• sha256 is good too
• Fluent Python is good, if you like books
• for speed, PyPy is good. Or Cython. if you want to write C code, you can use cffi to call it from Python
• curiosity is good
• collections.Counter is good at counting things, and would do this in O(N).
• .encode makes the conversion explicit, which is good. my_bytes = my_unicode.encode(“utf8”)
• they is good.
• pudb is good
• in python 3, super() is good, but it doesn’t work in python 2.
• the -k option is good for this, or you can define markers.
• virtualenv is good for separating different projects’ needs
• tig is good too
• rst is good at multi-page docs, without assuming it will be html. markdown just shrugs and says, “use html when you have to”
• writing is good just for its own sake.
• bpaste.net is good.
• learning is good
• dependencies are good. using other people’s solutions to your problems is good.
• split has a much better PR agency, but partition is good too
• attribute access is good.
• i won’t say that loops should introduce scopes, but it is good to be able to understand the interplay between scoping and closur-ing
• https://pypi.org/project/appdirs/ is good for answering that question
• automate the boring stuff is good. What kind of software will you be writing?
• iso8601 is good
• prompt_toolkit is good
• numpy is good when you have an array full of data, and you can do one operation that works on all of it at once