Mailman 3 February 2015 - Python-ideas

PEP 485: A Function for testing approximate equality
by Chris Barker 14 Feb '15

14 Feb '15

Hi folks, After much discussion on this list, I have written up a PEP, and it is ready for review (see below) It is also here: https://www.python.org/dev/peps/pep-0485/ That version is not quite up to date just yet, so please refer to the one enclosed in this email for now. I am managing both the PEP and a sample implementation and tests in gitHub here: https://github.com/PythonCHB/close_pep Please go there if you want to try it out, add some tests, etc. Pull requests welcomed for code, tests, or PEP editing. A quick summary of the decisions I made, and what I think are the open discussion points: The focus is on relative tolerance, but with an optional absolute tolerance, primarily to be used near zero, but it also allows it to be used as a plain absolute difference check. It is using an asymmetric test -- that is, the tolerance is computed relative to one of the arguments. It is perhaps surprising and confusing that you may get a different result if you reverse the arguments, but in this discussion it became clear that there were some use-cases where it was helpful to know exactly what the tolerance is computed relative too, and that in most use cases, if just doesn't matter. I hope this is adequately explained in the PEP. We could add a flag to set a symmetric test (I'd go with what boost calls the "strong" test), but I'd rather not -- it just confuses things, and I expect users will tend to use defaults anyway. It is designed to work mostly with floats, but also supports Integer, Decimal, Fraction, and Complex. I'm not really thrilled with that, though, it turns out to be not quite as easy to duck-type it as I had hoped. To really do it right, there would have to be more switching on type in the code, which I think is ugly to write -- contributions, opinions welcome on this. I used 1e-8 as a default relative tolerance -- arbitrarily because that's about half of the decimal digits in a python float -- suggestions welcome. Other than that, of course, we can bike-shed the names of the function and the parameters. ;-) Fire away! -Chris PEP: 485 Title: A Function for testing approximate equality Version: $Revision$ Last-Modified: $Date$ Author: Christopher Barker <Chris.Barker(a)noaa.gov> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 20-Jan-2015 Python-Version: 3.5 Post-History: Abstract ======== This PEP proposes the addition of a function to the standard library that determines whether one value is approximately equal or "close" to another value. Rationale ========= Floating point values contain limited precision, which results in their being unable to exactly represent some values, and for error to accumulate with repeated computation. As a result, it is common advice to only use an equality comparison in very specific situations. Often a inequality comparison fits the bill, but there are times (often in testing) where the programmer wants to determine whether a computed value is "close" to an expected value, without requiring them to be exactly equal. This is common enough, particularly in testing, and not always obvious how to do it, so it would be useful addition to the standard library. Existing Implementations ------------------------ The standard library includes the ``unittest.TestCase.assertAlmostEqual`` method, but it: * Is buried in the unittest.TestCase class * Is an assertion, so you can't use it as a general test (easily) * Uses number of decimal digits or an absolute delta, which are particular use cases that don't provide a general relative error. The numpy package has the ``allclose()`` and ``isclose()`` functions. The statistics package tests include an implementation, used for its unit tests. One can also find discussion and sample implementations on Stack Overflow, and other help sites. These existing implementations indicate that this is a common need, and not trivial to write oneself, making it a candidate for the standard library. Proposed Implementation ======================= NOTE: this PEP is the result of an extended discussion on the python-ideas list [1]_. The new function will have the following signature:: is_close_to(actual, expected, tol=1e-8, abs_tol=0.0) ``actual``: is the value that has been computed, measured, etc. ``expected``: is the "known" value. ``tol``: is the relative tolerance -- it is the amount of error allowed, relative to the magnitude of the expected value. ``abs_tol``: is an minimum absolute tolerance level -- useful for comparisons near zero. Modulo error checking, etc, the function will return the result of:: abs(expected-actual) <= max(tol*expected, abs_tol) Handling of non-finite numbers ------------------------------ The IEEE 754 special values of NaN, inf, and -inf will be handled according to IEEE rules. Specifically, NaN is not considered close to any other value, including NaN. inf and -inf are only considered close to themselves. Non-float types --------------- The primary use-case is expected to be floating point numbers. However, users may want to compare other numeric types similarly. In theory, it should work for any type that supports ``abs()``, comparisons, and subtraction. The code will be written and tested to accommodate these types: * ``Decimal``: for Decimal, the tolerance must be set to a Decimal type. * ``int`` * ``Fraction`` * ``complex``: for complex, ``abs(z)`` will be used for scaling and comparison. Behavior near zero ------------------ Relative comparison is problematic if either value is zero. In this case, the difference is relative to zero, and thus will always be smaller than the prescribed tolerance. To handle this case, an optional parameter, ``abs_tol`` (default 0.0) can be used to set a minimum tolerance to be used in the case of very small relative tolerance. That is, the values will be considered close if:: abs(a-b) <= abs(tol*expected) or abs(a-b) <= abs_tol If the user sets the rel_tol parameter to 0.0, then only the absolute tolerance will effect the result, so this function provides an absolute tolerance check as well. A sample implementation is available (as of Jan 22, 2015) on gitHub: https://github.com/PythonCHB/close_pep/blob/master/is_close_to.py Relative Difference =================== There are essentially two ways to think about how close two numbers are to each-other: absolute difference: simply ``abs(a-b)``, and relative difference: ``abs(a-b)/scale_factor`` [2]_. The absolute difference is trivial enough that this proposal focuses on the relative difference. Usually, the scale factor is some function of the values under consideration, for instance: 1) The absolute value of one of the input values 2) The maximum absolute value of the two 3) The minimum absolute value of the two. 4) The arithmetic mean of the two Symmetry -------- A relative comparison can be either symmetric or non-symmetric. For a symmetric algorithm: ``is_close_to(a,b)`` is always equal to ``is_close_to(b,a)`` This is an appealing consistency -- it mirrors the symmetry of equality, and is less likely to confuse people. However, often the question at hand is: "Is this computed or measured value within some tolerance of a known value?" In this case, the user wants the relative tolerance to be specifically scaled against the known value. It is also easier for the user to reason about. This proposal uses this asymmetric test to allow this specific definition of relative tolerance. Example: For the question: "Is the value of a within x% of b?", Using b to scale the percent error clearly defines the result. However, as this approach is not symmetric, a may be within 10% of b, but b is not within x% of a. Consider the case:: a = 9.0 b = 10.0 The difference between a and b is 1.0. 10% of a is 0.9, so b is not within 10% of a. But 10% of b is 1.0, so a is within 10% of b. Casual users might reasonably expect that if a is close to b, then b would also be close to a. However, in the common cases, the tolerance is quite small and often poorly defined, i.e. 1e-8, defined to only one significant figure, so the result will be very similar regardless of the order of the values. And if the user does care about the precise result, s/he can take care to always pass in the two parameters in sorted order. This proposed implementation uses asymmetric criteria with the scaling value clearly identified. Expected Uses ============= The primary expected use case is various forms of testing -- "are the results computed near what I expect as a result?" This sort of test may or may not be part of a formal unit testing suite. The function might be used also to determine if a measured value is within an expected value. Inappropriate uses ------------------ One use case for floating point comparison is testing the accuracy of a numerical algorithm. However, in this case, the numerical analyst ideally would be doing careful error propagation analysis, and should understand exactly what to test for. It is also likely that ULP (Unit in the Last Place) comparison may be called for. While this function may prove useful in such situations, It is not intended to be used in that way. Other Approaches ================ ``unittest.TestCase.assertAlmostEqual`` --------------------------------------- ( https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertAlm… ) Tests that values are approximately (or not approximately) equal by computing the difference, rounding to the given number of decimal places (default 7), and comparing to zero. This method was not selected for this proposal, as the use of decimal digits is a specific, not generally useful or flexible test. numpy ``is_close()`` -------------------- http://docs.scipy.org/doc/numpy-dev/reference/generated/numpy.isclose.html The numpy package provides the vectorized functions is_close() and all_close, for similar use cases as this proposal: ``isclose(a, b, rtol=1e-05, atol=1e-08, equal_nan=False)`` Returns a boolean array where two arrays are element-wise equal within a tolerance. The tolerance values are positive, typically very small numbers. The relative difference (rtol * abs(b)) and the absolute difference atol are added together to compare against the absolute difference between a and b In this approach, the absolute and relative tolerance are added together, rather than the ``or`` method used in this proposal. This is computationally more simple, and if relative tolerance is larger than the absolute tolerance, then the addition will have no effect. But if the absolute and relative tolerances are of similar magnitude, then the allowed difference will be about twice as large as expected. Also, if the value passed in are small compared to the absolute tolerance, then the relative tolerance will be completely swamped, perhaps unexpectedly. This is why, in this proposal, the absolute tolerance defaults to zero -- the user will be required to choose a value appropriate for the values at hand. Boost floating-point comparison ------------------------------- The Boost project ( [3]_ ) provides a floating point comparison function. Is is a symetric approach, with both "weak" (larger of the two relative errors) and "strong" (smaller of the two relative errors) options. It was decided that a method that clearly defined which value was used to scale the relative error would be more appropriate for the standard library. References ========== .. [1] Python-ideas list discussion thread (https://mail.python.org/pipermail/python-ideas/2015-January/030947.html) .. [2] Wikipedaia page on relative difference (http://en.wikipedia.org/wiki/Relative_change_and_difference) .. [3] Boost project floating-point comparison algorithms ( http://www.boost.org/doc/libs/1_35_0/libs/test/doc/components/test_tools/fl… ) Copyright ========= This document has been placed in the public domain. -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

