3 ms·
The more TypeScript I write, the less I like Python. In a recent project that involved pulling some data from Hive via Pandas dataframes and merging it with dat
by seanp2k2 8y ago
The more TypeScript I write, the less I like Python. In a recent project that involved pulling some data from Hive via Pandas dataframes and merging it with data from a JSON REST API, then doing some calculations and stuffing that data into a different JSON REST API (with a totally different shape to the data), I kept running into little edge cases that Python forces you to handle explicitly vs Javascript just doing what you want. It also annoys me to an irrational degree that Python has "dicts" and not objects, "lists" and not arrays, KeyError everywhere, error looking up dict keys as ints (you can only look them up by str with no implicit type conversion), can't say "dict.keyname", have to do dict['keyname'] or usually dict.get('keyname') and handle things like dicts within dicts where you're not sure if keys exist even more verbosely, etc
example of something annoying that came up:
foo = [1,2,3]
bar = {'1': 1, '2': 2, '3': 3}
for i in foo:
print(bar.get(i))
What does it output? None x3. In order to get it to do the thing, I did something like this:
foo = [1,2,3]
bar = {'1': 1, '2': 2, '3': 3}
for i in foo:
str_i = str(i) # even more fun when this throws
print(bar.get(str_i))
I use python because most of my coworkers understand it and it has wide library + runtime support where I work, but it's definitely not my favorite thing to work with. Dynamic typing where types still matter and where the language is picky about implicit type conversions kind of sucks.
I also couldn't do:
foo = [1,2,3]
bar = {'1': 1, '2': 2, '3': 3}
for str(i) in foo:
print(bar.get(i))
Which was also eyeroll. Like, I get it, but...c'mon. Working with Pandas is also more or less learning another language, with the insanity that is df.T.whatever and df.loc[]:
df.loc[df['shield'] > 6, ['max_speed']]
I'm sure that someone will comment about how I'm an idiot and there's a much better way to do it, but given PEP20:
There should be one-- and preferably only one --obvious way to
do it. Although that way may not be obvious at first unless
you're Dutch.
I guess I'm not Dutch enough.
- xapata 8y ago> I guess I'm not Dutch enough. I could write an "obvious" fix for your example, but I expect that it'd be unsatisfactory, since the real problem likely has a different solution. It looks like you might want a little utility to transform key lookups to a standard. Web frameworks do stuff like that for mapping URLs to functions, to ignore case, etc. You might be interested in learning about the ``dict.__missing__`` magic method.
- bkad 8y agodicts are like Maps in JavaScript, so the type of a key matters. It enables usecases where your keys aren't always strings: >> bar = {1: "a", "1": "b"} >> bar[1] "a" >> bar["1"] "b"
- antod 8y agoSo, in a discussion where most complaints about Python are that it is dynamically typed (vs statically typed eg Java, Go, Rust etc) you're complaining that it is strongly typed (eg vs weakly typed eg Javascript)? I don't have a problem with that - it just seemed kinda incongruous in that context. I imagine the other critics would be even more unhappy about implicit type conversions.
- Franciscouzo 8y agoNo, the problem you had was not because of Python, but because of JavaScript, JavaScript's objects only let you put strings inside of object keys, and JSON inherited that, it would have been more sensible for bar to come from the API like this: bar = {1: 1, 2: 2, 3: 3}
- throwaway37585 8y agoWhy should it implicitly convert a number to a string? That's a common source of bugs. Explicit is definitely better. Why not just do the following? foo = [1,2,3] bar = {'1': 1, '2': 2, '3': 3} for i in foo: print(bar[str(i)])
- sime2009 8y agoI'm not familiar with Pandas but I'm guessing that its API is similar in style to numpy just by looking at the code snippet. I can't rule out that you might be an idiot, but it is not because you find that line of code confusing. The numpy API is horrific. Its abuse of operator overloading and undermining of expectations is shockingly awful. They should have just made a separate query language.