17 ms·

Static types in Python

• wyldfire 10y ago
  Type annotations and mypy are a great idea, sure. But IMO the low hanging fruit is from static analysis tools like pyflakes, prospector, bandit. Most projects don't even capitalize on these and your time is better spent remediating the findings from these and/or carving out the exceptions where necessary.
• krylon 10y ago
  I still think the way Common Lisp handled typing was very convenient: Typing was basically dynamic, but one could use static typing in specific places, and one could even tell the compiler if this was for speed or for safety. I like the idea of a hybrid type system where statically typed and dynamically typed parts coexist, OTOH, I can imagine it being difficult to implement.
  • bandrami 10y ago
    Lisp has an extremely strong type system for values (in fact every value is a structure that includes a tag that says its primary type) but zero type checking for variables (a variable can have as its symbol-value literally any value at any time), other than the type hints you provide (which by the spec the compiler is free to ignore). I think a lot of static type systems don't sufficiently appreciate that those are two different questions.
    • krylon 10y ago
      Somewhere on the Internet - I think on the c2.com wiki - there is a discussion on type systems that organizes them on two axes, static vs dynamic and strong vs weak. Static vs dynamic refers to how much the compiler/interpreter knows about the types being used before execution. Strong vs weak refers to how easy or difficult it is to subvert the type system, e.g. by casting pointers or using unions. That discussion was an eye-opener for me regarding type systems; to this day, I cringe when somebody calls, e.g. Python or Javascript a "typeless" languange.
      • paddyoloughlin 10y ago
        Strong vs weak is essentially meaningless. There is no generally agreed upon definition of what the distinction means.
        • kbenson 10y ago
          Just because there is some controversy over it doesn't mean it's meaningless. In this case it just means that it's not as descriptive as we would hope, and it's better used to describe as aspect of a language, as they are often strongly typed in some aspects and weakly typed in others.
          • jstimpfle 10y ago
            Bravo! So much hair-splitting and (deliberate?) misinterpretation of context on the internet. We need more counters done your way to keep discussions focused: Factual and to the point.
          • paddyoloughlin 10y ago
            First, my post said 'essentially meaningless', which is to say 'possibly not completely, but for the most part, meaningless'. Second, the context here is whether or not the type system of a language is strong or it is weak. I stand by my assertion that describing type systems as strong or weak typing is essentially meaningless. It's so far from descriptive that all 'strongly typed' ever really means is 'I like this feature' and 'weakly typed' means 'I do not like this feature'. There are alternative, accurate ways of talking about what people think they are trying to get at when they use the terms strong and weak in relation to languages. They should be used instead.
      • kbenson 10y ago
        This is a well known distinction, talked about in many places[1]. Python would be dynamic and strongly typed, Perl would be dynamic and weakly typed, at least WRT numerical and string types, which is why it uses different operators to distinguish between those types of operations (compared to Python's use of + for for numerical addition and string concatenation. Perl could also be said to be strongly typed WRT scalars and arrays, so it depends on your point of view. There is some controversy over the strong/weak terminology, IMO mostly because almost no language is clearly strong or weak based on the definitions generally used[2]. I find it useful to think about whether things are done implicity, or whether you need to specifically convert types. Perl will happily add "1" and "1" to get 2, because the + operator forces it to be interpreted as a numeric type. Python will not, and expects you to convert to a numeric type first. Of course, exceptions to the rule abound. 1: http://stackoverflow.com/questions/2351190/static-dynamic-vs-strong-weak http://stackoverflow.com/questions/2351190/static-dynamic-vs... 2: https://en.wikipedia.org/wiki/Strong_and_weak_typing https://en.wikipedia.org/wiki/Strong_and_weak_typing
    • hcarvalhoalves 10y ago
      > Lisp has an extremely strong type system for values (in fact every value is a structure that includes a tag that says its primary type) Out of curiosity: if I'm not mistaken, this was an implementation detail of LISP machines [1], and allowed bytecode-level optimizations. [1] https://en.wikipedia.org/wiki/Tagged_architecture https://en.wikipedia.org/wiki/Tagged_architecture
      • krylon 10y ago
        I vaguely remember reading that this did not originate on Lisp machines, but they supported this at the hardware level, making it a lot faster. (Like I said: "vaguely"! This is third- to fourth-hand knowledge, at best.)
  • junke 10y ago
    Agree. However: s/was/is/g s/could/can/g Premature burial is a little bit scary, I take it you are doing this because Halloween is near.
    • Roboprog 10y ago
      Languages never die. But companies stop making new projects with them - for some number of 9s percent of companies. E.g. - FOOGOLTRAN is a five-nine dead language, if 99.999% of new projects don't use it.
      • Roboprog 10y ago
        I guess as long as a language is used in at least 11% of projects, it can avoid being "one-nine" dead :-)
      • sillysaurus3 10y ago
        I like this definition of language deadness. It seems especially useful when restricted to one decade.
    • krylon 10y ago
      Thanks for the correction! ;-)
  • ddfisher 10y ago
    This is exactly what mypy allows, actually! (Except for speedups -- types currently have no effect on runtime behavior, and it turns out they wouldn't make a big difference anyway.) The hybrid type system concept is called "gradual typing", and it's actually powered by some somewhat-recent developments in programming language theory. See this seminal paper by Jeremy Siek in 2006 if you're interested in the details: http://scheme2006.cs.uchicago.edu/13-siek.pdf http://scheme2006.cs.uchicago.edu/13-siek.pdf [Source: I'm a mypy core developer.]
    • krylon 10y ago
      That sounds sweet! It's been a while since I did anything in Python (at work, for various reasons, I mostly use Perl when I can, C# when I have to). But the next time I do something with Python, I'll make sure to check it out!
