citeproc-py module naming

CSL Development
1

I stumbled on this just now:

The relevant bit for citeproc-py is:

" Modules should have short, all-lowercase names. Underscores can be used
in the module name if it improves readability. Python packages should
also have short, all-lowercase names, although the use of underscores is
discouraged.
"

Does this mean that files like InfoAuthor.py should really be infoauthor.py?

Also, there are a lot of files; might make sense to consolidate some
of them at some point? E.g. maybe something like:

csl/
info.py
generic.py
formatting.py

That would end up with import statements like:

from citeproc.csl.info import *

Don’t know; just an idea. I’m noticing Liam took a little different
tack on the ruby version:

$ ls -R /Users/darcusb/xbiblio/citeproc-rb/lib/
biblio_utils.rb csl_biblio_input_filter.rb
bibliontology.rb csl_input_filter.rb
csl.rb csl_parser.rb
csl_base_formatter.rb csl_reference.rb

Bruce

2

Hello Bruce,

I am not a big fan of consolidating many classes in a single file,
certainly not at this point of development. It would make it harder to
find the way around in the file in my opinion. Especially since most
classes have very similar methods with the same names. Maybe later
this could be consolidated, but I have my doubts on the usefulness of
such an exercise, though I am open to any arguments in favour of it.

I am not sure if the capitalization of the modules is such a big deal.
It kinda made sense to me to name the file the same as the object
class they contained.

I am not familiar enough with the way the ruby version is implemented
and functioning at the moment to comment on the structure that Liam
has chosen. I just know that the current structure of citeproc-py
makes sense to me. Is that not the case for you?

Cheers,

Johan—
http://www.johankool.nl/

3

In the abstract, sort of. There are two issues:

  1. perhaps particularly so in Python, conventions about code design
    usually exist for good reason, and best to follow them so that it’s
    familiar and consistent with the expectations of other Python coders.
    I may not have read that discussion right (it might not have been
    referring to the file names?), but if I did, there seems no good
    reason to violate it.

  2. the file-per-class approach is just a little awkward to me, b/c it
    yields a lot of import statements, and they are of the form:

from example.SomeClass import SomeClass

… as opposed to:

from example.import SomeClass

This is no great issue, and it may not matter now as you say, but just
wanted to point it out as I came across it.

Bruce

4

oops …On Mon, May 12, 2008 at 7:44 AM, Bruce D’Arcus <@Bruce_D_Arcus1> wrote:

… as opposed to:

from example.import SomeClass

… I meant, of course:

from example import SomeClass

Bruce

5

The file-per-class approach is more of a stylistic thing. I think it
should be possible to make it so that it doesn’t require the “from
example.SomeClass import SomeClass” import, but that it can also work
with “from example import SomeClass” but I have to look into that.
Other than that, it doesn’t make much of a difference. Except, that
for me the code is much more manageable if not in one gigantic text
file.

I don’t see any value currently in renaming all files to be
lowercased. If it becomes an issue it can always be fixed, but there
are more important things to look at at this moment.

But, yes I agree, it can’t hurt to follow conventions, though I don’t
believe they always need to be followed rigourously. I don’t think
that my Python code is that far off that other Python coders will have
much difficulty understanding it.

Johan—
http://www.johankool.nl/