Re: [HTCondor-users] Some bugs and inconsistencies in the new Python bindings

[Todd L Miller <tlmiller@xxxxxxxxxxx>]

> Sorry for the German negativity.

	Thank you for the careful bug reports.  They'll help us help other 
users, and, of course, were things that we didn't notice. :)

> The new bindings are actually a 
> nice step up from the old design. ;)

	I appreciate the praise. :)

> - Passing either tuple or list to `htcondor2.Collector` as `pool` 
> doesn't work as the internal type check is wrong: (it should say 
> `isinstance(pool, (list, tuple))`)

	So it should!  We're clearly missing a test here.

> - `RecursionError` for anything needing `len(htcondor2.param)` (e.g. 
> `list(htcondor2.param.keys())`) since the `KeysView` delegates back to 
> the mapping and vice versa.

	I fixed a very similar problem once already.  Thanks for the 
heads-up.

> - Typehint for `htcondor2.Collector` `pool` arguments includes 
> `Tuple[str]` (a tuple with exactly one string) but should say 
> `Tuple[str, ...]` (a tuple with any number of strings).

	Good catch.

> - The docs for `classad2.ClassAd` say

>       Expressions are always evaluated before being returned, and unless
>       you call lookup(), converted into the corresponding Python type.

>   Yet using `classad[key]` access seems to only evaluate constant
>   literal expressions, not general expressions.

	That's weird, and also indicative of a missing test.

> - `classad2.ClassAd.matches` is explicitly documented to only check for 
> a `True` return value, but also accepts non-zero int and float.

	I think this is a documentation error, but I'll have to ask 
around; non-zero int and float type-coerce to true, so I think HTCondor 
iself can't tell the difference.

> - Misleading `ClassAd.printJson` and `ClassAd.printOld` method names â 
> they donât `print` but merely format. I understand thatâs the name in C 
> source, but `ClassAd.formatJson` and `ClassAd.formatOld` aliases or 
> similar would be nice for code clarity.

	We had to leave those function names for compatibility with 
version 1 of the bindings.  I'll consider adding aliases, but formatting 
functions don't seem particularly Pythonic.  Do you know of a more 
idiomatic way of dealing with different ways to serialize objects in 
Python?

> - Several enums are `enum.IntEnum` but have power-of-two values and are 
> intended for bitwise combinations. Python's `enum.IntFlag` is more 
> appropriate for that.

	I hadn't known about `enum.IntFlag`.  It looks like it's 
intentended to be a fully-compatible replacement for `enum.IntEnum`s which 
meet its requirements for values?  (If so, we can just make the switch 
immediately; otherwise, it's an API change, which I was hoping to avoid 
for a while....)

>   - `htcondor2.LogLevel` can be combined using bitwise-or according to
>   `htcondor2.log`, but its member values are not power-of-two (e.g.
>   `htcondor2.LogLevel.Error | htcondor2.LogLevel.Job ==
>   htcondor2.LogLevel.Machine`)

	The constants for htcondor2.LogLevel are the C constants, which 
are definitely _not_ safe to arbitrarily combine.  I'll ask if there was a 
good reason to omit LogLevel.ErrorAlso, which is what you'd use if you 
wanted a single log message to go to both the D_ERROR log and whatever 
other category you chose.

-- ToddM