• cozmo 10y ago
  This goes against everything that I learned about Python. Python does not check types by default and many functions and classes take advantage of this fact. Therefore, in a typical code base, you have some functions where you want to check types and some functions where you don't. Of course, you can now start putting in the checking code inside the functions that need it, but this is not good practice as there isn't a clear separation of concerns. I think tests and code should be kept separate and this kind of checking code should go inside unit tests, where it rightly belongs. You can always describe the intended behavior of the function in a docstring for people reading your codebase. But this docstring should not have other unintended behavior, like type checking. It simply isn't very Pythonic.
• tabbott 10y ago
  Original author here; I'm happy to answer any questions about the mypy experience!
  • tantalor 10y ago
    Why not put type annotations in docstrings?
    • tabbott 10y ago
      There's some discussion of this in PEP-484: https://www.python.org/dev/peps/pep-0484/#other-backwards-compatible-conventions https://www.python.org/dev/peps/pep-0484/#other-backwards-co....
  • thristian 10y ago
    Does Sphinx (or any other automated-documentation tool) read the MyPy annotations, or would I have to type them in twice, in different syntaxes, if I wanted types in my docs + linting? Or does type documentation not matter that much, once it's being enforced by a tool?
    • RubyPinch 10y ago
      there is at least this, others might also exist https://pypi.python.org/pypi/sphinx-autodoc-annotation https://pypi.python.org/pypi/sphinx-autodoc-annotation
  • muzakthings 10y ago
    Does mypy see any performance improvements over vanilla python (because types are static)?
    • detaro 10y ago
      No, the interpreters make no use of annotations.
• StavrosK 10y ago
  I am extremely excited about this. I already verify parts of my applications, but better support (especially in libraries) will make this that much more useful. It's an essential part of the checking pipeline (with pyflakes, pep8, McCabe, etc).
• CJefferson 10y ago
  I just tried taking the article's advice, and running mypy on some of my code (completely unannotated) to see what came up. Some interesting things have, already made 3 patches. One comment to the article author: Tell people how to install mypy. I started by trying 'pip install mypy', then wondered why I didn't end up with a mypy executable (you need pip3 install mypy-lang, mypy is an unrelated package).
  • tabbott 10y ago
    Thanks for pointing that out, fixed!
  • deleted 10y ago
    [deleted]
