Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Samuele Pedroni <pedronis <at> strakt.com>
Subject: Re: cherrypy 2.0.0
Newsgroups: gmane.comp.lang.jython.devel
Date: Wednesday 22nd November 2006 21:58:38 UTC (over 11 years ago)
Charlie Groves wrote:
> On 11/22/06, s|s  wrote:
>   
>> As a stepping stone, I have gotten cherrypy 2.0.0 to work on jpython.
>>     
>
> That's cool.  We were just talking about working towards running
> TurboGears on Jython as the next step after the 2.2 release and this
> is definitely along that path.
>
>   
>> Also I would like to know why this error occurs
>>
>> ('_local__key', 'thread.local.2') {}
>> Traceback (innermost last):
>>   File "05_derived_objects.py", line 75, in ?
>>   File
"/home/ss/dev/jython/trunk/jython/dist/Lib/cherrypy/_cpserver.py",
>> line 74, in start
>>   File
"/home/ss/dev/jython/trunk/jython/dist/Lib/cherrypy/_cpthreadinglocal.py",
>> line 158, in __new__
>> TypeError: keys in namespace must be strings
>>     
>
> It looks like cherrypy uses a tuple as a key in an instance's
> __dict__.  IJython uses PyStringMap for __dict__ instead of the full
> PyDictionary.  The big difference between the two is that PyStringMap
> only accepts str keys. 
and it interns them, and accept interned java strings directly.

>  I imagine it's used because it's faster or
> more space efficient than PyDictionary, but I'm not sure.  Does anyone
> know why we're using PyStringMap?  Could we just swap PyDictionary in?
>
>   
it should be measured, but I fear it would have an impact on speed, we 
have a lot of code
that does lookup starting from interned java strings, and given that 
PyDictionary is using
an Hashtable we could not easily avoid wrapping the string to do lookups.

This also considered an implementation detail whether instance and type 
dicts, accept or not
only strings. PyPy right now for example uses general dicts for 
instances but not types.

The code in cherrypy is basically CPython specific. At some level we 
need to draw a line
about to which extent we try to follow CPython details, also because 
that's going to have
an impact on performance in many cases. In this case I think cherrypy 
should use more portable
code across Pythons.



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
 
CD: 4ms