Mailman 3 April 2004 - Python-Dev

syncmail question - how to get submitter as From:?
by Skip Montanaro 16 Apr '04

16 Apr '04

(I'm not sure where precisely to address this. I'd send it directly to Barry but figure that someone else might also know the answer and have infinitessimally more time to respond.) In my new job I nipped the Python project's syncmail script and added it to our CVSROOT. I then tweaked the loginfo file to run syncmail under the proper conditions. The messages go out just fine, but they come from server@servername instead of from the person who executed the checkin (e.g. skipm@servername). Since that's the only indication in the syncmail message who performed the checkin I'd like to get that corrected. It appears syncmail just sends out the message as the user it's running as. Is this a cvs server setting or some tweak to the SF version of CVS? Locally we're running cvs 1.11.2, which seems to match what SF runs on shell.sf.net. Thanks, Skip

3 3

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

16 Apr '04

[Casey Duncan] #- If the context must be explicitly provided as an argument #- (rather than #- just a flag) I think a) is better. It depends also on what other #- arguments the constructor has, and thus what other contracts it #- fulfills. Are there other optional arguments? Until now, it receives just the number. Community seems to agree to be optional to pass a context for construction-time. There isn't other argument by now. . Facundo

1 0

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

16 Apr '04

[Tim Peters] #- [Facundo Batista, on max exponent] #- > But it's still an artificial restriction. We have no-limit longs, #- > should have limited Decimal? #- #- Nobody has a use for unbounded exponents, so it's a silly #- thing to support #- if there are costs. There are costs, including: #- #- + As mentioned last time, eliminating bounds on exponents effectively #- ... #- + Virtually all implementations of 854 use (and as IBM's #- ... #- + Big as it is, the IBM standard is a tiny start at supplying a #- ... The feeling previous to this mail was that an artificial limit was silly if you don't gain nothing. Here are three valuable reasons for keep the limits. So, if nobody opposes strongly, I'll put these reasons in the PEP and keep the limit. #- > not creations (with the exception of from_string). #- #- I don't understand. The only place the spec uses the word #- "creation" is in #- regard to the creation of context objects. What do you mean #- by "creations"? #- Context does affect every way of creating a decimal number #- in the spec; the #- only ways to create numbers covered by the spec are via #- operations (and #- from_string isn't a special case here, from_string is just one of the #- required operations in the spec, and all operations covered #- by the spec #- respect context). Until now, Decimal does not uses context in creation time (with creation I mean when you create an object instantiating the class). This allows to not lose any information at creation time, and only use the context in operations. Do you want to change this behaviour? #- > I'm lost here. Are you saying that str() should have the #- same behaviour #- > that to_sci_string()? #- #- Yes, that str(Decimal) should produce exactly the string the Ok. #- supplied. The #- meaning of to-sci-string is precisely specified by the #- standard, and is a #- good choice for both str(Decimal) and repr(Decimal). (It's both #- human-readable and exact.) The only issue *I* see here, is that you don't have a clear representation of the internals of the object, but yes, you have an exact representation of that number. Let me show an example: >>> d = Decimal.Decimal((1, (1,2,3,4,0), 1)) >>> d Decimal( (1, (1, 2, 3, 4, 0), 1L) ) >>> d.to_sci_string() '-1.2340E+5' There you have to count the decimals and use the exponent in the string to know what the real exponent is (but I don't know how much important this is). . Facundo

3 2

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

16 Apr '04

[Ka-Ping Yee] #- My understanding of the reason for disallowing a float #- argument to the #- Decimal constructor is that people may be confused by exact #- conversion: #- they don't realize that the exact value may be slightly different #- from the decimal number they entered. #- #- My point is that since exact conversion is the confusing case, that's #- what the special method should be for. I think is deeper than that. For example, *I* don't understand what is "exact conversion" to you: 1.1 -> "1.1" 1.1 -> "1.1000000000000001" 1.1 -> "1.100000000000000088817841970012523233890533447265625" So, what is the expectation that floating point newbies will understand this safely enough as to let them create from: Decimal(float, extra_argument) Decimal.exact_float() To me, is complicate the things to much for the newcomer. I think the following reasoning is simpler: Do you want to create from string? Strings are exact, use Decimal(string) Do you want to create from int/long? Ints and longs are exact, use Decimal(int/long) Do you want to create from float? Oops, floats are NOT exact, so you have to use Decimal.from_float(float), but take note of this, this and this. . Facundo

