Can global variable be passed into Python function?

[Steven D'Aprano]

And, as proven here in this thread, you do not know what you are doing.

Steady on, that's a bit harsh. In context, I think that Marko is assuming
that the caller will only ever use the state values via their symbolic
names, e.g. only refer to them as IDLE, CONNECTED etc. and never use
their internal string values "IDLE", "CONNECTED".

I don't think that's a safe assumption, since it requires the caller to
only ever do the right thing, but if it is true, then using "is" in the
way he suggests cannot fail.

Still, I've repeatedly asked Marko to justify why we should care about
the symbols being singletons, and unless I've missed something, he hasn't
even attempted to justify that. It seems to me that he's just assuming
that symbols ought to be singletons, hence his focus on identity rather
than equality.

 

[Steven D'Aprano]

I need *identifiers*. I could simply define:

class ABC:
A = object()
B = object()
C = object()

The program would work perfectly.

Except, if it's got a bug. I know self.abc contains either A, B or C,
but which one? Printing out self.abc won't give me any help. I could
print out ABC.A, ABC.B and ABC.C and see which one matches, but that's
cumbersome.

All very good so far.

The next variant is to use objects that have names:

class Symbol:
def __init__(self, name):
self.name = name
def __str__(self):
return self.name

class ABC:
A = Symbol("A")
B = Symbol("B")
C = Symbol("C")


The same program still works (and still uses "is" for identity tests,
mind you).

But why are you using identity tests? Equality will work perfectly well,
and won't expose the implementation detail that these objects may be
singletons. That's especially important at the next step, when you
replace the Symbol class with regular strings. If the caller happens to
use "C" rather than ABC.C, why is this a problem?

 

[Marko Rauhamaa]

No. I'm telling you that ‘is’ is *wrong* for comparing strings,
because it is unreliable.

No, it isn't as long as the string object references have a common
assignment "pedigree." Assignment (including parameter passing) is
guaranteed to preserve identity of any object.


Marko

 

[Chris Angelico]

Steady on, that's a bit harsh. In context, I think that Marko is assuming
that the caller will only ever use the state values via their symbolic
names, e.g. only refer to them as IDLE, CONNECTED etc. and never use
their internal string values "IDLE", "CONNECTED".

A bit harsh, perhaps, but I stand by it: by repeatedly declaring that
something is safe when it has been proven not safe, he shows that he
does not know what he is doing - that he is not fully comprehending
the significance of object value vs identity as regards strings.

Incidentally, Python somewhat creates this issue, by sometimes
interning and sometimes not. (And the same with small integers,
although I've never heard the expression "int interning".) If strings
were always interned, then it would be obvious that identity and value
were one and the same. On the flip side, if a string literal always
created a new string (that is, if it were more like a "string
construction syntax" like square brackets for lists), then it would be
obvious that each one is a separate object. I don't say either option
is worth doing (especially the latter, O!), but by sometimes merging
and sometimes not, Python does slightly blur the line between identity
and value. (Obviously if strings were mutable, they'd *have* to have
separate identities.)

I don't think that's a safe assumption, since it requires the caller to
only ever do the right thing, but if it is true, then using "is" in the
way he suggests cannot fail.

If you're depending on the caller doing the right thing, it's still
safe to use == rather than is. The only reason to use 'is' is to
prevent the caller from stuffing in some other string that happens to
be correct - hence his point about being able to change the keywords.
If the caller stuffs in the string "INIT" instead of the object
Foo.INIT, then "==" will happen to work until such time as Foo.INIT
becomes "INITIALIZING", at which point it breaks. Preventing that
means that unique object identity is crucial to the system working,
and that's pretty much impossible with strings. (I don't say it's
absolutely impossible; maybe if you intern some other string with the
same value, and then construct the string you want out of pieces, and
somehow prevent the compiler from figuring out what you're doing and
optimizing it all away, then maybe you could have something that
doesn't get reused anywhere else. But it's certainly not normal to be
able to be sure of that.)

ChrisA

 

[Marko Rauhamaa]

No, '==' works fine no matter what objects you assign to your state
variables.

Well, it doesn't since
False

More generally, it depends on how the __eq__ method has been implemented
for the class. You might even (foolishly) define a class such that:
False

The "is" operator is immune to such modality.


Marko

 

[Chris Angelico]

No, it isn't as long as the string object references have a common
assignment "pedigree." Assignment (including parameter passing) is
guaranteed to preserve identity of any object.

Of course it is, but your identity tests also depend on there NOT
being a common object when there is NOT an "assignment pedigree". The
positive is guaranteed; the negative is not. And if you don't care
about a false positive - that is, that some other string with the same
value matches - then what you actually want is equality, not identity,
comparison.

ChrisA

 

[Chris Angelico]

You might even (foolishly) define a class such that:

False

Not necessarily even foolish; the SQL NULL value [1] behaves like that.

ChrisA

[1] Which isn't a value, except when it is

 

[Michael Torrie]

Well, it doesn't since

False

More generally, it depends on how the __eq__ method has been implemented
for the class. You might even (foolishly) define a class such that:

False

Yes, good point.

 

[Marko Rauhamaa]

It seems to me that he's just assuming that symbols ought to be
singletons, hence his focus on identity rather than equality.

Yes.

A practical angle is this: if I used strings as symbols and compared
them with "==", logically I shouldn't define them as constants but
simply use strings everywhere:

class Connection:
def __init__(self):
self.state = "IDLE"

def connect(self, address):
if self.state == "IDLE":
...
elif self.state == ...

The principal (practical) problem with that is that I might make a typo
and write:

if self.state == "IDLE ":

which could result in some hard-to-find problems. That's why I want get
the help of the Python compiler and always refer to the states through
symbolic constants:

if self.state == self.IDLE:


Marko

 

[Roy Smith]

Well, it doesn't since

False

More generally, it depends on how the __eq__ method has been implemented
for the class. You might even (foolishly) define a class such that:

False

Well, there's always things like SQL's NULL, which is both not equal and
not not equal to itself.

 

[Mark H. Harris]

much code. If you want to change anything, you potentially have to

edit three places: the list of constants at the top, the condition

function, and the switch.



This can't be your idea of readability. Show me where I'm wrong.



ChrisA

hi Chris, I don't think you're wrong. There are two issues for me (and one of them is not how the switch is implemented).

1) Is it easier for average users of python as a language to read switch case default, or if elif else ?

2) Would most average users concur that 'readable' means something like, "readily understandable at quick glance, or rapid preview" (or quiv).

I readily admit that 'subjective' is the operative work here. As Guido found at his 2007 keynote most experienced devs are not clamoring for a switch block. Just so. But I'm not thinking of experienced devs. I'm thinking of the average coder who is used to looking at switch blocks.

I personally can see and understand a switch block 2x to 3x faster than looking at an elif chain. Because I am primarily a C programmer and I personally use and read switch blocks.

An experienced python dev can readily 'see' an elif chain, well, because that's all they have and that's all they look at day to day. So, naturally apython dev is going to think an elif chain is readable.

Thank you sir, you have good insights. A quote from the high seas is classy..

(another post with no elipses)

Cheers

 

[Mark Lawrence]

hi Chris, I don't think you're wrong. There are two issues for me (and one of them is not how the switch is implemented).

1) Is it easier for average users of python as a language to read switch case default, or if elif else ?

