python 3 constant

Waldek M. wm at localhost.localdomain
Sat Jun 25 06:42:41 EDT 2011


Dnia Thu, 23 Jun 2011 23:04:37 +1000, Ben Finney napisał(a):
>>> The ability to re-bind any attribute, even ones which the author
>>> thought should be constant, makes writing unit tests much easier. I
>>> don't see that putative benefits of constant bindings would be
>>> anywhere near as valuable.
>>
>> Primo, isn't it usually the author that does the unit testing?
> 
> I don't see how that's relevant. I'm referring to run-time re-binding of
> attributes, without the need for changing the code.

I meant simply that the author knows his/hers software and takes into
consideration while unit testing the fact that some things is constant.
I still can't see how checking if 2 == 2 (in the morning, in the afternoon
and in the night, and even tomorrow) helps making the software
significantly better.

>> Anyway, correct me if I'm wrong but I always thought that unit tests
>> should prove the correctness and quality of the code under test,
> 
> Right. Which often involves special set up of the environment in which
> that code runs, in order to conduct a proper test.
> 
> If the test I need to perform involves demonstrating what the code under
> test will do with different values for a name you consider constant,
> then I have Python's ability to re-bind that name at run-time.

In languages that allow constants, you can still make dirty hacks, like
casting to pointers, const_cast<>'ing and so on.
It is technically possible to override the constants one way or another;
yet I (and many people) find it useful that the language itself helps me
preventing myself from eg. distraction or being overwhelmed by the size of
a project.

Or, when a project is being developed by several people, helps
avoiding problems caused by 'hey, I thought binding 5 to this great 
name DOZEN was a realy great idea' attitude.

>> Secundo, one can say that re-binding gives the freedom to change what
>> one likes; I'd say that I'd also like the freedom to decide what is
>> mutable and what is not.
> 
> And I, as the user of your code, say that you don't get to dictate how I
> use it. I will take the authors's recommendations under advisement, but
> I reject any authority to restrict what I can do with it.
> 
> Unit tests are just an obvious example. The real lesson here is that the
> reciient of the code you write can, and probably will, use it in ways
> you never expected. It's not for you to decide which of those uses are
> permitted.

He can take my code and rework it if he/she likes. If that's what he wants,
that's fine with me. If he doesn't want to do that, I'm pretty sure he'll
find another ways to hack the logic I put into my code.
But he's one for a thousand; the rest would be rather grateful to me that
I let them know some things are constants. And currently, in Python,
I cannot do that.

>> Of course, it is just my personal opinion. It might be not pythonic,
> 
> Right. One useful phrase to remember from the founder of the Python
> language is that “We're all consenting adults here”.

I agree with that statement, sure. Only... I've never seen an adult who
doesn't make mistakes and who shouldn't be given any instructions.

> Indicate through the API and its documentation how you recommend I use
> your code; but treat me as an adult capable of making my own decisions
> about what risks I accept. Understand that I will be using the code you
> wrote in the way I see fit.

Yup. That's what I'd like to do: be able to indicate in the API that some
things should be *better* left unchanged. That A_DOZEN_IN_INTEGER IMO
should really stay 12, not 1 or -23.34. 

Documentation is a great thing, but tends to go out of date pretty soon..
much sooner than the code itself. Not mentioning those who just don't read
them carefully enough (I guess you'd call them non-adults, right? ;-) ).

So let me warn with language syntax that it's probably not a good idea
to change 'this' and 'that'. Do they still want to change it? It's their
responsibility, I'd let them hack themselves silly...

To summarize: I do miss constants in Python and I think Python could really
benefit from them. I haven't seen so far any convincing argument to not
have them. That said, I'm not that kind of person who says "hey, you Python
people, give me my constants or I won't use it". No, I like the language, 
I will still learn it and use it...  and I'll still miss the constants ;-)

Best regards,
Waldek



More information about the Python-list mailing list