21 137

Re: [Python-ideas] Adding "+" and "+=" operators to dict
by Chris Barker 14 Feb '15

14 Feb '15

On Fri, Feb 13, 2015 at 9:11 PM, Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote: > 2) The LHS is a complex expression that you only want >> to write out and evaluate once. >> >> Can you give an example of this? how can put an expression in the right >> hand side? >> > > myobj.dingle.dell[17] += 42 Hmmm -- I guess I need to look up "expression" -- I would have thought of that as a single object -- but yes, name lookups can be expensive, so there may be a win there. But: In this case, this will only work if myobj.dingle.dell is a mutable object. Even if myobj.dingle.dell[17] is imuttable. but if dell is immutable, it won't work even if dell[17] is mutable. So we don't have the full win here. if += was only supported on mutables, then it would be the other way around. Not sure if there is a clear win there. But maybe it is possible to have a kind of hot fix that allows both. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

1 0

Fwd: Adding "+" and "+=" operators to dict
by Chris Barker 14 Feb '15

14 Feb '15

Oops, Accidentally went off-list -- here it is: On Fri, Feb 13, 2015 at 8:32 PM, Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote: > Steven D'Aprano wrote: > >> I think that focusing on the question of "which wins" in the case of >> duplicate keys, the left or right operand, is not very productive. We can >> just declare that Python semantics are that the last value seen wins, >> > > Sure we can, but that's something to be learned. It's > not going to be obvious to everyone. no -- but some things are more obvious to more people than others. dict1 + dict2 being the same as dict1.update(dict2) Is pretty easy to explain, and probably the most likely to be intuitively obvious to the most people. It might be interesting to put a poll on a more general list: What do you think the result of : dict1 = {'a':1, 'b':2} dict2 = {'c':3, 'b':4} dict3 = dict1 + dict2 to be? And see what shakes out with a mixture of newbies and more experienced pythoneers think. This is a pretty classic usability issue -- "intuitive" means "works like one expects" , but everyone expects different things, so different things are intuitive to different people. So often there is NO ONE thing that is most intuitive to everyone. But the only way to know is some usability testing. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

