Improve Namespace attribute handling

[niklasl]

Since rdflib.namespace.Namespace inherits from unicode, certain vocabulary names clashes with methods on unicode objects, and have to be accessed using __getitem__ (e.g. NS['upper']) instead of NS.upper.

A possible improvement (for 5.0, since it would be backwards incompatible) would be to either just not inherit from unicode, or to add something like:

def __getattribute__(self, name):
    return Namespace.term(self, name)

to Namespace. Any need to use unicode methods on a Namespace instance would then have to be done using unicode(DCTERMS).title() (or unicode.title(DCTERMS) if its inheritance is kept).

[joernhees]

hmm, in that case what about basing on object instead of unicode especially for Namespace, but potentially for all rdflib classes (esp. URIRef, Literal, BNode)?

I mean there is a certain convenience in basing on unicode as it allows to just put them wherever a unicode/str object is expected, but to be honest that convenience has bitten me more often than it helped... it makes things certain things implicit that maybe should be explicit as it gives you a dangerous impression that it just works correctly but you might be losing data in the long run:

In [1]: from rdflib import URIRef, Literal
INFO:rdflib:RDFLib Version: 4.2.2-dev

In [2]: import json

In [3]: json.dumps([URIRef('http://foo.bar'), Literal('http://foo.bar')])
Out[3]: '["http://foo.bar", "http://foo.bar"]'

(The above should actually throw a TypeError on serialization to make you think and notice that you'll lose information and maybe should use json-ld, but as the default json is "nice enough" to handle every subclass of basestring, it will happily serialize destroying information.)

I know that rdflib goes to quite some lengths to make RDF feel pythonic, but quoting from import this "Explicit is better than implicit.". Maybe it's worth discussing whether we should just move away from the unicode base class to force developers to make explicit decisions where necessary and remove a whole lot of inconsistencies and traps, of which the Namespace.title is just one instance?

[niklasl]

Yes, I agree, this is definitely worth discussing. Hopefully reliance on the unicode convenience isn't that widespread, or at least amenable enough for such a change to be accepted for 5.0.

(Although with enough of such fixes, we might be better off considering something like an rdflib2 (and/or opening up possible API alignments (cf. #539)). It might not be a good idea (things rarely unfold that cleanly), but worth mentioning still (since sometimes they do).)

[gromgull]

Ditching unicode inheritance from Namespace seems tempting. I am less convinced about ditching it from everything. More because it will be a lot of work and will introduce a lot of bugs that we don't really have the developer resources to fix. Maybe when @joernhees has finished his PhD? :)

I wonder what we gain by having things inherit from unicode code. Off the top of my head I cannot think of that many things this enables that I actively use?

Pros:

• it is neat :)
• You can compose URIRefs easily (but a Namespace is safer)
• You can slice URIRefs (but we could implement slicing anyway?)

Cons:

• Python is pretty good at transparently converting to str/unicode with __str__, __unicode__ anyway.
• No concensus on what operators on objects should return. (For literals there is value/lexical space: Bugfix: term.Literal.__add__ #451) (For URIRefs we did this: Make string operations on URIRefs return URIRefs #258, perhaps hastily - I was bitten by composing a string for logging with + ( yes, yes, I know ... ) and URIRef tried to validate it )

[aucampia]

Is this still an issue?

[tehaef]

Is this still an issue?

Yes, i am also encountering this issue. I am implementing something based on the BIBFRAME Ontology and i am getting comparable collision issues for bf:countand bf:index (but interestingly not bf:title).