Mailman 3 March 2010 - Python-ideas

Re: [Python-ideas] Why is nan != nan?
by Alexander Belopolsky 28 Mar '10

28 Mar '10

Since we are now venturing in the realm of python-ideas, I am switching the mailing lists. Please see more below. On Wed, Mar 24, 2010 at 7:31 PM, Mark Dickinson <dickinsm(a)gmail.com> wrote: > On Wed, Mar 24, 2010 at 11:11 PM, Alexander Belopolsky > <alexander.belopolsky(a)gmail.com> wrote: >> On Wed, Mar 24, 2010 at 7:02 PM, Mark Dickinson <dickinsm(a)gmail.com> wrote: >> .. >>> >>> So if I understand correctly, you propose that float('nan') == >>> float('nan') return True. Would you also suggest extending this >>> behaviour to Decimal nans? >>> >> >> yes >> > > Okay. So now it seems to me that there are many decisions to make: I maybe show my ignorance, but I don't see the significance of bringing Decimal nans to the discussion. My answers below apply equally to binary and decimal floating point numbers. > should any Decimal nan compare equal to any other? Yes. > What if the two nans have different payloads or signs? They are still equal. Just as 0.0 and -0.0 are now. > How about comparing a > signaling nan with either an arbitrary quiet nan, or with the exact > quiet nan that corresponds to the signaling nan? I don't think signaling nans can be produced using Python float type. I may be mistaken about this and the answer may be different in some decimal contexts. Nevertheless, I always thought that any operation with an sNaN should raise an exception, so comparing an sNaN with anything, NaN or not, should just raise an exception. > How do decimal nans compare with float nans? Good question. Does IEEE 754 or rather 854 specify cross-radix comparisons? My answer would be that they should compare equal. > Should Decimal.compare(Decimal('nan'), Decimal('nan')) return 0 rather than nan? I would think with deprecation of __cmp__, Decimal.compare would not be that useful. I would rather not expand this discussion to what NaN < NaN should return. In my view it should just raise an exception because there is no practical way to propagate NaN through boolean results. Decimal.compare may similarly raise an exception when comparing NaNs. Returning Decimal('nan') seems least useful. With the current NaN properties, I would rather see Decimal.compare return 2 for unordered values. > If not, how do you justify the difference between == and compare? Just as (a > b or b < a) is currently not equivalent to a != b in the presence of unordered values (i.e. when a and b are of different type). > If so, how do you justify the > deviation from the standard on which the decimal modulo is based? I assume you mean "decimal module" because I don't know what "decimal modulo" is based on. Is that IEEE 854? I need to get a copy of that before I can answer. :-) > > In answering all these questions, you effectively end up developing > your own standard, and hoping that all the answers you chose are > sensible, consistent, and useful. > As Grace Hopper is reported to have said, "The wonderful thing about standards is that there are so many of them to choose from." As much as I don't like most of the choices that Java designers made, I think they got this one right. > Alternatively, we could do what we're currently doing: make use of > *existing* standards to answer these questions, and rely on the > expertise of the many who've thought about this in depth. > I don't think I can answer this better than Bertrand Meyer: """ Before commenting further let me note the obvious: I am by no means a numerics expert; I know that IEEE 754 was a tremendous advance, and that it was designed by some of the best minds in the field, headed by Velvel Kahan who received a Turing Award in part for that success. So it is quite possible that I am about to bury myself in piles of ridicule. On the other hand I have also learned that (1) ridicule does not kill, so I am game; and more importantly (2) experts are often right but not always, and it is always proper to question their reasoning. So without fear let me not stop at the arguments that “the committee must have voted on this point and they obviously knew what they were doing” and “it is the standard and implemented on zillions of machines, you cannot change it now”. Both are true enough, but not an excuse to censor questions. """ http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civili… > You say that you don't see any compromise: I say that there's value > in adhering to (de facto and de jure) standards, and I see a > compromise between standards adherence and Python pragmatics. Bertrand Meyer again: """ A few of us who had to examine the issue recently think that — whatever the standard says at the machine level — a programming language should support the venerable properties that equality is reflexive and that assignment yields equality. """ IEEE standards were developed in a different problem domain: hardware or low level programming language design. They may not be appropriate for an object oriented language like Python. Java and recently Eiffel designers seem to have realized that.

9 15

Re: [Python-ideas] [Python-Dev] Why is nan != nan?
by Mark Dickinson 27 Mar '10

27 Mar '10

