You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2006/10/02 19:40:27 UTC
Re: SDO in a Python component?
[snip]
> On 9/22/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> To allow Python components to handle more than just simple data types,
>> we need to decide how we present structured data / complex types to
>> Python components. We'll probably want to support many more data binding
>> options in the future, but we need one simple solution as a starting
>> point.
>>
>> For Ruby I have implemented support for Rexml for now mainly because
>> it's included in the Ruby distribution. What do you guys think we should
>> use for Python?
>> - an xml.dom or xml.minidom - from the Python standard library
>> - an xml.ElementTree - more pythonic and nicer rendering, recent
>> addition to the Python 2.5 standard library (just released on Sept
>> 19th), available as a separate package on older releases
>> - a new implementation of a Python transcription of the SDO API?
>>
>> Here's what I was thinking about:
>> - step 1, soon - ElementTree
>> - step 2, longer term - an SDO API
>>
>> Any thoughts?
>>
>> --
>> Jean-Sebastien
>>
Andrew Borley wrote:
[snip]
> Yep, I was thinking about this too - I think you're right that we need
> something soon (and basing it on an XML technology that's already
> available is the right way to do this) and then an SDO API later
> (probably wrappering the C++ implementation, in a similar way to the
> PHP SDO package).
>
>
We're going to need something if we want to include the support for
Python in our M2 release. I was rereading this thread and I'm not sure
that we've clearly identified how we're going to present structured data
to Python scripts (coming from a Web Service for example).
Any more thoughts? Do people prefer:
- ElementTree?
- A flavor of DOM?
- the SDO API wrapped in SWIG?
- a more Pythonic rendering of the SDO API?
Any Python developers out there would like to jump in and tell us their
preference?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO in a Python component?
Posted by Andrew Borley <aj...@gmail.com>.
On 11/27/06, Andrew Borley <aj...@gmail.com> wrote:
> On 11/27/06, Andrew Borley <aj...@gmail.com> wrote:
> > On 11/27/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > > Andrew Borley wrote:
> > > > OK, with no dissenting voices, I've put in this fix at r476094. SDOs
> > > > now get converted to Python xml.etree.ElementTree.Element objects when
> > > > used as parameters or properties to Python components (and the
> > > > conversion goes in the opposite direction when a Python component
> > > > returns an Element).
> > > >
> > > > Cheers
> > > >
> > > > Andy
> > > >
> > > >
> > > > On 11/15/06, Andrew Borley <aj...@gmail.com> wrote:
> > > >> I've started to fix this hole in the SCA C++ Python support.
> > > >>
> > > >> Looking at the various options, ElementTree seems the simplest, most
> > > >> "Pythonic" XML library to use - this is included in Python 2.5, but I
> > > >> don't think it is in earlier versions so we'll need to up our required
> > > >> Python level to 2.5 or provide the details of how to add ElementTree
> > > >> support (which is very simple - the library is written in Python and
> > > >> claims to be runnable on 1.5.2 and later).
> > > >>
> > > >> In the future it may be good to have something more SDO-ish - what do
> > > >> people think?
> > > >>
> > > >> Cheers
> > > >> Andy
> > > >>
> > > >> On 10/2/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > > >> > [snip]
> > > >> > > On 9/22/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > > >> > >> To allow Python components to handle more than just simple data
> > > >> types,
> > > >> > >> we need to decide how we present structured data / complex types to
> > > >> > >> Python components. We'll probably want to support many more data
> > > >> binding
> > > >> > >> options in the future, but we need one simple solution as a
> > > >> starting
> > > >> > >> point.
> > > >> > >>
> > > >> > >> For Ruby I have implemented support for Rexml for now mainly
> > > >> because
> > > >> > >> it's included in the Ruby distribution. What do you guys think
> > > >> we should
> > > >> > >> use for Python?
> > > >> > >> - an xml.dom or xml.minidom - from the Python standard library
> > > >> > >> - an xml.ElementTree - more pythonic and nicer rendering, recent
> > > >> > >> addition to the Python 2.5 standard library (just released on Sept
> > > >> > >> 19th), available as a separate package on older releases
> > > >> > >> - a new implementation of a Python transcription of the SDO API?
> > > >> > >>
> > > >> > >> Here's what I was thinking about:
> > > >> > >> - step 1, soon - ElementTree
> > > >> > >> - step 2, longer term - an SDO API
> > > >> > >>
> > > >> > >> Any thoughts?
> > > >> > >>
> > > >> > >> --
> > > >> > >> Jean-Sebastien
> > > >> > >>
> > > >> > Andrew Borley wrote:
> > > >> > [snip]
> > > >> > > Yep, I was thinking about this too - I think you're right that we
> > > >> need
> > > >> > > something soon (and basing it on an XML technology that's already
> > > >> > > available is the right way to do this) and then an SDO API later
> > > >> > > (probably wrappering the C++ implementation, in a similar way to the
> > > >> > > PHP SDO package).
> > > >> > >
> > > >> > >
> > > >> >
> > > >> > We're going to need something if we want to include the support for
> > > >> > Python in our M2 release. I was rereading this thread and I'm not sure
> > > >> > that we've clearly identified how we're going to present structured
> > > >> data
> > > >> > to Python scripts (coming from a Web Service for example).
> > > >> >
> > > >> > Any more thoughts? Do people prefer:
> > > >> > - ElementTree?
> > > >> > - A flavor of DOM?
> > > >> > - the SDO API wrapped in SWIG?
> > > >> > - a more Pythonic rendering of the SDO API?
> > > >> >
> > > >> > Any Python developers out there would like to jump in and tell us
> > > >> their
> > > >> > preference?
> > > >> >
> > > >> > --
> > > >> > Jean-Sebastien
> > > >> >
> > > >> >
> > > >> > ---------------------------------------------------------------------
> > > >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >> >
> > > >> >
> > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > > Andy,
> > >
> > > I'm putting together a new REST sample illustrating how to
> > > Create/Retrieve/Update/Delete resources using a REST binding, and I'm
> > > writing this sample in Python (to help show your Python extension as
> > > well). Do you have any code snippets showing how to use Python
> > > ElementTrees in a component that I could reuse?
> > >
> >
> > Hi Sebastien,
> >
> > I'm just tidying up a sample that demonstrates using ElementTrees
> > returned from a web service - found & fixed a couple of bugs on the
> > way that I need to check in too - will hopefully get this up tonight.
> >
>
> Gah! My development machine appears to have crashed - I'm unable to
> login remotely. Sorry Sebastien, I'm going to have to check these
> changes in tomorrow..
>
> The Python code for dealing with ElementTrees looks something like:
>
> import xml.etree.ElementTree
> elem = myService.myMethod(arg1, arg2) # gets an Element object
> tree = ElementTree(elem) # convert the Element to an ElementTree object
> data = tree.findtext("//data") # Finds the text in the first <data> tag
>
> See http://docs.python.org/lib/elementtree-elementtree-objects.html
> for more info, or there are a few tutorials around the web
>
OK, I've put up this sample at
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/PythonWeatherForecast/
It uses the US Weather Forecast service at
http://www.webservicex.net/WeatherForecast.asmx which returns a
complexType, which binding.ws converts to SDO, which the Python
extension then converts to an ElementTree.
I looked at using the Amazon web services, but discovered an Axis2C
bug that would strip off the query part of the endpoint URL, so the
address called was incorrect.
I looked at using the Google web services but they are RPC, which we
don't (yet) support
I looked at using the eBay web services but they required a security
element in the SOAP header. We don't currently support anything like
this - anyone have any good ideas how we might go about this? Some
kind of property perhaps?
I looked at using the Yahoo web services but they don't do SOAP, only REST..
So, lots to do to get our real-world web-service support up to scratch!
Cheers
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO in a Python component?
Posted by Andrew Borley <aj...@gmail.com>.
On 11/27/06, Andrew Borley <aj...@gmail.com> wrote:
> On 11/27/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > Andrew Borley wrote:
> > > OK, with no dissenting voices, I've put in this fix at r476094. SDOs
> > > now get converted to Python xml.etree.ElementTree.Element objects when
> > > used as parameters or properties to Python components (and the
> > > conversion goes in the opposite direction when a Python component
> > > returns an Element).
> > >
> > > Cheers
> > >
> > > Andy
> > >
> > >
> > > On 11/15/06, Andrew Borley <aj...@gmail.com> wrote:
> > >> I've started to fix this hole in the SCA C++ Python support.
> > >>
> > >> Looking at the various options, ElementTree seems the simplest, most
> > >> "Pythonic" XML library to use - this is included in Python 2.5, but I
> > >> don't think it is in earlier versions so we'll need to up our required
> > >> Python level to 2.5 or provide the details of how to add ElementTree
> > >> support (which is very simple - the library is written in Python and
> > >> claims to be runnable on 1.5.2 and later).
> > >>
> > >> In the future it may be good to have something more SDO-ish - what do
> > >> people think?
> > >>
> > >> Cheers
> > >> Andy
> > >>
> > >> On 10/2/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > >> > [snip]
> > >> > > On 9/22/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > >> > >> To allow Python components to handle more than just simple data
> > >> types,
> > >> > >> we need to decide how we present structured data / complex types to
> > >> > >> Python components. We'll probably want to support many more data
> > >> binding
> > >> > >> options in the future, but we need one simple solution as a
> > >> starting
> > >> > >> point.
> > >> > >>
> > >> > >> For Ruby I have implemented support for Rexml for now mainly
> > >> because
> > >> > >> it's included in the Ruby distribution. What do you guys think
> > >> we should
> > >> > >> use for Python?
> > >> > >> - an xml.dom or xml.minidom - from the Python standard library
> > >> > >> - an xml.ElementTree - more pythonic and nicer rendering, recent
> > >> > >> addition to the Python 2.5 standard library (just released on Sept
> > >> > >> 19th), available as a separate package on older releases
> > >> > >> - a new implementation of a Python transcription of the SDO API?
> > >> > >>
> > >> > >> Here's what I was thinking about:
> > >> > >> - step 1, soon - ElementTree
> > >> > >> - step 2, longer term - an SDO API
> > >> > >>
> > >> > >> Any thoughts?
> > >> > >>
> > >> > >> --
> > >> > >> Jean-Sebastien
> > >> > >>
> > >> > Andrew Borley wrote:
> > >> > [snip]
> > >> > > Yep, I was thinking about this too - I think you're right that we
> > >> need
> > >> > > something soon (and basing it on an XML technology that's already
> > >> > > available is the right way to do this) and then an SDO API later
> > >> > > (probably wrappering the C++ implementation, in a similar way to the
> > >> > > PHP SDO package).
> > >> > >
> > >> > >
> > >> >
> > >> > We're going to need something if we want to include the support for
> > >> > Python in our M2 release. I was rereading this thread and I'm not sure
> > >> > that we've clearly identified how we're going to present structured
> > >> data
> > >> > to Python scripts (coming from a Web Service for example).
> > >> >
> > >> > Any more thoughts? Do people prefer:
> > >> > - ElementTree?
> > >> > - A flavor of DOM?
> > >> > - the SDO API wrapped in SWIG?
> > >> > - a more Pythonic rendering of the SDO API?
> > >> >
> > >> > Any Python developers out there would like to jump in and tell us
> > >> their
> > >> > preference?
> > >> >
> > >> > --
> > >> > Jean-Sebastien
> > >> >
> > >> >
> > >> > ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >> >
> > >> >
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
> > Andy,
> >
> > I'm putting together a new REST sample illustrating how to
> > Create/Retrieve/Update/Delete resources using a REST binding, and I'm
> > writing this sample in Python (to help show your Python extension as
> > well). Do you have any code snippets showing how to use Python
> > ElementTrees in a component that I could reuse?
> >
>
> Hi Sebastien,
>
> I'm just tidying up a sample that demonstrates using ElementTrees
> returned from a web service - found & fixed a couple of bugs on the
> way that I need to check in too - will hopefully get this up tonight.
>
Gah! My development machine appears to have crashed - I'm unable to
login remotely. Sorry Sebastien, I'm going to have to check these
changes in tomorrow..
The Python code for dealing with ElementTrees looks something like:
import xml.etree.ElementTree
elem = myService.myMethod(arg1, arg2) # gets an Element object
tree = ElementTree(elem) # convert the Element to an ElementTree object
data = tree.findtext("//data") # Finds the text in the first <data> tag
See http://docs.python.org/lib/elementtree-elementtree-objects.html
for more info, or there are a few tutorials around the web
Cheers
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO in a Python component?
Posted by Andrew Borley <aj...@gmail.com>.
On 11/27/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Andrew Borley wrote:
> > OK, with no dissenting voices, I've put in this fix at r476094. SDOs
> > now get converted to Python xml.etree.ElementTree.Element objects when
> > used as parameters or properties to Python components (and the
> > conversion goes in the opposite direction when a Python component
> > returns an Element).
> >
> > Cheers
> >
> > Andy
> >
> >
> > On 11/15/06, Andrew Borley <aj...@gmail.com> wrote:
> >> I've started to fix this hole in the SCA C++ Python support.
> >>
> >> Looking at the various options, ElementTree seems the simplest, most
> >> "Pythonic" XML library to use - this is included in Python 2.5, but I
> >> don't think it is in earlier versions so we'll need to up our required
> >> Python level to 2.5 or provide the details of how to add ElementTree
> >> support (which is very simple - the library is written in Python and
> >> claims to be runnable on 1.5.2 and later).
> >>
> >> In the future it may be good to have something more SDO-ish - what do
> >> people think?
> >>
> >> Cheers
> >> Andy
> >>
> >> On 10/2/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >> > [snip]
> >> > > On 9/22/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >> > >> To allow Python components to handle more than just simple data
> >> types,
> >> > >> we need to decide how we present structured data / complex types to
> >> > >> Python components. We'll probably want to support many more data
> >> binding
> >> > >> options in the future, but we need one simple solution as a
> >> starting
> >> > >> point.
> >> > >>
> >> > >> For Ruby I have implemented support for Rexml for now mainly
> >> because
> >> > >> it's included in the Ruby distribution. What do you guys think
> >> we should
> >> > >> use for Python?
> >> > >> - an xml.dom or xml.minidom - from the Python standard library
> >> > >> - an xml.ElementTree - more pythonic and nicer rendering, recent
> >> > >> addition to the Python 2.5 standard library (just released on Sept
> >> > >> 19th), available as a separate package on older releases
> >> > >> - a new implementation of a Python transcription of the SDO API?
> >> > >>
> >> > >> Here's what I was thinking about:
> >> > >> - step 1, soon - ElementTree
> >> > >> - step 2, longer term - an SDO API
> >> > >>
> >> > >> Any thoughts?
> >> > >>
> >> > >> --
> >> > >> Jean-Sebastien
> >> > >>
> >> > Andrew Borley wrote:
> >> > [snip]
> >> > > Yep, I was thinking about this too - I think you're right that we
> >> need
> >> > > something soon (and basing it on an XML technology that's already
> >> > > available is the right way to do this) and then an SDO API later
> >> > > (probably wrappering the C++ implementation, in a similar way to the
> >> > > PHP SDO package).
> >> > >
> >> > >
> >> >
> >> > We're going to need something if we want to include the support for
> >> > Python in our M2 release. I was rereading this thread and I'm not sure
> >> > that we've clearly identified how we're going to present structured
> >> data
> >> > to Python scripts (coming from a Web Service for example).
> >> >
> >> > Any more thoughts? Do people prefer:
> >> > - ElementTree?
> >> > - A flavor of DOM?
> >> > - the SDO API wrapped in SWIG?
> >> > - a more Pythonic rendering of the SDO API?
> >> >
> >> > Any Python developers out there would like to jump in and tell us
> >> their
> >> > preference?
> >> >
> >> > --
> >> > Jean-Sebastien
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >
> >> >
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
> Andy,
>
> I'm putting together a new REST sample illustrating how to
> Create/Retrieve/Update/Delete resources using a REST binding, and I'm
> writing this sample in Python (to help show your Python extension as
> well). Do you have any code snippets showing how to use Python
> ElementTrees in a component that I could reuse?
>
Hi Sebastien,
I'm just tidying up a sample that demonstrates using ElementTrees
returned from a web service - found & fixed a couple of bugs on the
way that I need to check in too - will hopefully get this up tonight.
Cheers
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO in a Python component?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Andrew Borley wrote:
> OK, with no dissenting voices, I've put in this fix at r476094. SDOs
> now get converted to Python xml.etree.ElementTree.Element objects when
> used as parameters or properties to Python components (and the
> conversion goes in the opposite direction when a Python component
> returns an Element).
>
> Cheers
>
> Andy
>
>
> On 11/15/06, Andrew Borley <aj...@gmail.com> wrote:
>> I've started to fix this hole in the SCA C++ Python support.
>>
>> Looking at the various options, ElementTree seems the simplest, most
>> "Pythonic" XML library to use - this is included in Python 2.5, but I
>> don't think it is in earlier versions so we'll need to up our required
>> Python level to 2.5 or provide the details of how to add ElementTree
>> support (which is very simple - the library is written in Python and
>> claims to be runnable on 1.5.2 and later).
>>
>> In the future it may be good to have something more SDO-ish - what do
>> people think?
>>
>> Cheers
>> Andy
>>
>> On 10/2/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> > [snip]
>> > > On 9/22/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> > >> To allow Python components to handle more than just simple data
>> types,
>> > >> we need to decide how we present structured data / complex types to
>> > >> Python components. We'll probably want to support many more data
>> binding
>> > >> options in the future, but we need one simple solution as a
>> starting
>> > >> point.
>> > >>
>> > >> For Ruby I have implemented support for Rexml for now mainly
>> because
>> > >> it's included in the Ruby distribution. What do you guys think
>> we should
>> > >> use for Python?
>> > >> - an xml.dom or xml.minidom - from the Python standard library
>> > >> - an xml.ElementTree - more pythonic and nicer rendering, recent
>> > >> addition to the Python 2.5 standard library (just released on Sept
>> > >> 19th), available as a separate package on older releases
>> > >> - a new implementation of a Python transcription of the SDO API?
>> > >>
>> > >> Here's what I was thinking about:
>> > >> - step 1, soon - ElementTree
>> > >> - step 2, longer term - an SDO API
>> > >>
>> > >> Any thoughts?
>> > >>
>> > >> --
>> > >> Jean-Sebastien
>> > >>
>> > Andrew Borley wrote:
>> > [snip]
>> > > Yep, I was thinking about this too - I think you're right that we
>> need
>> > > something soon (and basing it on an XML technology that's already
>> > > available is the right way to do this) and then an SDO API later
>> > > (probably wrappering the C++ implementation, in a similar way to the
>> > > PHP SDO package).
>> > >
>> > >
>> >
>> > We're going to need something if we want to include the support for
>> > Python in our M2 release. I was rereading this thread and I'm not sure
>> > that we've clearly identified how we're going to present structured
>> data
>> > to Python scripts (coming from a Web Service for example).
>> >
>> > Any more thoughts? Do people prefer:
>> > - ElementTree?
>> > - A flavor of DOM?
>> > - the SDO API wrapped in SWIG?
>> > - a more Pythonic rendering of the SDO API?
>> >
>> > Any Python developers out there would like to jump in and tell us
>> their
>> > preference?
>> >
>> > --
>> > Jean-Sebastien
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> >
>> >
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Andy,
I'm putting together a new REST sample illustrating how to
Create/Retrieve/Update/Delete resources using a REST binding, and I'm
writing this sample in Python (to help show your Python extension as
well). Do you have any code snippets showing how to use Python
ElementTrees in a component that I could reuse?
Thanks,
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO in a Python component?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Andrew Borley wrote:
> OK, with no dissenting voices, I've put in this fix at r476094. SDOs
> now get converted to Python xml.etree.ElementTree.Element objects when
> used as parameters or properties to Python components (and the
> conversion goes in the opposite direction when a Python component
> returns an Element).
>
> Cheers
>
> Andy
>
Nice! What would you think of using a well know Web service like Google
search, a translation service, or another service from Yahoo, Amazon or
eBay for example to demonstrate the handling of complex types in a
Python SCA component?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO in a Python component?
Posted by Andrew Borley <aj...@gmail.com>.
OK, with no dissenting voices, I've put in this fix at r476094. SDOs
now get converted to Python xml.etree.ElementTree.Element objects when
used as parameters or properties to Python components (and the
conversion goes in the opposite direction when a Python component
returns an Element).
Cheers
Andy
On 11/15/06, Andrew Borley <aj...@gmail.com> wrote:
> I've started to fix this hole in the SCA C++ Python support.
>
> Looking at the various options, ElementTree seems the simplest, most
> "Pythonic" XML library to use - this is included in Python 2.5, but I
> don't think it is in earlier versions so we'll need to up our required
> Python level to 2.5 or provide the details of how to add ElementTree
> support (which is very simple - the library is written in Python and
> claims to be runnable on 1.5.2 and later).
>
> In the future it may be good to have something more SDO-ish - what do
> people think?
>
> Cheers
> Andy
>
> On 10/2/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > [snip]
> > > On 9/22/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > >> To allow Python components to handle more than just simple data types,
> > >> we need to decide how we present structured data / complex types to
> > >> Python components. We'll probably want to support many more data binding
> > >> options in the future, but we need one simple solution as a starting
> > >> point.
> > >>
> > >> For Ruby I have implemented support for Rexml for now mainly because
> > >> it's included in the Ruby distribution. What do you guys think we should
> > >> use for Python?
> > >> - an xml.dom or xml.minidom - from the Python standard library
> > >> - an xml.ElementTree - more pythonic and nicer rendering, recent
> > >> addition to the Python 2.5 standard library (just released on Sept
> > >> 19th), available as a separate package on older releases
> > >> - a new implementation of a Python transcription of the SDO API?
> > >>
> > >> Here's what I was thinking about:
> > >> - step 1, soon - ElementTree
> > >> - step 2, longer term - an SDO API
> > >>
> > >> Any thoughts?
> > >>
> > >> --
> > >> Jean-Sebastien
> > >>
> > Andrew Borley wrote:
> > [snip]
> > > Yep, I was thinking about this too - I think you're right that we need
> > > something soon (and basing it on an XML technology that's already
> > > available is the right way to do this) and then an SDO API later
> > > (probably wrappering the C++ implementation, in a similar way to the
> > > PHP SDO package).
> > >
> > >
> >
> > We're going to need something if we want to include the support for
> > Python in our M2 release. I was rereading this thread and I'm not sure
> > that we've clearly identified how we're going to present structured data
> > to Python scripts (coming from a Web Service for example).
> >
> > Any more thoughts? Do people prefer:
> > - ElementTree?
> > - A flavor of DOM?
> > - the SDO API wrapped in SWIG?
> > - a more Pythonic rendering of the SDO API?
> >
> > Any Python developers out there would like to jump in and tell us their
> > preference?
> >
> > --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SDO in a Python component?
Posted by Andrew Borley <aj...@gmail.com>.
I've started to fix this hole in the SCA C++ Python support.
Looking at the various options, ElementTree seems the simplest, most
"Pythonic" XML library to use - this is included in Python 2.5, but I
don't think it is in earlier versions so we'll need to up our required
Python level to 2.5 or provide the details of how to add ElementTree
support (which is very simple - the library is written in Python and
claims to be runnable on 1.5.2 and later).
In the future it may be good to have something more SDO-ish - what do
people think?
Cheers
Andy
On 10/2/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> [snip]
> > On 9/22/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >> To allow Python components to handle more than just simple data types,
> >> we need to decide how we present structured data / complex types to
> >> Python components. We'll probably want to support many more data binding
> >> options in the future, but we need one simple solution as a starting
> >> point.
> >>
> >> For Ruby I have implemented support for Rexml for now mainly because
> >> it's included in the Ruby distribution. What do you guys think we should
> >> use for Python?
> >> - an xml.dom or xml.minidom - from the Python standard library
> >> - an xml.ElementTree - more pythonic and nicer rendering, recent
> >> addition to the Python 2.5 standard library (just released on Sept
> >> 19th), available as a separate package on older releases
> >> - a new implementation of a Python transcription of the SDO API?
> >>
> >> Here's what I was thinking about:
> >> - step 1, soon - ElementTree
> >> - step 2, longer term - an SDO API
> >>
> >> Any thoughts?
> >>
> >> --
> >> Jean-Sebastien
> >>
> Andrew Borley wrote:
> [snip]
> > Yep, I was thinking about this too - I think you're right that we need
> > something soon (and basing it on an XML technology that's already
> > available is the right way to do this) and then an SDO API later
> > (probably wrappering the C++ implementation, in a similar way to the
> > PHP SDO package).
> >
> >
>
> We're going to need something if we want to include the support for
> Python in our M2 release. I was rereading this thread and I'm not sure
> that we've clearly identified how we're going to present structured data
> to Python scripts (coming from a Web Service for example).
>
> Any more thoughts? Do people prefer:
> - ElementTree?
> - A flavor of DOM?
> - the SDO API wrapped in SWIG?
> - a more Pythonic rendering of the SDO API?
>
> Any Python developers out there would like to jump in and tell us their
> preference?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org