Mailman 3 April 2004 - Python-Dev

RE: [Python-Dev] Decimal data type issues
by Batista, Facundo 14 Apr '04

14 Apr '04

[Aahz] #- > Exponent Maximum #- > ---------------- #- > #- > The Decimal number composes of three elements: A sign that #- can be 0 or 1, a #- > tuple of digits where each can be 0..9, and an exponent. #- > #- > The exponent is an integer, and in the actual #- implementation exists a #- > maximum #- > value:: #- > #- > DEFAULT_MAX_EXPONENT = 999999999 #- > DEFAULT_MIN_EXPONENT = -999999999 #- > ABSOLUTE_MAX_EXP = 999999999 #- > ABSOLUTE_MIN_EXP = -999999999 #- > #- > The issue is that this limit is artificial: As long it's a #- long, you should #- > be able to make it as big as your memory let you. #- #- As long as it's in Python code, it's easy enough for a #- whiner to modify #- it. Leave it as-is. Other than that, I agree with Tim. That means that I should let the limit be, because can be easily modified? If I don't put the limit, nobody will need to modify it, :) . Facundo

1 0

RE: [Python-Dev] Decimal data type issues
by Batista, Facundo 14 Apr '04

14 Apr '04

[Tony Meyer] #- As a relative newbie, I think that it would be better if (c) #- had a name that #- somehow indicated the difference; however, I can't think of #- one offhand that #- does :) It seems to me that it would be easy to assume that The name cames from the specification. A better name it's obviously more useful. If you think one, propose it to the list and if get accepted, I'll change the code. It better be soon, because when the interface get fixed, I don't think we all would want to change it. #- Even if from_string took a parameter "honour_context", #- defaulting to True, #- that would, IMO, be more clear that there's a difference #- between the two, #- and what it is. Don't like it, because the doc specify to honor the context. I don't want the method to comply with the specification regarding the value of an argument. . Facundo

1 0

pipe syntax for sequential data
by "Maxim Krikun=?koi8-r?Q?=22=20?= 14 Apr '04

14 Apr '04

Helo python-dev. Please take a look at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/276960 This recipe proposes an alternative syntax for sequential data processing functions, that reflects unix shell pipe syntax. Here is an example: bash_users = ( file('/etc/passwd') | grep('/bin/bash') | aslist ) I don't know if this idea was already explored before; hope this can be useful. For details and sample code please see link above. regards, Maxim

7 6

Re: [Python-Dev] PEP 318 - check for consensus
by Phillip J. Eby 14 Apr '04

14 Apr '04

(I'm replying to this on the list because there are a couple of errors in it regarding names and scopes, and you probably don't want the private votes you get to be based on misunderstandings.) At 11:27 AM 4/14/04 -0400, Jewett, Jim J wrote: > Issue 1: When is the name bound? > >The current proposal is that the name does not get >bound until after the final decorator is applied. >This means that decorators do not have access to >the function by its name. > >They can learn the name, perhaps through sys._getframe, Actually, they can learn the name via the 'func_name' or '__name__' attribute of the function. sys._getframe is only needed to access any *previous* binding of the name, or to do other magic in the class or module namespace. >but the name will not yet be bound, unless it happens >to refer to an unrelated object. (See issue two for >a better way to get the name.) > >Does anyone feel strongly that the name should be >bound to the original function before decorators are >applied? > >Does anyone feel strongly that the name should be >bound to the result of each intermediate step, if >there are multiple decorators? A strong -1 on both questions. The name should not be bound until after all decorators have completed. Nobody has presented any use cases for early binding of the name, but several use cases for late binding the name. Also, all actual implementation patches to date implement the late binding. > Issue 2: Restrictions on decorators > >The working assumption had been "any callable, which >will be called with a single object as the argument" Yes. However, Mike Pall's suggestion of an e.g. '__decorate__' member has some very appealing characteristics, with the downside of requiring a more complex implementation. > Issue 2a: name of the entry point > >Is there a strong feeling (in any direction) about >calling the decorator's "decorate" or "__decorate__" >attribute, rather than its "__call__" attribute? +0.5. I like it, but not enough to want to take the time to write a new patch to implement it, at least not this month. :) > Issue 2b: context available to decorators > >Would there be any objection to passing additional >context as keywords? Only that builtin decorators like classmethod and staticmethod would have to change to support it. >decorate(object, name="myfunc") > >The obvious keywords are the name and the context's >globals; Actually, those are not the obvious keywords. The function's name is an attribute of the function, so it's redundant. For that matter, a function's globals are available as 'func_globals'. It's the enclosing *local* scope that the function was defined in that's needed. For a function defined at module level, the globals and locals are the same, but for functions defined in a class body, you need the class locals. So, 'locals' would be a more obvious keyword. > decorators should probably accept arbitrary >keywords for forward-compatibility. I'm not sure this is a good idea. The only additional argument that anyone has proposed that makes sense is the local scope. I can't imagine what kind of change to Python would result in there being anything else that one might want. On the other hand, I *can* imagine accidentally calling a decorator (assuming __call__ is used) and passing it invalid keywords that are then ignored, silencing an otherwise useful error message.

2 1

PEP 318 - check for consensus
by Jewett, Jim J 14 Apr '04

14 Apr '04