[Moving back to python-ideas] On Sat, Mar 27, 2010 at 12:05 AM, Steven D'Aprano <steve(a)pearwood.info> wrote: > Certainly not. That defeats the whole purpose of NANs. I wish floating > point calculations in Python would return NANs rather than raise the > exceptions they do now. I'd prefer the opposite: that arithmetic operations and math functions raise rather than produce nans; this seems friendlier for users who don't want to know or care about infinities and nans. But I agree that there are uses for nonstop mode. <python-ideas-territory> How about default behaviour like the above, with a "from __options__ import non-stop-arithmetic" for people who want 1./0. to give infinity and sqrt(-1) to give nan? In order words, default behaviour roughly corresponds to the IEEE 754 spec with the 'invalid operation', 'overflow' and 'divide-by-zero' operations trapped (exactly as the default context in the decimal module does currently), and the non-stop behaviour corresponds to IEEE 754 with none of those operations trapped and returning default values. A more elaborate proposal would allow individual control over the three signals above. (Full control over the 'underflow' and 'inexact' signals isn't really feasible given C's poor support for these things.) </python-ideas-territory>. Mark

1 1

Adding exception logging function to syslog module.
by Sean Reifschneider 25 Mar '10

25 Mar '10

As someone who writes mostly programs that run unattended on servers, one thing I often want to do is have my tracebacks logged to syslog. I would propose adding something like the following to the syslog module: def logexceptions(also_stderr = True): class ExceptHook: def __init__(self, useStderr = False): self.useStderr = useStderr def __call__(self, etype, evalue, etb): import traceback, string tb = traceback.format_exception(*(etype, evalue, etb)) tb = map(string.rstrip, tb) tb = string.join(tb, '\n') for line in string.split(tb, '\n'): syslog.syslog(line) if self.useStderr: sys.stderr.write(line + '\n') sys.excepthook = ExceptHook(also_stderr) Now, the downside to this is that currently the syslog module is entirely in C. So either I'd need to implement the above in C, or I'd need to add a Python wrapper to the C module and use that. This would allow users to also log exceptions to syslog by doing: import syslog syslog.openlog('myprogram', syslog.LOG_PID, syslog.LOG_MAIL) syslog.logexceptions() Thoughts? Thanks, Sean -- Python: even though everyone's using it now, somehow it's still the coolest. Sean Reifschneider, Member of Technical Staff <jafo(a)tummy.com> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability

2 5

setting function properties with a decorator syntax
by nbv4 19 Mar '10

19 Mar '10

Decorators are great, they make this: def some_func(*args, **kwargs): return "sup" some_func = decorator(some_func) into this: @decorator def some_func(*args, **kwargs): return "sup" which makes the code look more structured. The line at the bottom looks more like it 'belongs' to the function when it's at the top of the def block, as opposed to the bottom. But when it comes to function properties, it'd be nice if that same pattern was availiable: def some_func(*args, **kwargs): return "sup" some_func.printable = True becomes: @printable=True def some_func(*args, **kwargs): return "sup" Any thoughts?

11 14

__metafunc__
by Zac Burns 18 Mar '10

18 Mar '10