1 0

Re: [Python-ideas] A (meta)class algebra
by Martin Teichmann 13 Feb '15

13 Feb '15

Hi everyone, I guess I need to give an example to show what my proposal is about. Imagine a metaclass which registers all classes based on it: class MetaRegistrar(type): def __init__(self, name, bases, dict): super().__init__(name, bases, dict) Registrar.classlist.append(self) class Registrar(object, metaclass=MetaRegistrar): classlist = [] now every subclass of Registrar is registered into its classlist. Imagine now you want to register a class which inherits another metaclass. A real world example I stumbled over was using a QObject from PyQt4. Then you have: class Spam(Registrar, QObject): pass which gives you a nice error message. Sure, you can now define a new metaclass: class MetaQRegistrar(MetaRegistrar, type(QObject)): pass but then you always have to write something like class Spam(Registrar, QObject, metaclass=MetaQRegistrar): pass everyone who uses Registrar needs to know the details of how those classes can be combined. With my addition, one could simply add a method to MetaRegistrar: def __add__(self, other): class Combination(self, other): pass return Combination which mixes MetaRegistrar into whatever comes. Sure, this is a very simplified example, one would cache the created classes, and maybe one wants to register classes that can be mixed. So, I hope this helps to illustrate my idea, now I'm answering specific questions raised: > Why the + operator? This doesn't seem to have anything to do with > addition, or concatentation. well, technically I'm fine with any method name, one of the binary operators just has the advantage that all the details with when __add__ as opposed to __radd__ is called are all sorted out already. But maybe the | operator is a better choice, as mixing classes is more like a union of two sets. > Your default implementation of __add__ > shows that this has nothing to do with anything remotely like the > standard use of plus: That's actually not true. My methods combine classes, and if one is already a subclass of the other, they are already mixed, so yes, it is like a standard union of sets (I start to like the idea of |) > Just overriding __add__ (or whatever method used) doesn't solve the > problem. You still have to actually make the metaclasses compatible, so > that it is meaningful to mix the metaclasses. Well, it does solve the problem. Before it was not at all possible to programmatically make metaclasses compatible, you had to write it down explicitly, each time of use. >> They can be easily overwritten to get a different metaclass mixing >> behavior. > > I question how easy that would be. If I have understood your proposal > for metaclass __add__, mc1 + mc2 would have to return a new metaclass, > mc3, which somehow combines behaviour from the two arguments. Even with > cooperative metaclasses designed to work together, that sounds to me > like it would be painful. well, to give an example: class MetaClassMixin(type): def __add__(self, other): class ret(self, other): pass return ret just mixes your class into the other class. Greetings Martin