The decorator discussion has gotten lively again, and a summary would be a long list of options. I'm hoping that at least some of the decisions are non-controversial. If you have an opinion on the following, please email me directly (to not clutter the list). If several people disagree (or some disagree strongly), I'll consider the issue still undecided. Issue 1: When is the name bound? The current proposal is that the name does not get bound until after the final decorator is applied. This means that decorators do not have access to the function by its name. They can learn the name, perhaps through sys._getframe, but the name will not yet be bound, unless it happens to refer to an unrelated object. (See issue two for a better way to get the name.) Does anyone feel strongly that the name should be bound to the original function before decorators are applied? Does anyone feel strongly that the name should be bound to the result of each intermediate step, if there are multiple decorators? Issue 2: Restrictions on decorators The working assumption had been "any callable, which will be called with a single object as the argument" Issue 2a: name of the entry point Is there a strong feeling (in any direction) about calling the decorator's "decorate" or "__decorate__" attribute, rather than its "__call__" attribute? Issue 2b: context available to decorators Would there be any objection to passing additional context as keywords? decorate(object, name="myfunc") The obvious keywords are the name and the context's globals; decorators should probably accept arbitrary keywords for forward-compatibility. -jJ

3 2

RE: [Python-Dev] Decimal data type issues
by Tony Meyer 14 Apr '04

14 Apr '04

> c. ``to-number``: This operation converts a string to a > number, as defined by its abstract representation. [...] > c. from_string [...] > Regarding the method (c), the only difference with creating > the decimal with Decimal(string) is that method (c) honors > the context (if the literal contains more digits that the > current precision the numbers get rounded, and gets rounded > according to the round method specified in context, etc). > For example, with a precision of 9 and with the name I proposed:: > > >>> Decimal('112233445566') > Decimal( (0, (1, 1, 2, 2, 3, 3, 4, 4, 5, 5, 6, 6), 0) ) > >>> Decimal.from_string('112233445566') > Decimal( (0, (1, 1, 2, 2, 3, 3, 4, 4, 6), 3L) ) As a relative newbie, I think that it would be better if (c) had a name that somehow indicated the difference; however, I can't think of one offhand that does :) It seems to me that it would be easy to assume that the two above cases were the same (and given that they produce the same result in some situations, might be missed by weak testing). Certainly a quick look at documentation would correct that, but if the name could also reflect the difference, that would be better. Even if from_string took a parameter "honour_context", defaulting to True, that would, IMO, be more clear that there's a difference between the two, and what it is. So, (a) +1 (b) +1 (c) +0 =Tony Meyer

3 2

RE: [Python-Dev] Re: Decimal data type issues
by Batista, Facundo 13 Apr '04

13 Apr '04

[Bob Ippolito] #- Make hash(Decimal('123.1')) == hash(Decimal('123.1')) .. there is no I'm pretty sure that those two hash will return the same value, as long have the same argument (?). #- hash(float(1.0)) == hash(Decimal(1)) comes for free, because #- hash(float(1.0)) == hash(1). For the few other non-integer numbers #- that can be accurately represented as floating point, it might make #- sense to keep the same property? Though I suppose that is pretty #- what-the-heck-does-C-do specific, so I wouldn't blame anyone if this #- property couldn't be maintained. OK, so I won't promise it. . Facundo

1 0

RE: [Python-Dev] Re: Decimal data type issues
by Batista, Facundo 13 Apr '04

13 Apr '04

[Paul Moore] #- So far, I've found your instincts to be pretty good. I'd say #- #- 1. Remove the limits. #- 2. Make hashes the same for int/long, but not str/float. #- 3. While I'm at it, I'm OK with the names you suggest for the 3 extra #- functions. Thank you very much. . Facundo

1 0

RE: [Python-Dev] Decimal data type issues
by Batista, Facundo 13 Apr '04

13 Apr '04

[Shane Hathaway] #- Should we expect this to work? #- #- d = {} #- d[Decimal('1.1')] = 1 #- print d[float('1.1')] #- No, because Decimal('1.1') is not the same number than float('1.1')! >>> d = {} >>> d[Decimal('1.1')] = 1 >>> d {Decimal( (0, (1, 1), -1) ): 1} >>> d[float('1.1')] Traceback (most recent call last): File "<pyshell#10>", line 1, in ? d[float('1.1')] KeyError: 1.1000000000000001 In part, this is why you can not compare Decimal with float, and why you can not create a Decimal directly from float. You can use the alternative method, but you should know what you're doing: >>> Decimal.from_float(1.1) Decimal( (0, (1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 8, 8, 8, 1, 7, 8, 4, 1, 9, 7, 0, 0, 1, 2, 5, 2, 3, 2, 3, 3, 8, 9, 0, 5, 3, 3, 4, 4, 7, 2, 6, 5, 6, 2, 5), -51L) ) >>> Decimal.Decimal.from_float(1.1, 1) Decimal( (0, (1, 1), -1L) ) . Facundo

1 0

RE: [Python-Dev] Decimal data type issues
by Batista, Facundo 13 Apr '04

13 Apr '04

[Bob Ippolito] #- >>> hash(float(1.0)) == hash(1) == hash(1L) #- True #- #- Since this is already true, hash(Decimal.from_float(1.0)), #- hash(Decimal(1)), hash(Decimal(1L)), hash(Decimal('1.0')), #- hash(Decimal('1')), hash(Decimal(u'1.0')), etc. better be equal as #- well, whatever that takes. #- #- As far as arbitrary floats hashing equally, I don't really care, but #- the simple ones definitely should. Hopefully at some point, "float #- constants" (as in coming from source code or user input) in #- Python will #- actually be Decimal representations, so you don't lose #- precision until #- you ask for it. I agree. The detail is that the "simple ones" means the same Decimal that the ones constructed from ints: >>> Decimal.from_float(1.0) Decimal( (0, (1,), 0L) ) >>> Decimal(1) Decimal( (0, (1,), 0) ) >>> hash(Decimal.Decimal(1)) 1 So, you'll *always* have the same hash there. Regarding user input, treating them as strings, >>> Decimal('1') Decimal( (0, (1,), 0) ) >>> hash('1') 1977051568 There, you won't have the same hash that the string. But I don't think we need this as long as you can not compare Decimal with strings... . 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.

1 0