[Jython-dev] Re: <type 'unicode'>

> Notice that there's a basestring class too that both str and unicode
> subclass in CPython.
>=20
> The cleanest approach is to have such a separate class, have PyString
> subclass it and unicode subclass
> PyString but expose (with expose_base) just basestring as superclass.
>
Why not move the guts of PyString to the basestring class
(PyBaseString I guess) and have PyUnicode subclass PyBaseString (*not*
subclassing PyString in the java sense or the expose_base sense)?
Frank

Thread view

Do we want to have a new-style unicode type? It seems a little
redundant since we are internally storing all strings as unicode java
Strings, but we would need to have a unicode type if we are going to
pass all of test_unicode.py
Frank

Frank Wierzbicki wrote:
>>Notice that there's a basestring class too that both str and unicode
>>subclass in CPython.
>>
>>The cleanest approach is to have such a separate class, have PyString
>>subclass it and unicode subclass
>>PyString but expose (with expose_base) just basestring as superclass.
>>
>>
>>
>Why not move the guts of PyString to the basestring class
>(PyBaseString I guess) and have PyUnicode subclass PyBaseString (*not*
>subclassing PyString in the java sense or the expose_base sense)?
>
>
well, basestring is expected to be abstract (empty) at Python level, of
course
you could have method there and expose them only in the levels down I think.
The advantage of unicode subclassing PyString is that old java code
using Jython
expecting PyString would work for unicode too. But as I said this change
is delicate
because you have issue like what should a the result of a java method
returning a String
be converted to now?

> The advantage of unicode subclassing PyString is that old java code
> using Jython
> expecting PyString would work for unicode too.
ok. Backwords compatibility is reason enough.
> But as I said this change
> is delicate
> because you have issue like what should a the result of a java method
> returning a String
> be converted to now?
Hmmm. I see the problem. I guess I'll take a crack at implementing
this and we can see what happens.
Frank

Frank Wierzbicki wrote:
> Do we want to have a new-style unicode type? It seems a little
> redundant since we are internally storing all strings as unicode java
> Strings, but we would need to have a unicode type if we are going to
> pass all of test_unicode.py
>
> Frank
>
It does seem redunant but we should probably have it. Would it take
long to implement?
thanks,
brian

> It does seem redunant but we should probably have it. Would it take
> long to implement?
>=20
I don't think it would take too long, anyway if we need it I'll start
working on it. I'm going to try to just subclass PyString and see if
I can make that work.
Frank

Frank Wierzbicki wrote:
>>It does seem redunant but we should probably have it. Would it take
>>long to implement?
>>
>>
>>
>I don't think it would take too long, anyway if we need it I'll start
>working on it. I'm going to try to just subclass PyString and see if
>I can make that work.
>
>
the design of this is a bit delicate, so far Jython string type was used
both for unicode and str,
sadly this fails in the cases were code tries to detect wheter something
is unicode or is a char sequence
needing decoding. For backward compatibility reason str should still
support all of unicode,
one possibility is to make unicode just subclass of str so with a
different identity but no other difference.
Notice that there's a basestring class too that both str and unicode
subclass in CPython.
The cleanest approach is to have such a separate class, have PyString
subclass it and unicode subclass
PyString but expose (with expose_base) just basestring as superclass.

> Notice that there's a basestring class too that both str and unicode
> subclass in CPython.
>=20
> The cleanest approach is to have such a separate class, have PyString
> subclass it and unicode subclass
> PyString but expose (with expose_base) just basestring as superclass.
>
Why not move the guts of PyString to the basestring class
(PyBaseString I guess) and have PyUnicode subclass PyBaseString (*not*
subclassing PyString in the java sense or the expose_base sense)?
Frank

[Frank Wierzbicki]
>> Do we want to have a new-style unicode type? It seems a little
>> redundant since we are internally storing all strings as unicode java
>> Strings, but we would need to have a unicode type if we are going to
>> pass all of test_unicode.py
[Brian Zimmer]
>>> It does seem redunant but we should probably have it. Would it take
>>> long to implement?
[Frank Wierzbicki]
>> I don't think it would take too long, anyway if we need it I'll start
>> working on it. I'm going to try to just subclass PyString and see if
>> I can make that work.
Hi all,
One concern I would have is that the following cpython codes would work
seamlessly on jython.
# Written by me
def dont_allow_string_argument(v):
assert type(v) not in [types.StringType, types.UnicodeType]
or
# Written by Duncan Booth
def dont_allow_string_argument(v):
assert type(v) not in types.StringTypes
or
# Written by Duncan Booth
def dont_allow_string_argument(v):
for t in types.StringTypes:
assert not isinstance(v, t)
or
# Written by Alex Martelli
def dont_allow_string_argument(v):
assert not isinstance(v, types.StringTypes)
All of which are proposed solutions to the problem of differentiating
sequences from strings, taken from the following comp.lang.python thread.
"Iteration of Strings"
http://mail.python.org/pipermail/python-list/2002-November/131999.html
I looked a cursory look at cpython 2.3 test_unicode.py, but don't see
any mention of this type of test? i.e. textual searches for "isinstance"
and "StringType" gave no results.
Regards,
Alan.

Alan,
I will try to make sure this use case works the same in Jython as it
does in CPython as I work on it.
Thanks,
Frank
On 6/22/05, Alan Kennedy <jython-dev@...> wrote:
> [Frank Wierzbicki]
> >> Do we want to have a new-style unicode type? It seems a little
> >> redundant since we are internally storing all strings as unicode java
> >> Strings, but we would need to have a unicode type if we are going to
> >> pass all of test_unicode.py
>=20
> [Brian Zimmer]
> >>> It does seem redunant but we should probably have it. Would it take
> >>> long to implement?
>=20
> [Frank Wierzbicki]
> >> I don't think it would take too long, anyway if we need it I'll start
> >> working on it. I'm going to try to just subclass PyString and see if
> >> I can make that work.
>=20
> Hi all,
>=20
> One concern I would have is that the following cpython codes would work
> seamlessly on jython.
>=20
> # Written by me
> def dont_allow_string_argument(v):
> assert type(v) not in [types.StringType, types.UnicodeType]
>=20
> or
>=20
> # Written by Duncan Booth
> def dont_allow_string_argument(v):
> assert type(v) not in types.StringTypes
>=20
> or
>=20
> # Written by Duncan Booth
> def dont_allow_string_argument(v):
> for t in types.StringTypes:
> assert not isinstance(v, t)
>=20
> or
>=20
> # Written by Alex Martelli
> def dont_allow_string_argument(v):
> assert not isinstance(v, types.StringTypes)
>=20
> All of which are proposed solutions to the problem of differentiating
> sequences from strings, taken from the following comp.lang.python thread.
>=20
> "Iteration of Strings"
> http://mail.python.org/pipermail/python-list/2002-November/131999.html
>=20
> I looked a cursory look at cpython 2.3 test_unicode.py, but don't see
> any mention of this type of test? i.e. textual searches for "isinstance"
> and "StringType" gave no results.
>=20
> Regards,
>=20
> Alan.
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> Jython-dev mailing list
> Jython-dev@...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details