4 4

Re: [Python-ideas] Adding "+" and "+=" operators to dict
by Chris Barker - NOAA Federal 12 Feb '15

12 Feb '15

+1 on += Isn't that confusing ;-) Yes, we have dict.update(), but the entire reason += exists (all the augmented assignment operators -- they are called that, yes?) is because we didn't want methods for everything. It particular, I believe a major motivator was numpy, where in-place operations are a major performance boost. Sure, numpy could have added methods for all those, but the operator syntax is so much nicer, why not use it where we can? And I prefer + to | ... Seems much more obvious to me. Chris -Chris

2 2

A (meta)class algebra
by Martin Teichmann 12 Feb '15

12 Feb '15

Hi list, metaclasses are a really cool thing in python. Unfortunately, it can easily get out of hand if you use them too much, once one wants to inherit from two classes with different metaclasses one has to go some lengths to get things going again. On one hand this is unavoidable, as python has no way to guess how two metaclasses are to be mixed. Often, however, two metaclasses are designed to work together. But currently, there is no way to tell the metaclass machinery how to mix them. I propose to use the + operator to mix metaclasses. This means one can simply overwrite __add__ to get a new metaclass mixing behavior. Let's look at how metaclass determination works right now. It is done in typeobject.c. I'm giving here the python equivalent of the function doing it: def CalculateMetaclass(metatype, type): winner = metatype for b in type.__bases__: if issubclass(winner, b): continue elif issubclass(b, winner): winner = b continue else: raise TypeError("metaclass conflict") return winner I would replace that with the following function, which uses addition istead of issubclass: def CalculateMetaclass(metatype, type): winner = metatype for b in type.__bases__: try: winner = winner + b except TypeError: raise TypeError("metaclass conflict") Now the default implementation of __add__ in type would be something like: def __add__(self, other): if issubclass(self, other): return self return NotImplemented def __radd__(self, other): if issubclass(self, other): return self return NotImplemented This gives the default behavior for all metaclasses inheriting type. They can be easily overwritten to get a different metaclass mixing behavior. Greetings Martin

