[Python-Dev] Re: Why aren't we allowing the use of C11?

[Nathaniel Smith]

On Thu, Jan 28, 2021 at 9:03 PM Gregory P. Smith  wrote:
>
> On Thu, Jan 28, 2021 at 10:52 AM Charalampos Stratakis  
> wrote:
>>
>>
>>
>> - Original Message -
>> > From: "Mark Shannon" 
>> > To: "Python Dev" 
>> > Sent: Thursday, January 28, 2021 5:26:37 PM
>> > Subject: [Python-Dev] Why aren't we allowing the use of C11?
>> >
>> > Hi everyone,
>> >
>> > PEP 7 says that C code should conform to C89 with a subset of C99 allowed.
>> > It's 2021 and all the major compilers support C11 (ignoring the optional
>> > parts).
>> >
>> > C11 has support for thread locals, static asserts, and anonymous structs
>> > and unions. All useful features.
>> >
>> > Is there a good reason not to start using C11 now?
>> >
>> > Cheers,
>> > Mark.
>> >
>> >
>> > ___
>> > 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
>> > https://mail.python.org/archives/list/python-dev@python.org/message/PLXETSQE7PRFXBXN2QY6VNPKUTM6I7OD/
>> > Code of Conduct: http://python.org/psf/codeofconduct/
>> >
>> >
>>
>> Depends what platforms the python core developers are willing to support.
>>
>> Currently downstream on e.g. RHEL7 we compile versions of CPython under gcc 
>> 4.8.2 which does not support C11.
>>
>> In addition the manylinux2014 base image is also based on CentOS 7, which 
>> wouldn't support C11 as well.
>
>
> I suspect this is the primary technical reason not to adopt C11 left.
>
> But aren't things like manylinux2014 defined by the contents of a centrally 
> maintained docker container?
> If so (I'm not one who knows how wrong my guess likely is...), can we get 
> those updated to include a more modern compiler so we can move on sooner than 
> the deprecation of manylinux2014?

RedHat maintains builds of gcc 8.2.1 for CentOS/RHEL 7, that have some
clever hacks to guarantee that the resulting binaries will work on
CentOS/RHEL 7: https://www.softwarecollections.org/en/scls/rhscl/devtoolset-8/

I'm pretty sure that's what the manylinux2014 image is using.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/5QQIKXXY7MNXPYM5AZYXPQFAQOHOYRTP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why aren't we allowing the use of C11?

[Gregory P. Smith]

On Thu, Jan 28, 2021 at 10:52 AM Charalampos Stratakis 
wrote:

>
>
> - Original Message -
> > From: "Mark Shannon" 
> > To: "Python Dev" 
> > Sent: Thursday, January 28, 2021 5:26:37 PM
> > Subject: [Python-Dev] Why aren't we allowing the use of C11?
> >
> > Hi everyone,
> >
> > PEP 7 says that C code should conform to C89 with a subset of C99
> allowed.
> > It's 2021 and all the major compilers support C11 (ignoring the optional
> > parts).
> >
> > C11 has support for thread locals, static asserts, and anonymous structs
> > and unions. All useful features.
> >
> > Is there a good reason not to start using C11 now?
> >
> > Cheers,
> > Mark.
> >
> >
> > ___
> > 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
> >
> https://mail.python.org/archives/list/python-dev@python.org/message/PLXETSQE7PRFXBXN2QY6VNPKUTM6I7OD/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
> >
>
> Depends what platforms the python core developers are willing to support.
>
> Currently downstream on e.g. RHEL7 we compile versions of CPython under
> gcc 4.8.2 which does not support C11.
>
> In addition the manylinux2014 base image is also based on CentOS 7, which
> wouldn't support C11 as well.
>

I *suspect* this is the primary technical reason not to adopt C11 left.

But aren't things like manylinux2014 defined by the contents of a centrally
maintained docker container?
If so (I'm not one who knows how wrong my guess likely is...), can we get
those updated to include a more modern compiler so we can move on sooner
than the deprecation of manylinux2014?

-gps


>
> --
> Regards,
>
> Charalampos Stratakis
> Software Engineer
> Python Maintenance Team, Red Hat
> ___
> 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
> https://mail.python.org/archives/list/python-dev@python.org/message/PCOZN5NHNZ7HIANOKQQ7GQQMV3A3JF72/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/MNLR45HD4X6EKYO2ARXLOF7OGTKODOJG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: What is the pyclbr public API?

[Guido van Rossum]

On Thu, Jan 28, 2021 at 8:08 PM Terry Reedy  wrote:

> On 1/27/2021 7:01 PM, Guido van Rossum wrote:
> > It's likely that the additions are going to break someone's code;
>
> Since at least 2007, when Georg moved the 3i reST tree into the 3k
> branch, the instances have been described as "Class/Function Descriptor
> Objects", returned by readmodule(_ex), that "provide the following data
> members".  There are no methods (maybe __repr__ should be added for
> debugging), so these are pure data classes, identical in purpose to pure
> dataclasses.
>

