Python-Dev October 2003

python-dev@python.org

130 participants
211 discussions

by Jeremy Hylton

The top-level walk() function in the compiler package returns the visitor object that is passed to walk. I'd like to change it to return the result of the top-level dispatch() or visit() call. Right now, visitor methods can return a value, which is useful for a visit() call that is internal to a visitor, but can't return it to the caller of walk(). The current return value is pretty useless, since the caller of walk() must pass the visitor as one of the arguments. That is, walk() returns one of its arguments. The change might break some code, but only in a trivial way, and it will make possible to write visitors that don't have any state-- simple combinators. Example: class NameVisitor: """Compute a dotted name from an expression.""" def visitGetattr(self, node): return "%s.%s" % (self.visit(node.expr), node.attrname) def visitName(self, node): return node.name Jeremy

17 years, 5 months

prePEP: Decimal data type

by Batista, Facundo

Here I send it. Suggestions and all kinds of recomendations are more than welcomed. If it all goes ok, it'll be a PEP when I finish writing/modifying the code. Thank you. . Facundo ------------------------------------------------------------------------ PEP: XXXX Title: Decimal data type Version: $Revision: 0.1 $ Last-Modified: $Date: 2003/10/31 15:25:00 $ Author: Facundo Batista <fbatista(a)unifon.com.ar> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 17-Oct-2003 Python-Version: 2.3.3 Abstract ======== The idea is to have a Decimal data type, for every use where decimals are needed but floating point is too inexact. The Decimal data type should support the Python standard functions and operations and must comply the decimal arithmetic ANSI standard X3.274-1996. Rationale ========= I must separate the requeriments in two sections. The first is to comply with the ANSI standard. All the needings for this are specified in the Mike Cowlishaw's work at http://www2.hursley.ibm.com/decimal/. Cowlishaw's also provided a **lot** of test cases. The second section of requeriments (standard Python functions support, usability, etc) are detailed in the `Requirements`_ section. Here I'll include all the decisions made and why, and all the subjects still being discussed. The requirements will be numbered, to simplify discussion on each point. This work is based on code and test functions written by Eric Price, Aahz and Tim Peters. Actually I'll work on the Decimal.py code in the sandbox (at python/nondist/sandbox/decimal in SourceForge). Some of the explanations of this PEP are taken from the Cowlishaw's work. Items In Discussion ------------------- When in a case like ``Decimal op otherType`` (see point 12 in Requirements_ for details), what should happen? if otherType is an int or long: a. an exception is raised b. otherType is converted to Decimal c. Decimal is converted to int or long (with ``int()`` or ``long()``) if otherType is a float: d. an exception is raised e. otherType is converted to Decimal (rounding? see next item in discussion) f. Decimal is converted to float (with ``float()``) if otherType is a string: g. an exception is raised h. otherType is converted to Decimal i. Decimal is converted to string (bizarre, huh?) When passing floating point to the constructor, what should happen? j. ``Decimal(1.1) == Decimal('1.1')`` k. ``Decimal(1.1) == Decimal('110000000000000008881784197001252...e-51')`` Requirements ============ 1. The syntax should be ``Decimal(value)``. 2. The value could be of the type: - another Decimal - int or long - float - string 3. To exist a Context. The context represents the user-selectable parameters and rules which govern the results of arithmetic operations. In the context the user defines: - what will happen with the exceptional conditions. - what precision will be used - what rounding method will be used 4. The Context must be omnipresent, meaning that changes to it affects all the current and future Decimal instances. 5. The exceptional conditions should be grouped into signals, which could be controlled individually. The context should contain a flag and a trap-enabler for each signal. The signals should be: clamped, division-by-zero, inexact, invalid-operation, overflow, rounded, subnormal and underflow. 6. For each of the signals, the corresponding flag should be set to 1 when the signal occurs. It is only reset to 0 by explicit user action. 7. For each of the signals, the corresponding trap-enabler will indicate which action is to be taken when the signal occurs. If 0, a defined result should be supplied, and execution should continue. If 1, the execution of the operation should end and an exception should be raised. 8. The precision (maximum number of significant digits that can result from an arithmetic operation) must be positive (greater than 0). 9. To have different kinds of rounding; you can choose the algorithm through context: - ``round-down``: (Round toward 0, truncate) The discarded digits are ignored; the result is unchanged:: 1.123 --> 1.12 1.128 --> 1.12 1.125 --> 1.12 1.135 --> 1.13 - ``round-half-up``: If the discarded digits represent greater than or equal to half (0.5) then the result should be incremented by 1 (rounded up); otherwise the discarded digits are ignored:: 1.123 --> 1.12 1.128 --> 1.13 1.125 --> 1.13 1.135 --> 1.14 - ``round-half-even``: If the discarded digits represent greater than half (0.5) then the result coefficient should be incremented by 1 (rounded up); if they represent less than half, then the result is not adjusted (that is, the discarded digits are ignored); otherwise the result is unaltered if its rightmost digit is even, or incremented by 1 (rounded up) if its rightmost digit is odd (to make an even digit):: 1.123 --> 1.12 1.128 --> 1.13 1.125 --> 1.12 1.135 --> 1.14 - ``round-ceiling``: If all of the discarded digits are zero or if the sign is negative the result is unchanged; otherwise, the result should be incremented by 1 (rounded up):: 1.123 --> 1.13 1.128 --> 1.13 -1.123 --> -1.12 -1.128 --> -1.12 - ``round-floor``: If all of the discarded digits are zero or if the sign is positive the result is unchanged; otherwise, the absolute value of the result should be incremented by 1:: 1.123 --> 1.12 1.128 --> 1.12 -1.123 --> -1.13 -1.128 --> -1.13 - ``round-half-down``: If the discarded digits represent greater than half (0.5) then the result should be incremented by 1 (rounded up); otherwise the discarded digits are ignored:: 1.123 --> 1.12 1.128 --> 1.13 1.125 --> 1.12 1.135 --> 1.13 - ``round-up``: (Round away from 0) If all of the discarded digits are zero the result is unchanged. Otherwise, the result should be incremented by 1 (rounded up):: 1.123 --> 1.13 1.128 --> 1.13 1.125 --> 1.13 1.135 --> 1.14 10. Strings with floats in engineering notation will be supported. 11. Calling repr() should do round trip, meaning that:: m = Decimal(...) m == eval(repr(m)) 12. To support the basic aritmetic (``+, -, *, /, //, **, %, divmod``) and comparison (``==, !=, <, >, <=, >=, cmp``) operators in the following cases: - Decimal op Decimal - Decimal op otherType - otherType op Decimal - Decimal op= Decimal - Decimal op= otherType Check `Items In Discussion`_ to see what types could OtherType be, and what happens in each case. 13. To support unary operators (``-, +, abs``). 14. To support the built-in methods: - min, max - float, int, long - str, repr - hash - copy, deepcopy - bool (0 is false, otherwise true) 15. To be immutable. Reference Implementation ======================== To be included later: - code - test code - documentation Copyright ========= This document has been placed in the public domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVERTENCIA La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley. Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada. Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje. Muchas Gracias.

