>> Does anyone object to my changing the ZEO version number to match the
>> ZODB version number?  Concretely, that means:
>>     import ZODB
>>     import ZEO
>>     assert ZODB.__version__ == ZEO.version
>> would no longer fail.

> +1

You could consider it done, then -- all that remains is to do it <wink>.

>> I've seen code and docs that actually reference ZEO.version (and why
>> that isn't spelled "__version__" is also unknown to me),

> Because of silly developer preferences.  I don't like to use an
> __variable__ unless that __variable__ has an actual meaning to the Python
> interpreter.  The __variable__ namespace is supposed to be reserved for
> Python (sort of like names beginning with _P are reserved in std C).
> Also, it's not a private variable, so I didn't see any point to have any
> underscores in it.

Me neither, although many random modules in the Python core define
__version__ too, so I suppose it's a de facto standard "reserved name".  I'd
reserve intense dislike for, e.g., __no_side_effects__ (remember that one?).

>> There's also a file, ZEO/version.txt, that repeats the ZEO version
>> number (ZEO.version is set up by ZEO/__init__.py).  I have no idea why
>> that exists either.  Does any one here use ZEO/version.txt?

> Someone asked for it so that it would be easy to check the version of ZEO
> from a shell script.

Ah, of course -- if they upgraded to Windows, their shell script could have
sucked up the output of

    python -c "import ZEO; print ZEO.version"

instead, or picked apart the last line of ZEO/__init__.py.  I'll try to work
harder to keep in mind how limited Linux shells are <wink>.

one-wisecrack-back-and-i-change-'em-all-to-unicode-strings-ly y'rs  - tim

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to