Mailman 3 August 2014 - Python-ideas

Re: [Python-ideas] Proposal: Use mypy syntax for function annotations
by Sunjay Varma Aug. 16, 2014

Aug. 16, 2014

I am strongly opposed to this entire proposal. As Juancarlo points out, Python programs are small, but very understandable. I think this syntax detracts from that. I'll suggest an alternative further down in my reply. One benefit of Python that makes it so attractive for new programmers and even old programmers alike is that you can usually pick out any piece of Python code and begin to understand it immediately. Even if you come from a different programming language, Python is written in english explicitly using words like "and" and "or". Those constructs, as opposed to "&&" or "||" make the language less scary for new developers and in general easier to read as well. It's also easier to type regular english words (no need to use the shift key). Using the annotation syntax this heavily will detract very much from the readability of Python and from the overall usability as well. Programs are read more times than they are written. Several years ago, before I had any programming experience in any language at all, I needed to edit some Python code to make something I was doing work. Without any experience at all, I was able to look through the (small) program I was editing and figure out exactly what I needed to adjust. Without Python being such a clean, almost English language, that would have been impossible. Though the annotation syntax is already present in Python 3, I would argue that using this for type annotations will get very messy very quickly. If I'm understanding the syntax correctly, writing any function using a large library with many nested subpackages could result in code like this: import twisted.protocols.mice.mouseman def process_mouseman(inputMouseMan: twisted.protocols.mice.mouseman.MouseMan) -> twisted.protocols.mice.mouseman.MouseMan: pass That function definition is 122 characters long. Far more than what PEP8 recommends. Though this example was crafted to illustrate my point (I don't think most people would really write code like this), it is easy to see that this kind of code is possible and may sometimes be written by some less experienced programmers. It demonstrates how messy things can get even with just one parameter. It is also easy to see that it is very difficult to parse out what is going on in that function. Adding type annotations inline makes it very difficult to quickly get an idea of what arguments a function takes and in what order. It detracts from the overall readability of a program and can also lead to very poorly formatted programs that break the guidelines in PEP8. Though I have only demonstrated this for function declarations, the example could also be extended to inline statement comments as well. Things get too messy too quickly. My Alternative Proposal: As an alternative, I would like to propose a syntax that Pycharm already supports: http://www.jetbrains.com/pycharm/webhelp/using-docstrings-to-specify-types.… Since this type information isn't going to be used at runtime in the regular Python interpreter anyway, why not have it in the function docstring instead? This provides both readability and type checking. Standardizing that syntax or at least adding it as an optional way to check your program would in my opinion be a much better addition to the language. This approach needs no new syntax, keeps readability and allows the programmer to add additional documentation without going over the 80 character limit. Additionally, this approach can be used by documentation generators as well and removes any duplication from the function declaration and the docstring. Here's a taste of what that looks like: class SimpleEquation(object): def demo(self, a, b, c): """ This function returns the product of a, b and c @type self: SimpleEquation :param a: int - The first number :param b: int :param c: int - The third number should not be zero and should also only be -1 if you enjoy carrots (this comment spans 2 lines) :return: int """ return a * b * c Overall, I think overloading function declarations and inline comments is a bad idea. It promotes writing code with poor readability and in general adds a lot of extra bits to the language that (from the sounds of your proposal) aren't even going to be used by the main interpreter. On the original proposal: These changes really do seem to be overestimating the staticness of Python programs as well. What about functions that don't care about the type? What about functions that only want you to pass in an object that implements __iter__? Python should not become a language where developers are required to add hundreds of odd cast() calls every time they choose to pass a different, but still compatible type, to a function. This syntax makes too many assumptions about what developers know about their code. What if I develop a similar, but different class that is compatible with an existing function? If that function doesn't specify that my class can be used, my perfectly valid code will be rejected. -1 to adding mypy annotations to Python 3. Sunjay On Thu, Aug 14, 2014 at 10:59 AM, Juancarlo Añez <apalala(a)gmail.com> wrote: > > On Wed, Aug 13, 2014 at 3:14 PM, Guido van Rossum <guido(a)python.org> > wrote: > >> I am proposing that we adopt whatever mypy uses here, keeping discussion >> of the details (mostly) out of the PEP. The goal is to make it possible to >> add type checking annotations to 3rd party modules (and even to the stdlib) >> while allowing unaltered execution of the program by the (unmodified) >> Python 3.5 interpreter. > > > To the bottom of things... > > About the second time I wrote about Python ("Why not Python", 2007) I > dismissed it as serious software development environment because the lack > of static type checking hindered the creation of proper software > development environments. > > http://blog.neogeny.org/why-not-python.html > > So, Why do I now have doubts about adding support for static type checking? > > I've been programming in almost-only Python for several years now, and > this discussion had me think hard about "Why?". > > The answer is simple: I never was as productive as I've been since I've > centered on Python. > > But, again Why? > > Despite what my '07 article says, the IDE I use is pythonized-VIM and the > command line. Where does the productivity come from? > > 1. Readability with the right amount of succinctness. Python programs > are very small, but understandable. > 2. The breadth and design consistency of the standard library. Some > 70%? of what I need is there, and the design consistency makes it easy > (intiutive) to use. > 3. PyPi covers another 28%. > 4. The Zen of Python (import this) permeates all of the above, > including most third-party packages. The ecosystem is consistent too. It's > a culture. > > What do I fear? I think it is that Python be transformed into a > programming language different from the one that now makes me so productive. > > I studied Ruby, and I don't like it. I've been studying Go, and I don't > like it. One must like the concepts and the power, sure, but the syntax > required for some day-to-day stuff stinks like trouble; simple stuff is so > complicated to express and so easy to get wrong... > > I hate "List[str]" and "Dict[str:int]". Where did those come from? > Shouldn't they (as others have proposed) be "[str]" and "{str:int}"? What > about tuples? > Why not write a similar, but different programming language that targets > the Cython runtime and includes all the desired features? > > All said, this is my proposal. > > The PSF could support (even fund) MyPy and similar projects, promoting > their maturity and their convergence. The changes in 3.5 would be limited > but enough to enable those efforts, and those of the several IDE > tool-smiths (changes in annotations, and maybe in ABCs). Basically, treat > MyPy as PyPy or NumPy (which got '::'). It's in Python's history to enable > third-party developments and then adopt what's mature or become the > de-facto standard. > Then, on a separate line of work, it would be good to think about how to > enable different programming languages to target the CPython environment > (because of #2, #3, and #4 above), maybe by improving AST creation and > AST-to-bytecode? There could be other languages targeting the CPython > runtime, which is the relationship that Scala, Jython, IronPython, and > others have to their own runtimes. > > -1 for standardizing static type checking in 3.5 > > Cheers, > > -- > Juancarlo *Añez* > > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Sunjay Varma Python Programmer & Web Developer www.sunjay.ca