Lots of people just read the source code though. In general we've often
been careful with changing undocumented APIs if we believe they are
commonly used in ways not endorsed by the official documentation.


> The only intended reason to call these would be to create a tree for
> testing.


Really? Couldn't someone have an application where they insert new objects
(like is documented for the ast module)?


> We do this indirectly with a couple of private test-only
> pyclbr functions.  Being private, *those* functions can have the new
> parameter added anywhere, regardless of the Class/Function signatures.
>
> test_pyclbr uses a constructed tree as the expected output from
> readline_ex(test_code).  IDLE's test_browser uses a construction as test
> input to the browser widget. If someone does similar testing, it could
> break with the proposed changes.
>

So the question is whether we care. I don't know how to assess that.

> the
> > question seems to be do we care, since the constructors are undocumented?
>
> If any library functions return dataclasses, are the signatures of the
> (possibly generated) __init__ functions documented?
>

I'd say so, because we document how `@dataclass` constructs the
`__init__()` method.


> I care more about breaking tests than possibly non-existent 'off-label'
> uses, but Python won't know.
>
> > But shouldn't we just document the signatures,
>
> The existing or proposed signatures?
>

I meant the proposed signatures.

> so that in the future
> > we're not going to make the same mistake?
>
> I am not sure what you mean by the 'mistake' to not be repeated.  I
> consider it be had been either not declaring the signature private or at
> least not making optional parameters keyword only.
>

Yeah, by 'mistake' I meant leaving it ambiguous whether the constructor
signature is part of the API. And yes, we could also have designed the
constructor signatures more carefully.


> > I also wonder if some judicious use of keyword-only args might help
> > users who currently call the old constructors catch the breakage where
> > it's easily diagnosed (i.e. at the call site) instead of once the object
> > is instantiated (e.g. "why is end_lineno/parent the wrong type")?
>
> With 'end_lineno' added after existing required parameters, just before
> the existing optional parameter 'parent', an existing Class call ending
> with '..., posint, parent=SomeClass)' would fail with
>
> TypeError: Class.__init__ missing 1 required positional argument:
> 'end_lineno'
>

Unless you give end_lineno a default (I don't think we should do this
unless we find significant rogue usages).


> If parent had previously been made 'keyword only', a call ending instead
> with '..., num, SomeClass' would be a failure now.  But since not,
>

Right. One of the mistakes.