• snowoct 10y ago
  This goes against everything that I learned about Python. Python does not check types by default and many functions and classes take advantage of this fact. Therefore, in a typical code base, you have some functions where you want to check types and some functions where you don't. Of course, you can now start putting in the checking code inside the functions that need it, but this is not good practice as there isn't a clear separation of concerns. I think tests and code should be kept separate and this kind of checking code should go inside unit tests, where it rightly belongs. You can always describe the intended behavior of the function in a docstring for people reading your codebase. But this docstring should not have other unintended behavior, like type checking. It simply isn't very Pythonic.
• baq 10y ago
  i've been skeptical about mypy's usefulness. i'm absolutely thrilled to be proven wrong here. thanks for blazing the trail.
• weberc2 10y ago
  Why doesn't the import cycle trick work with the Python 3 syntax? This doc seems to suggest that it should: http://mypy.readthedocs.io/en/latest/common_issues.html#import-cycles http://mypy.readthedocs.io/en/latest/common_issues.html#impo...
  • ddfisher 10y ago
    It should work with the Python 3 syntax if you quote your type annotation. I.e. def f() -> "Bar": ... instead of def f() -> Bar: ... (This is normally used for forward references.) This makes it slightly less nice, but not a terrible workaround overall.
• scrollaway 10y ago
  > For the many programmers who work in large Python 2 codebases, the even more exciting news is that mypy has full support for type-checking Python 2 programs, scales to large Python codebases, and can substantially simplify the upgrade to Python 3. Woah! Excellent news. Really cool that they found a way to use this opportunity to bolster Python 3 migration.
• vegabook 10y ago
  ...and so we risk shuffling even further away from what made Python great. Simple pragmatism. Now in addition to unicode hair tearout, xrange forcefeed, dict access strait jacket, print function dogmatism, and extraneous unused async library which was already implemented 14x elsewhere, we are moving towards strictly typed Python?? If you want all this stuff, surely there is C, Ocaml, Go, or Typescript, etc, all of which are much faster?
  • protomikron 10y ago
    It is a common misconception that typing makes stuff more complicated and inconvenient. Some type systems are quiet bad (not powerful enough, so they do more harm than good), but that does not mean that the idea of typing itself is bad, but their implementation is. In my opinion Python kicks ass, because of world-class libraries for nearly anything, and not because it's dynamic (a broad term, I would say it's strongly typed) und you do not have to declare types (which can often be inferred). You listed 4 specific languages, but the following things are each inconvenient in them: - C: it's inconvenient to implement a quick prototype - Ocaml: it's inconvenient that the stdlib is so small - Go: it's inconvenient for scientific/numerical code - TypeScript: it's inconvenient to run server-side Obviously you can do everything in any language (Turing, blabla), but the question is, how much effort (time) does it cost. Python rocks in all of them (edit: the big exception being frontend webdev), in particular for quick prototyping. I think mypy is an exceptional and fine contribution to the eco-system and I really appreciate their effort.
    • llekn 10y ago
      Being in the middle of a struggle with Javascript tooling (Javascript, ES5 v/s ES6, typescript, webpack v/s System.js, shims, pollyfils, npm downloading the internet, etc, etc) I can't but imagine that there should be a better way. How much I would like Webassembly to be ready to open the gates to other languages on the frontend land. Anyone here has more information about webassembly / python on the browser? I would love to know what is the current state of the art of running python on the browser and contribute to make the dream come true. I have on my radar Brython [0], py.js [1](seems to be abandoned) and pypy.js [2] [0] http://www.brython.info/ http://www.brython.info/ [1] http://pyjs.org/ http://pyjs.org/ [2] http://pypyjs.org/ http://pypyjs.org/
