3 ms·

For Mercurial, this is the biggest problem with Python 3: http://bugs.python.org/issue3982 http://bugs.python.org/issue3982 They got rid of format for ordinar

by jordigh 13y ago

For Mercurial, this is the biggest problem with Python 3: http://bugs.python.org/issue3982 http://bugs.python.org/issue3982 They got rid of format for ordinary strings, and since we have to use bytestrings for handling hg's binary format, converting back and forth with .decode and .encode just to get the formatting is a lot of work. The Python devs have actually acknowledged this use case and apologised to hg. Kinda weird, considering how Python itself is hosted with hg. :-/

gejjaxxita 13y ago
That was opened five years ago, bizarre.
Groxx 13y ago
Why not write it yourself, as a utility method rather than something built-in? Granted it would be nice to be built in, but that shouldn't stop anyone. Or is there some other reason?
- jordigh 13y ago
  Speed is another big concern. You want your DVCS to be as fast as possible. You don't want to wait even half a second to see the output of "hg status" just to see which files you've modified.
  - Groxx 13y ago
    Mercurial is a big project. Surely there's one skilled C programmer who could write a relatively-portable, efficient, limited version of this feature (or find one, I assume something extremely similar exists in several flavors). Once that's done, have a Python fallback for those esoteric systems where it doesn't work, and move on with life. Since it's apparently a critical code-path, that's normal development for great performance. I could easily be underestimating the difficulty of integrating C with Python - I've never done it personally, but I gather that's one of its strengths. But this seems like a pretty simple problem, which has a pretty simple implementation in any language (there's an included Python implementation on the linked page, ~20 LOC?), and if it's a critical performance piece it's surely worth the cost to make that piece.
    - jordigh 13y ago
      It's more work than it appears. And it's work that doesn't seem to have immediate benefit, since Python 2 is still around. Augie Fackler has started tackling it, but even if we do get the change to Python 3 itself, it also requires a substantial rewrite of the hg codebase, since we use strings everywhere. And again, it's a lot of work with no huge payoff.
      - Groxx 13y ago
        >It's more work than it appears. I completely believe that, and good point about Python 2. I wasn't considering that side of things. Is it a complicated rewrite, or just big? Superficially it seems pretty mechanical, `bytes.format` to `bytes_format` (though finding them might be hard). I never feel like I have free time, but I don't tend to get exhausted from things like that, maybe I can contribute a bit. It would be good to get exposed to some decent, real Python code :)
        jordigh 13y ago
        Come join us in #mercurial in Freenode or in mercurial-devel@selenic.com if you're interested in solving this problem.

by jordigh 13y ago

gejjaxxita 13y ago

That was opened five years ago, bizarre.

Groxx 13y ago

Why not write it yourself, as a utility method rather than something built-in? Granted it would be nice to be built in, but that shouldn't stop anyone. Or is there some other reason?

jordigh 13y ago
Speed is another big concern. You want your DVCS to be as fast as possible. You don't want to wait even half a second to see the output of "hg status" just to see which files you've modified.
- Groxx 13y ago
  Mercurial is a big project. Surely there's one skilled C programmer who could write a relatively-portable, efficient, limited version of this feature (or find one, I assume something extremely similar exists in several flavors). Once that's done, have a Python fallback for those esoteric systems where it doesn't work, and move on with life. Since it's apparently a critical code-path, that's normal development for great performance. I could easily be underestimating the difficulty of integrating C with Python - I've never done it personally, but I gather that's one of its strengths. But this seems like a pretty simple problem, which has a pretty simple implementation in any language (there's an included Python implementation on the linked page, ~20 LOC?), and if it's a critical performance piece it's surely worth the cost to make that piece.
  - jordigh 13y ago
    It's more work than it appears. And it's work that doesn't seem to have immediate benefit, since Python 2 is still around. Augie Fackler has started tackling it, but even if we do get the change to Python 3 itself, it also requires a substantial rewrite of the hg codebase, since we use strings everywhere. And again, it's a lot of work with no huge payoff.
    - Groxx 13y ago
      >It's more work than it appears. I completely believe that, and good point about Python 2. I wasn't considering that side of things. Is it a complicated rewrite, or just big? Superficially it seems pretty mechanical, `bytes.format` to `bytes_format` (though finding them might be hard). I never feel like I have free time, but I don't tend to get exhausted from things like that, maybe I can contribute a bit. It would be good to get exposed to some decent, real Python code :)
      - jordigh 13y ago
        Come join us in #mercurial in Freenode or in mercurial-devel@selenic.com if you're interested in solving this problem.