Category: Programming

  • Swift to C++

    So having just watched a great webcast from O’Reilly on Swift (and certainly having plenty more to learn):

    • Protocols == Pure Virtuals
    • Generics == Templates
    • Extensions == Class Derivation/Extension/Overloading on steroids
    • Operator Overloading == Operator Overloading, again on steroids.
    • Closures == well, nothing innate, but pretty much same thing as Python Closures

    Curiously, and I wonder if it causes problems, that there is no “protected” equivalent. Also from a purely base syntactic level it looks remarkably Scala-like though it falls away quickly on analysis.

    Interesting language, definitely. Topic reminds me of Jason Bock’s “If Carpenters Were Hired Like Programmers”.

  • Python – some truth in this…

    I have to say even as a relative newcomer to Python, I find a fair bit of truth in this:

    Working in a non-homogenous (that is, heterogeneous OS) environment where Python 2.x vs. Python 3.x is not guaranteed, the lack of backwards (or forwards) compatibility is problematic. If nothing else it erodes trust in the language – will Python 4.x inflict similar pain? Should I be looking to yet another language that isn’t so willing to shoot itself in the foot?

    Not all environments, even if they should be, are Puppet-perfect and portability is still a major requirement.

    This is to some extent what happens when languages become religion and “purity” to ideological dogma becomes more important than functionality. While I have to praise the desire for perfection, sometimes the perfect really is the enemy of the good.

    All that said, as Python becomes more “native” to my mentality, maybe I’ll change my mind. I’ve found the transition to other languages, OSes, etc. offensive to my sensibilities only to later become “assimilated to the Borg” as it were.

  • Using LDAP Paged Controls with Python

    Most LDAP servers can be set to return an unlimited number of entries on an LDAP search, however depending on the size of the LDAP database/directory this can possibly exceed your memory. Moreover if you want to write portable code, you probably should not depend on the LDAP server being able to return unlimited entries. For instance, AD’s LDAP generally defaults to 1,000 entries maximum.

    Because using LDAP paging isn’t very difficult there’s not a lot of reason to not use it. Adding paging only marginally reduces performance, while certainly putting less stress on the LDAP server(s). Personally I recommend you use it on a general basis, even where not strictly necessary.

    Python’s LDAP supports paging, though it isn’t well documented. I found two examples this one and this one. Both had their pluses, but neither explained what was going on too much. I melded them together, added comments, and streamlined a bit. Hopefully this will help you get the mojo…

    As a final note, one of the documents I found said the paged controls did not work with OpenLDAP. That’s not what I found – pretty much the exact code above worked without issue with OpenLDAP.


    A GitHub “Gist” for the above can be found here.

    UPDATE 2:

    For users of Python LDAP 2.4, you should check out of the comment by Ilya Rumyantsev which gives a forward/backward compatible set of code snippets since the API has changed a bit. Many thanks to Ilya for the update.

    UPDATE 3:

    Below I took Ilya’s updates and merged them in with some minor enhancements to compare the Python LDAP version on the fly. My next stop is to take this and convert it to a generator function, which would be more ideal than using a callback. The issue with going to a generator is handling the errors, which means throwing exceptions in some sane fashion…

    UPDATE 4:

    It turns out that the Python “ldap” module does not follow “StrictVersion” versioning in it’s “__version__” string. I have updated the “UPDATE 3” code to use “LooseVersion” comparisons.

    UPDATE 5:

    I updated the above code to default to “criticality=False” for the paging control. If the LDAP service doesn’t support paging, it will yield a potentially confusing “Critical extension is unavailable” error.

    Note I need to ultimately fix the exception handling as for whatever reason the exception object passed back doesn’t have a reasonable “__str__()” method and the message is left in the “desc” key.

  • Bash TCP programming hack!?

    I had never heard of this until I ran into working on a recent project. In “bash” you can open sockets:

    exec file-descriptor<>/dev/tcp/IP-or-hostname-here/port

    so for example:

    exec 3<>/dev/tcp/

    would open port 23 (telnet) to IP “” for read and write (the “<>”) on file descriptor “3” (remember descriptors 0, 1, and 2 are used by default for stdin, stdout, and stderr respectively, so you probably don’t want to step on them). Or if you prefer easier to read:

    exec 3<>/dev/tcp/

    and thus it’ll also do host and service lookups.

    You can then write to the socket:

    echo “mylogin” >&3

    or read from the socket:

    cat <&3

    If you don’t use “<>” but rather just “<” or “>” you can open the socket only for read or write respectively.

    You can also close the socket (as all good programmers should):

    exec 3<&- # Close for read
    exec 3>&- # Close for write

    Bash – it shakes, it bakes, it does socket programming.

    To note this is an entire bash-ism, you can’t simply do:

    echo “hello” >/dev/tcp/

    “bash” is intercepting the “/dev/tcp” stuff and fudging it.

    And I thought Perl was the only one with ugly hacks.