Hi,
Jut to reiterate what I wrote on IRC:
Please do not write or advocate for import hooks, especially not for
porting purposes. It would either mean that people start adding that
hook on their own to the code (and that awfully reminds me of the days
of 'require rubygems' in the Ruby world) or
On Sun, Mar 4, 2012 at 6:43 AM, Armin Ronacher
armin.ronac...@active-4.com wrote:
Please do not write or advocate for import hooks, especially not for
porting purposes. It would either mean that people start adding that
hook on their own to the code (and that awfully reminds me of the days
of
Armin Ronacher armin.ronacher at active-4.com writes:
The current work in progress install time hook can be found here:
https://github.com/mitsuhiko/unicode-literals-pep/tree/master/install-hook
I realise that the implementation is different, using tokenize rather than
lib2to3, but in terms
Hi,
On 3/4/12 4:44 PM, Guido van Rossum wrote:
I'd love a pointer to the rubygems debacle...
Setuptools worked because Python had .pth files for a long, long time.
When the Ruby world started moving packages into nonstandard locations
(GameName/the files in that gem) something needed to activate
Hi,
On 3/4/12 9:00 PM, Vinay Sajip wrote:
I realise that the implementation is different, using tokenize rather than
lib2to3, but in terms of its effect on the transformed code, what are the
differences between this hook and running 2to3 with just the fix_unicode
fixer?
I would hope they
Armin Ronacher armin.ronacher at active-4.com writes:
Considering such an import hook has to run over all imports because it
would not know which to rewrite and which not I think it would be
equally problematic, especially if libraries would magically activate
that hook.
You could be right,
Armin Ronacher armin.ronacher at active-4.com writes:
I would hope they both have the same effect. Namely stripping the 'u'
prefix in all variations.
Okay, that's all I was curious about.
Why did I go with the tokenize approach? Because I never even
considered a 2to3 solution. Part of
