Libelektra: python: provide more high-level APIs

[markus2330]

I have some common helpers which are often needed and should be directly added to our binding (so that they are always available, well tested and well documented)

def make_set (ks, where):
    s = set ()
    for k in ks:
        if k.isDirectBelow (where):
            s.add (k)
    return s;

def unpack_names (ks):
    s = set ()
    for k in ks:
        s.add (k.name)
    return s

def unpack_basenames (ks):
    s = set ()
    for k in ks:
        s.add (k.basename)
    return s

def is_array_entry (k, arrayname):
    if k.basename[0] != '#':
        return False
    x = copy.copy(k)
    x.delBaseName()
    if x.basename == arrayname:
        return True

def append (ks, name, p):
    n = kdb.Key(name)
    n.string = str(p)
    ks.append (n)
    print n

# this is only a workaround, ideally this would be directly in kdb.KeySet:
class GetKeySet(kdb.KeySet):
    def get(self, n):
        k = ks.lookup(n)
        if not k:
            raise KeyError(n+" not found")
        return k.string
    def set(self, n, s):
        k = ks.lookup(n)
        if not k: # TODO: call append here
            raise KeyError(n+" not found")
        k.string = str(s)

[kodebach]

# this is only a workaround, ideally this would be directly in kdb.KeySet:
class GetKeySet(kdb.KeySet):
  def get(self, n):
      k = ks.lookup(n)
      if not k:
          raise KeyError(n+" not found")
      return k.string
  def set(self, n, s):
      k = ks.lookup(n)
      if not k: # TODO: call append here
          raise KeyError(n+" not found")
      k.string = str(s)

The binding already has __getitem__ so ks["/some/key"] already works. We should just add a __setitem__ instead of get and set.

Also is_array_entry would ideally use libease's elektraArrayValidateName (or elektraArrayValidateBaseNameString) to ensure consistency.

And if someone has the python skills for it, a constructor for creating a Key from two strings (name and value) and a dictionary of strings (for metadata) would be much nicer than the C like vararg constructor as well.

[markus2330]

Thank you for the feedback! Yes, then __setitem__ would be the more pythonic solution. Nevertheless, I would appreciate to also have get/set as my code already uses this. It is also more consistent with the C++ binding. (Where "get" is a template and also supports complex types.)

is_array_entry would ideally use libease's elektraArrayValidateName

You are completely right! If we pull in the libease dependency, however, we should fully add all these functions to the python binding. This would be a separate task, though. It would be interesting if elektraKsFilter is faster than a python loop.

And if someone has the python skills for it, a constructor for creating a Key from two strings (name and value) and a dictionary of strings (for metadata) would be much nicer than the C like vararg constructor as well.

Yes, in Java we already have this.

[manuelm]

There are some horrible ideas in here, but the __setitem__ is by far the most shocking. You guys are ill-treating the keyset api. The correct usage to change a value of a key in keyset is ks["some/key"].value = "foo"

e.g.

ks = kdb.KeySet()
ks.append (kdb.Key("user/foo", kdb.KEY_VALUE, "foo"))

print(ks["user/foo"].value)
ks["user/foo"].value = "bar"
print(ks["user/foo"].value)

bar

__getitem__ returns the key, not it's value!

[markus2330]

The correct usage to change a value of a key in keyset is

Could you please add this to the tutorial doc/tutorials/python-kdb.md?

[manuelm]

Could you please add this to the tutorial doc/tutorials/python-kdb.md?

I assume this is python3 only and python2 has been finally deprecated?

[manuelm]

So I've added support for kdb.Key(name, value, meta_dict). It mainly works on python3. Python2 is string_values only. Personally I'd rather remove python2.

Then I extended KeySet.append to accept list of keys ks.append(k1, k2, ...) as well as passing non-key values to the ctor of Key (e.g. ks.append("user/foo", "some_value", {"this":"works"})). And finally I've added a KeySet.extend to append a list as a single parameter.

I'll look into the others now

[markus2330]

I assume this is python3 only and python2 has been finally deprecated?

Yes, the tutorial can be python3 only.

Personally I'd rather remove python2.

Python2 was already deprecated by you but we did not remove it up-to-now. But you are right, now might be a good time to completely remove it, as python2 is more or less dead. And if we release Elektra 1.0 with python2 support there might be some expectation to maintain python2 for the Elektra 1.0 lifetime. The main reason for python2 actually mostly was the TU Wien lab, but they finally also got python3.

Then I extended [...]

Very nice, a big thanks. Please document these features in the tutorial as otherwise nobody will know about it.

What does "ready to merge" mean for you if applied to issues?

[manuelm]

What does "ready to merge" mean for you if applied to issues?

So I can skip it in my issue list.

[markus2330]

@manuelm Thank you, amazing job.