1 0

RE: [Python-Dev] Decimal data type issues
by Moore, Paul 16 Apr '04

16 Apr '04

From: Ka-Ping Yee > Here is my point, again: Decimal(1.1, significant_digits=4) is unambiguous. > > Converting from float is not confusing when the precision is specified > (either in terms of significant digits or decimal places). Decimal(1.1, significant_digits=34) is unambiguous, but confusing. Paul. __________________________________________________________________________ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. __________________________________________________________________________

2 1

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

16 Apr '04

[Ka-Ping Yee] #- Aren't you going to need an optional argument anyway to let the #- user specify a context? What for? #- I assume the purpose of from_float is to prevent people from being #- confused about whether Decimal(1.1) produces exactly 1.1 or #- the machine #- value of the double-precision rounded float closest to 1.1. Is that #- correct? #- #- If so, then the real exceptional case is *exact* conversion, #- not float #- conversion. Decimal(1.1, precision=4) is unambiguous. Therefore: Here I think you're confused. *Precision* is a parameter of the context, and determines in how many digits you will get the coefficient after an operation. The issue when constructing from float, is how many *positions* after the decimal point will be relevant when creating from a float. This list agreed to have a special method to creating from float, to avoid confusing users about the real behaviour there. And in that method only you permit to specify the positions. When constructing from other data types, positions does not have any meaning as those other data types are always exact. #- The extra method should be specifically for the exceptional case, #- and named appropriately. #- #- Decimal.exact_float(value) #- #- It would serve just one purpose: allow exact conversion from floats #- when it's really desired. #- #- This would both (a) separate the functionality between Decimal() #- and Decimal.exact_float() in a more logical way; and (b) give #- the extra method a more meaningful, useful name -- a name that #- really explains why the extra method exists. I think that *maybe* a better name is needed, but just that. #- > Also, remember that the context doesn't affect the #- creation when you create #- > directly from string (only if you use from_string). Your #- example means to #- > change the behaviour of the creation when creating #- directly from string? And #- > when create directly from int or long? #- #- That's what I'm suggesting: that you can supply a context object, #- or ask for the default context, when constructing any Decimal value. Do you want to supply a context that *will affect* the creation process, or just supply one that the Decimal will keep to use in other operations? Remember that you have one context per thread. All the decimal instances in a thread share the same context. This was specified by Aahz, the list agreed, and get into the PEP. Do you want to change it? . Facundo

3 2

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

16 Apr '04

[Ka-Ping Yee] #- I agree with Tony. Having both Decimal() and #- Decimal.from_string() work #- in similar but subtly different ways seems likely to be #- misunderstood. Decimal(string) works the way we want/need/desire. Decimal.from_string(string) works the way the documentation specify. I think we can only change the way the former works or the name of the latter. #- I also think his last suggestion could provide a nice, #- convenient solution #- to the conversion-from-float issue, since it raises the same #- question (a #- method named "Decimal.from_float" doesn't explain how or why #- it is different #- from just constructing with a float). You can NOT construct directly from a float. That's the difference. #- So here's a more detailed suggestion. Suppose s = '12345', #- f = 12.345, #- the default context specifies a precision of 9 as given in #- the PEP, and #- c is a context object with a precision of 6. #- #- Then this: would yield this: #- #- Decimal(s) Decimal((0, (1, 2, 3, 4, 5), 0)) #- ... #- Decimal(s, context=c) Decimal((0, (1, 2, 3, 4, 5, 0), -1)) #- ... #- Decimal(f) Decimal((0, (1, 2, 3, 4, 5, 0, 0, 0, 0, 0,... #- ... The community agreed to not create directly from float. You have the from_float() method instead. Also, remember that the context doesn't affect the creation when you create directly from string (only if you use from_string). Your example means to change the behaviour of the creation when creating directly from string? And when create directly from int or long? #- (Do I assume correctly that there will be context objects #- that wrap up #- the precision and rounding mode, and there will be some sort #- of interface #- for getting and setting the current context?) Yes. You can get the context with getcontext() and then change it attributes. . Facundo

