I think it's a great idea! :) [1]
LLVM did the same recently (though they imported all previous messages from the
mailinglist, thus making them searchable in discourse) [2 - announcement; 3 -
retro], and by and large, I think it was a success.
One of the comments in the retro was:
> Searching
Agreed on all 4 counts! :)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
> Also the GH bot is using DD/MM/ date format :-( whyy?
Because github is international, and everyone but the US seems to agree that
```
/\
/ \
/\
/ day \
/\
/ \
/month \
/__\
/
> Not for me to answer, I'm not a proponent of the change. I'm sure if
> you read past discussions here and on Discourse you'll find answers
> from the people who studied the problem carefully.
The opening mail proposed C++11 without rationale or references. I did search
the archives and
> I work on Apache Arrow, where the C++ parts require C++11 (and we can't
go further than this for now because of R compatibility concerns).
Thanks for the datapoint, that's reasonable of course (though I'll note you're
using abseil at least through grpc, and abseil is scheduled to remove C++11
> > While I don't know who proposed C++11 or where, I'd therefore like
> > to propose to move to _at least_ C++14.
>
> What benefits does this have for Python development?
Likewise I can ask what benefits choosing C++11 would have?
In general, I think standards and compilers need version
> In terms of C++ version, it was proposed to target C++11.
GCC 5 has full C++14 support (one library functionality missing), and so does
VS2015 onwards as well as Clang 3.4, see
https://en.cppreference.com/w/cpp/compiler_support
I doubt that any older compilers are in use _anywhere_ in
> And it seems like we still care about support Visual Studio 2017, even
> if Visual Studio 2019 and 2022 are available.
Can we make this more concrete? Do we know of affected parties? Numbers
of affected users? Or are we just conservatively guesstimating the thickness
of the long tail of
> While the SC's decision to keep the syntax uniform is certainly laudable,
> it's creating the issue of packaging new complexities into a very limited
> syntactic & semantic space (e.g. no new magic symbols like "->", which I
> agree with BTW), leaving only very verbose solutions that the
> Maybe a more practical approach would be to use C99 "except of
features not supported by MSVC of Visual Studio 2019"?
This could be formulated in a more neutral way by saying
"C99 without the things that became optional in C11", or perhaps
"C11 without optional features" (at least from the POV
I find this a really elegant approach.
While the SC's decision to keep the syntax uniform is certainly laudable, it's
creating the issue of packaging new complexities into a very limited syntactic
& semantic space (e.g. no new magic symbols like "->", which I agree with BTW),
leaving only very
Baptiste Carvello wrote:
> y = config["handler"]["parameters"]["y"] with KeyError as None
I love the look of this! While it doesn't address everything that PEP505 does,
that's IMO a good thing, because - as other people mentioned already - None
does too many things already.
On another note,
12 matches
Mail list logo
