Re: Issue 43 in rdflib: naming ambiguity rdflib.URIRef / rdflib.Literal etc
rdf...@googlecode.com
Comment #4 on issue 43 by drewpca: naming ambiguity rdflib.URIRef /
rdflib.Literal etc
http://code.google.com/p/rdflib/issues/detail?id=43
manu.alem, your issue seems unrelated to this bug regarding rdflib imports.
If you're
still having a problem, please post it as a new issue and remember to
include your
exact error message so we can fix it.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
rdf...@googlecode.com
Comment #5 on issue 43 by drewpca: naming ambiguity rdflib.URIRef /
rdflib.Literal etc
http://code.google.com/p/rdflib/issues/detail?id=43
Regarding the imports, work has already been done to put Literal/etc in a
term.py
module. But meanwhile, imports that have worked for years are now broken. I
shall
prepare a patch that makes "from rdflib import Literal, URIRef, BNode,
Variable" work
again. I'll also see what it would take to make things like "from
rdflib.Graph import
ConjunctiveGraph" work but print a deprecation warning. If legacy projects
can't even
start up with rdflib 2.5, they're going to hate moving to it.
rdf...@googlecode.com
Comment #6 on issue 43 by lindstream: naming ambiguity rdflib.URIRef /
rdflib.Literal etc
http://code.google.com/p/rdflib/issues/detail?id=43
While still supporting rdflib.Graph et.al. is very nice for 2.4.x-users
(whose code will break otherwise),
IMHO this breaking change is for the better at large. I have faith that
this wouldn't hurt the people
using 2.4.x too much, as long as we're explicit and helpful in informing
about this (and why it's been
done).
As for supporting convenience import, I think it's both good for those who
have used it in 2.4 (I did),
and for the future as well. I have this for "rdflib/__init__.py"::
# import common classes, functions and constants:
# IMPORTANT: make sure to *never* shadow module names with these
imports!
from rdflib.graph import (Graph, ConjunctiveGraph,
QuotedGraph, ReadOnlyGraphAggregate,
ModificationException, UnSupportedAggregateOperation)
from rdflib.namespace import Namespace, RDF, RDFS, OWL, _XSD_NS as XSD
from rdflib.term import BNode, Identifier, Literal, URIRef, Variable
The big difference from 2.4.x is (at least) that Graph is exposed directly,
instead of rdflib.Graph being
BackwardCompatGraph. I think it's fairly ok now not to expose that though
(it's been deprecated for
quite a while AFAIK).
rdf...@googlecode.com
Comment #7 on issue 43 by lindstream: naming ambiguity rdflib.URIRef /
rdflib.Literal etc
http://code.google.com/p/rdflib/issues/detail?id=43
Still, do we need an explicit declaration about exactly which namespace
changes are ok to go into
2.5? If we want to do more, should we defer all the rest to 3.0, or
progressively rename (e.g.
lowercase, relocate) "internal" packages for 2.6 etc.?
I'm unsure about how many 3d-party packages import from the internals of
syntax etc.. (And what
tolerance those would have regarding any changes.)
rdf...@googlecode.com
Comment #8 on issue 43 by gromgull: naming ambiguity rdflib.URIRef /
rdflib.Literal etc
http://code.google.com/p/rdflib/issues/detail?id=43
I disagree with lindstream, and semi agree with drewpca.
I think being able to do:
import rdflib
and then rdflib.Graph, Literal, etc.
is a great usability feature. It's annoying to write the extra module in
the middle
of rdflib.graph.Graph, we should really try to make working with rdflib as
easy as
possible.
rdf...@googlecode.com
Comment #9 on issue 43 by lindstream: naming ambiguity rdflib.URIRef /
rdflib.Literal etc
http://code.google.com/p/rdflib/issues/detail?id=43
Sorry, I was unclear. We really do agree. :) I just meant that I don't
think we need to support the 2.4.x
uppercase-modules (as I interpreted it drewpca was looking into).
So, no to the old (and currently fixed, i.e. removed):
from rdflib.Graph import ConjunctiveGraph
The new full forms are of course (e.g.):
from rdflib.graph import ConjunctiveGraph
from rdflib.namespace import Namespace
from rdflib.term import URIRef
But *also* support:
from rdflib import ConjunctiveGraph, Namespace, URIRef
I.e. add back the convenience imports in "rdflib/__init__.py".
rdf...@googlecode.com
Status: Started
Comment #10 on issue 43 by eikeon: naming ambiguity rdflib.URIRef /
rdflib.Literal etc
http://code.google.com/p/rdflib/issues/detail?id=43
I'm going to work on adding the short forms back in now. I do not plan on
adding back the upper case modules
that were clashing with the class names however.
rdf...@googlecode.com
Comment #11 on issue 43 by eikeon: naming ambiguity rdflib.URIRef /
rdflib.Literal etc
http://code.google.com/p/rdflib/issues/detail?id=43
This issue was updated by revision r1768.
moved
rdf...@googlecode.com
Comment #12 on issue 43 by eikeon: naming ambiguity rdflib.URIRef /
rdflib.Literal etc
http://code.google.com/p/rdflib/issues/detail?id=43
This issue was updated by revision r1769.
Forgot to add this as part of r1767
rdf...@googlecode.com
Comment #13 on issue 43 by drewpca: naming ambiguity rdflib.URIRef /
rdflib.Literal etc
http://code.google.com/p/rdflib/issues/detail?id=43
The revisions in the last two comments seem to be about some other thing.
Anyway, what is the decision for the __repr__ of URIRef, Literal, etc? Since
rdflib.URIRef will work, I would like the repr to be shorter:
GOOD rdflib.URIRef('http://example.com/')
BAD rdflib.term.URIRef('http://example.com/')
I have implemented the shorter repr and refactored the repetitive __repr__
code in
branches/repr-43. Note that URIRefs and BNodes now emit unicode strings,
which is a
small change. I think that's correct given that URIRef and BNode are
subclasses of the
unicode type.
The tests are passing in that branch, feel free to just merge it in if you
approve of
the new reprs.
http://code.google.com/p/rdflib/source/detail?r=1793 has the diffs
Ivan Herman
from the module itself. Ie,
from rdflib.Namespace import Namespace
from rdflib.URIRef import URIRef
from rdflib.Literal import Literal
in other words, if all these module names become lower case, I would
have to rewrite quite a lot in quite a number of places. I am personally
opposed to such a change.
(I agree it is 'nicer'. But, well, we can live with our own mistakes,
and aesthetics should not be the only reason for chaging...)
Ivan
--
Ivan Herman
Bankrashof 108, 1183NW Amstelveen, The Netherlands
tel: +31-641044153;
URL: http://www.ivan-herman.net
Niklas Lindström
Just tinkered some and discussed with Daniel a bit about
possibilities. This is one way which may provide a "middle way", if
we'd like to go with RDFLib 2.5 and support the old namespace "for a
while", but still have the new real modules lower-cased, the test
suite working and so forth.
The following is an example of "hacking" sys.modules to provide
"virtual" modules, which would allow 2.4-imports like the ones Ivan
exemplified to work without those modules being there.
If I put this in "rdflib/__init__.py" (prior to the "del sys" line):
---- 8< ----
# Hacking sys.modules to support the deprecated RDFLib 2.4 namespace:
from rdflib import namespace, term, graph
sys.modules['rdflib.Namespace'] = namespace
sys.modules['rdflib.BNode'] = term
sys.modules['rdflib.Literal'] = term
sys.modules['rdflib.URIRef'] = term
sys.modules['rdflib.Variable'] = term
sys.modules['rdflib.Graph'] = graph
del namespace, term, graph
---- >8 ----
Then this code will work:
---- 8< ----
# These are "virtual" modules:
from rdflib.Namespace import Namespace
from rdflib.URIRef import URIRef
from rdflib.Literal import Literal
from rdflib.Graph import ConjunctiveGraph
# Their real modules are:
assert Namespace.__module__ == "rdflib.namespace"
assert URIRef.__module__ == "rdflib.term"
assert ConjunctiveGraph.__module__ == "rdflib.graph"
# Convenience imports still work:
from rdflib import URIRef, ConjunctiveGraph
assert isinstance(URIRef, type)
assert isinstance(ConjunctiveGraph, type)
assert URIRef.__module__ == "rdflib.term"
assert ConjunctiveGraph.__module__ == "rdflib.graph"
# Check out what's really there:
#import rdflib
#print vars(rdflib)
---- >8 ----
And the test suite still runs fine.
.. Note that I'm not suggesting we go this route yet (as opposed to a
bit more backwards-incompatible RDFLib 3.0), but I think it's worth
considering. It may make everyone happy. ;)
(We should certainly warn about the use of the old UpperCased module
names though..)
Best regards,
Niklas
> You received this message because you are subscribed to the Google Groups "rdflib-dev" group.
> To post to this group, send email to rdfli...@googlegroups.com.
> To unsubscribe from this group, send email to rdflib-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rdflib-dev?hl=en.
>
>
drewpca
> The following is an example of "hacking" sys.modules to provide
> "virtual" modules, which would allow 2.4-imports like the ones Ivan
> exemplified to work without those modules being there.
>
> If I put this in "rdflib/__init__.py" (prior to the "del sys" line):
>
> ---- 8< ----
> # Hacking sys.modules to support the deprecated RDFLib 2.4 namespace:
> from rdflib import namespace, term, graph
> sys.modules['rdflib.Namespace'] = namespace
> sys.modules['rdflib.BNode'] = term
> sys.modules['rdflib.Literal'] = term
> sys.modules['rdflib.URIRef'] = term
> sys.modules['rdflib.Variable'] = term
> sys.modules['rdflib.Graph'] = graph
> del namespace, term, graph
> ---- >8 ----
I am open to this trick, but it would be really sweet if you could
make it show a DeprecationWarning when people used the old form. In
particular, it should not be easy for someone *starting* with version
2.5 to accidentally write old style import lines just because they saw
them in an example somewhere. If a warning is too hard, it might be
acceptable to provide this hack in an explicitly imported module:
import rdflib.old_term_names
from rdflib.Literal import Literal
...
To everyone with "from rdflib.Literal import Literal" in their current
code, I would suggest changing your import lines now. One of the good
things about this cleanup is that it's easy to make one's code forward-
compatible now, and it gets shorter as well.
BTW, isn't this discussion only about the terms Literal/URIRef/BNode/
Variable? Stuff like "from rdflib.Graph import ConjunctiveGraph",
where there is no forward-compatible alternative, ought be preserved
in version 2.5. (I realize that one does not currently work on trunk
at the moment.)