On 6/30/14, 9:07 PM, Kim Gräsman wrote:
Hi Gregory,
On Mon, Jun 30, 2014 at 11:17 PM, Gregory Szorc <g...@mozilla.com> wrote:
On 6/30/14, 2:06 PM, Kim Gräsman wrote:
Do you have any ideas for version-agnostic patterns?
The generally accepted solution is either:
1) Use 2to3 to produce a copy of the code that is Python 3 compatible and
then run the copy
2) Use six [1] (or similar compatibility layer) to abstract iteritems, etc
I'm a huge fan of a single code base without a 2to3 copy. I also prefer to
not introduce six or similar shims unless it's absolutely necessary: I'd
rather the code be readable, vanilla Python.
Great, me too.
If there is no or a small performance hit switching iteritems() and friends
to their non-iter-on-python-2 equivalents, I'm fine with doing that. Have
you measured the differences on a real project (such as Firefox)?
No, I was hoping I wouldn't have to try and build Firefox on my tired,
antivirus-laden corporate laptop. Let me see if I can get the build
working here so I can measure.
Assuming there is a significant performance hit, I guess I would
introduce my own shims somehow. I could either:
- create shims in pymake.util
- switch inline (there are 30-or-so places where we use these iterables)
Do you have a preference here? Other ideas?
Given it's 9 PM and I have a beer in me, I will also suggest the
"honeybadger" approach: just use items() and friends without worrying
about performance. Will non-iterable functions make pymake a little
slower? Probably. But is this the biggest performance concern? Probably
not (we know variable evaluations are quite painful on large make files
and I doubt iteration over 10,000+ item collections or iteration where
lazy evaluation is important has much to do with anything).
Besides, Mozilla has already stopped supporting pymake to build Firefox
because it's slower than GNU make. Given that pymake was invented to
make building Firefox faster [on Windows], I'd say that leaves pymake as
purely a "research" project. I'd say it is acceptable for pymake to
continue a long tradition of academic projects and not care too much
about performance.
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