3 2

Add 'use warnings' directive, like in Perl
by Eduard Bondarenko 11 Feb '15

11 Feb '15

Hello group, my name is Eduard. I came into the Python community with an idea to add (implicitly or explicitly) 'use warnings' directive into the python's programs. I think that everyone who worked with Perl understand what I am talking about. For the rest I will explain the idea. Actually, this is my first experience for writing into the community like this, so excuse me if you found some mistakes or oddities. Also I do not know whether you are already talk about this topic..in any case - sorry. So, imagine that you have a program: #!/usr/bin/python *word* = raw_input("Enter line : ") if *word* == "hello": print ("You wrote \'hello\'") else: if *world* == "buy": #Error! should be word not world print "Buy" else: *iamnotfunction* #Also error This script contains two errors. And in both cases we will know about it at runtime. And the most worst thing is that you will not know about these errors until someone enters anything other than the "hello" word.. Try and except blocks do not solve this problem. Within this approach we also receive problem at runtime. What I propose ? I propose to add 'use warnings' directive. This directive will provide deeply verification. Like this: #!/usr/bin/python *use warnings* *word* = raw_input("Enter line : ") if *word* == "hello": print ("You wrote \'hello\'") else: if *world* == "buy": #Error! should be word not world print "Buy" else: *iamnotfunction* #Also error Output: Use of uninitialized value world in eq (==) at test.py line .. Useless use of a constant (iamnotfunction) in void context at test.py line .. The user will see the output like this and the program will not start. To my mind the good idea is to explicitly set this directive. If developer does not want spend time for this checking, he can omit 'use warning' directive. Also it will not corrupt the existing programs. And developers will have a chance to add this line gradually. Many thanks! - Eduard

7 7

Re: [Python-ideas] Add 'use warnings' directive, like in Perl
by Eduard Bondarenko 11 Feb '15

11 Feb '15

Dear Ian Cordasco, > So as a maintainer/contributor to three of those I agree. But they're > external dependencies which I sense is something you don't want. > > The reality is that you can compile this code with some standard > library modules and they'll give you the feedback you want. If you > were to run this code you'd get a NameErrors for the first line where > you expect a warning and you would get a SyntaxError for the second > else statement after the first. pyflakes and flake8 turn those into > error codes for you. So really, python already comes with the warnings > on because doing > > $ python test.py > > Would first result in a SyntaxError (because of your else following > the first else) and then once that's been fixed, you'd get a > NameError. > > Disclaimer: I didn't actually run the code so I may have the order of > errors wrong, but I think this is roughly correct. I am sorry..I mean: #!/usr/bin/python word = raw_input("Enter line : ") if word == "hello": print ("You enter \'hello\'") else: if world == "buy": #Error! should be word not world print "Buy" else: dasdas We will not have a problem with else. Okay, we can split this example: The first part is: #!/usr/bin/python *word* = raw_input("Enter line : ") if *word* == "hello": print ("You enter \'hello\'") else: if *world* == "buy": *#Error! should be word not world* print "Buy" *"NameError: name 'world' is not defined" - only in case if the word != 'hello'*!! The second one: #!/usr/bin/python *word* = raw_input("Enter line : ") if *word* == "hello": print ("You enter \'hello\'") else: if *word* == "buy": #Now correct! print "Buy" else iamnotfunction *#Error* *"NameError: name 'iamnotfunction' is not defined" only in case if word != 'hello' and word != "buy"*!! So I can type whatever I want in else block and someone can detect it after the several years.. And the first thing that I have to do programming in Python is to download analyser tool..I understand the importance of static analyser tools, but in this case (to check simple things like a variables and functions names) it is like "To use a sledge-hammer to crack a nut.". Many thanks! - Eduard PS. Within C++ or other languages I should use static analyser tools to check real bug-prone situation, but in new, modern Python I should use third-party tools to check the real simple errata. Maybe I do not understand something..