17 years, 5 months

Speeding up regular expression compilation

by Bram Moolenaar

In the python-dev archives I find remarks about the old pre module being much faster at compiling regular expressions than the new sre module. My own experiences are that pre is about twenty times as fast. Since my application uses a lot of simple patterns which are matched on short strings (file names actually), the pattern compilation time is taking half the CPU cycles of my program. The faster execution of sre apparently doesn't compensate for the slower compile time. Is the plan to implement the sre module in C getting closer to being done? Is there a trick to make compiling patterns go faster? I'm already falling back to the pre module with Python 2.2 and older. With Python 2.3 this generates a warning message, thus I don't do it there. I considered copying the 2.2 version of pre.py into my application, but this will stop working as soon as the support for pre is dropped (the compiled C code won't be there). Thus it would be only a temporary fix. I don't care about the Unicode support. -- LAUNCELOT: Isn't there a St. Aaaaarrrrrrggghhh's in Cornwall? ARTHUR: No, that's Saint Ives. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- Bram(a)Moolenaar.net -- http://www.Moolenaar.net \\\ /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\ \\\ Project leader for A-A-P -- http://www.A-A-P.org /// \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///

17 years, 5 months

RE: [Python-Dev] inline sort option

by Batista, Facundo

#- > > like type checkers (and IMO are also easily overseen by human #- > > readers). And, it's easier to write l.sorted() rather than #- > > l.sort(inline=True). #- #- [Aahz] #- > Let's make explicit: l.copysort() #- > #- > I'm not a big fan of grammatical suffixes for #- distinguishing between #- > similar meanings. #- #- +1 +2, considering that the difference in behaviour with sort and sorted it's no so clear to a non-english speaker. (my first post to the development list, :D ) . Facundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVERTENCIA La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley. Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada. Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje. Muchas Gracias.

17 years, 5 months

RE: [Python-Dev] Looking for master thesis ideas involving Python

by Delaney, Timothy C (Timothy)

> From: "Martin v. Löwis" [mailto:martin@v.loewis.de] > > My answer is "it depends": If you did not do that, and, for example, > explain why it *can't* be done, than this is a good thesis, > provided you > give qualified scientific rationale for why it can't be done. If you > say you did not do it, but it could be done in this and that way if > you had 50 person years available, then this could be a good thesis > as well, provided the strategy you outline, and the rationale for > computing the 50 person years is convincing. If you just say, "Oops, > I did not finish it because it is too much work", then this would be > a bad thesis. Yep - that was what I was getting at, and your explanation corresponds exactly with my gut feeling. Cheers. Tim Delaney

