Can global variable be passed into Python function?

[Steven D'Aprano]

On Sun, 02 Mar 2014 13:33:11 +0200, Marko Rauhamaa wrote:

> Steven D'Aprano <steve+comp.lang.python at pearwood.info>:
> 
>> On Sun, 02 Mar 2014 11:35:43 +0200, Marko Rauhamaa wrote:
>>> Now, what kinds of object are those constants? We are not supposed to
>>> know or care.
>>
>> Incorrect. We are supposed to know and care.
> 
> Then, the documentation is seriously flawed. It gives no hint whatsoever
> on the nature of those objects.

"Seriously" flawed? I doubt it. It's a trivial, pedantic point, and I 
expect that most practising Python programmers will consider it too 
obvious to bother documenting the fact that flags meant for compatibility 
with POSIX operating systems are ints.

On the other hand, perhaps I am wrong and it is a documentation bug. Feel 
free to suggest a documentation patch on the bug tracker.


>> os.posix is exactly the sort of library I mentioned earlier when I said
>> sometimes you're constrained by compatibility with some other system.
>> In this case, the os module is explicitly designed to be compatible
>> with the POSIX interface, which is defined to use certain integer
>> values as flags. This is not an implementation choice which
>> implementers can change at will, it is part of the interface.
> 
> The values of those Python constants don't need to have any relationship
> with those of the underlying operating system.

In theory, they could be different. In practice, no they won't. You 
should be able to pass the Python constants directly to some C library 
which expects to see ints. It's a thin wrapper, not a bridge.


>> Python does not guarantee that there is only a single 1 instance.
> 
> Nobody has ever argued such a thing. I certainly haven't.

You may not have intended to, but by championing the use of "is", that is 
precisely what you have done. Using "is" tests for *identity*, not value. 
To get the behaviour you want, it requires those objects to be singletons.


> However, nothing in the API spec gives you the right to call the
> function with an integer.

But you do call the function with an integer. And if you don't, you get a 
type error that explicitly tells you that an integer is needed:

py> os.posix_fadvise(open("/tmp/spam").fileno(), 0, 100, None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required


>> If you want to test whether a value is os.POSIX_FADV_RANDOM, the right
>> way is to compare that value for equality with os.POSIX_FADV_RANDOM,
>> not identity.
> 
> That might well be true but is not explicitly or implicitly specified in
> the documentation. (The os.SEEK_* constants are explicitly defined.)

Not everything needs to be documented explicitly. Would you rather the 
Python developers spend their time fixing bugs and improving the 
language, or ensuring that every trivial and obvious point is explicitly 
documented?

If you feel this is not a trivial or obvious point, and that it needs 
documenting, then feel free to contribute a documentation patch.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/