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
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.
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
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
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.)
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
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
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
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.
