Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #8239 > unrolled thread

python 3 constant

Back to article view | Back to comp.lang.python

Contents

  python 3 constant sidRo <slacky2005@gmail.com> - 2011-06-22 11:54 -0700
    Re: python 3 constant Noah Hall <enalicho@gmail.com> - 2011-06-22 22:17 +0100
      Re: python 3 constant "Waldek M." <wm@localhost.localdomain> - 2011-06-23 08:40 +0200
        Re: python 3 constant Ben Finney <ben+python@benfinney.id.au> - 2011-06-23 17:22 +1000
          Re: python 3 constant "Waldek M." <wm@localhost.localdomain> - 2011-06-23 13:58 +0200
            Re: python 3 constant Ben Finney <ben+python@benfinney.id.au> - 2011-06-23 23:04 +1000
              Re: python 3 constant "Waldek M." <wm@localhost.localdomain> - 2011-06-25 12:42 +0200
            Re: python 3 constant Chris Angelico <rosuav@gmail.com> - 2011-06-24 01:29 +1000
              Re: python 3 constant "Waldek M." <wm@localhost.localdomain> - 2011-06-23 21:56 +0200
                Re: python 3 constant Chris Angelico <rosuav@gmail.com> - 2011-06-24 08:00 +1000
                  Re: python 3 constant "Waldek M." <wm@localhost.localdomain> - 2011-06-25 12:50 +0200
                    Re: python 3 constant Chris Angelico <rosuav@gmail.com> - 2011-06-25 20:59 +1000
                      Re: python 3 constant "Waldek M." <wm@localhost.localdomain> - 2011-06-25 13:24 +0200
                Re: python 3 constant alex23 <wuwei23@gmail.com> - 2011-06-23 20:04 -0700
                  Re: python 3 constant "Waldek M." <wm@localhost.localdomain> - 2011-06-25 12:44 +0200

#8239 — python 3 constant

How to declare a constant in python 3?

[toc] | [next] | [standalone]

#8243

On Wed, Jun 22, 2011 at 7:54 PM, sidRo <slacky2005@gmail.com> wrote:
> How to declare a constant in python 3?

There aren't true constants in Python, but instead we use a standard
defined by PEP 8, which states constants are in all caps, for example,
PI = 3.14, as opposed to pi = 3.14 which could change (according to
PEP 8, that is)

[toc] | [prev] | [next] | [standalone]

#8271

Dnia Wed, 22 Jun 2011 22:17:49 +0100, Noah Hall napisał(a):

> On Wed, Jun 22, 2011 at 7:54 PM, sidRo <slacky2005@gmail.com> wrote:
>> How to declare a constant in python 3?
> 
> There aren't true constants in Python, but instead we use a standard
> defined by PEP 8, which states constants are in all caps, for example,
> PI = 3.14, as opposed to pi = 3.14 which could change (according to
> PEP 8, that is)

That said, there are some workarounds for that:
http://code.activestate.com/recipes/65207-constants-in-python/?in=user-97991

Still, I'd reallly like to have constants as a built-in...

Best regards,
Waldek

[toc] | [prev] | [next] | [standalone]

#8276

"Waldek M." <wm@localhost.localdomain> writes:

> Still, I'd reallly like to have constants as a built-in...

If you mean creating a binding which can't be re-bound: −1.

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.

-- 
 \       “I love and treasure individuals as I meet them, I loathe and |
  `\     despise the groups they identify with and belong to.” —George |
_o__)                                                     Carlin, 2007 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#8291

Dnia Thu, 23 Jun 2011 17:22:37 +1000, Ben Finney napisał(a):
> If you mean creating a binding which can't be re-bound: −1.

Perhaps. Or perhaps that could be done in some other fashion;
I admit that I usually stick to more strict languages
and while Python's flexibility is great... I'm really missing
constants.

> 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?
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,
and not the other way around, which would be sacrifising
code security to make testing easier.

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.

Of course, it is just my personal opinion. It might be not pythonic,
I may be wrong, yet - concept of constants is not something new and
if other languages, like C/C++/Java/Perl/ (bash even) have them, 
I can't see the reason not to have them in Python.

Best regards,
Waldek

[toc] | [prev] | [next] | [standalone]

#8292

"Waldek M." <wm@localhost.localdomain> writes:

> Dnia Thu, 23 Jun 2011 17:22: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.

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

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

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

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.

-- 
 \     “Don't be afraid of missing opportunities. Behind every failure |
  `\         is an opportunity somebody wishes they had missed.” —Jane |
_o__)                                          Wagner, via Lily Tomlin |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#8441

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

[toc] | [prev] | [next] | [standalone]

#8308

On Thu, Jun 23, 2011 at 9:58 PM, Waldek M. <wm@localhost.localdomain> wrote:
> Of course, it is just my personal opinion. It might be not pythonic,
> I may be wrong, yet - concept of constants is not something new and
> if other languages, like C/C++/Java/Perl/ (bash even) have them,
> I can't see the reason not to have them in Python.
>

