Python-Dev February 2004

python-dev@python.org

96 participants
135 discussions

math.sqrt(-1) - NaN, ValueError or whatever you want?
by Jack Jansen 05 Feb '04

05 Feb '04

The answers to my math questions never seem to stick, so I'm afraid I'm gonna have to ask this question again (even though I think I did the same a couple of years ago, but google doesn't find it). It turns out that on MacOS math.sqrt(-1) returns "nan", as does math.log(-1), and I didn't try any other ones. This is true for all possible combinations of MacPython 2.3, 2.4a0 or apple-Python 2.3, MacPython-OS9 or MacPython-OSX, and Mac OS 9 or Mac OS X. When I tried the same on a linux box (Python 2.4a0) it raised ValueError: math domain error, which is what I would have expected. Why this difference? Is it something I should fix? How? Or document it? -- Jack Jansen, <Jack.Jansen(a)cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman

3 2

RE: [Python-Dev] PEP 327: Decimal Data Type
by Batista, Facundo 05 Feb '04

05 Feb '04

Stephen Horne writes: #- Good point. A 'DecimalExact' or similar function could perhaps be #- provided to replace the simple conversion when people have really #- thought about it and do really want it. So, making it short: When you have som rounding, it's ok to have a second parameter: Decimal(1.1, 2) == Decimal('1.1') I proposed that without the second parameter, the conversion to be exact: Decimal(1.1) == Decimal('110000000000000008881784197001252...e-51') Michael Chermside proposed to have the second parameter mandatory: avoids the problem of a newbie forgetting it, and if you want an exact conversion you can always put a very large number (e.g.: 60). If the second parameter will be mandatory, I prefer a non sense number there, for example: 0. And Stephen Horne proposed to have an explicit method to do the exact conversion, kind of: Decimal.fromFloat(1.1) == Decimal('110000000000000008881784197001252...e-51') So, we need to choose one of three ways to obtain an exact conversion: 1. Without a second parameter. 2. With a second parameter "big enough" or a special value (0? -1?) 3. With another method. Name? Thank you all! . 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.

2 1

pickle.dump(..) interface change ... documentation
by Christian Stork 05 Feb '04

05 Feb '04

Hi, I just ran across something that looks like a very unfortunate interface change in the pickle module: Python 2.2: dump(object, file[, bin]) Python 2.3: dump(object, file[, protocol[, bin]]) ...and indeed I have code, which uses pickle.dump(obj, f, True). Hmm, ok, so probably this means now (under python 2.3) I'm using protocol number 1 (==True)?! Tricky. :-) Maybe that warrants a comment in the docs? Thanks, Chris -- Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/ OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F

6 7

Charles Waldman?
by Skip Montanaro 05 Feb '04

05 Feb '04

Sorry for the OT post. Has anyone got a contact for Charles Waldman? He used to be at FermiLab, then at a small trading firm in Chicago, but he's left there as well. Thx, Skip

1 0

RE: [Python-Dev] namespace for generator expressions
by Phillip J. Eby 04 Feb '04

04 Feb '04

At 09:02 AM 1/27/04 +1100, Delaney, Timothy C (Timothy) wrote: > > From: Guido van Rossum > > > > > I'm happy to see progress on the generator expressions > > implementation, > > > but I think the specification of namespaces, which is just a sketch, > > > might be simplified. > > > > Ouch! Where were you when this PEP was discussed on python-dev? I > > was originally strongly in your camp, but Tim and several others > > convinced me that in every single case where a generator expression > > has a free variable, you want early binding, not late. > >I think I agree with Jeremy. I was originally in the early-binding camp, >but I think we're better off trusting the programmer. The intent is that listcomps should be "safely" replaceable with genexprs anywhere that an iterator is acceptable in place of a list. >How often is a generator expression not going to be evaluated almost >immediately? I guess, when they're passed to a function. But even in that >case, how often are the bindings going to change? Except in pathological >cases, they won't. A trivial example is: iterators = [] for i in range(5): iterators.append(x*2 for x in range(i)) print map(list,iterators) If a listcomp is used, you get: [[],[0,],[0,2],[0,2,4],[0,2,4,6],[0,2,4,6,8]] If genexprs do late binding, you get: [[0,2,4,6,8],[0,2,4,6,8],[0,2,4,6,8],[0,2,4,6,8],[0,2,4,6,8]] which is a significant difference in semantics. To make this code work with a late binding genexpr, it becomes necessary to create a function definition, thus negating the benefit of using the genexpr in the first place. As to how common this is, ask how often you use a list comprehension inside of another loop, and then ask how often you'd use a genexpr instead if it was available. Finally, ask yourself whether you're likely to remember that you need to totally rewrite the structure if you decide to use a genexpr instead. :) (Of course, I also often forget that free variables don't bind early in nested functions! It always seems strange to me that I have to write a function that returns a function in order to just define a function with bound variables. Indeed, it's hard to think of a time where I've *ever* wanted late binding of variables in a nested function.)

5 6

Proposed addition to ftplib
by Jordan Haven 03 Feb '04

03 Feb '04

Hey Python developers! First, since this is my first message to this group, let me introduce myself. My name is Jordan Haven, I'm 16, I live just outside of DC and have been programming for only a few years (~ 2 years). Python was the first language I started, and I have loved it since the beginning. Now, onto the real purpose of this email. Recently, while creating a CLI FTP program as a precursor to my GUI version (SF project: ftpy), I ran into a roadblock: I couldn't change permissions on the remote file. So I searched the comp.lang.python newsgroup, the python-list archives, these development archives, and countless ftplib tutorials and books and couldn't find anything on chmod'ing files through FTP with the standard ftplib module. So I went through ftplib.py (Python 2.3), and there was no function for chmod'ing files. I think (and hope you all will agree with me :)) that there needs to be a chmod funtcion included in the ftplib module. So I took the liberty to write one up (see attached). It works fine on my box (Windows 2000 with Python 2.3), and there aren't any obvious backwards compatibility problems that I can see, so the only thing left is to test crossplatform portability. However, looking at the code there doesn't seem to be any issues with that, but if some of you could check it out on various other platforms, I would be most appreciative. Hopefully it (or a modified version) will make it into the next release of Python. Well, thank you for your time, and for taking a look at the included function. I look forward to hearing back from you. -- Jordan Haven _________________________________________________________________ Find high-speed net deals comparison-shop your local providers here. https://broadband.msn.com

4 3

release23-maint is reopened for business.
by Anthony Baxter 03 Feb '04

03 Feb '04

The release23-maint branch (for bugfixes on the 2.3 train of code) is now open for your bugfixing pleasure. My next (planned) release off that branch will be May-June, assuming Tim doesn't create^H^H^H^H^H "find" any more critical bugs before then. (Oh sure, he'll claim that the bugs were there already...) ta, Anthony