> Perhaps even add some type checks to catch obvious mistakes (could be as
> > simple as `assert isinstance(end_lineno, int)").
>
> Do you consider this enough to make the proposed positioning of
> 'end_lineno' acceptible?  The tradeoff is some immediate annoyance
> versus forever annoyance of a misplaced required 'optional' parameter.
>

Yes, I think that would be sufficient -- we'd break rogue usages (if there
are any) but at least they'd break pretty cleanly, in a way that's easy to
debug.


> Since I have in mind a possible IDLE use for end_lineno, quite different
> from that of the patch author, I consider either way of adding it
> superior to never adding it.
>

Agreed.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/2DVSVQZTXYPMP33UN3KNZ2MTDH4ZKEXS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: What is the pyclbr public API?

[Terry Reedy]

On 1/27/2021 7:01 PM, Guido van Rossum wrote:

It's likely that the additions are going to break someone's code;


Since at least 2007, when Georg moved the 3i reST tree into the 3k 
branch, the instances have been described as "Class/Function Descriptor 
Objects", returned by readmodule(_ex), that "provide the following data 
members".  There are no methods (maybe __repr__ should be added for 
debugging), so these are pure data classes, identical in purpose to pure 
dataclasses.


The only intended reason to call these would be to create a tree for 
testing.  We do this indirectly with a couple of private test-only 
pyclbr functions.  Being private, *those* functions can have the new 
parameter added anywhere, regardless of the Class/Function signatures.


test_pyclbr uses a constructed tree as the expected output from 
readline_ex(test_code).  IDLE's test_browser uses a construction as test 
input to the browser widget. If someone does similar testing, it could 
break with the proposed changes.


the 
question seems to be do we care, since the constructors are undocumented?


If any library functions return dataclasses, are the signatures of the 
(possibly generated) __init__ functions documented?


I care more about breaking tests than possibly non-existent 'off-label' 
uses, but Python won't know.



But shouldn't we just document the signatures,


The existing or proposed signatures?

so that in the future 
we're not going to make the same mistake?


I am not sure what you mean by the 'mistake' to not be repeated.  I 
consider it be had been either not declaring the signature private or at 
least not making optional parameters keyword only.


I also wonder if some judicious use of keyword-only args might help 
users who currently call the old constructors catch the breakage where 
it's easily diagnosed (i.e. at the call site) instead of once the object 
is instantiated (e.g. "why is end_lineno/parent the wrong type")?


With 'end_lineno' added after existing required parameters, just before 
the existing optional parameter 'parent', an existing Class call ending 
with '..., posint, parent=SomeClass)' would fail with


TypeError: Class.__init__ missing 1 required positional argument: 
'end_lineno'


If parent had previously been made 'keyword only', a call ending instead 
with '..., num, SomeClass' would be a failure now.  But since not,


Perhaps even add some type checks to catch obvious mistakes (could be as 
simple as `assert isinstance(end_lineno, int)").


Do you consider this enough to make the proposed positioning of 
'end_lineno' acceptible?  The tradeoff is some immediate annoyance 
versus forever annoyance of a misplaced required 'optional' parameter.


Since I have in mind a possible IDLE use for end_lineno, quite different 
from that of the patch author, I consider either way of adding it 
superior to never adding it.



On Wed, Jan 27, 2021 at 2:36 PM Terry Reedy > wrote:


pyclbr is the stdlib module browser (once just class browser, hence the
name).  The doc
https://docs.python.org/3/library/pyclbr.html#module-pyclbr
, which I
revised in 2017, documents readline and readline_ex as the public call
interface.  The functions return a hierarchical structure that includes
Function and Class instances.  (Both subclass pyclbr._Object.)  The doc
I revised already omitted signatures for these classes and just listed
the attributes of instances.  Just before that listing, I added "Users
are not expected to create instances of these classes."

https://bugs.python.org/issue38307
 and
https://github.com/python/cpython/pull/24348

propose to add an end_lineno attribute. Since pyclbr is now, since last
November, based on the ast tree and since the relevant ast nodes
have an
end_line attribute, the proposal amounts to copying that attribute,
along with others, instead of ignoring it.

The patch proposes to add 'end_lineno' after existing start 'lineno' in
the _Object, Function, and Class signatures.  I prefer doing this,
rather than adding the new parameter at the end of the list, because a)
being the the logical place would make the code easier to read, and b)
new names as the end of the signature, follow optional arguments, would
have to be optional, whereas

My question is whether the omission of signatures and my added sentence
sufficiently defines the signatures of these classes (in particular,
the
argument order) as private to approve the patch as is?


-- 
Terry Jan Reedy

___
Python-Dev mailing list -- python-dev@python.org

To unsubscribe send an email to python-dev-le...@python.org

[Python-Dev] Re: Why aren't we allowing the use of C11?

[Emily Bowman]

 On Thu, Jan 28, 2021 at 1:31 PM MRAB  wrote:

> I have Microsoft Visual Studio Community 2019 Version 16.8.4 (it's free)
> and it supports C11 and C17.


While an upgrade for Community is free, for Pro/Enterprise without an
annual license it's not. They've gone 100% subscription now, but people who
have outright purchased in the past would now have to make that decision.
The other problem is that a large version update can consume a large
portion of a day, or even a week if it all goes horribly wrong, especially
if your real job is supposed to be building things with it. Then you get to
deal with the fun time that is deprecations and new warnings (and
potentially new bugs) hitting your other codebases. If you're in a team,
it'll have to be a team consensus and effort, since you probably need to be
in lockstep. If you're restricted by corporate policy to software that's
gone through specific approval processes, that takes even longer. All of
this contributes to weighing all the cool new stuff you get against all the
irritating everyone who uses it, thus the inertia.

In some ways it's a lot easier being a home user who can experiment with
the bleeding edge and use whatever they want with their projects, but we
don't pay the bills like the big companies with big governance do.

-Em
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/CCQ4CT3ZQPHRJHWUK57L2PFMPIJFXDKH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why aren't we allowing the use of C11?

[MRAB]

On 2021-01-28 19:20, Terry Reedy wrote:


On 1/28/2021 11:26 AM, Mark Shannon wrote:


PEP 7 says that C code should conform to C89 with a subset of C99 allowed.


As I remember, when the Python C dialect was discussed about 4 years
ago, no one seriously proposed moving beyond a subset of C99 addition,
because of the state of MSVC.

It's 2021 and all the major compilers support C11 (ignoring the optional 
parts).


