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