2 1

OSCON Reminder: proposal deadline Februrary 9
by Guido van Rossum 03 Feb '04

03 Feb '04

Just a quick reminder: you have another week to submit a proposal for the Python 12 Conference at OSCON: The O'Reilly Open Source Convention (OSCON) will be held July 26-30, 2004 at the Portland Marriott Downtown in Portland, OR. http://conferences.oreillynet.com/os2004/ Proposals Submission Information--Deadline: February 9, 2004 http://conferences.oreillynet.com/cs/os2004/create/e_sess --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

RE: [Python-Dev] PEP 327: Decimal Data Type
by Michael Chermside 02 Feb '04

02 Feb '04

I wrote: > (a) What's the syntax for changing the context? I'd > think we'd want > a "pushDecimalContext()" and "popDecimalContext()" sort of > approach, since most > well-behaved routines will want to restore their caller's context. Facundo Batista replies: > You can save a copy of the context in a variable and then > restore it. No stack. Imagine the following senario. I write some code which uses Decimal, and which sets the context to get the desired rounding behavior. Somewhere in my code I call a routine written by somebody else... perhaps some library code... which also does some calculations using Decimal. It would be a major pain if every time I called that library code it changed the context. I'd have to keep setting the context back after each and every call to the library code. A well-behaved library will not require me to go through these contortions, so after it does its work it will set the context back to what it was when I called it. It seems to me that in almost all situations where one changes the context, one will also want to restore it later. If so, then it seems perverse to tell every user that they must capture and store the old context someplace and restore it later. Why not make the best practice be the *obvious* idiom by providing matched pushContext() and popContext() functions as the normal way of setting the context. Of course, one could choose to call pushContext() without a matching popContext(), or call popContext() repeatedly until the stack is empty (some exception is raised), but if the best behavior is the easy behavior then most people will use it. And if that didn't convince you, then go ahead... I think it's only a minor detail. -- Michael Chermside

4 4

RE: [Python-Dev] PEP 327: Decimal Data Type
by Batista, Facundo 02 Feb '04

02 Feb '04

Michael Chermside wrote: #- Imagine the following senario. I write some code which uses #- Decimal, and which sets the context to get the desired rounding #- behavior. Somewhere in my code I call a routine written by #- somebody else... perhaps some library code... which also does #- some calculations using Decimal. This subject already has been discussed in c.l.p: Emile van Sebille: ...from which I infer that Context exists in part to limit/round calculated results. Even if it were possible for me, as a user of Decimal, to set Context appropriately to achieve these ends, what if I use a library that also changes Context? The integrity of my calculations may be impacted. Aahz: That's correct. There needs to be a social convention that libraries intended for use by other people *CANNOT* muck with Context, and if they do so for their own internal calculations, they must save and restore Context. You can probably find additional information about this in Cowlishaw. Emile van Sebille: Enter the context stack. Aahz: Well, sure. And it won't be hard to add given that Decimal will already need to track thread-specific Context. But modules changing Context will still need to explicitly push and pop Context because usually you will just want to replace the current Context. Tim Peters: They have another choice, because Guido had a brilliant idea: the arithmetic operations in Eric's implementation are methods *of* a context object (because Guido suggested that). So a maximally robust library doesn't *have* to change the thread context at all: it can create whatever private context object(s) it needs, and spell arithmetic as explicit method calls on its private context object(s), so that the default thread context object is neither consulted nor modified. This is very robust, and in small doses is quite bearable. I don't have any problem to implement a context stack. But I think that it's no clear to be useful, so I think it's better to go for the sure staff, and when Decimal gets heavy use, if everybody agrees to add a context stack, we'll go for it. What do you think? . 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.

2 1

Jump to page:

2022

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 February 2004