You can have them in Python. Just run your code through cpp (the C
preprocessor) first. Voila!

It's handy for other things too. Don't like Python's lack of "then"
and "end if"?

#define then :
#define end(x)

lst=[1,2,3]
if lst then
  do_stuff
end(if)

You can even make functions that take reference arguments!

#define inc(x) x=x+1

i=3
inc(i)
print("i = ",i)
j=4
inc(i+j)
print("i + j = ",i+j

This is an excellent technique, and I heartily recommend it.

Assuming you're writing an entry for the International Obfuscated
Python Code Contest, that is.

ChrisA

[toc] | [prev] | [next] | [standalone]

#8324

Dnia Fri, 24 Jun 2011 01:29:38 +1000, Chris Angelico napisał(a):
> You can have them in Python. Just run your code through cpp (the C
> preprocessor) first. Voila!
> 
> It's handy for other things too. Don't like Python's lack of "then"
> and "end if"?
[...]
Yup, got the sarcasm, that's for sure.
But your point was...?

Br.
Waldek

[toc] | [prev] | [next] | [standalone]

#8330

2011/6/24 Waldek M. <wm@localhost.localdomain>:
> Dnia Fri, 24 Jun 2011 01:29:38 +1000, Chris Angelico napisał(a):
>> You can have them in Python. Just run your code through cpp (the C
>> preprocessor) first. Voila!
>>
>> It's handy for other things too. Don't like Python's lack of "then"
>> and "end if"?
> [...]
> Yup, got the sarcasm, that's for sure.
> But your point was...?

That if you want something, there's usually a way to get it.
Sometimes, giving someone what they want - or showing them how to get
it - makes it obvious to them whether or not they really want it.

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#8443

Dnia Fri, 24 Jun 2011 08:00:06 +1000, Chris Angelico napisał(a):
>> Yup, got the sarcasm, that's for sure.
>> But your point was...?
> 
> That if you want something, there's usually a way to get it.
> Sometimes, giving someone what they want - or showing them how to get
> it - makes it obvious to them whether or not they really want it.
> 
> Chris Angelico

Usually, it does. But presenting me with a fake and
obviously-not-logical-and-useful version of constants didn't really
say anything about why is having constants such a bad idea :-)
Just like presenting me with a rotten apple doesn't prove
anything general about that fruit.

I'm not into endless/pointless advocacy; I'm really curious.

And - as I've answered to someone else - I dont't *require* anyone
to change anything in the language. I just miss the feature and can't
really think of a sensible reason why it so wrong.

Best regards,
Waldek

[toc] | [prev] | [next] | [standalone]

#8444

2011/6/25 Waldek M. <wm@localhost.localdomain>:
> Dnia Fri, 24 Jun 2011 08:00:06 +1000, Chris Angelico napisał(a):
>>> Yup, got the sarcasm, that's for sure.
>>> But your point was...?
>>
>> That if you want something, there's usually a way to get it.
>> Sometimes, giving someone what they want - or showing them how to get
>> it - makes it obvious to them whether or not they really want it.
>>
>> Chris Angelico
>
> Usually, it does. But presenting me with a fake and
> obviously-not-logical-and-useful version of constants didn't really
> say anything about why is having constants such a bad idea :-)
> Just like presenting me with a rotten apple doesn't prove
> anything general about that fruit.

In all seriousness, sometimes adding features to one language is best
done by dropping to another. This is probably not as useful in
interpreted languages like Python, but I have on multiple occasions
run code through the C preprocessor as part of my compilation process,
as per my example.

ChrisA

[toc] | [prev] | [next] | [standalone]

#8445

Dnia Sat, 25 Jun 2011 20:59:17 +1000, Chris Angelico napisał(a):
> In all seriousness, sometimes adding features to one language is best
> done by dropping to another. This is probably not as useful in
> interpreted languages like Python, but I have on multiple occasions
> run code through the C preprocessor as part of my compilation process,
> as per my example.

A little off-topic but I see your point :-) Tried it once or twice - when
generating some C++ and .sip files code from a template, then generating
SIP wrappers, then generating .pyd libraries, then using in Python...  

Yeah, might be useful, even if sometimes complexity of the process
is a bit overwhelming to me :-)

Br.
Waldek

[toc] | [prev] | [next] | [standalone]

#8343

"Waldek M." <w...@localhost.localdomain> wrote:
> But your point was...?

That it's easier for you to find ways to achieve what you want than it
is require Python to change to accommodate your need.

[toc] | [prev] | [next] | [standalone]

#8442

Dnia Thu, 23 Jun 2011 20:04:43 -0700 (PDT), alex23 napisał(a):
>> But your point was...?
> 
> That it's easier for you to find ways to achieve what you want than it
> is require Python to change to accommodate your need.

And when exactly did I write that I require anyone to change anything?
I'd like that, sure. IMHO it'd be useful. But I don't *require*.

Can you see the slight difference? :-)

Best regards,
Waldek

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web