I guess we forgot to observe it yesterday, but: February 19, 1991, was
the day Guido first posted Python 0.9.1 to alt.sources:
https://groups.google.com/g/alt.sources/c/O2ZSq7DiOwM/m/gcJTvCA27lMJ
Happy 30th birthday, Python!
//arry/
___
Python
Mike Miller writes:
> Sounds like automating until it is "just a push of a button,"
> should be a goal. According to Victor there has been progress, but
> always room for more.
When XEmacs was releasing betas regularly, everything from tagging the
local authoritative repo to pushing to the pub
Hi,
I propose to actively remove support for *legacy* platforms and
architectures which are not supported by Python according to PEP 11
rules: hardware no longer sold and end-of-life operating systems. The
removal should be discussed on a case by case basis, but I would like
to get an agreement on
On 21/02/2021 13.13, Victor Stinner wrote:
> Hi,
>
> I propose to actively remove support for *legacy* platforms and
> architectures which are not supported by Python according to PEP 11
> rules: hardware no longer sold and end-of-life operating systems. The
> removal should be discussed on a case
(Since my first reply here somehow got lost, I'm posting this again).
Rust doesn't prevent anyone from building Tier 2 or Tier 3 targets. There is no
limitation for "legacy" or "deprecated" targets. Any target can be built and
any target can be selected by the Rust compiler for cross-compliation
Rust doesn't keep any user from building Rust for Tier 2 or Tier 3 platforms.
There is no separate configure guard. All platforms that Rust can build for,
are always enabled by default. No one in Rust keeps anyone from cross-compiling
code for sparc64 or powerpcspe, for example.
So if you want
On Sun, Feb 21, 2021 at 12:05 AM Larry Hastings wrote:
> I guess we forgot to observe it yesterday, but: February 19, 1991, was the
> day Guido first posted Python 0.9.1 to alt.sources:
>
> https://groups.google.com/g/alt.sources/c/O2ZSq7DiOwM/m/gcJTvCA27lMJ
>
> Happy 30th birthday, Python!
Happ
Hello,
Here's example:
Traceback (most recent call last):
File "pseudoc_tool.py", line 91, in
first_class_function_value(func, **pass_params)
TypeError: print() got an unexpected keyword argument 'noann'
Ok, which "print" do you mean, dear CPython? I have a dozen of print
functions (most
It looks like CPython remains 100% C, so clang becomes more attractive:
https://stackoverflow.com/questions/6329688/llvm-and-visual-studio-obj-binary-incompatibility
Then again, do we allow C++ extension modules? That might make C++ more
relevant, even if CPython itself is purely C.
On Sat, Feb
On 21/02/2021 13.47, glaub...@debian.org wrote:
> Rust doesn't keep any user from building Rust for Tier 2 or Tier 3 platforms.
> There is no separate configure guard. All platforms that Rust can build for,
> are always enabled by default. No one in Rust keeps anyone from
> cross-compiling code
On Sun, 2021-02-21 at 19:12 +0100, Christian Heimes wrote:
> On 21/02/2021 13.47, glaub...@debian.org wrote:
> > Rust doesn't keep any user from building Rust for Tier 2 or Tier 3
> > platforms. There is no separate configure guard. All platforms that Rust
> > can build for, are always enabled by
On Sun, 2021-02-21 at 13:35 +0100, Christian Heimes wrote:
> On 21/02/2021 13.13, Victor Stinner wrote:
> > Hi,
> >
> > I propose to actively remove support for *legacy* platforms and
> > architectures which are not supported by Python according to PEP 11
> > rules: hardware no longer sold and end
On Sun, Feb 21, 2021 at 10:15 AM Christian Heimes
wrote:
> On 21/02/2021 13.47, glaub...@debian.org wrote:
> > Rust doesn't keep any user from building Rust for Tier 2 or Tier 3
> platforms. There is no separate configure guard. All platforms that Rust
> can build for, are always enabled by defau
On Sun, Feb 21, 2021 at 12:03 PM Michał Górny wrote:
> On Sun, 2021-02-21 at 13:35 +0100, Christian Heimes wrote:
> > On 21/02/2021 13.13, Victor Stinner wrote:
> > > Hi,
> > >
> > > I propose to actively remove support for *legacy* platforms and
> > > architectures which are not supported by Pyt
On Sun, Feb 21, 2021 at 1:07 PM Gregory P. Smith wrote:
>
> > I'm +1 in general for your proposal. I also like the idea to adopt
>> > Rust's platform support definition.
>>
> +1, but see below.
>
> The main thing from a project maintenance perspective is for platforms to
> not become a burden t
On Sun, Feb 21, 2021 at 4:16 AM Victor Stinner wrote:
>
> There is also a 4th category: platforms/archs which are really not
> supported, like they legacy ones for which we removed the code :-)
> Examples: BeOS, MacOS 9, platforms with no thread support, etc.
>
FWIW, BeOS may be resurfacing some
On 2/21/2021 12:04 PM, Paul Sokolovsky wrote:
Traceback (most recent call last):
File "pseudoc_tool.py", line 91, in
first_class_function_value(func, **pass_params)
TypeError: print() got an unexpected keyword argument 'noann'
This is not typical behavior in current Python (3.8+).
de
On Sun, Feb 21, 2021 at 10:02 AM Dan Stromberg wrote:
>
> It looks like CPython remains 100% C, so clang becomes more attractive:
>
> https://stackoverflow.com/questions/6329688/llvm-and-visual-studio-obj-binary-incompatibility
>
> Then again, do we allow C++ extension modules? That might make C
Thank you for all.
I finally submit the PEP 597 with PYTHONWARNDEFAULTENCODING /
warn_default_encoding.
On Mon, Feb 15, 2021 at 2:28 PM Inada Naoki wrote:
>
> I am updating PEP 597 to include discussions in the thread.
> Before finishing the PEP, I need to decide the option name.
>
> I used PYTH
Hello, I am trying to sort out what can be done for bpo-35753 /
https://github.com/python/cpython/pull/22981
Basically any module that does "from unittest.mock import call" will
crash the doctest scanner.
At this point I'm not sure how to proceed at this point, there is some
different ideas
There are zero technical reasons for what you are planning here.
You are inflating a few lines of autoconf into a "platform support", so you
have a reason to justify adding multiple lines of extra autoconf codes to make
life for downstream distributions harder.
I could understand the maintenanc
> The main thing from a project maintenance perspective is for platforms to
not become a burden to other code maintainers. PRs need to be reviewed.
Every #if/#endif in code is a cognitive burden. So being a minor platform
can come with unexpected breakages that need fixing due to other changes
ma
22 matches
Mail list logo