• RodericDay 10y ago
  sum_and_stringify(nums: List[int]) -> str: This looks so bad. I think Python is making a big mistake with this. The commented version is much more acceptable.
  • zanny 10y ago
    Its basically the same syntax as Rust, which I honestly like. I mean, I didn't like the syntax to begin with (I have always been a stickler for how name: type introduces a superfluous colon over type name syntax) and using two glyphs for returns is horrible, but since several languages are now doing this, if you are going to do it, you might as well keep it consistent.
    • RodericDay 10y ago
      ddfisher up there is already talking about stuff like ---- It should work with the Python 3 syntax if you quote your type annotation. I.e. def f() -> "Bar": ... instead of def f() -> Bar: ... --- Yeah, you need to write `from typing import List` to get the generic List class that you can parameterize with an item type. As you pointed out, you can use the builtin lowercase-l list without importing anything, but that doesn't allow you to specify the item type. --- imo, this is brutal. I'll just wait and see whether I'm proven right or wrong, but the extremely poor aesthetics of the whole thing bode badly.
• sumitgt 10y ago
  This sort of reminds me of how TypeScript got started. Bracing to hear about TypePy in coming days :P
  • zo1 10y ago
    And what exactly do you think they would add to Python that is not already there?
• fuzzythinker 10y ago
  Don't see c/c++ target in the roadmap, which seems like an ideal use case for typed python besides correctness. Thoughts?
  • ddorian43 10y ago
    What ? You mean like export to c/c++ code? Isn't python too dynamic for that ?
    • fuzzythinker 10y ago
      I'll say python isn't any more dynamic than ruby and groovy, and they have fairly stable and usable static compile target release/ports [1]. Python has a few [2] attempts, but none of them is close to stable or really useful. [1] https://crystal-lang.org/ https://crystal-lang.org/ http://groovy-lang.org/releasenotes/groovy-2.0.html http://groovy-lang.org/releasenotes/groovy-2.0.html [2] https://github.com/shedskin/shedskin https://github.com/shedskin/shedskin https://github.com/codeblazer-io/blazescript https://github.com/codeblazer-io/blazescript https://github.com/serge-sans-paille/pythran https://github.com/serge-sans-paille/pythran
      • ddfisher 10y ago
        Don't forget Cython [1]! My understanding is that it's quite useable (though it unfortunately uses a different static type system/syntax than mypy). [1] http://cython.org/ http://cython.org/
        • fuzzythinker 10y ago
          Didn't forget it, just didn't include it since to me, it's more like a totally different (and not pretty) language that tries to look like python. I should however include Nuitka [1] since it is fairly usable, it's just the generated version isn't much faster than its interpreted python version. [1] http://nuitka.net/ http://nuitka.net/
          • 10y ago
• singularity2001 10y ago
  @OP(tabbott), you can add to "Benefits of using type annotations": Improves IDE integration, especially IntelliJ PyCharm's jump-to-source
• singularity2001 10y ago
  Sorry for posting this issue here: python3 type_annotations.py def sum_and_stringify(nums: List[int]) -> str: NameError: name 'List' is not defined EDIT: Solved: Either just list or List[int] with import: from typing import List Thanks for all the help guys! By the way I took the example from the mypy page. A classical case of 'critical line missing from example code' (as perfectioned by Bjarne Stroustrup back when)
  • ddorian43 10y ago
    I think you have to import that.
    • singularity2001 10y ago
      import List?? At least this works: def sum_and_stringify(nums: list) -> str:
      • dcre 10y ago
        The built-in constructor is `list`, not `List`.
        • singularity2001 10y ago
          Thanks for all the help guys! by the way I took the example from the mypy page def sum_and_stringify(nums: list[int]) -> str: TypeError: 'type' object is not subscriptable so either just list or List[int] with import, got it. A classical case of 'critical line missing from example code' (as perfectioned by Bjarne Stroustrup back when)
      • ddfisher 10y ago
        Yeah, you need to write `from typing import List` to get the generic List class that you can parameterize with an item type. As you pointed out, you can use the builtin lowercase-l list without importing anything, but that doesn't allow you to specify the item type.
      • 10y ago
