It depends. When identifying as a member of the Clojure community, 1️⃣. When identifying as Clojure programmer to non-Clojure people, 2️⃣.

As a beginner in Clojure: why? 🙂

Classic Clojure way of solving these issues: consult an etymological dictionary. https://www.etymonline.com/word/-ian#etymonline_v_34526 The entry is a little unclear, but look at the “Related Entries”: “algonquian amazonian antichristian apollonian…”

Whereas for “-ist” https://www.etymonline.com/search?q=-ist

“one who does or makes”, from Greek “-istes”, the agent-noun ending.

We've been over this, it's "clojocytes". As in, "the Java codebase was devoured by clojocytes".

Are individual clojocytes part of a superorgansim then?

The former makes me think "librarian". The latter makes me think "terrorist". So in other words, it depends on my current mood

Clojeur?

Call me old fashioned but how about Clojure Users?

This is what happens when a core is too stable. We spend our time endlessly debating how to refer to ourselves 😆

what about Clojurusts?)))

That’s true. However, most of the Clojure core is written to support nil as arguments where as that’s not really the case in Python.

(:pizza {}) => nil but in Python {}['pizza'] raises a KeyError.

maybe make two variants, one which raises an error and another which returns None?

I think it depends mostly on what you want out of it yourself 🙂

That’s a solid option 🙂 I just thought it was an interesting discussion topic since you have to think if it’s better to be consistent with Clojure or be Pythonic where it makes sense.

if you market the library as clojure core functions for Python, then I would stick to the Clojure idioms

Clojure also has the not-found arity

so by default you get nil (useful for conditions) but allows you to distinguish nil vs not-found when needed

it might be also be worth looking at https://github.com/appliedsciencestudio/js-interop which does the same for JS

for Clojure's "open maps" philosophy, error does not make sense

What does “open maps” mean? My guess is that they may have less or more than expected keys?

Doesn't python have a .get? I would copy those semantics

it means the set of keys is not fixed - all maps may have missed attributes or extra attributes. so failing to find an attribute isn't an error, it's just that attribute isn't present and so you get nil

even records in Clojure, while having a fixed set of known attributes, can carry extra attributes

although taking away required keys is considered breakage, and adding keys is always compatible

@U09LZR36F Yes, Python has a .get on dictionaries which take an optional second argument as an optional value. But here is an opportunity to move things in a data-driven, functional-programming inspired direction. Especially since it should support lists and dictionaries. I hope people understand my hesitation in how clojure vs pythonic I should go with this. I am trying to think through the consequences of both approaches.

Also, for context, this is not a Clojure inspired library for Python. Only a util function in the codebase at work. While the idea of such a library is appealing, I am concerned I would likely misrepresent Clojure.

@jayzawrotny I guess it’s in the same vein as js-interop which I already mentioned?

@U04V15CAJ That’s correct. This just reminded me that in Pyton {}[‘pizza’] => KeyError but {}.get(‘pizza’) => None.

Ok, now I see more value in dominicm and borkdude’s points. It should probably behave more like .get and not throw an error. If needed I could wrap it in another function like get_in_or_error to throw. Much easier to go this way than the other way.

Thanks so much for helping me think through this. You never know the implications of “I’ll just do it like Clojure” for long term maintenance and stability for other languages.