Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #82571 > unrolled thread

Re: Portable code: __import__ demands different string types between 2 and 3

Started byEthan Furman <ethan@stoneleaf.us>
First post2014-12-15 17:49 -0800
Last post2014-12-15 17:49 -0800
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Portable code: __import__ demands different string types between 2 and 3 Ethan Furman <ethan@stoneleaf.us> - 2014-12-15 17:49 -0800

#82571 — Re: Portable code: __import__ demands different string types between 2 and 3

FromEthan Furman <ethan@stoneleaf.us>
Date2014-12-15 17:49 -0800
SubjectRe: Portable code: __import__ demands different string types between 2 and 3
Message-ID<mailman.16992.1418694593.18130.python-list@python.org>

[Multipart message — attachments visible in raw view] — view raw

On 12/15/2014 05:36 PM, Ben Finney wrote:
> 
> That's not the issue at all. I know how to declare a literal such that
> it is Unicode in Python 2 and Python 3 (that's what the ‘from __future__
> import unicode_literals’ does).
> 
> Rather, the problem is ‘__import__’ having incompatible expectations:
> the ‘fromlist’ parameter's items must be bytes in Python 2, and must be
> Unicode in Python 3.

Ah.  Well, then you do not want the `unicode_literals` import or it won't be bytes in Python 2 (as I'm sure you know).


> The same parameter value can't satisfy both those requirements in a
> single 2-and-3 compatible code base, without either using the
> bytes-and-text ambiguity of ‘str’, or some kludge over-riding a simple
> ‘__import__’ call. Both of those are ugly and make for buggy code.

If this is for a large(ish) application, make one module with stuff that needs the ambiguity to work correctly.  Comment
the heck out of it.  ;)


> I'm increasingly of the opinion this is a subtle bug in ‘__import__’
> that should be fixed instead of worked around.

Of course.  But you'll still need to work around it for previous versions, unless you can say you only support 2.7.10+
(maybe 2.7.9+ if it gets fixed quick enough).

> But it will likely be rejected because the documentation advises against using ‘__import__’.

Functions that should accept str but barf on unicode have a tendency to get fixed.

--
~Ethan~

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web