/
13.08.2020 at 10:00 am
Cuttings

Consenting Pythonic Adults

Do it Pythonically, preferably.

I've long chosen Python as my mother tongue, for these reasons:

  1. Openness. In Python, I can expose, modify or access virtually all properties/interfaces and protocols with ease. Iterators act intuitively, as well as in-built methods like len(). The syntactic sugars using or affecting them (e.g. via dataclasses and decorators/wrappers like functools.wraps) are clear and documented; moreover the motive for new features/modules can often be gleaned from historical and well-argued PEPs. Python's philosophy is one of consistency without restraints.

  2. Freedom from structure. Following the above, I'm free to write (if I wish) insanely tightly-coupled, low-cohesion code with numerous side effects first, and be allowed to come back and resolve that technical debt later when I have time. The language doesn't force me to think deeply in terms of private/public access, or about serious architectural or memory management concerns at the outset just to get something to work now (or be scared that I can't even dissect my code later), as I may be put to with Java or C. Yes, I should think deeply about those, but I may not want to. Python lets me do so.

  3. I'm a lawyer - more accurately, a litigator. In my line of work, we think of time on the order of days, weeks, months and years. Not seconds.

    In fact, even if the code could only process things within minutes or hours, that's perfectly acceptable. Ultra-performant code, optimization and Big O notation issues (and being too precious with shaving off seconds) aren't concerns directly relevant to my overall work, nor would it affect it much. Where I need to batch out things, Python's threading and concurrency libraries are good enough for most applications. I see no need to resort to specific concurrency-friendly languages like Go.

  4. Flexible types. I tend to be rigorous with parameters/returns and docstrings. And I'm very testing-driven, and do not want to change substantive code or write more tests than would be necessary. Python's type hints are flexible, and non-invasive. With PyCharm's superb linting/inspection and static analysis, it counterbalances duck typing's drawbacks enough without affecting its advantages.

  5. Agnostic paradigms. In Python, I can shift between programming styles - procedural, object-oriented or functional - with ease, for different code achieving different purposes. Compare this to the enforced paradigms of other languages, which could be useful for full-time professional programmers to learn, but provides little to no learning incentive (beyond intellectual curiosity) for full-time professional court advocates like me:

    ... Where your noodle really gets baked is when you jump paradigms:

    1. List based languages like Lisp or Tcl
    2. Logic based languages like Prolog
    3. Stack based languages like Forth
    4. Functional Programming Languages like Haskell and Elm
    6. Systems programming language with ZCA like Rust
    7. Hardware Description Languages like VHDL or Verilog

  6. Friendly to prototyping. When I read source code in other languages, I find them limiting for prototyping ideas - e.g strict typing/casting requirements, inherently-required design patterns (given a language's design/constraints) and an almost-necessary requirement for IDEs (given the verbosity of certain languages, like Java and C#).

    When sketching code and when my data structures aren't yet rigid or definite, I don't need more mental overhead. Consider this comment, from someone who has moved from Python to Java:

    1. Does no one trust each other?? Why must all goddamn properties of a class be private by default? I had gotten so used to the "consenting adults" paradigm of python that Java just felt patronising. Libraries tend to be incredibly narrow minded and impossible to extend. If the creators did not anticipate your use case then you are often SOL.

    2. Oh god the verbosity... I don't think you can code without a good IDE and expect to keep your sanity. Oftentimes 50% of my code is auto-generated.

    3. Having to learn "Design patterns" because certain easy tasks in python is an insanely complex framework of builders, factories and god knows what.

    4. Beginners can test fairly easily in python due to how easy it is to just monkey patch. Testing in Java takes a lot of learning in order to understand how to mock stuff correctly. And still you find yourself designing business logic in ways that is explicitly easier to test with no other benefit.

  7. Opiniated look. I like enforced indentations and snake_case. It makes code more consistent and readable for me. I prefer that look over curly brackets, semicolons and CamelCase - and the fact that indentations/snake_case are an expected and recognized / 'official' style of Python, makes digesting code an even quicker process, all the more so with autoformatters like Black being in vogue these days.

  8. Gigantic ecosystem. Python has such a vibrant ecosystem; if you can't code it, or don't have time to, someone likely would have packaged it. (Consider for instance, Wand and Imagemagick.) Python is also the supreme glue language; it wraps around interfaces with languages I don't work with or don't want to work with, with no real issues in most instances.

  9. IDE-optional. I love PyCharm, and use it tons. But even without it, I can fire up Sublime Text and immediately write productive, debugged, and readable code, thanks to Anaconda's auto-completion/jump-to/doc hints, SublimeREPL, and various packages/tools (e.g. SQL Tools, Text Pastry, Origami). Until I have to think about projects and package/module management and juggling sources, I don't want to have to launch a full-blown IDE. This IDE-optional approach may not be productive, if I had to resort to verbose languages, like Java/C#.

All the above, and a ton more things! I love Python.


Filed under:
#
#
Words: 959 words approx.
Time to read: 3.84 mins (at 250 wpm)
Keywords:
, , , , , , , , ,

Potentially related: Reflections - 43 Things I Learned or Did In 2019

Other suggested posts

  1. 03.07.2022 at 05:15 pm / The Unpreparedness Apology
  2. 02.07.2021 at 09:51 am / The Problem With New Tools
  3. 07.04.2021 at 12:00 am / Harangued Commitments
  4. 22.08.2020 at 05:49 pm / Decoding Code Specimens
  5. 14.01.2020 at 01:24 pm / Third Time's A Charm
  6. 14.12.2018 at 03:09 pm / Recursion, Succinctly Put
  7. 22.08.2018 at 02:13 pm / Heinrich Schliemann's Learning Method
  8. 03.01.2016 at 12:00 am / Creators And Their Gems (Polished or Otherwise)
  9. 12.06.2015 at 12:00 am / He Conquers Who Endures
© Wan Zafran. See disclaimer.