C11 has support for thread locals, static asserts, and anonymous structs 
and unions. All useful features.


Is there a good reason not to start using C11 now?


Inertia is *a* reason.  C11 would require (and allow!) most (nearly
all?) people compiling CPython on Windows to upgrade their VS-VC setup.
   Maybe including some buildbot machines.

Judging from the post for
https://bugs.python.org/issue42380
this requires VS 16.8 with MSVC 14.28, released last November.  Prior
distributions of VS 2019 had earlier versions.  Last I knew, regular
people without a dev license cannot get just MSVC.  So we cannot require
a compiler most people cannot get.  This post otherwise gives additional
reasons why upgrading would be good.


[snip]

I have Microsoft Visual Studio Community 2019 Version 16.8.4 (it's free) 
and it supports C11 and C17.

___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/OHYLWZ6GTHPFI3FH7OEMXAHCSW5PVRNA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why aren't we allowing the use of C11?

[Terry Reedy]

On 1/28/2021 11:26 AM, Mark Shannon wrote:


PEP 7 says that C code should conform to C89 with a subset of C99 allowed.


As I remember, when the Python C dialect was discussed about 4 years 
ago, no one seriously proposed moving beyond a subset of C99 addition, 
because of the state of MSVC.


It's 2021 and all the major compilers support C11 (ignoring the optional 
parts).


C11 has support for thread locals, static asserts, and anonymous structs 
and unions. All useful features.


Is there a good reason not to start using C11 now?


Inertia is *a* reason.  C11 would require (and allow!) most (nearly 
all?) people compiling CPython on Windows to upgrade their VS-VC setup. 
 Maybe including some buildbot machines.


Judging from the post for
https://bugs.python.org/issue42380
this requires VS 16.8 with MSVC 14.28, released last November.  Prior 
distributions of VS 2019 had earlier versions.  Last I knew, regular 
people without a dev license cannot get just MSVC.  So we cannot require 
a compiler most people cannot get.  This post otherwise gives additional 
reasons why upgrading would be good.


https://bugs.python.org/issue39952 discusses issues compiling with VS 
2019 last spring (compiler not specified.  The main blocker was tcl/tk.
3.9 uses 8.6.9; 3.10 is using 8.6.10 and I hope this is upgraded to 
3.6.11 before release.


The devguide needs updating, as it says to get VS 2017, while 
https://visualstudio.microsoft.com/ only distributes VS 2019.  It 
appears that C11 would require VS 2019 16.8 or later.


https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Internal_version_numbering 
has a table of MSVC versions, _MSC_VERs, and VS 20xx releases.  Each of 
'VS 2017' and 'VS 2019' are not just one thing but comprise multiple 
releases/versions, just like 'Windows 10'.


--
Terry Jan Reedy
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/PAWQQIGS2HJQ5F7GD5BF2YPOI5EAPKTG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

[Jim J. Jewett]

I see a bunch of similar -- but not quite the same -- use cases.  

I feel like instead of a set, it should be a dict pointing to an object with 
attributes that describe the module in various ways (top-level vs subpackage, 
installed on this machine or not, test module or not, etc).  I'll understand if 
this seems like scope creep, but try not to rule it out as a future 
enhancement.  (e.g., don't promise it will be precisely a set., as opposed to 
the keys of a map.)
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/VZ5NSCXXHRE63477ANQXJHD3U2YDFU3J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

[Jim J. Jewett]

I probably wouldn't think of that on my own, but the need is rare enough that 
having the recipe in the documentation (preferably including the docstring) 
might be enough.  (Or it might not.)
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/BFSS7QXGT3PA6TKSC55JLLUFO5AXUTOC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why aren't we allowing the use of C11?

[Charalampos Stratakis]

- Original Message -
> From: "Mark Shannon" 
> To: "Python Dev" 
> Sent: Thursday, January 28, 2021 5:26:37 PM
> Subject: [Python-Dev] Why aren't we allowing the use of C11?
> 
> Hi everyone,
> 
> PEP 7 says that C code should conform to C89 with a subset of C99 allowed.
> It's 2021 and all the major compilers support C11 (ignoring the optional
> parts).
> 
> C11 has support for thread locals, static asserts, and anonymous structs
> and unions. All useful features.
> 
> Is there a good reason not to start using C11 now?
> 
> Cheers,
> Mark.
> 
> 
> ___
> 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
> https://mail.python.org/archives/list/python-dev@python.org/message/PLXETSQE7PRFXBXN2QY6VNPKUTM6I7OD/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 

