Summary: | unicode package name causes erroneous KeyError (no key provided) in aux_get routine (portage_db_template.check_key()) | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Yobbo Bandana <yobbobandana> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | VERIFIED LATER | ||
Severity: | major | ||
Priority: | High | ||
Version: | 2.1 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
a one line patch to portage_db_template.py
patch compatible with python 2.2 |
Description
Yobbo Bandana
2005-05-23 19:41:37 UTC
There's a heap of work that needs to be done to make portage unicode compatible. No guarantees until there is an official API. Admittedly the unicode wasn't meant to have been passed to portage in the first place. But that one line in portage_db_template.check_key() was the only place that seemed to be causing problems. This was just a problem with ascii being passed on in unicode format, not with an actual unicode name. Created attachment 59712 [details, diff]
a one line patch to portage_db_template.py
Need to check out python-2.2 compatibility on this one. Created attachment 59847 [details, diff]
patch compatible with python 2.2
Ahh, sorry. to be compatible with python 2.2 it would have to be
"(isinstance(key, str) or (isinstance(key, unicode))" in stead of
"isinstance(key, basestring)".
A crude regex showed 14 occurrences throughout portage of issues regarding type. However, there's probably other issues too. I don't really like the idea of making those 14 places into a test that takes over half a 80-char line though. Will keep this for later when we put together a supported API, which is already planned to be released with a requirement of python 2.3. Closing due to old age. |