[Python-Dev] Is it safe to assume that Python 2.7 is always built with unicode support?
Hello every one, I'm looking into issue 1065986 [1], and in order to submit a patch I need to know whether I have to take into account the eventuality that cpyhon 2.7 be built without unicode support. As far as I can see it is no longer possible to configure cpython 2.7 with --disable-unicode as a consequence of the merge 59157:62babf456005 on 27 Feb 2010 of the commit 59153:8b2048bca33c of the same day. Since I could not find an discussion on the topic leading explicitly to this decision, I was wondering whether this is in fact an unintended consequence of the check introduced in 59153:8b2048bca33c, which excludes "no" from the acceptable values for configuring unicode support. In conclusion, can you guys confirm that I don't have to worry that cpython 2.7 could be built with no unicode support? Or not? If so, shouldn't it be properly documented, at least in Misc/NEWS ? Bye, Stefano [1] http://bugs.python.org/issue1065986 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is it safe to assume that Python 2.7 is always built with unicode support?
Understood. May I suggest that http://bugs.python.org/issue8767 be reopened, to make things clear? Stefano On 26 April 2012 16:01, wrote: > I'm looking into issue 1065986 [1], and in order to submit a patch I need >> to know whether I have to take into account the eventuality that cpyhon >> 2.7 >> be built without unicode support. >> > > It's intended (at least, it is *my* intention) that Python 2.7 can be built > without Unicode support, and it's a bug if that is not possible anymore. > Certain embedded configurations might want that. > > That doesn't mean that the bug needs to be fixed; this can be deferred > until > somebody actually requests that bug being fixed, or better, until somebody > contributes a patch to do so. > > However, it *does* mean that we shouldn't further break the feature, at > least > not knowingly. > > OTOH, it's clear that certain functionality cannot work if Unicode is > disabled, > so it may be acceptable if pydoc breaks in such a configuration. > > Regards, > Martin > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dir() in inspect.py ?
On 21 May 2012 03:36, Guido van Rossum wrote: > [...] > > I have to agree with Christian that inspect.py is full of hacks and > heuristics that would be fine in a module that's part of a user's app > or even in a library, but stand out as brittle or outright unreliable > in a stdlib module. Basically, you can't trust that inspect.py will > work. I've seen various occasions (sorry, can't remember details) > where some function in it outright crashed when given a slightly > unusual (but not unreasonable) argument. It might be a nice project > for a new contributor to improve this situation. > [...] > An example that crashes is >>> def f(l, (x, y)): ...sup = max(u*x + v*y for u, v in l) ...return ((u, v) for u, v in l if u*x + v*y == sup) >>> inspect.getargspec(f) See http://bugs.python.org/issue14611 . I did submit a patch, a few weeks ago. Stefano ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