• Roboprog 10y ago
  I am glad to see that this is optional. We need languages that mix compile/parse time (static) and run time (dynamic) types, to mix what fits best to each situation. Of course type checking can catch some problems. The more extremist elements of the static types proponents seldom seem to ask the cost of adding types, and making some otherwise generic/overloaded operations harder to implement (e.g. - excess clutter in some "wordy" type systems, particularly in the C lineage where declared identifier names follow the other verbiage). We need more tools that allow us to easily nail down fixed interfaces to avoid errors, but still allow flexible / dynamic / metaprogramming type code when needed, without having to jump through hoops in either case. Don't be a static typing extremist! (or throw the baby out with the bath-water, either, I guess)
  • jjnoakes 10y ago
    > Of course type checking can catch some problems. Keep in mind, static types can also help performance, tooling (refactoring, cross-referencing, etc) and human understanding. This is not an argument for or against static types; it is simply a longer list of what they can be useful for in the many situations.
    • Roboprog 10y ago
      Sorry to vent on you, specifically, but many people seem to have missed the point where I said I wanted them. I just don't want to be forced into a jail cell 100% of the time. I want an escape hatch to do the needful once in a while to do something that the language designer never planned for.
  • bjz_ 10y ago
    I dunno, I find static types to be a core design tool that are highly beneficial from the earliest stage of a project. They help you probe a problem space as you develop, and offload a great deal of cognitive burden to your tools. I actually find myself working a great deal slower on new dynamically typed projects because I have to juggle a great deal more context in my head, and am encumbered by larger test suites that are more difficult to change. Note that I am referring to type systems with succinct syntax, type inference, structural typing and ADTs.
• mixmastamyk 10y ago
  Nice, how come some of the type names are capitalized? When the builtins are lower-case? e.g.: List compared to list()
  • ddfisher 10y ago
    Good question! There are separate capitalized types for List, Dict, etc provided as part of the `typing` module in order to let you specify element types. Types are all normal Python expressions, so if you wrote `list[int]` you'd get a runtime error, because `type` objects (i.e. the `list` class) aren't subscriptable.
• clusmore 10y ago
  Honestly I haven't looked into MyPy a huge amount, and haven't used it yet. But from reading the docs on it I feel like it's taking the wrong approach. In my opinion, Python is all about duck typing, so having a static type checker that seems to focus on concrete types feels wrong to me. Consider the first example, def sum_and_stringify(nums: List[int]) -> str: return str(sum(nums)) The type here is way more specific than it needs to be. Not only will this work on any sequence type (anything that supports __iter__), the element type only needs to support __add__ and __radd__ (to work against the implicit seed value of sum). I really feel like in order to get the best of duck typing, you need a good syntax for describing types by usage, not by explicit name. Please let me know if I'm missing something, and this is actually more expressive than the documentation suggests.
  • dbcurtis 10y ago
    Well, I like to put that another way -- I think Python is all about protocols (in the Python sense of the word protocol). I think that is what most people mean when they say Python is all about duck typing, and it communicates the concept more precisely. The concept of 'type' is overloaded with too many meanings these days. It started out as a what-storage-to-allocate and which-instruction-to-generate (int v float) concept (FORTRAN I, variables starting with I..N are ints, others real). Deep class hierarchies muddied the waters by overlaying the idea of whether or not a class implements a particular property or method, and how to locate the property or method that you want. Python shows us that types and protocols/interfaces are two very different thing. In Python, asking 'isinstance()' is usually a bad idea unless you are doing something very low level, low level as in next stop is a C extension. The missing predicate in Python is 'hasprotocol()'. Abstract base classes can be used to accomplish that: isinstance(foo, SomeABC), but I think the intent could be more transparent with different syntax.
    • clusmore 10y ago
      Yeah I agree with you completely, I think we just use different terminology to describe the same thing. It sounds like you use "type" to mean "concrete type", i.e. the thing it actually is, and not the thing it acts like, and then "protocol/interface" to describe the behaviour, the thing we can use it as. As somebody who mostly uses statically-typed languages, I use "type" to mean "the thing my static type checker knows this as", which could be a concrete type or simply an interface, and then obviously I use the term "concrete type" when I need to be more explicit. I like the idea of a hasprotocol or supportsprotocol predicate, certainly over usage of isinstance, since one of the beauties of duck typing is that it works without requiring the type hierarchy. The tricky part will be in allowing you to define your own protocols, like "has these attributes/methods". An example would be the difference (or lack thereof) between classes and namedtuples.