3 3

Inno Setup script for Python debug runtime
by Thomas Heller 15 Apr '04

15 Apr '04

I've made a short script (74 lines) for Inno Setup, which builds an installer for the Python debug exes, dlls, and pyds. The installer copies these debug images into the correct places when a 'normal' installation of Python is found in the registry. I don't think it would be a good idea to publish this installer on python.org, but it may be convenient for people who build python from source, because they no longer have to copy the files in place manually. Can I check this into the release-23maint branch in the PCBuild directory, or are there any objections? Thomas

5 7

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

15 Apr '04

[Michael Chermside] #- > The issue is that this limit is artificial: #- [...] #- > So, should we impose an artificial limit to the exponent? #- > #- > This is important, as there're several cases where this #- > maximums are checked #- > and exceptions raised and/or the numbers get changed. #- #- I strongly prefer for my programming language not to impose #- aribtrary limits, however, I can't see myself using decimal #- to represent numbers with 1 billion digits. So IMHO, I would #- avoid the limit if possible, but if imposing the limit #- permitted substantial code simplification or performance #- improvements then I wouldn't complain. Much. Actually, imposing the limit means more code and complexity, and I don't find any benefit. But as I answered to Paul, I'm searching for community agreement before changing functionality that I found in the implementation #- I disagree. If x == y, then that should imply that hash(x) #- == hash(y). #- So hash(Decimal(25)) == hash(25) had better be true. On the other #- hand, hash(Decimal('-33')) CANNOT equal hash(Decimal('-33')), since #- the latter must equal hash(-33). And I'm not particularly concerned #- about floats... if it's easy to make the hashes equal for those few #- numbers which can be expressed EXACTLY as both a (binary) float and #- a (decimal) Decimal, then that's be "kinda nice", but since there #- are so few values which can be expressed exactly as both a float #- and a Decimal, I don't see it as a big issue. So, while Decimal(25) == 25 is True, hash(Decimal(25)) should be equal to hash(25). The detail is that you can NOT compare Decimal to floats or strings, so maybe we should not worry about them to give the same hashes. I'm OK to make hash(int or long) == hash(Decimal(int or long)). But only to int or long, not float nor string. Do you agree? . 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.

7 9

Use case for class decorators
by Goncalo Rodrigues 15 Apr '04

15 Apr '04

Here is a use case for class decorators. I find myself writing a lot of proxies and adapters. Usually, they are just a subclass of something as simple as class Proxy(object): """The Proxy base class.""" def __init__(self, obj): """The initializer.""" super(Proxy, self).__init__(obj) #Private attributes. self.__obj = obj #Read-only properties. __obj__ = property(lambda self: self.__obj, doc = "The underlying object of the Proxy.") def __repr__(self): return "%s(%r)" % (self.__class__.__name__, self.__obj__) def __getattr__(self, attrib): return getattr(self.__obj__, attrib) This is all fine and dandy, except that no magic methods are trapped. Usually, I just inject them directly after the class statement via: #Auxiliary getter function. def getter(attrib): return lambda self, *args, **kwargs: getattr(self.__obj__, attrib)(*args, **kwargs) def inject(cls, magicnames): """Inject magic methods directly in a class. Warning(s): - Only magic names are injected. - Does not overwrite already present magic names. """ for magicname in magicnames: if magicname.startswith("__") and magicname.endswith("__"): if not hasattr(cls, magicname): setattr(cls, magicname, getter(magicname)) The function inject is a use case for a class decorator. If it's a good use case that's something I'll leave you to argue at will (<runs away>). I think it's fairly obvious that using a metaclass to do this simple operation is a clear case of the wrong tool for the job. With my best regards, G. Rodrigues p.s: <comment on syntax> The syntax for decorators: [dec1, dec2, ...] def foo(arg1, arg2, ...): pass is probably the worst of all syntaxes (with appologies for my bluntness). It just doesn't parse well. What I see in the above proposed syntax is just a list literal and a definition statement. There's no indication that the two are somehow linked (I can't express this any better, English is not my native lingo). The best, IMHO is def foo(arg1, arg2, ...) [dec1, dec2, ...]: pass <\ comment on syntax>

1 0