2) Would most average users concur that 'readable' means something like, "readily understandable at quick glance, or rapid preview" (or quiv).

I readily admit that 'subjective' is the operative work here. As Guido found at his 2007 keynote most experienced devs are not clamoring for a switch block. Just so. But I'm not thinking of experienced devs. I'm thinking of the average coder who is used to looking at switch blocks.

I personally can see and understand a switch block 2x to 3x faster than looking at an elif chain. Because I am primarily a C programmer and I personally use and read switch blocks.

An experienced python dev can readily 'see' an elif chain, well, because that's all they have and that's all they look at day to day. So, naturally a python dev is going to think an elif chain is readable.

Thank you sir, you have good insights. A quote from the high seas is classy.

(another post with no elipses)

Cheers

No elipses, just the paragraphs not wrapped and the double line spacing.
Good old gg, I just love it.

 

[Mark H. Harris]

No elipses, just the paragraphs not wrapped and the double line spacing.

Good old gg, I just love it.

How do I fix it? Is there a setting someplace? I tried pulling up the page you linked, but blank.

Thanks in advance.

 

[Chris Angelico]

hi Chris, I don't think you're wrong. There are two issues for me (and one of them is not how the switch is implemented).

1) Is it easier for average users of python as a language to read switch case default, or if elif else ?