• wyager 10y ago
  > It has a far lower false positive rate than the commercial static analyzers I’ve used! Hoo boy. That's not a good thing. A consistent type system doesn't have "false positives". Reading between the lines, this means "the type checker is incomplete and allows incorrect types." What is the story here with constraints, polymorphism, etc?
• Dowwie 10y ago
  Can someone point me to a live, public instance of Zulip that I can use to experience a real demo?
  • lima 10y ago
    https://zulip.tabbott.net/ https://zulip.tabbott.net/ It's amazing. Zulip is Slack done right. Their threading/light-weight topic approach is second to none.
• Animats 10y ago
  Optional static typing is fine. But this approach to it is not good. The correctness of the type information is optional. PEP 484: "While these annotations are available at runtime through the usual __annotations__ attribute, no type checking happens at runtime." (Italics in original) That's just not right. If you take that seriously, compilers can't use type information to optimize. It feels like Von Rossum is making life hard for the PyPy compiler project again. If they had hard type information, they could do serious optimizations. Guido's CPython still uses a CObject for everything internally, so it doesn't benefit much from this. The direction that everybody else seems to be taking is that function parameters, structure fields, and globals are typed, but local types are inferred as much as possible. C++ (with "auto"), Go, and Rust all take that route. Type information on function parameters and structure fields is an important item of documentation; if the language doesn't support that, you need to put it in separate documentation or comments. But writing elaborate type declarations for local variables is no fun, and the compiler can usually infer that info anyway.
  • zardeh 10y ago
    >It feels like Von Rossum is making life hard for the PyPy compiler project again. Or perhaps, he realizes that to require these typechecks at runtime would either - require a massive rewrite of the CPython interpreter - cause a performance penalty in code that is statically typed (there are pure python libraries that allow this, and yes your code runs slower) Further, it offers a relatively narrow amount of help to pypy, which has already come out and said that they have no interest in using annotations for efficiency gains, because they're a jit and they don't need them.
    • Animats 10y ago
      PyPy is written in RPython, which is Python with type annotations strict enough to allow hard precompilation to C. The type syntax is completely different from this new thing.[1] Only the built-in types are fully defined. There's "anytype", "sequence", and "object" to cover more general types without giving full details. This allows hard compilation of the stuff that compiles down to machine code, while dealing with user-defined object types more dynamically. That's one approach to typing Python. Von Rossum on PyPy (2016): "Otherwise, there are specialized versions of Python like PyPy that are still around." [1] https://bitbucket.org/pypy/pypy/src/default/rpython/translator/test/snippet.py?fileviewer=file-view-default https://bitbucket.org/pypy/pypy/src/default/rpython/translat...
• foxhop 10y ago
  The python 2.x "comment" version should have been parsed from the docstring...
