django on jython (new version)?
World Domination Kites
http://www.theserverside.com/news/thread.tss?thread_id=46661
http://www.jython.org/Project/download.html
Does this mean I will finally be able to use Django in my stuffy corporate app server environment?
If so, hot-diggety!
Marty Alchin
wondering this myself, since my employer uses strictly Java, and a
decent Jython might be just what I need to get them to start thinking
about Python. I might be doing some research on this soon, but I make
no guarantees to do so, nor do I guarantee I'll post my findings. But
I'll see what comes out, and maybe you'll hear from me.
-Gul
Jeremy Dunck
>
> Oh wow, I hadn't noticed Jython 2.2 yet (I've been out of town)! I'm
> wondering this myself, since my employer uses strictly Java,
$ java -jar jython.jar -Dpython.path=/home/jeremwork/djtrunk
~/work/djtrunk/tests/runtests.py
Traceback (innermost last):
File "/Users/jeremy/work/djtrunk/tests/runtests.py", line 147, in ?
ImportError: no module named optparse
Eugene Lazutkin
People are already testing Pylons, but I don't know how far they went.
There are some things, which are not supported in Jython but used in
Django --- like non-string keys. Barring unforeseen bugs, it should be
possible to accommodate Django for slightly different run-time. I wanted
to do it since this April, but didn't have a chance yet. If you need a
hand --- let me know, and I'll try to pitch in. And please keep us
posted on your research.
Thanks,
Eugene
Leo Soto M.
That's easy to solve: Just copy optparse.py from the python 2.3
distibution to the jython Lib directory. At least after doing that the
interpreter now complains because because django uses __builtins__
(which is a CPython implementation detail as noted on
http://docs.python.org/lib/module-builtin.html) instead of importing
the __builtin__ module.
I'm working on a patch to get rid of those small problems. But I'm
pretty sure there are bigger ones.
--
Leo Soto M.
Jeremy Dunck
...
> That's easy to solve: Just copy optparse.py from the python 2.3
> distibution to the jython Lib directory.
Odd; I thought it must be a C module, since Jython is under the Python
license and it'd make a lot more sense for them to ship the module if
it's pure python...
...
> I'm working on a patch to get rid of those small problems. But I'm
> pretty sure there are bigger ones.
>
It seems a JDBC/DB-API bridge is in order, but again, that seems like
a thing for the Jython distro. Then (I think) a single JDBC Django
backend would do.
Leo Soto M.
> It seems a JDBC/DB-API bridge is in order, but again, that seems like
> a thing for the Jython distro.
That's already distributed with Jython: http://www.jython.org/docs/zxjdbc.html
> Then (I think) a single JDBC Django backend would do.
No, you still need to manage the differences between SQL dialects.
--
Leo Soto M.
Mikhail Gusarov
Twas brillig at 23:18:25 23.08.2007 UTC-05 when Jeremy Dunck did gyre and gimble:
>> That's easy to solve: Just copy optparse.py from the python 2.3 distibution
>> to the jython Lib directory.
JD> Odd; I thought it must be a C module, since Jython is under the Python
JD> license and it'd make a lot more sense for them to ship the module if it's
JD> pure python...
Probably this due to jython 2.2 corresponds to cpython 2.2, and optparse module
has been added to cpython 2.3.
--
JID: dott...@jabber.dottedmag.net
Marty Alchin
Jython (Jango? Djython?) should work fairly well once it has a
database backend and a request handler. I have no idea how much it
would take to write a db backend using zxJDBC, but the request handler
should be fairly straightforward. Of course, each would have to
written against a specific intended use (such as DB2 and WebSphere),
but it might just be possible.
After doing a few fairly trivial search/replace operations and writing
a couple helper functions, templates and newforms seem to be working.
The test suite won't even run properly without a db backend, so I
can't be sure how completely those are working, but they passed some
basic interactive interpreter tests. This is great news though,
because those of us using Java as a day job might just be able to
start a shift to Python, or at least be able to use Django's template
language and form support to make life easier.
I should qualify this by saying that this was only tested with a
slightly-altered 0.95. I don't have Django SVN and a Java environment
on the same PC at the moment, so more testing will have to wait until
I do. Once I know a bit more, I'll write up my findings and keep you
all in the loop.
-Gul
Leo Soto M.
>
> I won't pretend to have tested everything, but it looks like Django on
> Jython (Jango? Djython?)
Jyngo? [Not a native speaker, so I really don't know which sounds better]
> should work fairly well once it has a
> database backend and a request handler. I have no idea how much it
> would take to write a db backend using zxJDBC,
I've been doing something in that department, copying
postgresql_psycopg2/ to postgresql_zxjdbc/ and doing some tweaks.
The first problem I encountered was that zxJDBC expects question marks
instead of '%s' as parameter marks on cursor.execute(). And now I'm
working on some mapping problems with python boolean being treated as
integers on the JDBC layer.
Anyway, I got to the point where the development server running on
jython shows the "It works" page. And now I'm trying run syncdb.
I'll post my changes (well, hacks) against the Django svn codebase as
soon as I can.
--
Leo Soto M.
Marty Alchin
> > I won't pretend to have tested everything, but it looks like Django on
> > Jython (Jango? Djython?)
>
> Jyngo? [Not a native speaker, so I really don't know which sounds better]
Sorry, I wasn't very clear that I was joking. I wouldn't really want
Django on Jython to have a separate name. It would just be silly.
> I've been doing something in that department, copying
> postgresql_psycopg2/ to postgresql_zxjdbc/ and doing some tweaks.
>
> The first problem I encountered was that zxJDBC expects question marks
> instead of '%s' as parameter marks on cursor.execute(). And now I'm
> working on some mapping problems with python boolean being treated as
> integers on the JDBC layer.
Glad to hear it sounds possible at least. I'll need a DB2 driver to
use this at work, though, and I'm not at all looking forward to that.
> Anyway, I got to the point where the development server running on
> jython shows the "It works" page. And now I'm trying run syncdb.
I hadn't gotten quite that far yet myself, but I'm nearly there.
> I'll post my changes (well, hacks) against the Django svn codebase as
> soon as I can.
Given that we're duplicating some effort here, I wonder if we could
set up an SVN repository somewhere to work on this together? It'd be
just another Django branch, but the official policy is to set up our
own SVN to work on it. I don't know anything about merging SVN
repositories though, to keep it up to date with trunk.
Are there any other people out there looking into Jython who would be
interested in joining forces?
-Gul
Eugene Lazutkin
> On 8/31/07, Leo Soto M. <leo....@gmail.com> wrote:
>>> I won't pretend to have tested everything, but it looks like Django on
>>> Jython (Jango? Djython?)
>> Jyngo? [Not a native speaker, so I really don't know which sounds better]
>
> Sorry, I wasn't very clear that I was joking. I wouldn't really want
> Django on Jython to have a separate name. It would just be silly.
+1. Django is Django. I think it is stupid to split projects and change
the name. Django on Jython should use the canonical Django + some
Jython-specific modules.
> Are there any other people out there looking into Jython who would be
> interested in joining forces?
Count me in --- I planed to look into that in the second half of September.
Thanks,
Eugene
Leo Soto M.
> Given that we're duplicating some effort here, I wonder if we could
> set up an SVN repository somewhere to work on this together? It'd be
> just another Django branch, but the official policy is to set up our
> own SVN to work on it. I don't know anything about merging SVN
> repositories though, to keep it up to date with trunk.
I have a mercurial repository where I'm tracking my changes :
https://hg.leosoto.com/django.jythonport/
The test suite doesn't runs with jython yet (because some doctest
string is bigger than 32KBytes), but at least nothings seems broken
when running it on regular python.
--
Leo Soto M.
Jacob Kaplan-Moss
I'm *way* to busy to work on this myself, but I wanted to chime in and
give a big, fat +1 -- Django on Jython would be a *big* win for people
looking to use Django in Enterprisy situations.
If there are bits of Django that need to be fixed for Jython support,
please file tickets with "jython" in the keywords field; I'll keep an
eye on that tag and try to fast-track them into trunk.
Jacob
Marty Alchin
> I'm *way* to busy to work on this myself, but I wanted to chime in and
> give a big, fat +1 -- Django on Jython would be a *big* win for people
> looking to use Django in Enterprisy situations.
My thoughts exactly. It's something I'll definitely include if I ever
get around to writing the Entrerprise Django book I have rattling
around in my head.
> If there are bits of Django that need to be fixed for Jython support,
> please file tickets with "jython" in the keywords field; I'll keep an
> eye on that tag and try to fast-track them into trunk.
There are a few I've already run into, whose fixes don't affect the
CPython execution at all. Leo's much further than me already, so I'm
sure he has a bit more that will need to go in. I'm not sure if
there's a way to streamline it given that he's already made the
changes in his repository. We'll figure it out though, and you'll
certainly see some tickets come in.
-Gul
Leo Soto M.
> > If there are bits of Django that need to be fixed for Jython support,
> > please file tickets with "jython" in the keywords field; I'll keep an
> > eye on that tag and try to fast-track them into trunk.
>
> There are a few I've already run into, whose fixes don't affect the
> CPython execution at all. Leo's much further than me already, so I'm
> sure he has a bit more that will need to go in. I'm not sure if
> there's a way to streamline it given that he's already made the
> changes in his repository. We'll figure it out though, and you'll
> certainly see some tickets come in.
As Marty said, I've been doing some progress, detailed on
<http://blog.leosoto.com/2007/09/django-on-jython-what-ive-done-until.html>.
But I'd not rush with patches to trunk until we prove that running
Django on Jython is viable. As far as I've seen, some Jython bugs need
to be fixed before we have a chance of running Django without doing
ugly workarounds.
That's why I've set up a separate mercurial repository to do some
exploratory work. Anyway, if people here thinks otherwise, I have no
problem on filling tickets with the changes.
--
Leo Soto M.
fwier...@gmail.com
My name is Frank Wierzbicki and I'm the lead maintainer of Jython.
Just wanted to let you know that getting Django and Jython working
together is a big goal for me. I have the start of a mysql jdbc
backend and a hacked up Django in Jython's svn -- but I believe Leo
Soto M. is further along (but I could at least add the mysql backend
work). I already know that some of the problems will be easier to
solve on the Jython side (for example the lack of pop() on stringmap
which we use for __dict__s) Anyway just wanted to chime in with my
support.
-Frank
Marty Alchin
inclusion of pop() on PyStringMap, since that would indeed solve a few
metaclass issues with Django (and perhaps others). It's starting to
sound like with a decent recent Jython SVN, we might be able to have
Django working soon with just a proper set of JDBC drivers.
Leo definitely does seem to be the furthest along out of all of us,
and he also seems to have a good amount of knowledge in the Jython
internals. He's working on a PostgreSQL JDBC backend for Django, and
he seems to be making good progress so far.
-Gul
Frank Wierzbicki
>
> That is excellent news! I'm especially excited to hear about the
> inclusion of pop() on PyStringMap, since that would indeed solve a few
> metaclass issues with Django (and perhaps others).
> It's starting to
> sound like with a decent recent Jython SVN, we might be able to have
> Django working soon with just a proper set of JDBC drivers.
I really hope so! I think this would be a very good thing for both projects.
> Leo definitely does seem to be the furthest along out of all of us,
> and he also seems to have a good amount of knowledge in the Jython
> internals. He's working on a PostgreSQL JDBC backend for Django, and
> he seems to be making good progress so far.
I am very excited about Leo's progress. The next thing I need to look
into is the __module__ metaclass problem -- his work around can
probably point me in the right direction. I'm guessing this is going
to take some mucking in deep dark parts of Jython :) but hopefully it
won't take too long.
-Frank
Marty Alchin
ahead and set up a Yahoo Pipe[1] to keep track of the various blogs
that are currently (or will be) dealing with the topic of Django on
Jython. If anybody else is writing on the subject, let me know and
I'll add you to it.
-Gul
[q] http://pipes.yahoo.com/pipes/pipe.info?_id=jroxOD1f3BGgvtiIqGIyXQ
Tristan King
I've only just signed up to this group so i'm hoping my Re: subject
links into the original chat about this.
Because i love the ease of development that django offers, i've been
moving bits of django code to get an autoreloading jython service
running.
After finding a few other blogs for other people trying to move django
to jython, i decided to post my work here so we might be able to merge
our efforts. (maybe we could get some svn space somewhere)
here is my trac page for my changes
https://dev.archer.edu.au/projects/kepler/log/jython-django (changeset
124 is the most interesting)
the changesets are a bit messed up since i have not updated all my files
to reflect the current django-svn.
below i'll post a description of all the things i've done so far for all
who're interested.
cheers
--Tristan
----------------
just a quick note: i'm very new to python. I've only been programming in
it for a few weeks now. so feel free to throw constructive criticisms at
my code :)
things i haven't done:
since i'm not interested in using the models package just yet, i haven't
moved any of that code to jython. but Leo Soto seems to be doing a fine
job at this. because of this i've had to work around some of the
references to the models package (ie. when the server validates the
models)
major things i've done include:
****** getting the autorealod module to work.
this has been an interesting task. I started off by replacing the
spawnve with java.lang.Runtime calls to spawn the new task. For which i
has to spawn a few other threads to read the process's stdout and err.
looking at the code as i type this i realise i can remove the loop
starting at line 111, i think that's just remains of some debuging :).
good how these things make you re look over old code :).
also the sys.executable call in jython doesn't work the same as it does
in python, so i had to dodgy that up a bit (if anyone starts their
jython with a name other than 'jython' it will break this :))
i've also had to work around a jython bug (i've still got to find out if
it's a known bug) with the modules. hence the try: except: in lines
53:81.
I've just spent the last hour trying to reproduce the jython bug, for
anyone interested,
https://dev.archer.edu.au/projects/kepler/wiki/Notes#myjythonbug . this
is just a temporary spot till i find the respective jython ticketing
system to throw it into :)
now where was i... So, After these changes, the reloader works as
expected. The only issue is that it's not as quick as the python one,
since jython has quite a hefty startup time. so there's a bit of waiting
around sometimes for the server to start up. but it's still completely
automatic, which is excellent!
****** automatic java library pathing
because i didn't want to have to manually load any new jars i want to
use in my jython app into the sys.path, i added a LIB_DIRECTORY setting
to the settings module. this is used in the setup_environ function
(core/management/__init__.py lines 148:153) which lists the directory
and adds all the jars it finds to sys.path.
this probably needs a bit more work but no use cases have come up for me
yet, so it'll stay like this till they do.
****** readline in the jython console so manage.py shell works
this is more of a jython specific thing than django but i've just been
messing with rlcompleter trying to tab completion in the jython console.
i've got it working satisfactorily, but it still borks out every now and
then.
what i'm currently messing with:
the simplejson modules. if a dictionary has javainstance objects in it,
the simplejson encoder doesn't know what to do with it. i'm trying to
work around this.
Tristan King
just a quick update on the little bit of work i've been doing on this.
i've been merging leo's code with my own, and updating my own to the
latest django svn code.
I've been working on getting the django tutorial to work, and got up to:
---------------
# objects.all() displays all the polls in the database.
>>> Poll.objects.all()
[<Poll: Poll object>]
--------------
before writing this (i'm about to pack it in for the day), which threw me a nasty error:
..........
File "/usr/local/share/jython/Lib/django/db/models/base.py", line 101, in __str__
File "/usr/local/share/jython/Lib/django/utils/encoding.py", line 37, in force_unicode
File "/usr/local/share/jython/Lib/django/db/models/base.py", line 101, in __str__
File "/usr/local/share/jython/Lib/django/utils/encoding.py", line 37, in force_unicode
java.lang.StackOverflowError: java.lang.StackOverflowError
i'll look into it tomorrow (unless someone on the other side of the world figures it out for me :)
i've started using the jython trunk (2.3a0) so a few things have been
easier.
i fought a bit with the re.compile(u"([\u0080-\uffff])") bug, and ended
up just working around it with the following jython patch (i'm not sure
how else to go about it seeing that java doesn't differentiate between
signed and unsigned variables)
$ jython/jython/src/org/python/core$ svn diff PyArray.java
Index: PyArray.java
===================================================================
--- PyArray.java (revision 3484)
+++ PyArray.java (working copy)
@@ -689,7 +689,7 @@
1);
PyObject obj = ap.getPyObject(0);
if(obj instanceof PyString) {
- String code = obj.toString();
+ String code = obj.toString().toLowerCase();
if(code.length() != 1) {
throw Py.ValueError("typecode must be in [zcbhilfd]");
}
i also applied the jython patch to fix the __module__ problems.
and that's about all for major stuff i think.
cheers
-Tristan
Leo Soto M.
>
> Hi guys,
>
> just a quick update on the little bit of work i've been doing on this.
>
> i've been merging leo's code with my own, and updating my own to the
> latest django svn code.
>
> I've been working on getting the django tutorial to work, and got up to:
> ---------------
> # objects.all() displays all the polls in the database.
> >>> Poll.objects.all()
> [<Poll: Poll object>]
> --------------
> before writing this (i'm about to pack it in for the day), which threw me a nasty error:
> ..........
> File "/usr/local/share/jython/Lib/django/db/models/base.py", line 101, in __str__
> File "/usr/local/share/jython/Lib/django/utils/encoding.py", line 37, in force_unicode
> File "/usr/local/share/jython/Lib/django/db/models/base.py", line 101, in __str__
> File "/usr/local/share/jython/Lib/django/utils/encoding.py", line 37, in force_unicode
> java.lang.StackOverflowError: java.lang.StackOverflowError
>
> i'll look into it tomorrow (unless someone on the other side of the world figures it out for me :)
Oh, yeah. That's Jython's unicode(foo) calling foo.__str__ even when
hasattr(foo, '__unicode__') under some circumstances.
It seems that Jython expects that hasattr(type(foo), '__unicode__')
too. CPython has the same requirement with __str__ , but for some
reason, it doesn't with __unicode__.
The very same problem affects lazy strings.
> i've started using the jython trunk (2.3a0) so a few things have been
> easier.
So, the autoreloading bits work unchanged with Jython trunk? Excelent!
> i fought a bit with the re.compile(u"([\u0080-\uffff])") bug, and ended
> up just working around it with the following jython patch (i'm not sure
> how else to go about it seeing that java doesn't differentiate between
> signed and unsigned variables)
Yep, I faced that too. But I don't know what side effects could it have.
[...]
> i also applied the jython patch to fix the __module__ problems.
>
> and that's about all for major stuff i think.
Cool. Keep up the good work! And file some tickets here when you think
is appropriate.
--
Leo Soto M.
Marty Alchin
started working out a servlet handler, so that once we get things
working fairly well, we can see how it works outside the test server.
I haven't really tested it yet or anything, but it seems like it
should work fairly well.
The one problem I ran into is that Jython's PyServlet isn't suitable
for Django, so I had to write a new one in Java. Since I'm not keen on
the idea of shipping Java code for Django, I'm trying to write it in
such a way that it might be useful for other Python frameworks.
Currently it uses an init variable of "python.servlet" to indicate an
import path for the Python-based servlet and passes the requests off
to that.
It's in that Python servlet where I'm doing all the heavy lifting of
converting the HttpServletRequest to a Django HttpRequest and writing
Django's HttpResponse back into the HttpServletResponse.
If it manages to work well (and hopefully with autoreloading at some
point), I'm considering sending it up to Jython to have it included
there. It should be generic enough to run any Python-based framework,
like Pylons or Turbogears, so I'd rather see it there. Right now I'm
calling it DjangoServlet, but perhaps FrameworkServlet or something?
-Gul
Leo Soto M.
>
> I'm definitely not on the cutting edge of Django on Jython here, but I
> started working out a servlet handler, so that once we get things
> working fairly well, we can see how it works outside the test server.
> I haven't really tested it yet or anything, but it seems like it
> should work fairly well.
>
> The one problem I ran into is that Jython's PyServlet isn't suitable
> for Django, so I had to write a new one in Java. Since I'm not keen on
> the idea of shipping Java code for Django, I'm trying to write it in
> such a way that it might be useful for other Python frameworks.
Maybe I completely misunderstood you, but what would be the difference
with modjy <http://www.xhaus.com/modjy/>?
--
Leo Soto M.
Leo Soto M.
I managed to run syncdb, the admin and the test suite under Jython.
The admin has problems with datetimes, but other than that, it works OK.
And the test suite reports something like a third of tests as failed.
We have work to do :D. [Nah, the great majority fails because strptime
is not present on Jython's datetime module]
As I touched many parts of Jython and Django, I'm now organizing all
the bits, to get presentable patches (or bug reports) to both
projects.
--
Leo Soto M.
Marty Alchin
> Maybe I completely misunderstood you, but what would be the difference
> with modjy <http://www.xhaus.com/modjy/>?
I hadn't known about modjy! That looks excellent, so we should be able
to reuse the existing WSGI handler, even in J2EE environments like I'm
using at work. I'll grab that and give it a shot. I'm not a competent
enough Java programmer to trust my custom servlet anyway. :)
-Gul
Tristan King
Poll extends from Model and does not implement __str__ or __unicode__, but inherits __str__ from Model, which calls __unicode__, and __unicode__ from object. however, object.__unicode__ calls __str__, which in this case is model.__str__ and so the loop begins.
of course this code works fine in CPython. so what's different?
simple:
tristan@quiver:~$ python
Python 2.5.1 (r251:54863, May 2 2007, 16:56:35)
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> hasattr(object, '__unicode__')
False
>>>
tristan@quiver:~$ jython
Jython 2.3a0 on java1.5.0_11
Type "copyright", "credits" or "license" for more information.
>>> hasattr(object, '__unicode__')
True
>>>
so, applying the following patch to jython fixes the aforementioned problem. and running 'ant bugtests' shows no change
Index: jython/src/org/python/core/PyObject.java
===================================================================
--- jython/src/org/python/core/PyObject.java (revision 3484)
+++ jython/src/org/python/core/PyObject.java (working copy)
@@ -224,7 +224,7 @@
}
}
- dict.__setitem__("__unicode__",new PyMethodDescr("__unicode__",PyObject.class,0,0,new exposed___unicode__(null,null)));
+ //dict.__setitem__("__unicode__",new PyMethodDescr("__unicode__", PyObject.class,0,0,new exposed___unicode__(null,null)));
class exposed___init__ extends PyBuiltinMethod {
exposed___init__(PyObject self,PyBuiltinFunction.Info info) {
My question is. Why, if in CPython object.__unicode__ doesn't exist, why does it in jython?
Leo Soto M.
> Ok I've been working on the problem quoted at the end of this email and have
> come up with a solution. but i'm not sure what to make of it.
[...]
> My question is. Why, if in CPython object.__unicode__ doesn't exist, why
> does it in jython?
Heh. I'm also having headaches with this behaviour. But people on the
jython-dev mailing list are in a better position to answer this.
--
Leo Soto M.
Tristan King
I think i've solved the __unicode__ problems which leo has been solving
with django workaround (i think it's the same problem anyways),
internally to jython.
(see obj-unicode.patch)
the changes to the __unicode__ function, check if the object has a
__unicode__ function, and runs that function rather than running __str__
everytime.
i also added a basic strptime function to the Time module (see
time-strptime.patch). this is in no means finished, it works for the
basic uses that the django tutorial needs it for. but much more testing
and hardening and optimising is needed.
I also added a bit of a workaround for the missing co_code variable in
PyTableCode. setting it to just "" seems to work for the moment, but it
might still break something later (hence it's just a workaround) (see
patch co_code-workaround.patch)
and that's about it for now. I was applying
http://sourceforge.net/tracker/index.php?func=detail&aid=1799330&group_id=12867&atid=312867 this patch of Leo's. but it left me with the following compile error.
[javac] /home/tristan/projects-local/jython/jython/src/org/python/core/PyUnicodeDerived.java:312: __mod__(org.python.core.PyObject) in org.python.core.PyUnicodeDerived cannot override __mod__(org.python.core.PyObject) in org.python.core.PyUnicode; attempting to use incompatible return type
[javac] found : org.python.core.PyObject
[javac] required: org.python.core.PyUnicode
[javac] public PyObject __mod__(PyObject other) {
[javac] ^
I am obviously missing something. any ideas?
Leo Soto M.
> A bit more progress today.
>
> I think i've solved the __unicode__ problems which leo has been solving
> with django workaround (i think it's the same problem anyways),
> internally to jython.
>
> (see obj-unicode.patch)
[More patches to Jython]
Tristan, please post this patches into the Jython tracker:
http://sourceforge.net/tracker/?group_id=12867 , or discuss them on
the Jython maling list: (I'm sure of the consequences of removing
object.__unicode__, nor about providing an empty co_code on
PyTableCode).
They are applying many patches for their 2.2.1 bugfix release, so it's
a good time to get this into the official Jython source code.
Also, feel free to modify http://wiki.python.org/jython/DjangoOnJython
, adding links to your posted patches or other reference material.
Oh, and thanks for the head up about my broken patch. I didn't made a
full build after doing it, so I didn't realized the problem.
--
Leo Soto M.
Charlie Groves
Would you mind coming up with a small test case that shows this going
off the rails? From reading your description, the basic object setup
sounds like the following:
class Model(object):
def __str__(self):
return self.__unicode__()
class Poll(Model):
pass
However, that code complains about the lack of __unicode__ under
CPython or Jython with your changes in place, so I must be missing
something.
Charlie
On 9/21/07, Tristan King <trista...@jcu.edu.au> wrote:
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Jython-dev mailing list
> Jytho...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
>
Tristan King
"return unicode(self)" instead
i've attached a test file to the bug i submitted at:
https://sourceforge.net/tracker/index.php?func=detail&aid=1800378&group_id=12867&atid=112867
Leo Soto M.
>
> you were close :)
> "return unicode(self)" instead
Almost. That alone would also end on and infinite loop on CPython.
This is directly from django.db.models.Model:
def __str__(self):
if hasattr(self, '__unicode__'):
return force_unicode(self).encode('utf-8')
return '%s object' % self.__class__.__name__
The key is the hasattr() check. It's always true on Jython because
__unicode__ is defined on object.
Anyway, I just noticed that the uploaded test case uses the hasattr, so it's OK.
--
Leo Soto M.
Ian Kelly
> hasattr(foo, '__unicode__') under some circumstances.
In case you missed it, Jython 2.2.1rc1 was made available yesterday,
and the changelog includes this line:
- [ 1799328 ] string formatting doesn't call __unicode__ on %s in
unicode objects
Ian
Leo Soto M.
Heh, that's my patch :)
But that only makes unicode string interpolation works on Jython, but
don't solve the problems caused by object.__unicode__ causing every
object having an __unicode__ attribute.
/me looks at the jython tracker
At least on SVN trunk , object.__unicode__ is gone too. So, #5560 is
no longer needed. Cool (But note that this doesn't come with Jython
2.2.1rc1).
--
Leo Soto M.
Leo Soto M.
[...]
> At least on SVN trunk , object.__unicode__ is gone too. So, #5560 is
> no longer needed.
Forget that. object__unicode__ is gone on Jython, but the __unicode__
attribute on the instances is not recognized yet.
So #5560 is still needed until Jython also fixes this.
--
Leo Soto M.