Armin Ronacher <armin.ronacher <at> active-4.com> writes:
> If by str() you mean using "str('x')" as replacement for 'x' in both 2.x
> and 3.x with __future__ imports as a replacement for native string
> literals, please mention why this is better than u(), s(), n() etc. It
> would be equally slow than a custom wrapper function and it would not
> support non-ascii characters.
Well, you can give it any name you like, but
if PY3:
def n(literal): return literal
else:
# used along with "from __future__ import unicode_literals" in client code
def n(literal): return literal.encode('utf-8')
will support non-ASCII characters. You have not provided anything other than a
microbenchmark regarding performance - as you are well aware, this does not
illustrate what the performance might be on a representative workload. While
there might be the odd percent in it, I didn't see any major degradation when
running the Django test suite - which I would think is a more balanced workload
than just benchmarking the wrapper. Of course, I don't claim to have studied the
performance characteristics closely - I haven't.
AFAICT, the incidence of native strings in an application is not that great (of
course there can be pathological cases), so the number of calls to n() or
whatever it's called is unlikely to have any significant impact. Even when I was
using u() calls with the 2.5 port - which are of course much more common - the
performance impact was unremarkable.
Regards,
Vinay Sajip
_______________________________________________
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