I personally can see and understand a switch block 2x to 3x faster than looking at an elif chain. Because I am primarily a C programmer and I personally use and read switch blocks.

Sure. But before you can ask us to consider how readable it is, we
need to have comparisons. Mock up a switch statement equivalent and
show us how it'd be better. I just looked at your version, and
couldn't see any way that it would be an improvement, because it
required that there be the exact same if/elif chain to figure out what
to switch on. So give us your readable version, in an exact
reimplementation of the if/elif chain, so we can see exactly how it
would go.

ChrisA

 

[Mark H. Harris]

Since when is the absence of action an "attempt" to do anything?

You're assuming the not-doing of something must have a purpose. That
assumption doesn't seem justified.

Correct. Argument from silence is logical fallacy; lack of motion is not the "doing" of being motionless.

 

[Steven D'Aprano]

Yes.

A practical angle is this: if I used strings as symbols and compared
them with "==", logically I shouldn't define them as constants

That doesn't follow. There is no logical connection between using named
constants (well, pseudo-constants, constants by convention only) and ==.
You can do both, or neither, or either one, whichever suits you.

You might as well say that when you have float constants:

TAU = 6.283185307179586

that "logically" implies that you are prohibited in asking whether
another float is less than or greater than TAU.

[...]

The principal (practical) problem with that is that I might make a typo
and write:

if self.state == "IDLE ":

Then used named constants.

if self.state == IDLE:


See how easy it is? Just replace "is" with == unless you have a good
reason for caring about identity instead of equality.

 

[Mark Lawrence]

How do I fix it? Is there a setting someplace? I tried pulling up the page you linked, but blank.

Thanks in advance.

https://wiki.python.org/moin/GoogleGroupsPython

 

[Mark H. Harris]

https://wiki.python.org/moin/GoogleGroupsPython

Thanks, Mark. Whoohoo! Looks like gg has some work to do. rats(). Ok, so I'm typing away here and when
I get to the boarder I should press the enter key so that the text is forced to wrap to the next line so that
you don't see the text as a run-off the page nuisance and complete annoyance leading to homicidal rage
and/or other illicit behaviors like nail-biting.
How does this look on your news client. I just need to setup an nntp server and use a real client.

Thanks for your input Mark.

Peace. marcus

 

[Chris Angelico]

Thanks, Mark. Whoohoo! Looks like gg has some work to do. rats(). Ok, so I'm typing away here and when
I get to the boarder I should press the enter key so that the text is forced to wrap to the next line so that
you don't see the text as a run-off the page nuisance and complete annoyance leading to homicidal rage
and/or other illicit behaviors like nail-biting.
How does this look on your news client. I just need to setup an nntp server and use a real client.

The usual recommendation is to wrap to 70-80 characters. Most likely
you're seeing a proportionally-spaced font, so going for the border of
the display is going to be inherently sloppy.

What I would recommend, if you don't feel like setting up NNTP, is to
subscribe to the mailing list:

https://mail.python.org/mailman/listinfo/python-list

All the same content, but via email instead. Take your pick between
that and a newsreader - whichever's easier to get to work.

ChrisA

 

[Mark Lawrence]

Thanks, Mark. Whoohoo! Looks like gg has some work to do. rats(). Ok, so I'm typing away here and when
I get to the boarder I should press the enter key so that the text is forced to wrap to the next line so that
you don't see the text as a run-off the page nuisance and complete annoyance leading to homicidal rage
and/or other illicit behaviors like nail-biting.
How does this look on your news client. I just need to setup an nntp server and use a real client.

Thanks for your input Mark.

Peace. marcus

I love it when a plan comes together