Depends what platforms the python core developers are willing to support.

Currently downstream on e.g. RHEL7 we compile versions of CPython under gcc 
4.8.2 which does not support C11.

In addition the manylinux2014 base image is also based on CentOS 7, which 
wouldn't support C11 as well.

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/PCOZN5NHNZ7HIANOKQQ7GQQMV3A3JF72/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PR review request: shutil permission errors

[Winson Luk]

Hi folks,

I've had an open PR for a few weeks that still needs a review:
https://github.com/python/cpython/pull/24001

This PR fixes a shutil.move() bug when permission to a directory is denied.

Thanks,
Winson
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/BTJK6HY3ZH2TBSO243W53PKYKKASJSDB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why aren't we allowing the use of C11?

[Antoine Pitrou]

On Thu, 28 Jan 2021 16:26:37 +
Mark Shannon  wrote:
> Hi everyone,
> 
> PEP 7 says that C code should conform to C89 with a subset of C99 allowed.
> It's 2021 and all the major compilers support C11 (ignoring the optional 
> parts).

I think that CPython is supposed to compile on non-mainstream compilers
too (e.g. vendor-specific compilers on embedded platforms).  While
those are likely to support C99, they may not have caught up with C11.

> C11 has support for thread locals, static asserts, and anonymous structs 
> and unions. All useful features.

Native (fast!) thread locals are definitely useful. The other ones
you're listing are syntactic sugar.

Regards

Antoine.

___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/4RY4U2XSIDAPEEOIYVADCDVOY62V2X5D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why aren't we allowing the use of C11?

[Brett Cannon]

On Thu, Jan 28, 2021 at 8:31 AM Mark Shannon  wrote:

> Hi everyone,
>
> PEP 7 says that C code should conform to C89 with a subset of C99 allowed.
> It's 2021 and all the major compilers support C11 (ignoring the optional
> parts).
>
> C11 has support for thread locals, static asserts, and anonymous structs
> and unions. All useful features.
>
> Is there a good reason not to start using C11 now?
>

Depends on compiler support. I would say that if clang, gcc, and MSVC all
support it then we should consider switching, but if any of them are
lagging we would need to find the common base line (hence why the subset of
C99 when we last talked about this).
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/6QFPY3YHZELZDUULAFLA5I3FR4K3NIBE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Why aren't we allowing the use of C11?

[Mark Shannon]

Hi everyone,

PEP 7 says that C code should conform to C89 with a subset of C99 allowed.
It's 2021 and all the major compilers support C11 (ignoring the optional 
parts).


C11 has support for thread locals, static asserts, and anonymous structs 
and unions. All useful features.


Is there a good reason not to start using C11 now?

Cheers,
Mark.


___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/PLXETSQE7PRFXBXN2QY6VNPKUTM6I7OD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Comments on PEP 558

[Mark Shannon]

Hi Nick,

Regarding `f_locals` PEP 558 states:

"""
Instead of being a direct reference to the internal dynamic snapshot 
used to populate the independent snapshots returned by locals(), 
frame.f_locals will be updated to instead return a dedicated proxy type 
(implemented as a private subclass of the existing 
types.MappingProxyType) that has two internal attributes not exposed as 
part of the Python runtime API:


*mapping: an implicitly updated snapshot of the function local 
variables and closure references, as well as any arbitrary items that 
have been set via the mapping API, even if they don't have storage 
allocated for them on the underlying frame

*frame: the underlying frame that the snapshot is for

"""

This seems rather complex, and consequently fragile.
I fear that this is just going to result in different bugs, rather than 
fixing the bugs it proposes to fix.


Why not just make `f_local` a direct view on the underlying frame?
It would be simpler to understand, more robust, and should perform better.

Cheers,
Mark.
___
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 
https://mail.python.org/archives/list/python-dev@python.org/message/A3UN4DGBCOB45STE6AQBITJFW6UZE43O/
Code of Conduct: http://python.org/psf/codeofconduct/