[Python-Dev] Re: Bug report

[Kyle Stanley]

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).

Best Regards,
-- 
--Kyle R. Stanley, Python Core Developer (what is a core dev?
)
*Pronouns: they/them **(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/WAJM6PFMX2DXOGPEC6I2QATAUT2GNJXC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: RFC for PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors

[Ethan Furman via Python-Dev]

On 7/21/21 5:33 AM, Nick Coghlan wrote:

> I don't have any substantive comments on what you're proposing (aside
> from "Yes, that sounds reasonable to me"), so my comments below are
> just some minor suggested clarifications for the PEP text.

Thanks, PEP updated.

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

[Python-Dev] Re: PEP 558: Defined semantics for locals()

[Joao S. O. Bueno]

Hi Nick - as for:
> Keys that are not defined as local or closure variables on the underlying
frame are still written to the f_locals cache on optimised frames.

This means current behavior will be kept, right? the f_locals cache is
persistent across descending calls
from the current frame?

To be more specific - I have a somewhat toy package (though I've used it on
serious code on occasion prior
to having the "walrus" operator) which allows one to keep an anonymous
stack on the current running frame
and operate on it with "push", "pop", "dup", etc... calls. The stack is a
list referenced in a "hidden" variable
created on the first call to "push".
>From my reading that would still work, right?


On Sun, 18 Jul 2021 at 03:01, Nick Coghlan  wrote:

> Hi folks,
>
> It's been a long time coming, but I've finally made enough progress on
> the reference implementation that I think it's time to ask Nathaniel
> to pronounce on the current iteration of PEP 558 (Defined semantics
> for locals()).
>
> The rendered version is up at
> https://www.python.org/dev/peps/pep-0558/, and I've included the plain
> text version below.
>
> For those that are reading the PEP for the first time, the gist is:
>
> * standardise on Python 3.10 behaviour *except* that locals() at
> function scope returns a fresh snapshot every time instead of a
> reference to the frame level state cache
> * make the Python level frame.f_locals on optimised frames a
> write-through proxy that keeps both the real fast locals storage and
> the C level f_locals state cache up to date
> * add new C APIs that allow C code to explicitly request the semantics
> the client code actually wants ("behave like the Python locals()
> builtin", "always make a copy", "always provide a read-only view")
> * soft-deprecate the legacy PyEval_GetLocals() API (while ensuring it
> still works)
> * use the new features to significantly improve the performance of
> code execution tracing hooks implemented in Python
>
> For those that remember reading older versions of the PEP, the key
> changes relative to the last discourse thread (back in late 2019/early
> 2020) are:[...]
>
___
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/LF7FOZFS6FI2757HPDDHV5DYBG4G3SWT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Bug report

[Patrick Reader]

This is because 3.10 is still in pre-release, which means the /3/ URL still 
uses the documentation for 3.9, which obviously does not contain a whatsnew 
page for the upcoming version. The correct URL is currently 
https://docs.python.org/3.10/whatsnew/3.10.html but the redirect should still 
probably be fixed

Patrick

On 21/07/2021 13:15, Nguyen Do Minh Duc 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?
>
> Sincerely
>
> xXPartOfMeXx
>
> ___
> 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/VOWYBW2OWVMHRDYNSIMHZSPNG7ATMCLU/
> 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/VGJKF5MMZTRYPXNUJ6JDMU4SCBUDAZFO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Bug report

[Nguyen Do Minh Duc]

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?

Sincerely

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

[Python-Dev] Re: PEP 558: Defined semantics for locals()

[Guido van Rossum]

Sounds good. Thanks!

On Wed, Jul 21, 2021 at 5:19 AM Nick Coghlan  wrote:

> On Mon, 19 Jul 2021 at 21:32, Petr Viktorin  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
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> 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/QLPJWPVNDZ3ODMS275VDW4M2UW6PUW5N/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


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

[Python-Dev] Re: RFC for PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors

[Nick Coghlan]

Thanks for this Ethan.

I don't have any substantive comments on what you're proposing (aside
from "Yes, that sounds reasonable to me"), so my comments below are
just some minor suggested clarifications for the PEP text.

On Wed, 21 Jul 2021 at 14:17, Ethan Furman  wrote:
> IntEnum, IntFlag, and StrEnum should be as close to a drop-in replacement of
> existing integer and string constants as is possible.  Towards that goal, the
> str() output of each should be its inherent value; i.e.::
>
>  >>> Color.RED
>  
>  >>> str(Color.RED)
>  1
>  >>> format(Color.RED)
>  '1'

The suggested output here looks like the second line was
`print(Color.RED)` rather than `str(Color.RED)` (since the quotes on
the string are missing).

The text should also state explicitly that `Color` in the example is
an `IntEnum` subclass.

> Note that format() already produces the correct output, only str() needs
> updating.

This paragraph may be a little clearer if it said "... correct output
in Python 3.10, only str() ...".


> Using the above enumerations, the following table shows the old and new
> behavior, while the last shows the final result:

Since the enum output changes were reverted for 3.10, replacing "3.9"
with "3.10" in the tables may make it a little clearer that there was
no intermediate step between 3.9 and 3.11.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/YF5QU23VJRVJINKXEPXHUI35WH5ZLDIF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 558: Defined semantics for locals()

[Nick Coghlan]

On Mon, 19 Jul 2021 at 21:32, Petr Viktorin  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

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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/QLPJWPVNDZ3ODMS275VDW4M2UW6PUW5N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 558: Defined semantics for locals()

[Nick Coghlan]

On Wed, 21 Jul 2021, 10:30 am Guido van Rossum,  wrote:

> On Tue, Jul 20, 2021 at 4:52 AM Nick Coghlan  wrote:
> [Petr]
>
>> >> int PyLocals_GetReturnBehavior();  # better name?
>>
> [Nick]
>
>> > We've used "Kind" for similar APIs elsewhere, so calling this API
>> "PyLocals_Kind()" would make sense to me.
>> >
>> > However, there's a potential point of confusion here, as there's
>> already an implementation level "locals kind" that the runtime uses. This
>> public kind is related to that internal kind, but they're not the same.
>>
>> [Nick, responding to himself]
>
>> Now that I'm on my actual computer rather than my phone, some further
>> details on the new-in-Python-3.11 internal-only API that already
>> refers to "locals kind":
>>
>> Typedef name: _PyLocals_Kind
>> Value flags: CO_FAST_LOCAL, CO_FAST_CELL, CO_FAST_FREE (with more
>> expected to be defined in the future)
>> Frame local variable lookup API: _PyLocals_GetKind, _PyLocals_SetKind
>>
>> Rather than relating to the frame as a whole, these flags relate to
>> individual variables on the frame. CO_FAST_FREE can even be used on
>> non-optimised frames, since classes defined inside functions have
>> access to variables defined in the function scope.
>>
>> Due to this, I'd definitely want to hear Mark Shannon's opinion before
>> we went down the path of using "PyLocals_Kind" (or variations on that
>> theme) as a public API, since we'd need to rename the internal APIs to
>> avoid confusion if we did that.
>>
>> I don't think a rename would be too bad though - since the existing
>> flags relate to individual local variables, my suggestion would be to
>> use `LocalVar` instead of `Locals`, giving the revised enum name
>> _PyLocalVar_Kind, and _PyLocalVar_GetKind and _PyLocalVar_SetKind as
>> the access and update methods. (There are only 27 hits on the
>> _PyLocals prefix across the current 3.11 code base, all relating to
>> this internal API)
>>
>
> My name isn't Mark Shannon, but I was involved in picking this name. I
> think it's fine to rename this concept to "local variable kind" and spell
> the typedef as you propose, though I think I'd like it slightly better to
> switch from "Locals" to "Local", and to put the underscore after that:
> `_PyLocal_VarKind`, `_PyLocal_GetVarKind()`, `_PyLocal_SetVarKind()`. (The
> API for this is very much in flux -- we'll settle by 3.11 beta 1 though. I
> expect we'll also have some Python-level public (but unstable) API to
> access these flags, so people can play around with this stuff.)
>

Thanks - that works for me. I'll update the draft implementation
accordingly, and add this API tweak to the pending changes for the PEP (I
won't merge any changes until Nathaniel has had a chance to comment on the
posted version, though)

Cheers,
Nick.


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