16 29

generic code and dependent types
by Neal Becker Aug. 16, 2014

Aug. 16, 2014

I'm interested in the proposals for adding type annotation. Coming from some experience with generic code in c++, one of the difficult issues has been reasoning about dependent types in generic code. In general, we need to be able to declare a type via an arbitrary metafunction some_metafunction<T>::type F (... It is also useful to be able to write something like: typedef typeof (int() * float()) my_type; I wonder if any of the proposals will be able to handle this sort of algebra on types? I think it's needed to truly support generic code.

5 7

Re: [Python-ideas] Python-ideas Digest, Vol 93, Issue 31
by Tin Tvrtković Aug. 15, 2014

Aug. 15, 2014

Hi, I realize I'm very late to the party, but just in the interest of completeness I thought I'd mention Typed Clojure (http://typedclojure.org/), which is an effort to add optional typing to Clojure. It has even had a successful crowdfunding campaign: https://www.indiegogo.com/projects/typed-clojure. I haven't had an opportunity of using it yet so this is all I know. P.S. Very excited about this effort! > Date: Wed, 13 Aug 2014 12:44:21 -0700 > From: Guido van Rossum <guido(a)python.org> > To: Python-Ideas <python-ideas(a)python.org> > Cc: Jukka Lehtosalo <jlehtosalo(a)gmail.com>, Bob Ippolito > <bob(a)redivi.com> > Subject: [Python-ideas] Proposal: Use mypy syntax for function > annotations > Message-ID: > < > CAP7+vJ+HouBUzaATiFnqGDT4WX99qt4k8X4jaT4T+RLuOO9Deg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > [There is no TL;DR other than the subject line. Please read the whole thing > before replying. I do have an appendix with some motivations for adding > type annotations at the end.] > > Yesterday afternoon I had an inspiring conversation with Bob Ippolito (man > of many trades, author of simplejson) and Jukka Lehtosalo (author of mypy: > http://mypy-lang.org/). Bob gave a talk at EuroPython about what Python > can > learn from Haskell (and other languages); yesterday he gave the same talk > at Dropbox. The talk is online ( > https://ep2014.europython.eu/en/schedule/sessions/121/) and in broad > strokes comes down to three suggestions: > > (a) Python should adopt mypy's syntax for function annotations > (b) Python's use of mutabe containers by default is wrong > (c) Python should adopt some kind of Abstract Data Types > > Proposals (b) and (c) don't feel particularly actionable (if you disagree > please start a new thread, I'd be happy to discuss these further if there's > interest) but proposal (a) feels right to me. > > So what is mypy? It is a static type checker for Python written by Jukka > for his Ph.D. thesis. The basic idea is that you add type annotations to > your program using some custom syntax, and when running your program using > the mypy interpreter, type errors will be found during compilation (i.e., > before the program starts running). > > The clever thing here is that the custom syntax is actually valid Python 3, > using (mostly) function annotations: your annotated program will still run > with the regular Python 3 interpreter. In the latter case there will be no > type checking, and no runtime overhead, except to evaluate the function > annotations (which are evaluated at function definition time but don't have > any effect when the function is called). > > In fact, it is probably more useful to think of mypy as a heavy-duty linter > than as a compiler or interpreter; leave the type checking to mypy, and the > execution to Python. It is easy to integrate mypy into a continuous > integration setup, for example. > > To read up on mypy's annotation syntax, please see the mypy-lang.org > website. Here's just one complete example, to give a flavor: > > from typing import List, Dict > > def word_count(input: List[str]) -> Dict[str, int]: > result = {} #type: Dict[str, int] > for line in input: > for word in line.split(): > result[word] = result.get(word, 0) + 1 > return result > > Note that the #type: comment is part of the mypy syntax; mypy uses comments > to declare types in situations where no syntax is available -- although > this particular line could also be written as follows: > > result = Dict[str, int]() > > Either way the entire function is syntactically valid Python 3, and a > suitable implementation of typing.py (containing class definitions for List > and Dict, for example) can be written to make the program run correctly. > One is provided as part of the mypy project. > > I should add that many of mypy's syntactic choices aren't actually new. The > basis of many of its ideas go back at least a decade: I blogged about this > topic in 2004 (http://www.artima.com/weblogs/viewpost.jsp?thread=85551 -- > see also the two followup posts linked from the top there). > > I'll emphasize once more that mypy's type checking happens in a separate > pass: no type checking happens at run time (other than what the interpreter > already does, like raising TypeError on expressions like 1+"1"). > > There's a lot to this proposal, but I think it's possible to get a PEP > written, accepted and implemented in time for Python 3.5, if people are > supportive. I'll go briefly over some of the action items. > > *(1) A change of direction for function annotations* > > PEP 3107 <http://legacy.python.org/dev/peps/pep-3107/>, which introduced > function annotations, is intentional non-committal about how function > annotations should be used. It lists a number of use cases, including but > not limited to type checking. It also mentions some rejected proposals that > would have standardized either a syntax for indicating types and/or a way > for multiple frameworks to attach different annotations to the same > function. AFAIK in practice there is little use of function annotations in > mainstream code, and I propose a conscious change of course here by stating > that annotations should be used to indicate types and to propose a standard > notation for them. > > (We may have to have some backwards compatibility provision to avoid > breaking code that currently uses annotations for some other purpose. > Fortunately the only issue, at least initially, will be that when running > mypy to type check such code it will produce complaints about the > annotations; it will not affect how such code is executed by the Python > interpreter. Nevertheless, it would be good to deprecate such alternative > uses of annotations.) > > *(2) A specification for what to add to Python 3.5* > > There needs to be at least a rough consensus on the syntax for annotations, > and the syntax must cover a large enough set of use cases to be useful. > Mypy is still under development, and some of its features are still > evolving (e.g. unions were only added a few weeks ago). It would be > possible to argue endlessly about details of the notation, e.g. whether to > use 'list' or 'List', what either of those means (is a duck-typed list-like > type acceptable?) or how to declare and use type variables, and what to do > with functions that have no annotations at all (mypy currently skips those > completely). > > I am proposing that we adopt whatever mypy uses here, keeping discussion of > the details (mostly) out of the PEP. The goal is to make it possible to add > type checking annotations to 3rd party modules (and even to the stdlib) > while allowing unaltered execution of the program by the (unmodified) > Python 3.5 interpreter. The actual type checker will not be integrated with > the Python interpreter, and it will not be checked into the CPython > repository. The only thing that needs to be added to the stdlib is a copy > of mypy's typing.py module. This module defines several dozen new classes > (and a few decorators and other helpers) that can be used in expressing > argument types. If you want to type-check your code you have to download > and install mypy and run it separately. > > The curious thing here is that while standardizing a syntax for type > annotations, we technically still won't be adopting standard rules for type > checking. This is intentional. First of all, fully specifying all the type > checking rules would make for a really long and boring PEP (a much better > specification would probably be the mypy source code). Second, I think it's > fine if the type checking algorithm evolves over time, or if variations > emerge. The worst that can happen is that you consider your code correct > but mypy disagrees; your code will still run. > > That said, I don't want to *completely* leave out any specification. I want > the contents of the typing.py module to be specified in the PEP, so that it > can be used with confidence. But whether mypy will complain about your > particular form of duck typing doesn't have to be specified by the PEP. > Perhaps as mypy evolves it will take options to tell it how to handle > certain edge cases. Forks of mypy (or entirely different implementations of > type checking based on the same annotation syntax) are also a possibility. > Maybe in the distant future a version of Python will take a different > stance, once we have more experience with how this works out in practice, > but for Python 3.5 I want to restrict the scope of the upheaval. > > > *Appendix -- Why Add Type Annotations?* > The argument between proponents of static typing and dynamic typing has > been going on for many decades. Neither side is all wrong or all right. > Python has traditionally fallen in the camp of extremely dynamic typing, > and this has worked well for most users, but there are definitely some > areas where adding type annotations would help. > > - Editors (IDEs) can benefit from type annotations; they can call out > obvious mistakes (like misspelled method names or inapplicable operations) > and suggest possible method names. Anyone who has used IntelliJ or Xcode > will recognize how powerful these features are, and type annotations will > make such features more useful when editing Python source code. > > - Linters are an important tool for teams developing software. A linter > doesn't replace a unittest, but can find certain types of errors better or > quicker. The kind of type checking offered by mypy works much like a > linter, and has similar benefits; but it can find problems that are beyond > the capabilities of most linters. > > - Type annotations are useful for the human reader as well! Take the above > word_count() example. How long would it have taken you to figure out the > types of the argument and return value without annotations? Currently most > people put the types in their docstrings; developing a standard notation > for type annotations will reduce the amount of documentation that needs to > be written, and running the type checker might find bugs in the > documentation, too. Once a standard type annotation syntax is introduced, > it should be simple to add support for this notation to documentation > generators like Sphinx. > > - Refactoring. Bob's talk has a convincing example of how type annotations > help in (manually) refactoring code. I also expect that certain automatic > refactorings will benefit from type annotations -- imagine a tool like 2to3 > (but used for some other transformation) augmented by type annotations, so > it will know whether e.g. x.keys() is referring to the keys of a dictionary > or not. > > - Optimizers. I believe this is actually the least important application, > certainly initially. Optimizers like PyPy or Pyston > <https://github.com/dropbox/pyston> wouldn't be able to fully trust the > type annotations, and they are better off using their current strategy of > optimizing code based on the types actually observed at run time. But it's > certainly feasible to imagine a future optimizer also taking type > annotations into account. > > -- > --Guido "I need a new hobby" van Rossum (python.org/~guido) >

1 0

Re: [Python-ideas] Proposal: Use mypy syntax for function annotations
by Guido van Rossum Aug. 14, 2014

Aug. 14, 2014

On Wed, Aug 13, 2014 at 3:26 PM, Manuel Cerón <ceronman(a)gmail.com> wrote: > The type checking algorithm might evolve over the time, but by including > typing.py in the stdlib, the syntax for annotations would be almost frozen > and that will be a limitation. In other projects such as TypeScript ( > http://www.typescriptlang.org/), that the syntax usually evolves > alongside the algorithms. > What kind of evolution did TypeScript experience? > Is the syntax specifyed in typing.py mature enough to put it in the stdlib > and expect users to start annotating their projects without worrying too > much about future changes? > This is a good question. I do think it is good enough as a starting point for future evolution. Perhaps the biggest question is how fast will the annotation syntax need to evolve? If it needs to evolve significantly faster than Python 3 feature releases come out (every 18 months, approximately) then it may be better to hold off and aim for inclusion in the 3.6 standard library. That would allow more time to reach agreement (though I'm not sure that's a good thing :-), and in the mean time typing.py could be distributed as a 3rd party module on PyPI. > Is there enough feedback from users using mypy in their projects? > > I think that rushing typing.py into 3.5 is not a good idea. However, It'd > be nice to add some notes in PEP8, encourage it's use as an external > library, let some projects and tools (e.g. PyCharm) use it. It's not that > bad if mypy lives 100% outside the Python distribution for a while. Just > like TypeScript to JavaScript. > Well, JavaScript's evolution is tied up forever in a standards body, so TypeScript realistically had no choice in the matter. But are there actually people writing TypeScript? I haven't heard from them yet (people at Dropbox seem to rather like CoffeeScript). Anyway, the situation isn't quite the same -- you wouldn't make any friends in the Python world if you wrote your code in an incompatible dialect that could only be executed after a translation step, but in the JavaScript world that's how all alternative languages work (and they even manage to interoperate). > After getting some user base, part of it (typing.py) could be moved to the > stdlib. > I'm still hopeful that we can get a sufficient user base and agreement on mypy's features for inclusion in 3.5 (extrapolating the 3.4 release schedule by 18 months, 3.5 alpha 1 would go out around February 2015; the feature freeze cut-off date, beta 1, would around May thereafter). -- --Guido van Rossum (python.org/~guido)

8 9

Re: [Python-ideas] Python-ideas Digest, Vol 93, Issue 31
by Raymond Hettinger Aug. 14, 2014

Aug. 14, 2014

On Aug 13, 2014, at 12:44 PM, python-ideas-request(a)python.org wrote: > The goal is to make it possible to add > type checking annotations to 3rd party modules (and even to the stdlib) > while allowing unaltered execution of the program by the (unmodified) > Python 3.5 interpreter. Is the goal to "make it possible" or would it quickly become required (i.e. any time you write normal, readable Python, it would break someone's optimizer, refactorer, linter, etc.?) Are these annotations going to be pushed into every nook and cranny in the standard library and wend their way into the C code? Raymond

7 9

Re: [Python-ideas] [Python-Dev] sum(...) limitation
by Stephen J. Turnbull Aug. 14, 2014

Aug. 14, 2014

Redirecting to python-ideas, so trimming less than I might. Chris Barker writes: > On Mon, Aug 11, 2014 at 11:07 PM, Stephen J. Turnbull <stephen(a)xemacs.org> > wrote: > > > I'm referring to removing the unnecessary information that there's a > > better way to do it, and simply raising an error (as in Python 3.2, > > say) which is all a RealProgrammer[tm] should ever need! > > > > I can't imagine anyone is suggesting that -- disallow it, but don't tell > anyone why? As I said, it's a regression. That's exactly the behavior in Python 3.2. > The only thing that is remotely on the table here is: > > 1) remove the special case for strings -- buyer beware -- but consistent > and less "ugly" It's only consistent if you believe that Python has strict rules for use of various operators. It doesn't, except as far as they are constrained by precedence. For example, I have an application where I add bytestrings bytewise modulo N <= 256, and concatenate them. In fact I use function call syntax, but the obvious operator syntax is '+' for the bytewise addition, and '*' for the concatenation. It's not in the Zen, but I believe in the maxim "If it's worth doing, it's worth doing well." So for me, 1) is out anyway. > 2) add a special case for strings that is fast and efficient -- may be as > simple as calling "".join() under the hood --no more code than the > exception check. Sure, but what about all the other immutable containers with __add__ methods? What about mappings with key-wise __add__ methods whose values might be immutable but have __add__ methods? Where do you stop with the special-casing? I consider this far more complex and ugly than the simple "sum() is for numbers" rule (and even that is way too complex considering accuracy of summing floats). > And I doubt anyone really is pushing for anything but (2) I know that, but I think it's the wrong solution to the problem (which is genuine IMO). The right solution is something generic, possibly a __sum__ method. The question is whether that leads to too much work to be worth it (eg, "homogeneous_iterable"). > > Because obviously we'd want the attractive nuisance of "if you > > have __add__, there's a default definition of __sum__" > > now I'm confused -- isn't that exactly what we have now? Yes and my feeling (backed up by arguments that I admit may persuade nobody but myself) is that what we have now kinda sucks[tm]. It seemed like a good idea when I first saw it, but then, my apps don't scale to where the pain starts in my own usage. > > It's possible that Python could provide some kind of feature that > > would allow an optimized sum function for every type that has > > __add__, but I think this will take a lot of thinking. > > does it need to be every type? As it is the common ones work fine already > except for strings -- so if we add an optimized string sum() then we're > done. I didn't say provide an optimized sum(), I said provide a feature enabling people who want to optimize sum() to do so. So yes, it needs to be every type (the optional __sum__ method is a proof of concept, modulo it actually being implementable ;-). > > *Somebody* will do it (I don't think anybody is +1 on restricting > > sum() to a subset of types with __add__). > > uhm, that's exactly what we have now Exactly. Who's arguing that the sum() we have now is a ticket to Paradise? I'm just saying that there's probably somebody out there negative enough on the current situation to come up with an answer that I think is general enough (and I suspect that python-dev consensus is that demanding, too). > sum() can be used for any type that has an __add__ defined. I'd like to see that be mutable types with __iadd__. > What I fail to see is why it's better to raise an exception and > point users to a better way, than to simply provide an optimization > so that it's a mute issue. Because inefficient sum() is an attractive nuisance, easy to overlook, and likely to bite users other than the author. > The only justification offered here is that will teach people that summing > strings (and some other objects?) Summing tuples works (with appropriate start=tuple()). Haven't benchmarked, but I bet that's O(N^2). > is order(N^2) and a bad idea. But: > > a) Python's primary purpose is practical, not pedagogical (not that it > isn't great for that) My argument is that in practical use sum() is a bad idea, period, until you book up on the types and applications where it *does* work. N.B. It doesn't even work properly for numbers (inaccurate for floats). > b) I doubt any naive users learn anything other than "I can't use sum() for > strings, I should use "".join()". For people who think that special-casing strings is a good idea, I think this is about as much benefit as you can expect. Why go farther?<0.5 wink/> > I submit that no naive user is going to get any closer to a proper > understanding of algorithmic Order behavior from this small hint. Which > leaves no reason to prefer an Exception to an optimization. TOOWTDI. str.join is in pretty much every code base by now, and tutorials and FAQs recommending its user and severely deprecating sum for strings are legion. > One other point: perhaps this will lead a naive user into thinking -- > "sum() raises an exception if I try to use it inefficiently, so it must be > OK to use for anything that doesn't raise an exception" -- that would be a > bad lesson to mis-learn.... That assumes they know about the start argument. I think most naive users will just try to sum a bunch of tuples, and get the "can't add 0, tuple" Exception and write a loop. I suspect that many of the users who get the "use str.join" warning along with the Exception are unaware of the start argument, too. They expect sum(iter_of_str) to magically add the strings. Ie, when in 3.2 they got the uninformative "can't add 0, str" message, they did not immediately go "d'oh" and insert ", start=''" in the call to sum, they wrote a loop. > while we are at it, having the default sum() for floats be fsum() > would be nice How do you propose to implement that, given math.fsum is perfectly happy to sum integers? You can't just check one or a few leading elements for floatiness. I think you have to dispatch on type(start), but then sum(iter_of_floats) DTWT. So I would suggest changing the signature to sum(it, start=0.0). This would probably be acceptable to most users with iterables of ints, but does imply some performance hit. > This does turn sum() into a function that does type-based dispatch, > but isn't python full of those already? do something special for > the types you know about, call the generic dunder method for the > rest. AFAIK Python is moving in the opposite direction: if there's a common need for dispatching to type-specific implementations of a method, define a standard (not "generic") dunder for the purpose, and have the builtin (or operator, or whatever) look up (not "call") the appropriate instance in the usual way, then call it. If there's a useful generic implementation, define an ABC to inherit from that provides that generic implementation.

9 10

Re: [Python-ideas] float comparison in doctest
by Erik Bray Aug. 14, 2014

Aug. 14, 2014

[Sorry for breaking the threading--turns out I didn't have a python-ideas subscription from this address] Just a few followup points I wanted to make to Kevin's post about a proposed +FLOAT_CMP flag for doctest. A better link for the implementation is this PR in Astropy: https://github.com/astropy/astropy/pull/2087 I can't take full credit either--most of the existing code was borrowed (with some small improvements) from the SymPy project. I had started on a similar feature independently, but then borrowed their implementation upon seeing that it was further along than mine. On 12 Aug 2014 04:16, "Terry Reedy" <tjreedy at udel.edu> wrote: > The problem with a simple flag is that almost_equal should sometimes be > absolute and sometimes relative and in both cases a parameter in needed. I > think there have been vague proposals for a float method, but "a - b < delta" > is shorter than "a.almost_equat(b, abs=delta)" and probably easier to > understand. Indeed, that's what I had in mind when I told Kevin that there were still issues with this. There's no obvious way (I can think of at least) to parameterize doctest flags. However, the original immediate purpose of this feature was to handle very small differences in representation of the same value between different platforms, and in that respect it has worked very well. Astropy has a lot of doctests, and many of which have floating point outputs. This +FLOAT_CMP flag enabled removing tons of ellipses from the test outputs, and restoring the full outputs which certainly read better in the docs. For more complete unit tests of course we use assert_almost_equal type functions. That said, if anyone has any ideas for allowing tweaking the tolerances for a doctest flag that would be great. If this otherwise seems like a good idea in general to include in the doctest module I will offer a patch. Erik

2 1

The non-obvious nature of str.join (was Re: sum(...) limitation)
by Nick Coghlan Aug. 13, 2014

Aug. 13, 2014

(switching from python-dev to python-ideas) FWIW, I don't consider str.join *or* sum with an empty string as the starting point to be particularly intuitive ways of joining iterables of strings. str.join was invented before we had keyword-only arguments as a common construct, and before print became an ordinary function that accepted a "sep" keyword-only argument. I'd be interested in seeing a concrete proposal for a "concat" builtin that accepted a "sep" keyword only argument. Even if such a PEP ends up being rejected, it would hopefully help cut short the *next* potentially interminable thread on the topic by gathering the arguments for and against in a more readily accessible place. Regards, Nick. On 10 Aug 2014 18:26, "Stephen J. Turnbull" <stephen(a)xemacs.org> wrote: > Alexander Belopolsky writes: > > On Sat, Aug 9, 2014 at 3:08 AM, Stephen J. Turnbull <stephen(a)xemacs.org > > > > wrote: > > > > > All the suggestions > > > I've seen so far are (IMHO, YMMV) just as ugly as the present > > > situation. > > > > > > > What is ugly about allowing strings? CPython certainly has a way to to > > make sum(x, '') > > sum(it, '') itself is ugly. As I say, YMMV, but in general last I > heard arguments that are usually constants drawn from a small set of > constants are considered un-Pythonic; a separate function to express > that case is preferred. I like the separate function style. > > And that's the current situation, except that in the case of strings > it turns out to be useful to allow for "sums" that have "glue" at the > joints, so it's spelled as a string method rather than a builtin: eg, > ", ".join(paramlist). > > Actually ... if I were a fan of the "".join() idiom, I'd seriously > propose 0.sum(numeric_iterable) as the RightThang{tm]. Then we could > deprecate "".join(string_iterable) in favor of "".sum(string_iterable) > (with the same efficient semantics). > > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com >

16 56

strptime without second argument as an inverse to __str__
by Ram Rachum Aug. 8, 2014

Aug. 8, 2014

What do you think about having `datetime.strptime`, when called without a `format` for the second argument, be a precise inverse of `datetime.__str__`? This is because I don't currently see an obvious way to get an inverse of `datetime.__str__`, and this seems like an okay place to put it.

13 52