[Python-ideas] One way to do format and print

[Nick Coghlan]

On 10 September 2015 at 12:07, Brendan Barnwell <brenbarn at brenbarn.net> wrote:
> On 2015-09-09 14:50, Andrew Barnert via Python-ideas wrote:
>>
>> Well, have you read the answers given by Nick, me, and others earlier
>> in the thread? If so, what do you disagree with? You've only
>> addressed one point (that % is faster than {} for simple cases--and
>> your solution is just "make {} faster", which may not be possible
>> given that it's inherently more hookable than % and therefore
>> requires more function calls...). What about formatting headers for
>> ASCII wire protocols, sharing tables of format strings between
>> programming languages (e.g., for i18n), or any of the other reasons
>> people have brought up?
>
>
>         This getting off on a tangent, but I don't see most of those as
> super compelling.  Any programming language can use whatever formatting
> scheme it likes.  Keeping %-substitutions around helps in sharing format
> strings only with other languages that use exactly the same formatting
> style.  So it's not like % has any intrinsic gain; it just happens to
> interoperate with some other particular stuff.  That's nice, but I don't
> think it makes sense to keep things in Python just so it can interoperate in
> specific ways with specific other languages that use less-readable syntax.

This perspective doesn't grant enough credit to the significance of C
in general, and the C ABI in particular, in the overall computing
landscape. While a lot of folks have put a lot of work into making it
possible to write software without needing to learn the details of
what's happening at the machine level, it's still the case that the
*one* language binding interface that *every* language runtime ends up
including is being able to load and run C libraries.

It's also the case that for any new CPU architecture, one of the first
things people will do is bootstrap a C compiler for it, as that then
lets them bootstrap a whole host of other things (including Python).

For anyone that wants to make the transition from high level
programming to low level programming, or vice-versa, C is also the
common language understood by both software developers and computer
systems engineers.

There *are* some worthy contenders out there that may eventually
topple C's permissive low level memory access model from its position
of dominance (I personally have high hopes for Rust), but that's not
going to be a quick process.

Regards,
Nick.

P.S. It's also worth remembering than many Pythonistas, including
members of the core development team, happily switch between
programming languages according to the task at hand. Python can still
be our *preferred* language without becoming the *only* language we
use :)

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia