Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open-sourcing MonkeyType – Let your Python code type-hint itself

engineering.instagram.com

Post reply on HN
Print view View original

231–237 of 237 posts

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#231

Post by joshuamorton »

tigershark wrote: post #200
aub3bhat wrote: post #107

Earlier quoted context omitted.

Please show me C++ equivalent of sorted([(k.weight, k.name) for k in somelist], reverse=True)

No idea about C++ but in C# seems quite more readable (and flexible) someList.OrderByDescending(x => x.weight).ThenByDescending(x => x.Name); It's quite similar to expressing the concept in English, certainly more than using list comprehension in Python. And how would you order it in Python by ascending on the first field and descending on the second using list comprehension?

That's not the same thing, you've sorted a list of objects, we're looking for a list of tuples of `weight, name`)

In answer to your question though,

    sorted(((k.weight, k.name) for k in some_list), key=lambda x: (-x[0], x[1]), reverse=True)
appears to work. This does use a non-obvious trick, but being more explicit is a smidge difficult, since the key function is called only n times, as opposed to O(nlogn) in the C# example.

Alternatively, you can use

    sorted(sorted(((k.weight, k.name) for k in some_list), key=lambda x: x[1], reverse=True), key=x[0])
Which is more like the original example, and if you're doing it in place, you get

    outs = [k.weight, k.name) for k in some_list]
    outs.sort(key=lambda x: x[1], reverse=True)
    outs.sort(key=lambda x: x[0])
Python's builtin sort is timsort, so despite sorting the list twice, this will still run in approximately NlogN comparisons, not 2NlogN.

You could also manually define a custom comparator, ie

   lambda s, o: (s[0] > o[0] * 10 + s[1]
and pass it to `functools.cmp_to_key`.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#232

Post by AlexCoventry »

user5994461 wrote: post #224
AlexCoventry wrote: post #129

Earlier quoted context omitted.

Sounds like the projects you worked on had excellent encapsulation.

I wouldn't say excellent encapsulation. It's just normal to use sub directories to split things. The project was over ten millions lines of python.

Subdirectory structure is sort of orthogonal to the issue of encapsulation. It's more about providing API's and clean abstractions which prevent incidental interactions between implementation details across module boundaries.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#233

Post by krotton »

outsideoflife wrote: post #186
blub wrote: post #174

Earlier quoted context omitted.

I'm not claiming that one can't be successful by using Python (or pretty much any programming language). Market success or user count are unfortunately not tightly correlated with technical excellence, as many of us have bitterly found out. Development speed, maintainability, error count are also important development issues. Unfortunately we don't have much data to judge, but the little that we have such as this art…

> Market success or user count are unfortunately not tightly correlated with technical excellence, as many of us have bitterly found out It depends on how you define technical excellence. I would suggest a low memory usage might get you a thumbs up from HN, but isn't real technical excellence the ability to solve users problems?

Nope. Publishing an offer on Craigslist to help with homework via Skype is solving some users' problems, yet has nothing to do with "technical excellence".

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#234

Post by Traveler42 »

ambivalence wrote: post #45
sbuccini wrote: post #12

Earlier quoted context omitted.

I'd also like to hear more about this -- both the feature set and the development process. It's interesting that two large engineering organizations responsible for some of the most popular applications on the planet spent hundreds of engineering hours building almost the same exact tool at around the exact same time. I'd also like to know how much quicker or better it could have been completed if it had been done ou…

The idea to gather types at runtime is as old as PEP 484. The Dropbox and Facebook teams working on Python type checking know each other. We both worked on our implementations independently since we wanted to first test internally whether the idea holds water. For example, I personally thought it wouldn't be as useful in practice as it turned out to be! We knew we're going to open-source each others' implementations,…

Even though MonkeyType is focused on Python 3, can the .pyi files be used with Python 2?

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#235

Post by sidlls »

jsjohnst wrote: post #137
sidlls wrote: post #112

Earlier quoted context omitted.

There's nothing here that tunes down the dynamism. Hints aren't statically checked or enforced. It's still possible to pass in an empty list to an int-hinted var and, e.g. have `if not var` evaluate to True (rather than raise an Exception). Type hints allow external tools to check some things, but at this point you're basically imposing static types so why not use a language with the tooling and optimizations to take…

> Beyond that its utility diminishes until it starts to become a hindrance. Tell that to any serious Numpy/Scipy/Pandas user.

Being the lead on a data science team I am one of those. They're great for exploratory research and prototyping, and for use in the very tiny fraction of code in a production system that deals with machine learning if I must. For everything else, from the data pipeline to delivering results, I'd prefer and recommend something else, like Haskell, C++, go or Rust.

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#236

Post by andybak »

walrus1066 wrote: post #179
andybak wrote: post #166

Earlier quoted context omitted.

> Second, you can't reliable do things like "find usages" or "go to definition" because of the dynamic typing. In my experience PyCharm can do both correctly for the vast majority of cases.

Still very limited, for example, if I have: def some_func(foo): foo.run() ... Find usages in the run() method will return dozens of results, the IDE can't help you any more, to find what 'foo' is at runtime.

Isn't that basically saying "it fails in the kind of cases that wouldn't even be possible in a statically typed language"?

Re: Open-sourcing MonkeyType – Let your Python code type-hint itself

#237

Post by blub »

ubernostrum wrote: post #213
blub wrote: post #176

Earlier quoted context omitted.

It doesn't correlate with success, but the choice of language does correlate with development speed, number of faults, maintainability, etc. The interesting thing to note is that a language that's perfectly acceptable at the above at small or medium scale might turn into a hindrance at large-scale. An otherwise fast to develop in language like Python won't be so fast if every change has to be painstakingly reviewed a…

won't be so fast if every change has to be painstakingly reviewed and tested due to the complexity of interactions in the code base You can write spaghetti code in any language, it turns out. Blaming the language for that is not really an indicator of understanding the problem.

Yes one can do a poor job in pretty much any situation, I'm afraid that's not an argument for anything though.

Here we're talking about average or best-effort: large code bases are complex in spite of the best intentions of their maintainers, so using tools that can manage that conplexity in an easier way through e.g their type systems could lead to better results.

Post reply on HN