[python3-ldap] python3-ldap 0.9.5.4 released

[Joseph L. Casale]

> I know there are plusses and minuses of doing
> import ldap3
> vs.
> from ldap3 import [....]
> as used in the example.

I always use the later, I only import what I use and never import the entire
module unless it makes sense, ie its needed for isolation.

> but having to import various constants there also becomes unwieldy
> quickly.

Well, thats a matter of opinion, I find the following short, terse and specific:

from ldap3 import (
    Connection,
    Server,
    ServerPool,
    POOLING_STRATEGY_ROUND_ROBIN,
    SEARCH_SCOPE_BASE_OBJECT,
    SEARCH_SCOPE_WHOLE_SUBTREE,
    STRATEGY_SYNC_RESTARTABLE
)

When you have more than one constant, coming up with creative acronyms to
introduce unnecessary obfuscation as they all begin collide serves no useful purpose.
I actually am relieved to see the full name, especially in the case of this library were
everything closely relates to the spec so when I am looking something up in the rfc's
for example, I done have to convert (rfc) LONG_KEY_WORD to (acronym) LKWZZ
because A  through ZY are already used. Think of other people who must maintain
your code:)

When I see code with anti patterns like 'import someModule as sm' I sigh... Now as I
am reading through it I need to stop and think, or worse go and check to see what the
heck "sm" is. So if isolation is needed, ldap3.Connection leaves nothing to be guessed
whereas if I know I am not in a scenario requiring isolation, Connection is just as obvious.

There is no tax on real estate, nor points for conserving it. You can still maintain the
silly 79 char limit from pep8 with proper formatting as illustrated.

jlc