#20 Error with graph.data.list


In graph.data.list(), there are two places where PyX attempts to
access the builtin list() function as builtins.list under certain
conditions. This is not correct, since builtins appears as a
dictionary and has no list attribute, and throws an exception.

If your really must create a class with the name graph.data.list
(which, because of the possible conflict with python's built-in list()
function, especially if someone does
from graph.data import *
may be a bad idea), it is probably best to, at the top of graph.data,
do something like


class list():...

and then use a=builtin_list(...)

where you currently use builtins.list(...)

In general, though, I think it would be even better to rename this
class to avoid some really mysterious behavior if anyone does do
an import * from it.

Marcus Mendenhall


  • Andre Wobst

    Andre Wobst - 2004-10-08

    Logged In: YES

    I've just corrected the bug in the 0.6.x trunk. In CVS head this problem
    does not occur anymore, since the conversion of a sequence into a list is
    not necessary anymore. (Instead the new data handling allows for direct
    mixing of several data sources, which also removes some strange side

    Beside that I'm totally aware of the problem of the name "list". The
    name comes out of the following consitency consideration: Creating
    graph data from a file is done by data.file, creating data from out of a
    function is done by data.function, creating data from a different data is
    done by data.data ... so what's the name for creating data from a list of
    points? I thought data.list would be best here ... but feel free to suggest
    a different naming. We could do data.points, but I do not really like it.
    Feel free to convince me or suggest other possibilities. I do not stop at
    those changes currently since I classify PyX to still be in the design
    phase ...

  • Marcus Mendenhall

    Logged In: YES

    I will only twist your arm gently over the data.list naming issue. I
    almost never import *, since I like using namespaces, so I will probably
    never see the namespace collision. However, unwary users could get in
    trouble with this.

    Thanks for fixing the problem. PyX is really a nice package, especially
    as it begins to settle down.


  • Andre Wobst

    Andre Wobst - 2004-10-25

    Logged In: YES

    I'm closing this issue, since it has been resolved. The name clash topic
    has also been discussed before. There seems to be no strong arguments
    against reusing some common names.

    Just to add some small talk about the name clashes (which are not name
    clashes due to Pythons name spaces): We actually have at least some
    other name clashes in PyX as well. The oldest one I can remember of is
    path.line against graph.style.line (graph.line in former times). When I
    started to work on the graph module, in my first versions I used
    graph.chain for a line connecting style. Jrg strongly argued against that
    naming and so it was changed to line in the early days already. And I'm
    aware of another clash in using the term "style" for stroke and fill styles
    vs. graph styles. Well ... we've decided that people have to learn about it
    beyond the naming ... ;-)


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks