[Python-Dev] Re: enum in the stable ABI (Was: PEP 558: Defined semantics for locals)

2021-07-23 Thread Devin Jeanpierre
On Fri, Jul 23, 2021 at 7:40 AM Petr Viktorin  wrote:
[snip]
> On 21. 07. 21 14:18, Nick Coghlan wrote:

> [snip]
> > Please don't put the enum in the stable ABI. If we would add another
> > value and then an older extension would receive it, we'd get
> undefined
> > behavior.
> >
> >
>
> After researching a bit more, I see that casting unknown values to enum
> is only undefined/unspecified behavior in C++. But we do support C++
> extensions, and so I'll try to get enums out of the stable ABI.
>
> (In both C & C++, the size of an `enum` is implementation-defined.
> That's unlikely to be a problem in practice, but one more point against
> enum.)
>

I can't speak much for C, but for C++ this is fine I think? enums have the
same range of values as their "underlying type" (see e.g.
[basic.fundamental]  and
[dcl.enum] ). Aside from representation,
[expr.static.cast]  explicitly
allows conversion when in-range: "the value is unchanged if the original
value is within the range of the enumeration values". (Note if you click
the link -- "fixed underlying type" refers to a form of enum which doesn't
exist in C; the C-like enums are the ones without a fixed underlying type.)

And as Larry points out, you can force the range of values to be as large
as you want by specifying a large enumerator.

However, the standard is not meant for reading by us mere mortals, so I
usually use cppreference, which has this to say at
https://en.cppreference.com/w/cpp/language/enum :

Values of integer, floating-point, and enumeration types can be converted
> by static_cast 
> or explicit cast
> , to any
> enumeration type. If the underlying type is not fixed and the source value
> is out of range, [the result is unspecified (until C++17) | the behavior
> is undefined (since C++17)]. [...] Note that the value after such
> conversion may not necessarily equal any of the named enumerators defined
> for the enumeration.


-- Devin
___
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/IRRUAJWZVPH6XXOP2NJKOH2UHEGM2JDH/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: enum in the stable ABI (Was: PEP 558: Defined semantics for locals)

2021-07-23 Thread Nick Coghlan
On Sat, 24 Jul 2021, 9:37 am Larry Hastings,  wrote:

>
> On 7/23/21 7:38 AM, Petr Viktorin wrote:
>
> (In both C & C++, the size of an `enum` is implementation-defined. That's
> unlikely to be a problem in practice, but one more point against enum.)
>
>
> True, but there's always the old trick of sticking in a value that forces
> it to be at least 32-bit:
>
> typedef enum {
> INVALID = 0,
> RED = 1,
> BLUE = 2,
> GREEN = 3,
>
> UNUSED = 1073741824
> } color_t;
>
>
> */arry*
>

My current inclination is to define the enum as "_PyLocals_KindValues", and
then typedef "PyLocals_Kind" itself as an int. The frame API would then
return the former, while the stable query API would return the latter.

However, I'll make a full survey of the enums currently in the stable ABI
before making a decision, as there may be an existing approach that I like
better.

I do agree Petr's right to be cautious about this, as compilers can get up
to some arcane shenanigans in the presence of formally undefined code:
https://queue.acm.org/detail.cfm?id=3468263

The fact that the behaviour in this case is likely to be well-defined at
the time of compilation would protect us from the weirder potential
outcomes, but it still makes sense for us to define the query API in a way
that tells both compilers and humans not to assume that the values returned
by the current version of Python are the only values that will ever be
returned by all future versions of Python.

Cheers,
Nick.


> ___
> 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/3C5ANX5ONLE6OWZ4N24ENDOX2H3R5UC2/
> 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/RNR6AVDT45PEKPY6TLQGF7ZPAB4NRBCD/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Bug report

2021-07-23 Thread Nick Coghlan
On Fri, 23 Jul 2021, 2:22 am Ee Durbin,  wrote:

> On Wed, Jul 21, 2021 at 7:45 PM Kyle Stanley  wrote:
>
>> On Wed, Jul 21, 2021 at 12:19 PM Nguyen Do Minh Duc <
>> gd.minhduc1...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> When I find what's new in 3.10 beta in
>>> https://docs.python.org/whatsnew/3.10.html
>>> It redirected me to https://docs.python.org/3/whatsnew/3.10.html which
>>> shows 404 error not found nginx. Can you fix this?
>>>
>>
>> Thanks for the report! I don't believe the code and/or config for the web
>> server hosting docs.python.org is a public repo (may be mistaken), so
>> I'll CC the director of infrastructure, Ee W. Durbin. I suspect they will
>> know who to forward this to (or be able to fix it).
>>
>
> Config that’s responsible for redirects lives at
>
> https://github.com/python/psf-salt/blob/master/salt/docs/config/nginx.docs-backend.conf
> if anyone is able to take a look before I’m able to ascertain what’s going
> on.
>
> Do we know what the expected behavior is?
>

