Repository navigation
Limit the max size of PyUnicodeObject->defenc? #45992
Description
| BPO | 1651 |
|---|---|
| Nosy | @malemburg, @gvanrossum, @pitrou, @tiran |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2008-01-22.23:05:23.756>
created_at = <Date 2007-12-18.12:13:40.727>
labels = ['interpreter-core']
title = 'Limit the max size of PyUnicodeObject->defenc?'
updated_at = <Date 2008-01-22.23:49:21.573>
user = 'https://github.com/tiran'bugs.python.org fields:
activity = <Date 2008-01-22.23:49:21.573>
actor = 'gvanrossum'
assignee = 'none'
closed = True
closed_date = <Date 2008-01-22.23:05:23.756>
closer = 'gvanrossum'
components = ['Interpreter Core']
creation = <Date 2007-12-18.12:13:40.727>
creator = 'christian.heimes'
dependencies = []
files = []
hgrepos = []
issue_num = 1651
keywords = []
message_count = 6.0
messages = ['58744', '58756', '61547', '61548', '61549', '61550']
nosy_count = 4.0
nosy_names = ['lemburg', 'gvanrossum', 'pitrou', 'christian.heimes']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1651'
versions = ['Python 3.0']
Activity
tiran commentedon Dec 18, 2007
I think that the cached default encoding version of the unicode object
should be limited in size. It's probably a bad idea to cache a 100MB of
data. For large amount strings and unicode objects the user should do
explicit caching if required.
gvanrossum commentedon Dec 18, 2007
I don't see a patch. And I think you cannot do this without compromising
correctness, since _PyUnicode_AsDefaultEncodedString() returns the
cached value without incrementing its refcount. (The only refcount that
keeps it alive is the cache entry.)
pitrou commentedon Jan 22, 2008
The default encoding version is generated lazily, and only from a couple
of places (if I believe my grepping through the py3k sources).
So we can:
convert the 20 or so places in which that function is used to properly
decref the value when done
gvanrossum commentedon Jan 22, 2008
Yes.
No. I suspect you'll find it quite difficult to pick a place where to do
the decref in some cases.
malemburg commentedon Jan 22, 2008
For Py3k you can get rid of the cached default encoded version of the
Unicode object altogether:
This was only needed to make the Unicode/string auto-coercion mechanism
efficient in Python 2.x. In Py3k, you'll only do such conversions at the
IO-boundaries and explicitly, so caching the converted value is no
longer necessary.
gvanrossum commentedon Jan 22, 2008
You wish. In practice (unfortunately) it's still used quite a bit. It
would be a good project to eradicate the need, but I see it as low priority.