Prev: Python parsing XML file problem with SAX
Next: Linear nterpolation in 3D
From: Carl Banks on 29 Jul 2010 11:29
On Jul 28, 7:45 pm, Steven D'Aprano <steve-REMOVE-
T...(a)cybersource.com.au> wrote:
> On Wed, 28 Jul 2010 08:47:52 -0700, Carl Banks wrote:
> > On Jul 28, 7:32 am, Steven D'Aprano <st...(a)REMOVE-THIS-
> > cybersource.com.au> wrote:
> >> On Wed, 28 Jul 2010 09:35:52 -0400, wheres pythonmonks wrote:
> >> > Thanks ... I thought int was a type-cast (like in C++) so I assumed I
> >> > couldn't reference it.
>
> >> Python doesn't have type-casts in the sense of "tell the compiler to
> >> treat object of type A as type B instead". The closest Python has to
> >> that is that if you have an instance of class A, you can do this:
>
> >> a = A()  # make an instance of class A a.__class__ = B  # tell it that
> >> it's now class B
>
> >> and hope that it won't explode when you try to use it :/
>
> > Type casts in C and non-pathlogical C++ don't modify the object they are
> > casting.
>
> > int (and str, float, etc.) is the closest thing to a type cast in
> > Python.
>
> Perhaps I have been misinformed, but my understanding of C type-casts is
> that (where possible), a cast like `int(var)`

(int)var


> merely tells the compiler
> to temporarily disregard the type of var and treat it as if it were an
> int. In other words, it's a compiler instruction rather than a conversion
> function.

Even if it did, it would still be temporary. The type of the variable
remains unchanged.

But it doesn't disregard the original type: type casts try to preserve
semantic value. (double)1 returns 1.0, which is not only a different
bit pattern but a different size. That's exactly what float() does in
Python.


Carl Banks
From: Lie Ryan on 5 Aug 2010 06:27
On Wed, 28 Jul 2010 15:58:29 +0200, Ulrich Eckhardt
<eckhardt(a)satorlaser.com> wrote:
> wheres pythonmonks wrote:
> > Thanks ... I thought int was a type-cast (like in C++) so I
assumed I
> > couldn't reference it.
> Firstly, "int" is a class. Python doesn't make a distinction
between builtin
> types and class types like C++, where you e.g. can't derive from
builtin
> types.

That wasn't true until recently with class and type unification. In
some older versions of python you cannot derive from build in types
either.

From: Lie Ryan on 5 Aug 2010 06:39
On Wed, 28 Jul 2010 09:15:24 -0400, wheres pythonmonks
<wherespythonmonks(a)gmail.com> wrote:
> A new python convert is now looking for a replacement for another
perl idiom.

A functional alternative:
l = ...
seqint = compose(map, int)
print f(seqint(l))

From: Albert van der Horst on 7 Aug 2010 09:54
In article <1pm7i7-473.ln1(a)satorlaser.homedns.org>,
Ulrich Eckhardt <eckhardt(a)satorlaser.com> wrote:
>Steven D'Aprano wrote:
>> Perhaps I have been misinformed, but my understanding of C type-casts is
>> that (where possible), a cast like `int(var)` merely tells the compiler
>> to temporarily disregard the type of var and treat it as if it were an
>> int. In other words, it's a compiler instruction rather than a conversion
>> function.
>
>You are misinformed. The result of a cast in C or C++ behaves as if a
>temporary was created:
>
> int x = 0;
> unsigned(x)--; // invalid, compiler error
>
>Now, where this distinction gets blurred is when you are casting pointers:
>
> (*(unsigned*)&x)--;
>
>or, in C++, references:
>
> reinterpret_cast<unsigned&>(x)--;
>
>Technically, these are still invalid though, only that they give you
>undefined behaviour at runtime instead of a compiler error, but those are
>already very fine details of the according standards.

There is just one conclusion that should remain from this.
If you're ever going to program in in c or c++, casts are to be
avoided like the plague. (And recently they have been thought over in
C++ to be split in different names with the reinterpret_cast the most
dangerous, but at least it is a big read flag.)
I see an analogy with goto's in my experience. Once you understand
how bad they are, you discover there is always a better solution.

It is unfortunate that cast's in Python share the same name, but
it is kind of unavoidable because it is about the proper CS name to use.

>Uli

Groetjes Albert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert(a)spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

From: Carl Banks on 7 Aug 2010 16:02
On Aug 7, 6:54 am, Albert van der Horst <alb...(a)spenarnc.xs4all.nl>
wrote:
> In article <1pm7i7-473....(a)satorlaser.homedns.org>,
> Ulrich Eckhardt  <eckha...(a)satorlaser.com> wrote:
>
>
>
> >Steven D'Aprano wrote:
> >> Perhaps I have been misinformed, but my understanding of C type-casts is
> >> that (where possible), a cast like `int(var)` merely tells the compiler
> >> to temporarily disregard the type of var and treat it as if it were an
> >> int. In other words, it's a compiler instruction rather than a conversion
> >> function.
>
> >You are misinformed. The result of a cast in C or C++ behaves as if a
> >temporary was created:
>
> >  int x = 0;
> >  unsigned(x)--; // invalid, compiler error
>
> >Now, where this distinction gets blurred is when you are casting pointers:
>
> >  (*(unsigned*)&x)--;
>
> >or, in C++, references:
>
> >  reinterpret_cast<unsigned&>(x)--;
>
> >Technically, these are still invalid though, only that they give you
> >undefined behaviour at runtime instead of a compiler error, but those are
> >already very fine details of the according standards.
>
> There is just one conclusion that should remain from this.
> If you're ever going to program in in c or c++, casts are to be
> avoided like the plague.

You sound as if you don't usually program in C or C++, which suggests
to me that you shouldn't be offering advice on how to program in these
languages. I program in C all the time, and I can tell you you can't
get very far in C or C++ without sometimes resorting to type-casts. (C
++ offers more help for class types, but there's not a lot you can do
to avoid casts for converting between built-in types.)

The CPython interpreter uses type casts all over the place, BTW.

> (And recently they have been thought over in
> C++ to be split in different names with the reinterpret_cast the most
> dangerous, but at least it is a big read flag.)

If by "recently" you mean "10 years ago", and by "thought over" you
mean "standardized and implemented".

> I see an analogy with goto's in my experience. Once you understand
> how bad they are, you discover there is always a better solution.

What better solution do you propose for this that doesn't use type-
casting?

int a, b;
double ratio;

ratio = (double)a/b;


> It is unfortunate that cast's in Python share the same name, but
> it is kind of unavoidable because it is about the proper CS name to use.

Not really. Very few people call int(), float(), and company "type
casts". They aren't type casts at all, they are constructors that
sometimes have the same semantics as type casts in C.


Carl Banks
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Python parsing XML file problem with SAX
Next: Linear nterpolation in 3D