compile Py2.6 on SL

Discussion in 'Python' started by moerchendiser2k3, Sep 16, 2010.

  1. Hi,

    I have some trouble with Python on Snow Leopard (10.6.3). I compile
    Python as a framework(for 32/64bit) without any problems.
    But implementing the lib in my C app, I get the following error on
    linking:

    Undefined symbols:
    "_Py_InitModule4_64", referenced from:
    RegisterModule_BPY(char const*, PyMethodDef*, char const*,
    _object*, int)in i_moduleobject.o
    ld: symbol(s) not found

    I read a lot of stuff about this problem, but nothing helped me. My
    app is in 64-bit and I compiled Python for 32/64bit.
    When I compile exactly the same package with the same configure flags
    under Leopard (10.5.8) it works fine.
    Any ideas?

    Thanks a lot!

    Bye, moerchendiser2k3
    moerchendiser2k3, Sep 16, 2010
    #1
    1. Advertising

  2. moerchendiser2k3

    John Nagle Guest

    The trouble with "dynamic attributes".

    There's a tendency to use "dynamic attributes" in Python when
    trying to encapsulate objects from other systems. It almost
    works. But it's usually a headache in the end, and should be
    discouraged. Here's why.

    Some parsers, like BeautifulSoup, try to encapsulate HTML tag
    fields as Python attributes. This gives trouble for several reasons.
    First, the syntax for Python attributes and Python tags is different.
    Some strings won't convert to attributes. You can crash BeautifulSoup
    (which is supposed to be robust against bad HTML) by using a non-ASCII
    character in a tag in an HTML document it is parsing.

    Then there's the reserved word problem. "class" is a valid field
    name in HTML, and a reserved word in Python. So there has to be a
    workaround for reserved words.

    There's also the problem that user-created attributes go into the
    same namespace as other object attributes. This creates a vulnerability
    comparable to MySQL injection. If an attacker controls the input
    being parsed, they may be able to induce a store into something
    they shouldn't be able to access.

    This problem shows up again in "suds", the module for writing
    SOAP RPC clients. This module tries to use attributes for
    XML structures, and it almost works. It tends to founder when
    the XML data model has strings that aren't valid attributes.
    ("-" appears frequently in XML fields, but is not valid in an
    attribute name.)

    Using a dictionary, or inheriting an object from "dict", doesn't
    create these problems. The data items live in their own dictionary,
    and can't clash with anything else. Of course, you have to write

    tag['a']

    instead of

    tag.a

    but then, at least you know what to do when you need

    tag['class']

    "suds", incidentally, tries to do both. They accept both

    item.fieldname

    and

    item['fieldname']

    But they are faking a dictionary, and it doesn't quite work right.

    'fieldname' in item

    works correctly, but the form to get None when the field is missing,

    item.get('fieldname',None)

    isn't implemented.

    Much of the code that uses objects as dictionaries either predates
    the days when you couldn't inherit from "dict", or was written by
    Javascript programmers. (In Javascript, an object and a dictionary
    are the same thing. In Python, they're not.) In new code, it's
    better to inherit from "dict". It eliminates the special cases.

    John Nagle
    John Nagle, Sep 16, 2010
    #2
    1. Advertising

  3. moerchendiser2k3

    James Mills Guest

    Re: The trouble with "dynamic attributes".

    On Fri, Sep 17, 2010 at 7:46 AM, John Nagle <> wrote:
    > There's a tendency to use "dynamic attributes" in Python when
    > trying to encapsulate objects from other systems.  It almost
    > works.  But it's usually a headache in the end, and should be
    > discouraged.  Here's why.



    What do you mean by "dynamic attributes " ?

    Can you show a simple code example ?

    cheers
    James

    --
    -- James Mills
    --
    -- "Problems are solved by method"
    James Mills, Sep 16, 2010
    #3
  4. moerchendiser2k3

    MRAB Guest

    Re: The trouble with "dynamic attributes".

    On 16/09/2010 22:46, John Nagle wrote:
    > There's a tendency to use "dynamic attributes" in Python when
    > trying to encapsulate objects from other systems. It almost
    > works. But it's usually a headache in the end, and should be
    > discouraged. Here's why.
    >
    > Some parsers, like BeautifulSoup, try to encapsulate HTML tag
    > fields as Python attributes. This gives trouble for several reasons.
    > First, the syntax for Python attributes and Python tags is different.
    > Some strings won't convert to attributes. You can crash BeautifulSoup
    > (which is supposed to be robust against bad HTML) by using a non-ASCII
    > character in a tag in an HTML document it is parsing.
    >
    > Then there's the reserved word problem. "class" is a valid field
    > name in HTML, and a reserved word in Python. So there has to be a
    > workaround for reserved words.
    >
    > There's also the problem that user-created attributes go into the
    > same namespace as other object attributes. This creates a vulnerability
    > comparable to MySQL injection. If an attacker controls the input
    > being parsed, they may be able to induce a store into something
    > they shouldn't be able to access.
    >
    > This problem shows up again in "suds", the module for writing
    > SOAP RPC clients. This module tries to use attributes for
    > XML structures, and it almost works. It tends to founder when
    > the XML data model has strings that aren't valid attributes.
    > ("-" appears frequently in XML fields, but is not valid in an
    > attribute name.)
    >
    > Using a dictionary, or inheriting an object from "dict", doesn't
    > create these problems. The data items live in their own dictionary,
    > and can't clash with anything else. Of course, you have to write
    >
    > tag['a']
    >
    > instead of
    >
    > tag.a
    >
    > but then, at least you know what to do when you need
    >
    > tag['class']
    >
    > "suds", incidentally, tries to do both. They accept both
    >
    > item.fieldname
    >
    > and
    >
    > item['fieldname']
    >
    > But they are faking a dictionary, and it doesn't quite work right.
    >
    > 'fieldname' in item
    >
    > works correctly, but the form to get None when the field is missing,
    >
    > item.get('fieldname',None)
    >
    > isn't implemented.
    >
    > Much of the code that uses objects as dictionaries either predates
    > the days when you couldn't inherit from "dict", or was written by
    > Javascript programmers. (In Javascript, an object and a dictionary
    > are the same thing. In Python, they're not.) In new code, it's
    > better to inherit from "dict". It eliminates the special cases.
    >

    For the work on updating the re module there was a discussion about
    whether named capture groups should be available as attributes of the
    match object or via subscripting (or both?). Subscripting seemed
    preferable to me because:

    1. Adding attributes looks too much like 'magic'.

    2. What should happen if a group name conflicts with a normal attribute?

    3. What should happen if a group name conflicts with a reserved word?

    For those reasons the new regex module uses subscripting. It's more
    Pythonic, IMHO.
    MRAB, Sep 17, 2010
    #4
  5. moerchendiser2k3

    James Mills Guest

    Re: The trouble with "dynamic attributes".

    On Fri, Sep 17, 2010 at 9:27 AM, MRAB <> wrote:
    > For the work on updating the re module there was a discussion about
    > whether named capture groups should be available as attributes of the
    > match object or via subscripting (or both?). Subscripting seemed
    > preferable to me because:
    >
    > 1. Adding attributes looks too much like 'magic'.
    >
    > 2. What should happen if a group name conflicts with a normal attribute?
    >
    > 3. What should happen if a group name conflicts with a reserved word?
    >
    > For those reasons the new regex module uses subscripting. It's more
    > Pythonic, IMHO.


    I agree with 2) and 3) and in general this is probably a
    "good approach".

    cheers
    James

    --
    -- James Mills
    --
    -- "Problems are solved by method"
    James Mills, Sep 17, 2010
    #5
  6. Re: The trouble with "dynamic attributes".

    I am really sorry, but what are you talking about ? Hmmm, ...I have
    problems to compile Python on SL, I did not ask anything about
    "dynamic attribute". I don't get it...
    moerchendiser2k3, Sep 17, 2010
    #6
  7. moerchendiser2k3

    James Mills Guest

    Re: The trouble with "dynamic attributes".

    On Fri, Sep 17, 2010 at 11:33 AM, moerchendiser2k3
    <> wrote:
    > I am really sorry, but what are you talking about ? Hmmm, ...I have
    > problems to compile Python on SL, I did not ask anything about
    > "dynamic attribute". I don't get it...


    You are subscribed to the python mailing list.

    Check your subscription status with the link below.

    cheers
    James


    --
    -- James Mills
    --
    -- "Problems are solved by method"
    James Mills, Sep 17, 2010
    #7
  8. moerchendiser2k3

    Terry Reedy Guest

    Re: The trouble with "dynamic attributes".

    On 9/16/2010 5:46 PM, John Nagle wrote:

    By mistakenly posted this as a response to "compile Py2.6 on SL", you
    1) confused the OP and
    2) limited it audience -- I agree with your points, but would have
    missed this if I had had threads collapsed, as I usually do, since I
    have no interest in 2.6 compilation.

    --
    Terry Jan Reedy
    Terry Reedy, Sep 17, 2010
    #8
  9. Hello!

    SL (SilverLight) is a library/techno who give functions.
    You cannot compile Python on SL (SilverLight).

    @-salutations
    --
    Michel Claveau
    Michel Claveau - MVP, Sep 17, 2010
    #9
  10. moerchendiser2k3

    Aahz Guest

    In article <4c934f3c$0$5417$>,
    Michel Claveau - MVP <> wrote:
    >
    >SL (SilverLight) is a library/techno who give functions.
    >You cannot compile Python on SL (SilverLight).


    SL (Snow Leopard) is a popular platform for Python development. I
    suppose this is another argument against TLAs.
    --
    Aahz () <*> http://www.pythoncraft.com/

    "The volume of a pizza of thickness 'a' and radius 'z' is
    given by pi*z*z*a"
    Aahz, Sep 17, 2010
    #10
  11. moerchendiser2k3

    Lie Ryan Guest

    Re: The trouble with "dynamic attributes".

    On 09/17/10 07:46, John Nagle wrote:
    > There's a tendency to use "dynamic attributes" in Python when
    > trying to encapsulate objects from other systems. It almost
    > works. But it's usually a headache in the end, and should be
    > discouraged. Here's why.


    I personally love them, they makes XML files looks more like python objects.

    <a>
    <b>foo</b>
    <c>bar</c>
    </a>

    being able to say:

    if a.b == 'foo':
    print a.c

    is very convenient.

    Yes, it doesn't work if the attribute contains special characters that
    python doesn't recognize; but you shouldn't use these syntax if that's
    the case. And even dict-syntax is not perfect for accessing XML file, e.g.:

    <a>
    <b>foo</b>
    <b>bar</b>
    </a>

    should a['b'] be 'foo' or 'bar'?

    So, personally I think both attribute-syntax and dict-syntax should
    continue; it should be up to the programmer to determine whether the
    limitations imposed by these syntaxes are suitable for their need (e.g.
    if the programmer knows he would only use alphabet tag name, then
    attr-style syntax is fine; and if he knows that there is no duplicate,
    then dict-style syntax is fine as well; and if he can't rely on both,
    then and only then, he'd be forced to do it the long way)
    Lie Ryan, Sep 17, 2010
    #11
  12. moerchendiser2k3

    Ethan Furman Guest

    Re: The trouble with "dynamic attributes".

    Lie Ryan wrote:
    [snip]
    > And even dict-syntax is not perfect for accessing XML file, e.g.:
    >
    > <a>
    > <b>foo</b>
    > <b>bar</b>
    > </a>
    >
    > should a['b'] be 'foo' or 'bar'?


    Attribute style access would also fail in this instance -- how is this
    worked-around?

    --
    ~Ethan~
    Ethan Furman, Sep 17, 2010
    #12
  13. moerchendiser2k3

    Jorgen Grahn Guest

    Re: The trouble with "dynamic attributes".

    On Fri, 2010-09-17, James Mills wrote:
    > On Fri, Sep 17, 2010 at 11:33 AM, moerchendiser2k3
    > <> wrote:
    >> I am really sorry, but what are you talking about ? Hmmm, ...I have
    >> problems to compile Python on SL, I did not ask anything about
    >> "dynamic attribute". I don't get it...

    >
    > You are subscribed to the python mailing list.
    >
    > Check your subscription status with the link below.


    JN's posting was technically a reply to JM's SL question -- a
    References: header led back to it. That's why he was confused.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Sep 19, 2010
    #13
  14. moerchendiser2k3

    Lie Ryan Guest

    Re: The trouble with "dynamic attributes".

    On 09/18/10 03:53, Ethan Furman wrote:
    > Lie Ryan wrote:
    > [snip]
    >> And even dict-syntax is not perfect for accessing XML file, e.g.:
    >>
    >> <a>
    >> <b>foo</b>
    >> <b>bar</b>
    >> </a>
    >>
    >> should a['b'] be 'foo' or 'bar'?

    >
    > Attribute style access would also fail in this instance -- how is this
    > worked-around?


    By not having multiple b in the first place!

    However, if you cannot avoid having duplicates, then you would have to
    use a different approach:

    SAX (Simple API for XML; Java has a weird sense of simplicity):

    import xml.sax as sax
    from xml.sax.handler import ContentHandler
    class MyHandler(ContentHandler):
    def __init__(self):
    self.inB = False
    def startElement(self, name, attrs):
    if name == 'b':
    self.inB = True
    def characters(self, ch):
    if self.inB:
    print ch
    def endElement(self, name):
    if name == 'b':
    self.inB = False

    data = '<a><b>Foo</b><c>Evil</c><b>Bar</b></a>'
    sax.parseString(data, MyHandler())


    or in ElementTree:

    import xml.etree.ElementTree as et
    data = '<a><b>Foo</b><c>Evil</c><b>Bar</b></a>'
    a = et.fromstring(data)
    for elem in a.findall('b'):
    print elem.text
    Lie Ryan, Sep 19, 2010
    #14
  15. Am 16.09.2010 17:34, schrieb moerchendiser2k3:
    > Hi,
    >
    > I have some trouble with Python on Snow Leopard (10.6.3). I compile
    > Python as a framework(for 32/64bit) without any problems.
    > But implementing the lib in my C app, I get the following error on
    > linking:
    >
    > Undefined symbols:
    > "_Py_InitModule4_64", referenced from:
    > RegisterModule_BPY(char const*, PyMethodDef*, char const*,
    > _object*, int)in i_moduleobject.o
    > ld: symbol(s) not found
    >
    > I read a lot of stuff about this problem, but nothing helped me. My
    > app is in 64-bit and I compiled Python for 32/64bit.


    I'm skeptical that you did - if you really *had* compiled Python for
    AMD64, this error would not have occured. Please use file/lipo to
    verify that the Python library really is available as 64-bit code.

    Regards,
    Martin
    Martin v. Loewis, Sep 19, 2010
    #15
  16. Re: The trouble with "dynamic attributes".

    On Sun, 19 Sep 2010 16:47:26 +1000, Lie Ryan wrote:

    > On 09/18/10 03:53, Ethan Furman wrote:
    >> Lie Ryan wrote:
    >> [snip]
    >>> And even dict-syntax is not perfect for accessing XML file, e.g.:
    >>>
    >>> <a>
    >>> <b>foo</b>
    >>> <b>bar</b>
    >>> </a>
    >>>
    >>> should a['b'] be 'foo' or 'bar'?

    >>
    >> Attribute style access would also fail in this instance -- how is this
    >> worked-around?

    >
    > By not having multiple b in the first place!



    Which works just as well for dict access.

    Given that attribute access is nothing but syntactic sugar for dict
    access, there is nothing you can do with attribute access that can't be
    done with dict access. However, the same does not apply in reverse --
    there are many things you can't do with attribute access that work fine
    with dict access.


    --
    Steven
    Steven D'Aprano, Sep 20, 2010
    #16
    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. Raymond Hettinger

    Py2.3: Feedback on Sets

    Raymond Hettinger, Aug 12, 2003, in forum: Python
    Replies:
    21
    Views:
    688
    Christos TZOTZIOY Georgiou
    Aug 20, 2003
  2. Holger Joukl

    py2.1->py2.3.3 __getattr__ confusion

    Holger Joukl, Jul 2, 2004, in forum: Python
    Replies:
    1
    Views:
    298
    Peter Otten
    Jul 2, 2004
  3. Holger Joukl
    Replies:
    2
    Views:
    249
    Michael Hudson
    Jul 9, 2004
  4. Nagaraj
    Replies:
    1
    Views:
    837
    Lionel B
    Mar 1, 2007
  5. Josef Dalcolmo

    getmtime differs between Py2.5 and Py2.4

    Josef Dalcolmo, May 7, 2007, in forum: Python
    Replies:
    16
    Views:
    527
    Joe Salmeri
    Jun 1, 2007
Loading...

Share This Page