> For example (I believe it's already been mentioned) "declaring" intX with
> some integer value does *nothing* to maintain
>
> X as an integer:
>
> --> intX = 32
>
> --> intX = intX / 3.0
>
> --> intX
>
> 10.66
>
Yes I did see that it is possible to redefine the type of a variable
>> intX = 32 # decl + init int var
> How is it not obvious that "intX" is an integer *without* the comment?
Indeed the assignment is enough to deduce "intX" is an int. The comment is
there to let me know it is unlikely intX appears earlier in the code. Please,
let me do
Josh,
Not thank you for your malicious post.
I think you are missing the point here.
My source code was just a dummy to offer context for the question I wanted to
ask. Further down the line, if I ever feel I don't need to pseudo-declare
variables I will stop doing it. But for the moment I am tr
> > if (some statement):# short form
> >
> > rather than
> >
> > if (some statement == true):# long form
>
>
> What all those ugly brackets are for?
>
Mark,
Back in the day when C was king, or take many newer long established languages
(C#, Java), the use of () has bee
> To demonstrate that the person who wrote this code was not a good Python
>
> programmer. I hope it wasn't you :-) This person obviously had a very
>
> basic, and confused, understanding of Python.
>
>
>
> And, quite frankly, was probably not a very good programmer of *any*
>
> language:
Hi guys,
Question. Have this code
intX = 32 # decl + init int var
intX_asString = None # decl + init with NULL string var
intX_asString = intX.__str__ ()# convert int to string
What are these ugly underscores for? _str__
Hi all,
(Ethan, I like your "resident troll" statement. Highly exit-aining!)
Thanks for all the input. I did not expect to get so much constructive
feedback, the more so that my initial attitude towards Python has been less
than positive, diplomatically speaking.
Yes, it's true that I am tryin
Hi Ian,
Thanks for typing all this for me. Really useful. I did some googling of my own
and I found that there was no concept of boolean in older versions of Python
like you said. (BTW, how does this omission go well with proper language
design, as Oscar seems to have hinted?) I think this obvi
Thanks to everyone for all the posts, some friendly some not. I read all of
them with genuine interest.
So I am continuing to learn Python, here are my new observations for your
consideration.
There seems to be a "heated" argument about Python's apparently intentional
ambiguity in conditional
Hi Chris,
Thanks for this. Regarding ambiguity, you will never find me write ambiguous
code. I don't sabotage my own work. But the reality is that in addition to
writing my own code, I have to maintain existing. I find it incredibly
confusing then I see a statement along the lines of "if not so
Thanks to all for quick relies.
Chris, you are (almost) spot on with the if blocks indentation. This is what I
do, and it has served me well for 15 years.
code
code
if (some condition)
{
code
code
}
code
code
This is what I call code clarity. With Python, I am having to d
11 matches
Mail list logo