• agentgt 10y ago
  Does PEP 484 plan to allow runtime reification of types (ie type information during runtime via reflection aka Java/C#)? I made a cursory check of it and it is unclear but I would assume no. I know some may disagree but I have found runtime reification of types fairly useful in the Java world (partly because Java does not have good code generators like OCaml/Haskell and partly because Java is not that expressive).
• jbritton 10y ago
  I wish PEP 484 put more thought into backward compatibility with Python2. Currently you need to import things like Callable, Tuple and these don't exist in Python2. It is especially odd since I am using MyPy comment syntax, so MyPy needs import statements even when all types are inside comments. I like the way Haskell puts type information above the definition.
  • price 10y ago
    In Python 2 and also in Python 3.4 and earlier, you get Callable, Tuple, and the rest from the `typing` module on PyPI: https://pypi.python.org/pypi/typing https://pypi.python.org/pypi/typing This is a direct backport of the same `typing` module that's in the stdlib starting in Python 3.5. (I'm one of the mypy core developers and work at Dropbox. We're using PEP 484 and mypy on a lot of Python 2 code!)
• meshko 10y ago
  Here's what I don't understand -- every discussion about static typing is full of people saying static typing is so good and useful. Everyone i talked to, everyone i work with, we all prefer static typing. And yet... Javascript and all that.
  • imtringued 10y ago
    Javascript runs in the browser natively. It's primary advantage is that you don't need to install anything other than the browser. The reasoning behind node.js is that a lot of front end engineers no longer need to learn and use a seperate language for the server and maybe even can reuse libraries between the server and browser. Javascript is the bash of the internet. It's not that great but it does have a "killerapp".
  • aikah 10y ago
    why do you think people are replacing Javascript with Typescript ? Ultimately, type resolution at compile time is better than an unmaintainble javascript.
• lyschoening 10y ago
  Mypy is great, but it still has some ways to go. For instance, the type checker is thrown off by descriptors (__get__ and __set__ are ignored). Further, the typing module needs some work. The types in the module are sufficient for annotating simple programs, but the more "meta" the programming becomes the more walls will pop up.
• aikah 10y ago
  Started to use python recently, coming from Go, I found: - the official docs are useless, return types are often not documented (wtf ?) and docs aren't structured and clean. Python documentation is a giant mess. - mypy is a god sent I used it from day one to document my Python code, but it needs better integration with python doc tools, 3rd party linters and co. I'm ok with optional type checking. A team can make it mandatory during continuous integration while not breaking legacy code, but I hope mypy will be directly integrated to Python in the future and not a 3rd party tool.
  • ubernostrum 10y ago
    Could you give some examples of functions in the standard library (or built-ins) which don't document their return types?
    • hawski 10y ago
      I sometimes have to write some python script. The documentation documents return (and expected) types, but in a manner that is a bit alien to C or C++ programmers. It is more talky. It is probably in dynamic nature of python. Instead of a list of possible returns with some kind of prototypes you may be left with description: "The returned object is always a file-like object whose file attribute is the underlying true file object.". See for example documentation for tempfile.NamedTemporaryFile [1]. This time possible returns are not in the separate paragraph as is in many other cases. You can't click anything expect TemporaryFile(), so you have to search for proper reference. The information is there, but instead of quick glance you have to parse and search more text. [1] https://docs.python.org/3.6/library/tempfile.html https://docs.python.org/3.6/library/tempfile.html
  • orf 10y ago
    The python3 docs are great, do you have any specific pages that you found issues with?
• whalesalad 10y ago
  It bothers me when the constructs of the language are not used for things like this. Example, the syntax for a list of ints is `List[int]` as opposed to `list(int)` where list is an actual fn in python and so it makes more sense. Obviously list(int) has far different meaning, but List is a totally foreign thing in Python. I think it makes sense for a DSL to remain as close to the parent as possible. Another example of this is most of the prismatic/schema-esque frameworks for python to do validation on datastructures. Instead of saying foo must be { "name": "String" } (where there is a framework-specific meaning behind the literal word "String") we should take advantage of the built-in types and say {"name": basestring}. End rant.
• vram22 10y ago
  Interesting. I had blogged about mypy here, a few years ago: https://jugad2.blogspot.in/2012/12/mypy-python-variant-with-goal-of.html https://jugad2.blogspot.in/2012/12/mypy-python-variant-with-... but had not tracked it much after that. Must check it out again.
• leshow 10y ago
  IMO adding static types is good step but it sort of misses the point of modern type systems. The good thing about types is not that you can just annotate (or not with good inference not) and validate that some type is what you expect it to be. It's that with a proper type system you can develop better abstractions.
• tofupup 10y ago
  neat