Hi Dave,
The call was with parameters "generateDS.py -f -o output.py input.xsd"
Apologies, i'm right now moving apartments (painting and schlepping boxes
around ) hence the delayed response. My python experience is around 2 years
old or so, so i'm a bit insecure. but here goes.
Since im python 3 centric, i will pose the question as a python 3
programmer.
Is there a requirement that the generateds library works with strings with
a specific encoding? I thought in the python 3 world, it could just use
python 3 unicode strings throughout.
Problems usually come up when reading from outside media like utf-8 encoded
files. but i think in such cases the user should convert this utf-8 encoded
string into a python 3 unicode string and then pass it to the generateds
library.
With parsing from strings, my guts say its highly inefficient to keep
encoding xml strings before sending them to the library unless there is
some fundamental concept/requirement for it i am unaware of. If it's a
limitation due to some implementation detail, then its understandable.
With parsing from files, i can imagine, it may make sense to pass an
encoding hint to the library with a default encoding being utf-8 similar to
open(filepath, encoding)
Rohan
On Fri, Dec 8, 2017 at 9:13 PM, Dave Kuhlman <dkuhl...@davekuhlman.org>
wrote:
> Rohan,
>
> Ah, so it was *not* a module generated with -s; it was one generated
> with -o. Still, what I fixed *was* a bug, and it needed to be fixed
> so that modules generated with -s would run under both Python 2 and
> Python3. Therefore, I'm still thankful that you prodded me into
> finding that.
>
> With respect to your problem, if I understand it correctly, you can
> fix it yourself by doing the following:
>
> >>> encoded_xml_string = xml_string.encode("utf-8")
> >>> gds_module.parseString(encoded_xml_string)
>
> Or, since "utf-8" is the default encoding, merely:
>
> >>> encoded_xml_string = xml_string.encode()
> >>> gds_module.parseString(encoded_xml_string)
>
> If I'm right about this, the question is whether you should do that
> encoding or whether the generated code (the parseString function)
> should do it for you. One argument in favor of putting the burden
> on the caller (instead of parseString) is that we do not know in
> advance what the encoding of the original string is, although it is
> very likely (maybe even very, very likely) that it is UTF-8.
>
> I can change the parseString generated function so that it does this:
>
> doc = parsexml_(IOBuffer(inString.encode()), parser)
>
> instead of this:
>
> doc = parsexml_(IOBuffer(inString), parser)
>
> That's a trivial change to make, but, that removes some flexibility
> from the user might need. See this:
>
> https://docs.python.org/3/library/codecs.html#standard-encodings
>
> Or, is that stretching things too far? Perhaps no one would ever
> need to use any encoding other than UTF-8.
>
> What do you think?
>
> Dave
>
>
> On Fri, Dec 08, 2017 at 03:23:30PM +0100, Rohan Dsa wrote:
> > Thank you Dave,
> >
> > Unfortunately the patch (and the latest generateds version) didn't help
> me
> > either. I get the following error. presumably the reason may be the
> > difference between strings in python 2 and 3? AFAIR, unicode strings in
> > python 3 as opposed to byte strings in python 2?
> >
> > File "c:\evobase2005\main\evopro\dc\dc\hci\operetta_data.py", line
> 15788,
> > in parseString
> > doc = parsexml_(IOBuffer(inString), parser)
> > TypeError: a bytes-like object is required, not 'str'
> >
> >
> > I didn't apply the -s argument either.
> >
> > let me know if i can do anything else to help.
> >
> > Thank you for the library. it generated 16000 LOC and saved me hours of
> > typing!
> >
> > Rohan
> >
> >
> >
> >
> > On Fri, Dec 8, 2017 at 12:22 AM, Dave Kuhlman <dkuhl...@davekuhlman.org>
> > wrote:
> >
> > > Rohan,
> > >
> > > That looks like a bug. After a quick search, I found that this
> > > error occurred in the parseString function in the generated subclass
> > > modules (that is, the modules generated with the -s command line
> > > option). Is that where you found it?
> > >
> > > I've attached a patch. If the patch does not apply correctly, you
> > > can find the patched version at any of the following:
> > >
> > > - https://bitbucket.org/dkuhlman/generateds
> > >
> > > - https://pypi.python.org/pypi/generateDS
> > >
> > > - https://sourceforge.net/projects/generateds/
> > >
> > > Thank you for reporting this. I appreciate your help.
> > >
> > > Dave
> > >
> > > On Thu, Dec 07, 2017 at 01:51:28PM +0100, Rohan Dsa wrote:
> > > > Dave,
> > > >
> > > > I need to keep changing a line in my auto generated code.
> > > >
> > > > from StringIO import StringIO
> > > >
> > > > to
> > > >
> > > > from io import StringIO
> > > >
> > > > The code runs only under Python3. is this normal or am i missing
> > > something?
> > > > I would have posted this somewhere, just didn't find any bugtracker
> > > online.
> > > >
> > > > Rohan
> > >
> > > --
> > >
> > > Dave Kuhlman
> > > http://www.davekuhlman.org
> > >
>
>
> --
>
> Dave Kuhlman
> http://www.davekuhlman.org
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