The expected behaviour is what is currently happening:
https://github.com/python/psf-salt/blob/6cdc61db0868d81514fde95ab5dfe11914e49754/salt/docs/config/nginx.docs-backend.conf#L19

3.10 is still in its pre-release cycle, so pages that don't exist in the
3.9 documentation (like the 3.10 What's New doc) need a "dev" or "3.10" in
their URL to be reachable.

Only when 3.10 is released and becomes the default version for the Python 3
docs would we expect the OP's link to work.

That said, if nginx config allows for rewrites that only happen when a 404
is about to be emitted otherwise, it would make sense to have "/3/" URLs
fall back to "/dev/" URLs before giving up and emitting the 404.

Cheers,
Nick.


___
> 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/3M4KRVNWXSC56VJK2E7O45DX3UJLBYM5/
> 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/6IXBHB5V6ROSOZPWDJN3CZ6WHCUX44TW/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: enum in the stable ABI (Was: PEP 558: Defined semantics for locals)

2021-07-23 Thread Larry Hastings


On 7/23/21 7:38 AM, Petr Viktorin wrote:
(In both C & C++, the size of an `enum` is implementation-defined. 
That's unlikely to be a problem in practice, but one more point 
against enum.)



True, but there's always the old trick of sticking in a value that 
forces it to be at least 32-bit:


   typedef enum {
    INVALID = 0,
    RED = 1,
    BLUE = 2,
    GREEN = 3,

    UNUSED = 1073741824
   } color_t;


//arry/

___
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/3C5ANX5ONLE6OWZ4N24ENDOX2H3R5UC2/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Summary of Python tracker Issues

2021-07-23 Thread Python tracker


ACTIVITY SUMMARY (2021-07-16 - 2021-07-23)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7420 (+17)
  closed 49041 (+54)
  total  56461 (+71)

Open issues with patches: 2951 


Issues opened (52)
==

#44656: Dangerous mismatch between MAXPATHLEN and MAX_PATH on Windows
https://bugs.python.org/issue44656  opened by izbyshev

#44657: instancemethod_call should use PyInstanceMethod_GET_FUNCTION m
https://bugs.python.org/issue44657  opened by colesbury

#44658: No ValueError for duplicate key value in mapping patern when l
https://bugs.python.org/issue44658  opened by jack__d

#44660: email.feedparser Module Lacks Support for Section 3.5 of RFC 6
https://bugs.python.org/issue44660  opened by f18a14c09s

#44662: Add ability to annotate types.Union
https://bugs.python.org/issue44662  opened by uriyyo

#44663: Possible bug in datetime utc
https://bugs.python.org/issue44663  opened by gabhcosta

#44664: builtins.chr and the 'c' format flag raise different errors
https://bugs.python.org/issue44664  opened by bup

#44665: asyncio.create_task() documentation should mention user needs 
https://bugs.python.org/issue44665  opened by bernat

#44666: compileall.compile_file fails when sys.stdout is redirected to
https://bugs.python.org/issue44666  opened by stefanhoelzl

#44667: tokenize.py emits spurious NEWLINE if file ends on a comment w
https://bugs.python.org/issue44667  opened by mdartiailh

#44668: More differences in instance and subclass checks between typin
https://bugs.python.org/issue44668  opened by serhiy.storchaka

#44669: TypeError: 'type' object is not subscriptable
https://bugs.python.org/issue44669  opened by michal.dziczkowski

#44671: Create a built-in yaml module
https://bugs.python.org/issue44671  opened by jarpri08

#44673: Embedded Python - local directories in pythonXX._pth
https://bugs.python.org/issue44673  opened by emve

#44674: dataclasses should allow frozendict default value
https://bugs.python.org/issue44674  opened by gianni

#44675: Cross-platform issues with private methods and multiprocessing
https://bugs.python.org/issue44675  opened by ymerej

#44677: CSV sniffing falsely detects space as a delimiter
https://bugs.python.org/issue44677  opened by pt12lol

#44678: Seperate error message for discontinuous padding in binascii.a
https://bugs.python.org/issue44678  opened by idan22moral

#44679: unittest.mock.sentinel documentation typo
https://bugs.python.org/issue44679  opened by gaydayav

#44680: Reference cycles from a WeakKeyDictionary value to its key are
https://bugs.python.org/issue44680  opened by andersk

#44682: Pdb commands allows to add commands to invalid breakpoint
https://bugs.python.org/issue44682  opened by andrei.avk

#44684: Docs for mock.call
https://bugs.python.org/issue44684  opened by guettli

#44685: Email package issue with Outlook msg files
https://bugs.python.org/issue44685  opened by heghine

#44686: use pkgutil.resolve_name in unittest.mock
https://bugs.python.org/issue44686  opened by graingert

#44687: io.BufferedReader:peek() closes underlying file, breaking peek
https://bugs.python.org/issue44687  opened by liquidpele

#44688: [sqlite3] Remove ASCII limitation from sqlite3.Connection.crea
https://bugs.python.org/issue44688  opened by erlendaasland

#44689: MacOS: Python binaries not portable between Catalina and Big S
https://bugs.python.org/issue44689  opened by bergkvist

#44690: Adopt binacii.a2b_base64's strict mode in base64.b64decode
https://bugs.python.org/issue44690  opened by idan22moral

#44693: Unclear definition of the "__future__" module in Docs
https://bugs.python.org/issue44693  opened by StevenHsuYL

#44694: Message from BytesParser cannot be flattened immediately
https://bugs.python.org/issue44694  opened by vitas1

#44695: asdict use deep copy to dataclass instances
https://bugs.python.org/issue44695  opened by Itayazolay

#44697: Memory leak when asyncio.open_connection raise
https://bugs.python.org/issue44697  opened by seer

#44698: Undefined behaviour in Objects/complexobject.c's complex_pow
https://bugs.python.org/issue44698  opened by twouters

#44699: Simple regex appears to take exponential time in length of inp
https://bugs.python.org/issue44699  opened by brezniczky

#44701: Create a @deprecated decorator (annotation)
https://bugs.python.org/issue44701  opened by Leonardofreua

#44702: Fix weakref doc
https://bugs.python.org/issue44702  opened by Prometheus3375

#44705: Support Windows file open modes for `open` built-in function
https://bugs.python.org/issue44705  opened by lukedeller1

#44707: runtime error: applying zero offset to null pointer in Objects
https://bugs.python.org/issue44707  opened by thatiparthy

#44709: [3.7] Popen Control Characters in stdout affect shell session
https://bugs.python.org/issue44709  opened by San

#44711: Optimize type check in pipes.p

[Python-Dev] enum in the stable ABI (Was: PEP 558: Defined semantics for locals)

2021-07-23 Thread Petr Viktorin

On 22. 07. 21 12:41, Nick Coghlan wrote:



On Thu, 22 Jul 2021, 6:01 pm Petr Viktorin, > wrote:




On 21. 07. 21 14:18, Nick Coghlan wrote:
 > On Mon, 19 Jul 2021 at 21:32, Petr Viktorin mailto:encu...@gmail.com>> wrote:
 >> The proposal assumes that in the future, ``PyLocals_Get``, and thus
 >> ``locals()``, will never gain another kind of return value, however
 >> unlikely that is.
 >> AFAICS, code that uses this will usually check for a single
special case
 >> and fall back (or error) for the other(s), so I think it'd be
reasonable
 >> to make this an "enum" with two values. e.g.:
 >>
 >> int PyLocals_GetReturnBehavior();  # better name?
 >> #define PyLocals_DIRECT_REFERENCE 0
 >> #define PyLocals_SHALLOW_COPY 1
 >
 > After looking at PyUnicode_Kind, PySendResult, and other already
 > public enums for inspiration, my proposed spelling is as follows:
 >
 > 
 > typedef enum {
 >      PyLocals_UNDEFINED = -1;
 >      PyLocals_DIRECT_REFERENCE = 0,
 >      PyLocals_SHALLOW_COPY = 1
 > } PyLocals_Kind;
 >
 > PyLocals_Kind PyLocals_GetKind(void);
 > PyLocals_Kind PyFrame_GetLocalsKind(PyFrameObject *);
 > 
 >
 > The PyLocals_UNDEFINED case comes from PyLocals_GetKind() needing an
 > error value to return when the query API is called with no active
 > thread state.
 >
 > I've updated the draft reference implementation to use this API, and
 > added the associated PEP changes to the review PR at
 > https://github.com/python/peps/pull/2038/files


Please don't put the enum in the stable ABI. If we would add another
value and then an older extension would receive it, we'd get undefined
behavior.


Hmm, I was copying an example that is already in the stable ABI 
(PySendResult).


I think it's new in 3.10, though, so it should still be possible to fix 
that.


After researching a bit more, I see that casting unknown values to enum 
is only undefined/unspecified behavior in C++. But we do support C++ 
extensions, and so I'll try to get enums out of the stable ABI.


(In both C & C++, the size of an `enum` is implementation-defined. 
That's unlikely to be a problem in practice, but one more point against 
enum.)



NB. I don't have access to the actual standards; feel free to check this 
if you do!

___
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/MRNSY5BWP7LBOA2MXHADSHM3WDNODI5O/
Code of Conduct: http://python.org/psf/codeofconduct/