News for hackers. Stuff that matters.
Re:The state of type hints in Python by seanp2k2 on Wednesday June 20, 2018 @08:59PM (#17361223)
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.
Re:The state of type hints in Python by antod on Wednesday June 20, 2018 @09:37PM (#17361368)
So, 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.

Re:The state of type hints in Python by bkad on Wednesday June 20, 2018 @09:37PM (#17361365)
dicts 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"
Re:The state of type hints in Python by sime2009 on Thursday June 21, 2018 @04:29AM (#17363163)
I'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.
Re:The state of type hints in Python by throwaway37585 on Wednesday June 20, 2018 @10:05PM (#17361498)
Why 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)])
Re:The state of type hints in Python by xapata on Wednesday June 20, 2018 @09:16PM (#17361281)
> 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.

Re:The state of type hints in Python by Franciscouzo on Wednesday June 20, 2018 @09:52PM (#17361440)
No, 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}