compile Py2.6 on SL

[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.
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

 

[John Nagle]

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

 

[James Mills]

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

 

[MRAB]

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.

 

[James Mills]

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

 

[moerchendiser2k3]

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...

 

[James Mills]

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

 

[Terry Reedy]

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.

 

[Michel Claveau - MVP]

Hello!

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

@-salutations

 

[Aahz]

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.

 

[Lie Ryan]

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)

 

[Ethan Furman]

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?

 

[Jorgen Grahn]

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

 

[Lie Ryan]

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

 

[Martin v. Loewis]

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

 

[Steven D'Aprano]

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.