[PATCH 3 of 7] parsers: avoid PyList_Append when parsing obs markers

[Gregory Szorc]

On Thu, Mar 16, 2017 at 10:47 AM, Augie Fackler <raf at durin42.com> wrote:

>
> On Mar 16, 2017, at 10:43, Gregory Szorc <gregory.szorc at gmail.com> wrote:
>
> Last time we had the Rust discussion, we couldn't ship Rust due to distro
> packaging support. Has that changed?
>
>
> My gut feeling with my maintainer hat on is that any rust speedups would
> need to be opt-in, much like today's C speedups. My understanding of Rust
> is that it'll have significantly fewer ABI woes for our needs than C++
> might.
>

I also agree I'd rather start using Rust before C++.

It's worth noting that while our C speedups are strictly speaking optional,
setup.py tries to build them by default and fails if it can't. Furthermore,
our default module import policy requires the C extensions by default. This
isn't a huge problem today because many systems can build Python C
extensions (or at least can easily after installing a python-dev or
python-devel package). But Rust support in distros isn't quite there. So I
fear requiring Rust today will make it more difficult to get the speedups
than the corresponding C versions.


>
> FWIW, Firefox appears to be driving a lot of distro support for Rust.
> Firefox 54+ now require Rust to build. Furthermore, Firefox is pretty
> aggressive about adopting new versions of Rust. What this means is that the
> next Firefox ESR (after 52, which was released last week) will effectively
> require distros to support whatever version of Rust that ESR is using. I'm
> not exactly where distros are w.r.t. Rust support today. But the major ones
> all know they need to get their Rust story in order for the next Firefox
> ESR, which I think is sometime in 2018. Ask me over beers what those
> conversations were like :)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170318/1e075cf5/attachment.html>