17 years, 5 months

HTML parsing: anyone use formatter?

by amk＠amk.ca

[Crossposted to python-dev, web-sig, and xml-sig. Followups to web-sig(a)python.org, please.] I'm working on bringing htmllib.py up to HTML 4.01 by adding handlers for all the missing elements. I've currently been adding just empty methods to the HTMLParser class, but the existing methods actually help render the HTML by calling methods on a Formatter object. For example, the definitions for the H1 element look like this: def start_h1(self, attrs): self.formatter.end_paragraph(1) self.formatter.push_font(('h1', 0, 1, 0)) def end_h1(self): self.formatter.end_paragraph(1) self.formatter.pop_font() Question: should I continue supporting this in new methods? This can only go so far; a tag such as <big> or <small> is easy for me to handle, but handling <form> or <frameset> or <table> would require greatly expanding the Formatter class's repertoire. I suppose the more general question is, does anyone use Python's formatter module? Do we want to keep it around, or should htmllib be pushed toward doing just HTML parsing? formatter.py is a long way from being able to handle modern web pages and it would be a lot of work to build a decent renderer. --amk

17 years, 5 months

RE: [Python-Dev] Re: Guido's Magic Code was: inline sort option

by Moore, Paul

From: Alex Martelli [mailto:aleaxit@yahoo.com] > Raymond and I would like to use it as the descriptor for > the new list.sorted. > If the code gets in Python anyway, then it should ideally > be somehow exposed for general use if it's right -- but not > if it's wrong. OK. I follow now. The only contribution I will make is to say that if list.sorted uses it, I think it should be available to the user. I don't like the flavour of "good enough for us, but not for you" that keeping this descriptor purely internal seems to have. On list.sorted, I have no opinion. Paul.

17 years, 5 months

RE: [Python-Dev] Re: Guido's Magic Code was: inline sort option

by Moore, Paul

From: Alex Martelli [mailto:aleaxit@yahoo.com] > On Thursday 30 October 2003 02:01 pm, Michael Chermside wrote: >> And that's exactly why I would be wary of it. One of the GREAT SIMPLICITIES >> of Python is that all calls are "the same". Calling a function works > > A new descriptortype wouldn't change the ``all the same'' idea at > the level at which descriptortypes such as staticmethod and classmethod > haven't changed it. Excuse me, did I miss something? Guido's code was entirely user-level Python, so is available for anyone who wants to use it right now, surely? And if you want it in a C extension, I guess you code a C version for your own use. Why bother arguing over whether it's "right" or "wrong"? Paul.

17 years, 5 months

Py_TPFLAGS_HEAPTYPE, what's its real meaning ?

by Boris Boutillier

Hi all, I've posted this question to the main python list, but got no answers, and I didn't see the issue arose on Python-dev (but I subscribed only two weeks ago). It concerns problems with the Py_TPFLAGS_HEAPTYPE and the new 'hackcheck' in python 2.3. I'm writing a C-extension module for python 2.3. I need to declare a new class, MyClass. For this class I want two things : 1) redefine the setattr function on objects of this class (ie setting a new tp_setattro) 2) I want that the python user can change attributes on MyClass (the class itself). Now I have a conflict on the Py_TPFLAGS_HEAPTYPE with new Python 2.3. If I have Py_TPFLAGS_HEAPTYPE set on MyClass, I'll have problem with the new hackcheck (Object/typeobject.c:3631), as I am a HEAPTYPE but I also redefine tp_setattro. If I don't have Py_TPFLAGS_HEAPTYPE, the user can't set new attributes on my class because of a check in type_setattro (Object/typeobject.c:2047). The only solution I've got without modifying python source is to create a specific Metaclass for Myclass, and write the tp_setattr. But I don't like the idea of making a copy-paste of the type_setattr source code, just to remove a check, this is not great for future compatibility with python (at each revision of Python I have to check if type_setattr has not change to copy-paste the changes). In fact I'm really wondering what's the real meaning of this flags, but I think there is some history behind it. If you think this is not the right place for this question, just ignore it, and sorry for disturbance. Boris

17 years, 5 months

Buffer object API

by s.keim

> Greg Ewing: > That's completely different from what I had in mind, which was: > > (1) Keep a reference to the base object in the buffer object, and > > (2) Use the buffer API to fetch a fresh pointer from the > base object each time it's needed. > > Is there some reason that still wouldn't be safe enough? I don't know if this can help, but I have once created an object with this behaviour, you can get it at: http://s.keim.free.fr/mem/ (see the memslice module) From my experience, this solve all the problems caused by the buffer object. Sébastien Keim

17 years, 5 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev October 2003