Re: Python memory usage
Le Mon, 13 Nov 2006 20:46:58 +0100, Fredrik Lundh <[EMAIL PROTECTED]> a écrit : > > http://effbot.org/pyfaq/why-doesnt-python-release-the-memory-when-i-delete-a-large-object > > > Is it still true with Python 2.5 ? I mean, [http://evanjones.ca/python-memory.html] should fix this behaviour, doesn't it ? Jonathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python memory usage
Le Mon, 13 Nov 2006 21:30:35 +0100, Fredrik Lundh <[EMAIL PROTECTED]> a écrit : > Jonathan Ballet wrote: > > >> http://effbot.org/pyfaq/why-doesnt-python-release-the-memory-when-i-delete-a-large-object > > > > Is it still true with Python 2.5 ? > > > > I mean, [http://evanjones.ca/python-memory.html] should fix this > > behaviour, doesn't it ? > > not really -- that change just means that Python's object allocator > will return memory chunks to the C allocator if the chunks become > empty, but as the FAQ entry says, there are no guarantees that > anything will be returned at all. it all depends on your > application's memory allocation patterns. Ah ok, I thought memory was much "directly freed" to system (but I misread the faq). Is there any documents on good application's memory allocation patterns ? > (did you read Evan's presentation material, btw?) I re-read it (thx for mentioning it), but schemas on pages 7, 8 and 9 are not very clear to me. (snip some questions, since I find answers will writing them). Where are stored pools which are not completely free ? (not in 'usedpools' nor in 'freepools' objects) (ah, this is the partially_allocated_arenas I guess :) ) Are 'usedpools' and 'freepools' arenas ? Smalls objects are stored in free blocks, so a block has a length of 256 bytes I guess. Can its size change (smaller, maybe larger) ? So, if I am correct : - I create a new 'small' object -> Python allocates a new arena, and stores my object in a free block in one of the pool of this arena - this arena is stored in the partially_allocated_arenas list (Python 2.5) - allocating more objects fills all the blocks of every pools of the arena -> all pools are going one by one into 'usedpools' object - del-eting every created object in my Python program free every blocks of every pools of the arena (with a lot of chance :) ), and pools are going into the 'freepools' object - if all pools from an arena are freed, the arena is freed - else, the arena stay allocated, in order to be re-used Thanks, Jonathan -- http://mail.python.org/mailman/listinfo/python-list
Re: SQLite3__Python2.3-SQLite__Problem
Le Fri, 24 Nov 2006 13:18:14 -0600, Cousin Stanley <[EMAIL PROTECTED]> a écrit : > >This problem is occuring under Debian GNU/Linux Sarge >using Python 2.3 > Hi, if you look at http://packages.debian.org/stable/python/python2.3-sqlite, you will see that the python2.3-sqlite package is built against SQLite 2. This is why you have a "file is encrypted or is not a database" message, since databases created with SQLite 2.x are not file-compatible with SQLite 3.x file. So, if you can find a Python binding for SQLite 3, go for it, but, unless you are building it from scratch (I mean, not from a Debian package), it might be difficult to find. Otherwise, use the sqlite command line tool (not sqlite3), which is built against SQLite 2.x. If you go for this solution, it's easy to migrate from a 2.x to a 3.x database, something like : $ echo ".dump" sqlite database.db.2x | sqlite3 database.db.3x (you will have to change the Python accordingly, of course ;) Hope it helps, - Jon -- http://mail.python.org/mailman/listinfo/python-list
Re: Standardizing XML
Le 15 Apr 2007 11:02:20 -0700, "ZeeGeek" <[EMAIL PROTECTED]> a écrit : > Thanks for correcting me. I worded it inproperly. For example, in > the code returned by Live Space, they use instead of so > that Blogger will complain that this tag is not valid because it > doesn't have a closing tag. Another example is that the contents of a > lot of the tag attributes like "color" and "size" are not surrounded > by quotes. Maybe you can try BeautifulSoup module which aims to handle things like that : http://www.crummy.com/software/BeautifulSoup/ - Jonathan -- http://mail.python.org/mailman/listinfo/python-list
xmlrpclib and carriagereturn (\r)
Hello,
I have developped a XMLRPC server, which runs under Gnu/Linux with
python2.3.
This server receives method calls from Windows client. The server got some
parameters which are string, which contains carriage return characters,
just after the line feed character; like "bla\n\rbla".
The problem is, xmlrpclib "eats" those carriage return characters when
loading the XMLRPC request, and replace it by "\n". So I got "bla\n\nbla".
When I sent back those parameters to others Windows clients (they are
doing some kind of synchronisation throught the XMLRPC server), I send
to them only "\n\n", which makes problems when rendering strings.
It seems that XMLRPC spec doesn't propose to eat carriage return
characters : (from http://www.xmlrpc.com/spec)
"""
What characters are allowed in strings? Non-printable characters?
Null characters? Can a "string" be used to hold an arbitrary chunk
of binary data?
Any characters are allowed in a string except < and &, which are
encoded as < and &. A string can be used to encode binary
data.
"""
Here is an example which described the problem :
$ python
Python 2.3.5 (#2, Sep 4 2005, 22:01:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import xmlrpclib
>>>
>>> data = """\n\n
testmethod\n
\n\n \n
bla\n\rbla\n\r bla\n \n\n
\n"""
>>>
>>> xmlrpclib.loads(data)
(('bla\n\nbla\n\n\tbla',), u'testmethod')
>>>
... whereas I expected to have (('bla\n\rbla\n\r\tbla',), u'testmethod')
It seems to be a rather strange comportement from xmlrpclib. Is it known ?
So, what happens here ? How could I solve this problem ?
Thanks for any answers,
Jonathan
--
http://mail.python.org/mailman/listinfo/python-list
Re: xmlrpclib and carriagereturn (\r)
Le Sat, 18 Mar 2006 02:17:36 -0800, Ben Cartwright a écrit :
> Jonathan Ballet wrote:
>> The problem is, xmlrpclib "eats" those carriage return characters when
>> loading the XMLRPC request, and replace it by "\n". So I got "bla\n\nbla".
>>
>> When I sent back those parameters to others Windows clients (they are
>> doing some kind of synchronisation throught the XMLRPC server), I send
>> to them only "\n\n", which makes problems when rendering strings.
>
[Just replying to this message. See F. Lundh reply too]
>
> Whoops, just realized we're talking about "\n\r" here, not "\r\n".
> Most of my previous reply doesn't apply to your situation, then.
>
> As far as Python's expat parser is concerned, "\n\r" is two newlines:
> one Unix-style and one Mac-style. It correctly (per XML specs)
> normalizes both to Unix-style.
>
> Is "\n\r" being used as a newline by your Windows clients, or is it a
> control code? If the former, I'd sure like to know why.
We are developping the Windows client. I think my teammates keep \n\r,
which is the defaut line terminator they had when getting string from text
input, and because ".net framework does the right things for you, etc. etc."
> If the
> latter, then you're submitting binary data and you shouldn't be using
> to begin with. Try .
>
> If worst comes to worst and you have to stick with sending "\n\r"
> intact in a param, you'll need to modify xmlrpclib to use a
> different (and technically noncompliant) XML parser. Here's an ugly
> hack to do that out of the box:
>
> # In your server code:
> import xmlrpclib
> # This forces xmlrpclib to fall back on the obsolete xmllib module:
> xmlrpclib.ExpatParser = None
>
> xmllib doesn't normalize newlines, so it's noncompliant. But this is
> actually what you want.
Well, I thought to use something like that. Currently, we are stucking
with the kind ugly hack you sent in your previous message (replace("\n",
"\n\r")
However, now that I know that xmlrpclib handle line terminator correctly
(regarding XML spec. ), I will try to see if we can handle line feed
correctly in our Windows application.
I think it should be the better solution.
Anyway, thanks a lot for your answers (both of them ;)
>
> --Ben
J.
--
http://mail.python.org/mailman/listinfo/python-list
Re: xmlrpclib and carriagereturn (\r)
Le Sat, 18 Mar 2006 08:54:49 +0100, Fredrik Lundh a écrit : > Jonathan Ballet wrote: > [snip] > > XMLRPC is XML, and XML normalizes line feeds: > > http://www.w3.org/TR/2004/REC-xml-20040204/#sec-line-ends > > relying on non-standard line terminators in text is fragile and horridly out- > dated; if the data you're sending qualifies as text, send it as text, and do > the conversion at the end points (if at all necessary). Ah, you send me the right link. So xmlrpclib handle those line terminators correctly. That's good. > > if it's not text, use the binary wrapper. > >> I send to them only "\n\n", which makes problems when rendering strings. > > how are you rendering things if you have problems treating a line feed > as a line feed? that's rather unusual; most Windows applications have > no problems handling line feeds properly, so I'm not sure why it has to > be a problem in your application... > > The problem recently pointed out, so we were searching where those carriage return disapeared. However, if we can throw them away and render line feed as line feed, it would be the best solution imho. I'll look into this. Thanks for your answer, J. -- http://mail.python.org/mailman/listinfo/python-list
