module confusion

Discussion in 'Python' started by rjcarr, Oct 2, 2007.

  1. rjcarr

    rjcarr Guest

    Sorry if this is a completely newbie question ...

    I was trying to get information about the logging.handlers module, so
    I imported logging, and tried dir(logging.handlers), but got:

    AttributeError: 'module' object has no attribute 'handlers'

    The only experience I have in modules is os and os.path ... if I do
    the same thing, simply import os and then type dir(os.path), it
    displays the contents as expected.

    So my question is ... why are they different? I mean, in terms of
    designing these modules, how would you go about getting a sub-module
    in your name space? And on the other side, how would you go about
    getting it out?

    Thanks!
     
    rjcarr, Oct 2, 2007
    #1
    1. Advertising

  2. rjcarr

    Guest

    On Oct 1, 10:03?pm, rjcarr <> wrote:
    > Sorry if this is a completely newbie question ...
    >
    > I was trying to get information about the logging.handlers module, so
    > I imported logging, and tried dir(logging.handlers), but got:
    >
    > AttributeError: 'module' object has no attribute 'handlers'


    What do suppose that message means?

    >
    > The only experience I have in modules is os and os.path ... if I do
    > the same thing, simply import os and then type dir(os.path), it
    > displays the contents as expected.
    >
    > So my question is ... why are they different?


    Because you misspelled it. First, do a dir() on logging:

    >>> import logging
    >>> dir(logging)

    ['BASIC_FORMAT', 'BufferingFormatter', 'CRITICAL', 'DEBUG', 'ERROR',
    'FATAL', 'FileHandler', 'Filter', 'Filterer', 'Formatter', 'Handler',
    'INFO', 'LogRecord', 'Logger', 'Manager', 'NOTSET', 'PlaceHolder',
    'RootLogger', 'StreamHandler', 'WARN', 'WARNING', '__author__',
    '__builtins__', '__date__', '__doc__', '__file__', '__name__',
    '__path__', '__status__', '__version__', '_acquireLock',
    '_defaultFormatter', '_handlerList', '_handlers', '_levelNames',
    '_lock', '_loggerClass', '_releaseLock', '_srcfile', '_startTime',
    'addLevelName', 'atexit', 'basicConfig', 'cStringIO', 'codecs',
    'critical', 'currentframe', 'debug', 'disable', 'error', 'exception',
    'fatal', 'getLevelName', 'getLogger', 'getLoggerClass', 'info', 'log',
    'logProcesses', 'logThreads', 'makeLogRecord', 'os',
    'raiseExceptions', 'root', 'setLoggerClass', 'shutdown', 'string',
    'sys', 'thread', 'threading', 'time', 'traceback', 'types', 'warn',
    'warning']

    You can now pick any item from this list to further expand
    with dir(), but notice "handlers" isn't one of them.

    > I mean, in terms of
    > designing these modules, how would you go about getting a sub-module
    > in your name space? And on the other side, how would you go about
    > getting it out?
    >
    > Thanks!
     
    , Oct 2, 2007
    #2
    1. Advertising

  3. rjcarr

    Robert Kern Guest

    wrote:
    > On Oct 1, 10:03?pm, rjcarr <> wrote:
    >> Sorry if this is a completely newbie question ...
    >>
    >> I was trying to get information about the logging.handlers module, so
    >> I imported logging, and tried dir(logging.handlers), but got:
    >>
    >> AttributeError: 'module' object has no attribute 'handlers'

    >
    > What do suppose that message means?
    >
    >> The only experience I have in modules is os and os.path ... if I do
    >> the same thing, simply import os and then type dir(os.path), it
    >> displays the contents as expected.
    >>
    >> So my question is ... why are they different?

    >
    > Because you misspelled it. First, do a dir() on logging:


    No, he didn't. There is a logging.handlers module; it's just not imported by
    importing logging.

    OP: logging is a package and logging.handlers is one module in the package. Not
    all of the modules in a package are imported by importing the top-level package.
    os.path is a particularly weird case because it is just an alias to the
    platform-specific path-handling module; os is not a package.

    --
    Robert Kern

    "I have come to believe that the whole world is an enigma, a harmless enigma
    that is made terrible by our own mad attempt to interpret it as though it had
    an underlying truth."
    -- Umberto Eco
     
    Robert Kern, Oct 2, 2007
    #3
  4. In message <>, Robert
    Kern wrote:

    > Not all of the modules in a package are imported by importing the
    > top-level package.


    You can't import packages, only modules.

    > os.path is a particularly weird case because it is just an alias to the
    > platform-specific path-handling module; os is not a package.


    os is a module, os.path is a variable within that module. That's all there
    is to it.
     
    Lawrence D'Oliveiro, Oct 2, 2007
    #4
  5. On Tue, 02 Oct 2007 19:34:29 +1300, Lawrence D'Oliveiro wrote:

    > In message <>, Robert
    > Kern wrote:
    >
    >> Not all of the modules in a package are imported by importing the
    >> top-level package.

    >
    > You can't import packages, only modules.


    Oh come on, this is unnecessary nitpicking. Importing the module
    `__init__` from a package using the name of the package is close enough to
    justify the phrase "I import the package" IMHO.

    Ciao,
    Marc 'BlackJack' Rintsch
     
    Marc 'BlackJack' Rintsch, Oct 2, 2007
    #5
  6. rjcarr

    Robert Kern Guest

    Lawrence D'Oliveiro wrote:
    > In message <>, Robert
    > Kern wrote:
    >
    >> Not all of the modules in a package are imported by importing the
    >> top-level package.

    >
    > You can't import packages, only modules.
    >
    >> os.path is a particularly weird case because it is just an alias to the
    >> platform-specific path-handling module; os is not a package.

    >
    > os is a module, os.path is a variable within that module. That's all there
    > is to it.


    Yes, but os.path is also module. That's why I said it was a weird case.

    In [1]: import os

    In [2]: type(os.path)
    Out[2]: <type 'module'>

    --
    Robert Kern

    "I have come to believe that the whole world is an enigma, a harmless enigma
    that is made terrible by our own mad attempt to interpret it as though it had
    an underlying truth."
    -- Umberto Eco
     
    Robert Kern, Oct 2, 2007
    #6
  7. rjcarr

    Steve Holden Guest

    Lawrence D'Oliveiro wrote:
    > In message <>, Robert
    > Kern wrote:
    >
    >> Not all of the modules in a package are imported by importing the
    >> top-level package.

    >
    > You can't import packages, only modules.
    >
    >> os.path is a particularly weird case because it is just an alias to the
    >> platform-specific path-handling module; os is not a package.

    >
    > os is a module, os.path is a variable within that module. That's all there
    > is to it.


    The Python documentation could probably be a little more expansive on
    the import front, but it's an area where historically many different
    attempts have been made to fix up the problems, or create new and more
    usable layers [that suffer from different problems].

    You *can* import a package, and a package is just a *little* different
    from a module in that the __init__.py file in the package directory
    provides the source for the first-import execution instead of the
    modulename.py file. The global namespace during this process is the
    package's global namespace, so if further imports are executed by the
    __init__ module the names of the imported objects are created in the
    package global namespace (along with the names of defined classes and
    functions, and other names bound by assignment) and can therefore be
    referenced relative to it. The package in which the package import was
    executed will end up defined in the namespace in which the import
    statement was executed.

    I will grant that you can't basically do anything in the __init__.py
    that you can't do in a module's modulename.py file. It is possible to
    define a hierarchy of namespaces concordant with the package's directory
    structure, but it doesn't matter whether package import creates the
    hierarchical namespace or assignment does. You can access module
    namespaces in a hierarchical way.

    That's about all that can be said without delving into the murky land of
    relative vs. absolute imports. That can be for another day. And another
    writer, probably.

    regards
    Steve
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    Holden Web LLC/Ltd http://www.holdenweb.com
    Skype: holdenweb http://del.icio.us/steve.holden

    Sorry, the dog ate my .sigline
     
    Steve Holden, Oct 2, 2007
    #7
  8. In message <>, Robert
    Kern wrote:

    > Lawrence D'Oliveiro wrote:
    >
    >> In message <>, Robert
    >> Kern wrote:
    >>
    >>> Not all of the modules in a package are imported by importing the
    >>> top-level package.

    >>
    >> You can't import packages, only modules.
    >>
    >>> os.path is a particularly weird case because it is just an alias to the
    >>> platform-specific path-handling module; os is not a package.

    >>
    >> os is a module, os.path is a variable within that module. That's all
    >> there is to it.

    >
    > Yes, but os.path is also module. That's why I said it was a weird case.


    You can't have modules within modules. os.path isn't an exception--see
    below.

    > In [1]: import os
    >
    > In [2]: type(os.path)
    > Out[2]: <type 'module'>


    On my Gentoo system:

    >>> import os
    >>> os.path

    <module 'posixpath' from '/usr/lib64/python2.5/posixpath.pyc'>

    It's just a variable that happens to point to the posixpath module.
     
    Lawrence D'Oliveiro, Oct 3, 2007
    #8
  9. In message <>, Steve
    Holden wrote:

    > You *can* import a package ...


    You're right. I was misremembering the behaviour of PyCrypto, where
    importing the upper-level packages do little more than give you a list of
    what algorithms are available.
     
    Lawrence D'Oliveiro, Oct 3, 2007
    #9
  10. rjcarr

    Ben Finney Guest

    Lawrence D'Oliveiro <_zealand> writes:

    > On my Gentoo system:
    >
    > >>> import os
    > >>> os.path

    > <module 'posixpath' from '/usr/lib64/python2.5/posixpath.pyc'>
    >
    > It's just a variable that happens to point to the posixpath module.


    There's no "pointing" going on. It's another name bound to the same
    object, of equal status to the 'posixpath' name.

    Python doesn't have pointers, and even "variable" is a misleading term
    in Python. Best to stick to "name" and "bound to".

    --
    \ "Crime is contagious ... if the government becomes a |
    `\ lawbreaker, it breeds contempt for the law." -- Justice Louis |
    _o__) Brandeis |
    Ben Finney
     
    Ben Finney, Oct 3, 2007
    #10
  11. Lawrence D'Oliveiro a écrit :
    > In message <>, Robert
    > Kern wrote:
    >
    >> Lawrence D'Oliveiro wrote:
    >>
    >>> In message <>, Robert
    >>> Kern wrote:
    >>>
    >>>> Not all of the modules in a package are imported by importing the
    >>>> top-level package.
    >>> You can't import packages, only modules.
    >>>
    >>>> os.path is a particularly weird case because it is just an alias to the
    >>>> platform-specific path-handling module; os is not a package.
    >>> os is a module, os.path is a variable within that module. That's all
    >>> there is to it.

    >> Yes, but os.path is also module. That's why I said it was a weird case.

    >
    > You can't have modules within modules.


    If you're talking about the filesystem representation (ie : .py files),
    you obviously can't have a file within a file, indeed.

    When it comes to the internal runtime representation of modules in
    Python, then it's totally different - a module is just an object, that
    can of course be an attribute of another module object.

    >>> import os
    >>> type(os)

    <type 'module'>
    >>> type(os.path)

    <type 'module'>
    >>>


    > os.path isn't an exception--see
    > below.
    >
    >> In [1]: import os
    >>
    >> In [2]: type(os.path)
    >> Out[2]: <type 'module'>

    >
    > On my Gentoo system:
    >
    > >>> import os
    > >>> os.path

    > <module 'posixpath' from '/usr/lib64/python2.5/posixpath.pyc'>
    >
    > It's just a variable that happens to point to the posixpath module.


    It's just a name bound to a module object.
     
    Bruno Desthuilliers, Oct 3, 2007
    #11
  12. En Wed, 03 Oct 2007 07:12:17 -0300, Lawrence D'Oliveiro
    <_zealand> escribi�:

    > In message <>, Robert
    > Kern wrote:
    >
    >> Lawrence D'Oliveiro wrote:
    >>
    >>> In message <>,
    >>> Robert
    >>> Kern wrote:
    >>>
    >>>> Not all of the modules in a package are imported by importing the
    >>>> top-level package.
    >>>
    >>> You can't import packages, only modules.
    >>>
    >>>> os.path is a particularly weird case because it is just an alias to
    >>>> the
    >>>> platform-specific path-handling module; os is not a package.
    >>>
    >>> os is a module, os.path is a variable within that module. That's all
    >>> there is to it.

    >>
    >> Yes, but os.path is also module. That's why I said it was a weird case.

    >
    > You can't have modules within modules. os.path isn't an exception--see
    > below.
    >
    >> In [1]: import os
    >>
    >> In [2]: type(os.path)
    >> Out[2]: <type 'module'>

    >
    > On my Gentoo system:
    >
    > >>> import os
    > >>> os.path

    > <module 'posixpath' from '/usr/lib64/python2.5/posixpath.pyc'>
    >
    > It's just a variable that happens to point to the posixpath module.


    A "module" is a certain type of Python objects, like ints, functions,
    exceptions and all else.
    The easiest way to create a module is to load it from file, but some
    modules are already built into the interpreter, and you can even create a
    module from scratch.

    py> import os
    py> type(os)
    <type 'module'>
    py> type(os.path)
    <type 'module'>
    py> os
    <module 'os' from 'c:\apps\python25\lib\os.pyc'>
    py> import sys
    py> type(sys)
    <type 'module'>
    py> sys
    <module 'sys' (built-in)>
    py> ModuleType = type(os)
    py> newmodule = ModuleType('newmodule')
    py> newmodule.a = 3
    py> newmodule
    <module 'newmodule' (built-in)>
    py> type(newmodule) is type(os.path)
    True

    "os" is a name that refers to the os module object. "os.path" means "the
    path attribute in the object referenced by the name os", that happens to
    be another module too.
    os is not a package; os.path is set when the os module is imported,
    depending on the platform. It may be ntpath, posixpath, macpath, or
    whatever. On Windows:

    py> import ntpath
    py> os.path is ntpath
    True
    py> import macpath
    py> import posixpath
    py> macpath.sep
    ':'
    py> ntpath.sep
    '\\'

    Apart from that, there is no magic involved, just plain attribute access
    like everywhere else.

    --
    Gabriel Genellina
     
    Gabriel Genellina, Oct 3, 2007
    #12
  13. On Wed, 2007-10-03 at 17:24 +0000, wang frank wrote:
    > Sorry for the wrong title of this email. Please ignore this email. I
    > have resend the question with correct title.


    But it's still in the wrong thread. When asking a new question, you
    should compose a new message instead of replying to an existing message.

    --
    Carsten Haese
    http://informixdb.sourceforge.net
     
    Carsten Haese, Oct 3, 2007
    #13
  14. rjcarr

    Robert Kern Guest

    Lawrence D'Oliveiro wrote:
    > In message <>, Robert
    > Kern wrote:
    >
    >> Lawrence D'Oliveiro wrote:
    >>
    >>> In message <>, Robert
    >>> Kern wrote:
    >>>
    >>>> Not all of the modules in a package are imported by importing the
    >>>> top-level package.
    >>> You can't import packages, only modules.
    >>>
    >>>> os.path is a particularly weird case because it is just an alias to the
    >>>> platform-specific path-handling module; os is not a package.
    >>> os is a module, os.path is a variable within that module. That's all
    >>> there is to it.

    >> Yes, but os.path is also module. That's why I said it was a weird case.

    >
    > You can't have modules within modules. os.path isn't an exception--see
    > below.
    >
    >> In [1]: import os
    >>
    >> In [2]: type(os.path)
    >> Out[2]: <type 'module'>

    >
    > On my Gentoo system:
    >
    > >>> import os
    > >>> os.path

    > <module 'posixpath' from '/usr/lib64/python2.5/posixpath.pyc'>
    >
    > It's just a variable that happens to point to the posixpath module.


    I believe that is precisely what I was saying.

    --
    Robert Kern

    "I have come to believe that the whole world is an enigma, a harmless enigma
    that is made terrible by our own mad attempt to interpret it as though it had
    an underlying truth."
    -- Umberto Eco
     
    Robert Kern, Oct 3, 2007
    #14
  15. +1 Subject line of the week (SLOTW)

    rjcarr wrote:
    > So my question is ... why are they [os.path and logging.handlers] different?


    [A] wrote:
    > Because you misspelled it. First, do a dir() on logging:


    wrote:
    > No, he didn't... OP: logging is a package and logging.handlers is one module
    > in the package... os.path is a particularly weird case...


    [C] wrote:
    > You can't import packages, only modules.


    [D] wrote:
    > Oh come on, this is unnecessary nitpicking.


    [E] wrote:
    > You *can* import a package, and a package is just a *little* different from a
    > module


    wrote:
    > Yes, but os.path is also module. That's why I said it was a weird case.


    [C] wrote:
    > You can't have modules within modules. os.path isn't an exception...It's just
    > a variable that happens to point to the posixpath module.


    [F] wrote:
    > There's no "pointing" going on. It's another name bound to the same object,
    > of equal status to the 'posixpath' name.


    [G] wrote:
    > a module is just an object, that can of course be an attribute of another
    > module object


    [H] wrote:
    > os is not a package; os.path is set when the os module is imported


    [C] wrote:
    > You're right. I was misremembering the behaviour of PyCrypto


    [J] wrote:
    > In Matlab you can use function dec2bin, hex2dec, dec2hex bin2dec functions to
    > convert decimal to binary and heximal etc.


    wrote:
    > I believe that is precisely what I was saying.



    with apologies to all concerned :)

    Michael
     
    Michael Spencer, Oct 3, 2007
    #15
  16. In message <>, Ben Finney wrote:

    > Lawrence D'Oliveiro <_zealand> writes:
    >
    >> On my Gentoo system:
    >>
    >> >>> import os
    >> >>> os.path

    >> <module 'posixpath' from '/usr/lib64/python2.5/posixpath.pyc'>
    >>
    >> It's just a variable that happens to point to the posixpath module.

    >
    > There's no "pointing" going on. It's another name bound to the same
    > object, of equal status to the 'posixpath' name.
    >
    > Python doesn't have pointers, and even "variable" is a misleading term
    > in Python. Best to stick to "name" and "bound to".


    In Python, all names _are_ variables. They are not "bound" to objects. The
    value of os.path is a pointer. It's implemented as a pointer, it has all
    the semantics of a pointer.

    Honestly, why do people react to the word "pointer" as though computers have
    to wear underwear to conceal something shameful going on in their nether
    regions?
     
    Lawrence D'Oliveiro, Oct 3, 2007
    #16
  17. On Thu, 2007-10-04 at 11:11 +1300, Lawrence D'Oliveiro wrote:
    > In Python, all names _are_ variables. They are not "bound" to objects. The
    > value of os.path is a pointer.


    No. "os.path" refers to the object that's known as the "path" attribute
    of the object known as "os". That object, in turn, is a module.

    > It's implemented as a pointer,


    While it is true that namespaces are implemented in CPython as
    collections of pointers to PyObject structures, that's an irrelevant
    implementation detail. I doubt that they are implemented as pointers in
    Jython, PyPy, or IronPython.

    > it has all the semantics of a pointer.


    No, it doesn't. A pointer means the physical address of a memory
    location, which implies that you can overwrite that memory location. Can
    you do that in Python?

    > Honestly, why do people react to the word "pointer" as though computers have
    > to wear underwear to conceal something shameful going on in their nether
    > regions?


    I won't speak for "people", but maybe it's because Python acts precisely
    as this underwear that does conceal the low-level regions of memory
    management and bit-twiddling that Python programmers like to avoid in
    favor of solving higher-level problems.

    If it helps you to think of Python names as "kind of like pointers,"
    you're free to do so, but it's only a weak analogy that can lead
    beginners to drawing incorrect conclusions.

    --
    Carsten Haese
    http://informixdb.sourceforge.net
     
    Carsten Haese, Oct 4, 2007
    #17
  18. rjcarr

    Steve Holden Guest

    Lawrence D'Oliveiro wrote:
    > In message <>, Ben Finney wrote:
    >
    >> Lawrence D'Oliveiro <_zealand> writes:
    >>
    >>> On my Gentoo system:
    >>>
    >>> >>> import os
    >>> >>> os.path
    >>> <module 'posixpath' from '/usr/lib64/python2.5/posixpath.pyc'>
    >>>
    >>> It's just a variable that happens to point to the posixpath module.

    >> There's no "pointing" going on. It's another name bound to the same
    >> object, of equal status to the 'posixpath' name.
    >>
    >> Python doesn't have pointers, and even "variable" is a misleading term
    >> in Python. Best to stick to "name" and "bound to".

    >
    > In Python, all names _are_ variables. They are not "bound" to objects. The
    > value of os.path is a pointer. It's implemented as a pointer, it has all
    > the semantics of a pointer.
    >
    > Honestly, why do people react to the word "pointer" as though computers have
    > to wear underwear to conceal something shameful going on in their nether
    > regions?


    Because they have been told by their church that all God-fearing names
    do what names have always done in programming languages, which is to
    describe areas of memory of a particular size, type and locality.

    You and I know that the semantics of Python names are precisely those of
    (to use an Algol 68 term, unless I am mistaken) automatically
    dereferenced pointers to objects of arbitrary type. I actually think
    that's one of the neatest things about Python, and I believe it's no
    accident that both Tim Peters and I were Icon enthusiasts.

    But the rest of the world clings to its illusions.

    regards
    Steve
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    Holden Web LLC/Ltd http://www.holdenweb.com
    Skype: holdenweb http://del.icio.us/steve.holden

    Sorry, the dog ate my .sigline
     
    Steve Holden, Oct 4, 2007
    #18
  19. rjcarr

    Steve Holden Guest

    Lawrence D'Oliveiro wrote:
    > In message <>, Ben Finney wrote:
    >
    >> Lawrence D'Oliveiro <_zealand> writes:
    >>
    >>> On my Gentoo system:
    >>>
    >>> >>> import os
    >>> >>> os.path
    >>> <module 'posixpath' from '/usr/lib64/python2.5/posixpath.pyc'>
    >>>
    >>> It's just a variable that happens to point to the posixpath module.

    >> There's no "pointing" going on. It's another name bound to the same
    >> object, of equal status to the 'posixpath' name.
    >>
    >> Python doesn't have pointers, and even "variable" is a misleading term
    >> in Python. Best to stick to "name" and "bound to".

    >
    > In Python, all names _are_ variables. They are not "bound" to objects. The
    > value of os.path is a pointer. It's implemented as a pointer, it has all
    > the semantics of a pointer.
    >
    > Honestly, why do people react to the word "pointer" as though computers have
    > to wear underwear to conceal something shameful going on in their nether
    > regions?


    Because they have been told by their church that all God-fearing names
    do what names have always done in programming languages, which is to
    describe areas of memory of a particular size, type and locality.

    You and I know that the semantics of Python names are precisely those of
    (to use an Algol 68 term, unless I am mistaken) automatically
    dereferenced pointers to objects of arbitrary type. I actually think
    that's one of the neatest things about Python, and I believe it's no
    accident that both Tim Peters and I were Icon enthusiasts.

    But the rest of the world clings to its illusions.

    regards
    Steve
    --
    Steve Holden +1 571 484 6266 +1 800 494 3119
    Holden Web LLC/Ltd http://www.holdenweb.com
    Skype: holdenweb http://del.icio.us/steve.holden

    Sorry, the dog ate my .sigline
     
    Steve Holden, Oct 4, 2007
    #19
  20. rjcarr

    Ben Finney Guest

    Steve Holden <> writes:

    > You and I know that the semantics of Python names are precisely
    > those of (to use an Algol 68 term, unless I am mistaken)
    > automatically dereferenced pointers to objects of arbitrary type.


    Yes. That's exactly why it's wrong to refer to them as pointers. They
    don't behave like the pointers in other languages, which are *not*
    "automatically-dereferenced", nor "to objects of arbitrary type".

    It's misleading to talk about a Python name as a "pointer" without
    those qualifiers, because they're *not* implicit in programmers'
    understanding of that term.

    If you want to continually refer to them as
    "automatically-dereferenced pointers to objects of arbitrary type", by
    all means go ahead. That at least *does* fit the semantics. But the
    simple term "pointer" does *not* describe them in the absence of those
    necessary and non-default qualifiers, and is misleading.

    --
    \ "I wish there was a knob on the TV to turn up the intelligence. |
    `\ There's a knob called 'brightness' but it doesn't work." -- |
    _o__) Eugene P. Gallagher |
    Ben Finney
     
    Ben Finney, Oct 4, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Doug Farrell

    re module substitution confusion

    Doug Farrell, Jul 7, 2003, in forum: Python
    Replies:
    1
    Views:
    295
    Doug Farrell
    Jul 8, 2003
  2. Replies:
    6
    Views:
    313
    Magnus Lycka
    Oct 7, 2005
  3. Maric Michaud
    Replies:
    0
    Views:
    7,194
    Maric Michaud
    Jun 24, 2006
  4. Jugdish
    Replies:
    3
    Views:
    339
    Scott David Daniels
    Jan 1, 2008
  5. Siddhant
    Replies:
    1
    Views:
    256
    Diez B. Roggisch
    May 6, 2008
Loading...

Share This Page