11 16

Add orderedset as set(iterable, *, ordered=False) and similarly for frozenset.
by Neil Girdhar 08 Feb '15

08 Feb '15

Hundreds of people want an orderedset (http://stackoverflow.com/questions/1653970/does-python-have-an-ordered-set) and yet the ordered sets that are in PyPI (oset, ordered-set) are incomplete. Please consider adding an ordered set that has *all* of the same functionality as set. The only major design decision is (I think) whether to store the elements in a linked list or dynamic vector. My personal preference is to specify the ordered set via a flag to the constructor, which can be intercepted by __new__ to return a different object type as necessary. (If anyone wants to add a complete ordered set to PyPI that would also be very useful for me!) Best, Neil

9 11

Re: [Python-ideas] Add orderedset as set(iterable, *, ordered=False) and similarly for frozenset.
by Raymond Hettinger 08 Feb '15

08 Feb '15

> * It isn't entirely clear what the set-to-set operations should do to maintain order, whether equality tests should require matching order, whether we care about loss of commutativity, and whether we're willing to forgo the usual optimizations on set-to-set operations (i.e. the intersection algorithm loops over the smaller of the two input sets and checks membership in the larger set -- that is fast, but it would lose order if the second set were the smaller of the two). > >> I agree it's not obvious, but I think that with a little debate we could come together on a reasonable choice. "In the face of ambiguity, refuse the temptation to guess." Some of the participants on python-ideas need to develop a much stronger aversion to opening a can of worms ;-) > You could even block the set-to-set operations for now. The main use of OrderedSet just requires add, update, and iteration as your recipe illustrates. Since you don't seem have any specific requirements for the order created by set-to-set operations, then just use the existing set operations on OrderedDict.keys(): >>> a = OrderedDict.fromkeys(['raymond', 'rachel', 'matthew']) >>> b = OrderedDict.fromkeys(['matthew', 'calvin', 'rachel']) >>> a.keys() & b.keys() {'rachel', 'matthew'} >>> a.keys() | b.keys() {'rachel', 'calvin', 'matthew', 'raymond'} >>> a.keys() - b.keys() {'raymond'} >>> a.keys() ^ b.keys() {'calvin', 'raymond'} >>> list(a.keys()) ['raymond', 'rachel', 'matthew'] > > * The standard library should provide fast, clean fundamental building blocks and defer all of the myriad of variants and derivations to PyPI. We already provide OrderedDict and MutableSet so that rolling your own OrderedSet isn't hard (see the recipe below). > > I think that OrderedSet is a fundamental building block :) The rule for "fundamental" that I've used for itertools is whether the thing you want can easily be built out of what you've already got. For example, you can't make accumulate() out of the other itertools, but you can make tabulate(func) from map(func, count()). Likewise, you can easily make an OrderedSet from an OrderedDict and MutableSet, or if you're needs are less, just use the existing set operations on dict views as shown above. > * We're likely to soon have an OrderedDict written in C (I believe Eric Snow has been working on that for some time), so anything build on top of an OrderedDict will inherit all the speed benefits. > > Sure. It's also easy to have an OrderedSet written in C (especially once OrderedDict is done.) You're profoundly under-estimating how much work it is to build and maintain a separate C implementation. I've maintained the code for collections and sets for over a decade and can assure you that the maintenance burden has been enormous. > Also, there is some chance that PyPy folks will contribute their work making regular sets and dicts ordered by default; in which case, having a separate OrderedSet would have been a waste and the question would be moot. > > I think that using dicts and sets and assuming that they're ordered because you plan on using PyPy is a terrible error. Perhaps, I wasn't clear. The PyPy folks have offered to port their work back into Python. They're offering a nice combination of faster performance (especially for iteration), better memory utilization, and as a by-product retaining insertion order. If their offer comes to fruition, then this whole discussion is moot. > > To be honest, my main issue is my personal need. The usual solution for personal needs is to have a personal utils module (it sounds like you've been using my recipe for over a year). Decisions about what to put in the standard library have far reaching impact and we need to consider what is best for most of the users most of the time (and to consider our own maintenance burden). I thought ordered sets were interesting enough to write an implementation six years ago, but frankly there are many other other things that have a much better case for being added to collections (for example, some sort of graph structure, some kind of binary tree, some kind of trie, or perhaps a bloom filter). > If there was a complete PyPI recipe, I would be very happy. Then, that is what we should do. > I don't think I'm the only one, but maybe you're right and I am. > > > * One thing I've used to test the waters is to include a link in the documentation to an OrderedSet recipe (it's in the "See also" section at the very bottom of the page at https://docs.python.org/2/library/collections.html ). As far as I can tell, there has been nearly zero uptake based on this link. That gives us a good indication that there is very little real-world need for an OrderedSet. > > I've been using your recipe for at least a year (thank you). How are you measuring uptake? That is a very difficult question to answer (there is no precise tool for saying X people care about thing Y). The inputs I do have are imprecise and incomplete but never-the-less still informative. When google's code search was still alive, there was a direct way of seeing what people used in published code, and I frequently searched to see what people were using in the python world and how they were using it (for example, that is how I was able to determine that str.swapcase() was nearly useless and propose that it be removed for Python 3). Since then, I rely on a number of other sources such as reading the python bug tracker every day for the last 15 years to know what people are requesting. Likewise, as frequent contributor to stack overflow you can see what people are asking about. As a person who does python code reviews and teaches python courses for a living, I get to see into the code base for many companies. Also, I spend time reading the source for popular python tools to see what their requirements are. Another source is reviewing what is included in toolsets from Continuum and Enthought to see what their client's have asked for. None of this is precise or sufficiently inclusive, but it does give me some basis for finding out what people care about. >> >> What I suggest is adding the recipe (like the one shown below) directly to the docs in this section: >> https://docs.python.org/2/library/collections.html#ordereddict-examples-and… >> There we already have code for a LastUpdatedOrderedDict() and an OrderedCounter(). >> >> In the past, I've used these recipes as a way to gauge interest. When the interest was sufficient, it got promoted from a recipe in the docs to a full implementation living in a standard library module. For example, itertools.combinations_with_replacement() and itertools.accumulate() started out as recipes in the docs. >> >> In general, there shouldn't be a rush to push more things in the standard library. We get many suggestions in the form, "it might be nice to have XXX in the standard library", however, in many cases there has been so little uptake in real-world code that it is isn't worth the maintenance burden or for the burden on the working programmer for having too many choices in the standard library (I encounter very few people who actually know most of what is available in the standard library). > > I agree. Sounds good. I think we can put an OrderedSet() recipe in the docs and another out on PyPI, and be done with it. > > > PyPI is a successful secondary source of code and has become part of the working programmer's life. We're gradually making it easier and easier to pull that code on-demand. IMO, that is where most of the collections variants should live. Otherwise, it would be easy to fill the collections module with dozens of rarely used dict/set variants, red-black trees, pairing heaps, tries, graph implementations, bitarrays, bitsets, persistent collections, etc.) > > my-two-cents-ly, > > > > Agreed. > > It would be nice to complete one of the recipes (oset or ordered-set) — at least for me. Completing a recipe is more reasonable than pushing for this to be in the standard library. Raymond

3 2