I would like to propose a __metafunc__ that would work similar to metaclasses but for functions. My use case is for duck punching all functions defined in a module. This tends to be difficult as a postprocess after __import__ (you have to modify method.im_func and deal with closures and functions in the module namespace that might be references to functions defined elsewhere - it's a mess). If instead when defining a function it did a lookup of __metafunc__ and called it (like a decorator) after a function was defined then I could import the module in a globals that includes my __metafunc__. Feel free to tear this idea apart, improve it, or dash it on the rocks. Perhaps some of you will also see use cases for this or something like it? -- Zachary Burns (407)590-4814 Aim - Zac256FL Production Engineer (Digital Overlord) Zindagi Games

1 0

Matching multiple regex patterns simultaneously
by Andrey Fedorov 17 Mar '10

17 Mar '10

So a couple of libraries (Django being the most popular that comes to mind) try to match a string against several regex expressions. I'm wondering if there exists a library to "merge" multiple compiled regex expressions into a single lookup. This could be exposed in a interface like: http://gist.github.com/319905 So for an example: rd = ReDict() rd['^foo$'] = 1 rd['^bar*$'] = 2 rd['^bar$'] = 3 assert rd['foo'] == [1] assert rd['barrrr'] == [2] assert rd['bar'] == [2,3] The naive implementation I link is obviously inefficient. What would be the easiest way to go about compiling a set of regex-es together, so that they can be matched against a string at the same time? Are there any standard libraries that do this I'm not aware of? Cheers, Andrey

5 6

EuroPython 2010 - Open for registration and reminder of participation
by Michael Foord 16 Mar '10

16 Mar '10

EuroPython 2010 - 17th to 24th July 2010 ---------------------------------------- EuroPython is a conference for the Python programming language community, including the Django, Zope and Plone communities. It is aimed at everyone in the Python community, of all skill levels, both users and programmers. Last year's conference was the largest open source conference in the UK and one of the largest community organised software conferences in Europe. This year EuroPython will be held from the 17th to 24th July in Birmingham, UK. It will include over 100 talks, tutorials, sprints and social events. Registration ------------ Registration is open now at: http://www.europython.eu/registration/ For the best registration rates, book as soon as you can! Extra Early Bird closes soon, after which normal Early Bird rate will apply until 10th May Talks, Activities and Events ---------------------------- Do you have something you wish to present at EuroPython? You want to give a talk, run a tutorial or sprint? Go to http://www.europython.eu/talks/cfp/ for information and advice! Go to http://wiki.europython.eu/Sprints to plan a sprint! Help Us Out ----------- EuroPython is run by volunteers, like you! We could use a hand, and any contribution is welcome. Go to http://wiki.europython.eu/Helping to join us! Go to http://www.europython.eu/contact/ to contact us directly! Sponsors -------- Sponsoring EuroPython is a unique opportunity to affiliate with this prestigious conference and to reach a large number of Python users from computing professionals to academics, from entrepreneurs to motivated and well-educated job seekers. http://www.europython.eu/sponsors/ Spread the Word --------------- We are a community-run not-for-profit conference. Please help to spread the word by distributing this announcement to colleagues, project mailing lists, friends, your blog, Web site, and through your social networking connections. Take a look at our publicity resources: http://wiki.europython.eu/Publicity General Information ------------------- For more information about the conference, please visit the official site: http://www.europython.eu/ Looking forward to see you! The EuroPython Team -- http://www.ironpythoninaction.com/

1 0

iterable: next() and __iter__() -- and __reset()
by spir 05 Mar '10

05 Mar '10

Hello, (1) I do not understand an iterable type's __iter__() method to be compulsary. Actually, each time I have defined one, I had to write: def __iter__(self): return self So, I guess that if python does not find __iter__(), but the object defines next(), then by default the said object could be used as its own iterator. This is what I understand by "iterable" and next() is the required method for it. Or even better: only if the object does not define next(), then python falls back to looking for __iter__(). Is there any obstacle for this I cannot see? Side-question: In which cases is it necessary to define the iterator as a separate object? (2) But: for any reason next() is not spelled as a "magic" method. If this method becomes the distinctive method of iterables, then it should be called __next__() for consistency. Side-question: Why is it called next(), as it is a magic method for iterators already? (3) What I miss actually for iterables (which are their own iterator) is a kind of __reset__(). In some cases, it is only needed to allow a new iteration from start. But it may even be needed to set some startup data the first time. __reset__() would thus be called once before the first call to next(). (Sure, "reset" may not be the best term. Maybe "begin" or "startup"? The sense is: "Prepare to yield the first item!") In absence of such a startup mechanism, I end up using __call__ instead: Example: class Powers(object): def __init__(self, exponent): self.exponent = exponent def next(self): n = self.n + 1 if (self.max is not None) and (n > self.max): raise StopIteration self.n = n return n*n def __call__(self, min=1,max=None): self.n = min-1 self.max = max return self #.__iter__() def __iter__(self): return self tripleCubes = [] cubes = Powers(3) for sq in cubes(7,17): if sq%3 == 0: tripleCubes.append(sq) print tripleCubes # ==> [81, 144, 225] __iter__() could be used directly if it would allow "free" args in addition to self (in this case: def __iter__(self, min=0,max=None). This beeing impossible, an aditional method seems to be needed. To sum up, I would enjoy beeing able to write Powers using a scheme like: class Powers(object): def __init__(self, exponent): self.exponent = exponent def __reset__(self, min=1,max=None): self.n = min-1 self.max = max def __next__(self): n = self.n + 1 if (self.max is not None) and (n > self.max): raise StopIteration self.n = n return n*n This matches the overall idea of iterable for me. Denis -- ________________________________ la vita e estrany spir.wikidot.com

11 12

Function caller in operator module
by Mike Graham 04 Mar '10

04 Mar '10

Most operations that are available using operators in Python are provided by the operator module, but calling functions is noticeably absent is calling functions. A user can slightly abuse operator.methodcaller('__call__', ...) to perform this operation, but that is far from ideal. Should operator grow a new function caller, such that operator.caller(*args, **kwargs)(f) returns f(*args, **kwargs)? I have never personally needed this exact operation; it would be somewhat odd but not altogether unthinkable to sort a list of callables by their return values. The closes thing to this I have seen in the wild is map(apply, fs), which is limited to the no-arguments case. It is also possibly uglier than [f() for f in fs]. In any event, it's not even an option in Python 3.x.

2 1

the Quantity pattern
by Bill Janssen 03 Mar '10

03 Mar '10

I was looking at Martin Fowler's Quantity pattern earlier. http://martinfowler.com/ap2/quantity.html I remember writing this up as an idea for Fortran back in the early 80's, only to find a CACM paper from 1978 exploring the idea: "Incorporation of Units into Programming Languages", Karr & Loveman, May 1978. But it would still be a cool idea for Python. Perhaps it's already there and I haven't noticed? Bill

6 8