[Python-Dev] Re: A ban from Core Developer spaces.

[Simon Cross]

Hi Thomas,

Could I ask a bit about the thinking behind extending the ban to a
year? A year is a long time and to me feels similar to asking someone
to go away and never come back. It's much longer than is needed to go
away and think about things.

Re the future of python-dev: That sounds a bit ominous. Is the
Steering Council considering removing python-dev? Eek.

Yours sincerely,
Simon Cross
___
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/XRCPPKUSA3ZVC3J2W2QGKLHO6NQHRTND/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

[Abdur-Rahmaan Janhangeer]

Greetings,

What about stating the version on each PEP8 file? Like the docs always
refer to a version of Python
Better, each version of Python can have it's PEP8 guide as language
features added
require style guidelines.

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

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

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

[Marc-Andre Lemburg]

On 26.08.2021 06:07, Christopher Barker wrote:
> I'm working on a PR now. It seems there is little support for keeping the
> python2 content in the docs, so I'm re-writing it as though it was never 
> there.
> If someone wants to add a note about Python 2, of course that can be added 
> later.
> 
> Note that "moving the Python 2 content to a section at the end" is not all 
> that
> straightforward, as it is pretty mixed in with the text at this point.
> 
> But now a question -- the current text reads:
> 
> "Code in the core Python distribution should always use UTF-8"
> 
> and then:
> 
> "In the standard library, non-default encodings should be used only for
> test purposes or when a comment or docstring needs to mention an author
> name that contains non-ASCII characters ..."
> 
> I *think* that's a remnant of the Py2 ASCII encoding days -- but I wanted to
> make sure, a bit later on, it says:
> 
> "The following policy is prescribed for the
> standard library ... In addition, string literals and comments must also be in
> ASCII."

For Python 2 code we mandated ASCII for the stdlib, with some exceptions
using the source code encoding for testing purposes or in case e.g.
Martin von Löwis or Marc-André Lemburg wanted to put his name into the code
without escaping part of it ;-)

Note that Python 2 defaults to ASCII as source code encoding.

With UTF-8 as standard source code encoding, this is no longer
necessary.

So the second quote can be changed to "In the standard library, non-default
source code encodings should be used only for test purposes ...".

> Is that still correct for string literals and comments? And what about 
> docstrings?
> 
> It seems to me that if we really are utf-8, then there is no need for those
> "textual" elements to be ASCII. e.g they can still contain non-ascii 
> characters,
> and escaping those makes things less readable, not more. 
> 
> So I think that section should now read:
> 
> """
> Source File Encoding
> 
> 
> Code in the core Python distribution should always use UTF-8, and should not
> have an encoding declaration.
> 
> In the standard library, non-UTF-8 encodings should be used only for
> test purposes.

I think the above should be limited to Python code. In C or other
source files you may well still need a source code encoding.

> The following policy is prescribed for the standard library (see PEP
> 3131): All identifiers in the Python standard library MUST use
> ASCII-only identifiers, and SHOULD use English words wherever feasible
> (in many cases, abbreviations and technical terms are used which aren't
> English). In comment and docstrings, authors whose names tht are not
> based on the Latin alphabet (latin-1, ISO/IEC 8859-1 character set)
> MUST provide a transliteration of their names in this character set.
> 
> Open source projects with a global audience are encouraged to adopt a
> similar policy.
> """
> 
> But maybe we do want to keep comments, docstrings and literals as ASCII with
> escapes?

No need for the stdlib, since UTF-8 is widely accepted by now
and why should people with non-ASCII names not be able to write
their true name ?

You may have noted that I rarely do... the reason is that in the
past, the accent on the "e" caused me too many problems. Perhaps
one of these days, I'll go back to adding it again :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Aug 26 2021)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/

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

[Python-Dev] Re: PEP 667: Consistent views of namespaces

[Nick Coghlan]

On Mon, 23 Aug 2021 at 13:07, Guido van Rossum  wrote:
> But... I also care about backwards compatibility, and I have a crazy idea for 
> making PyEval_GetLocals() work in a useful manner without compromising the 
> behavior of the f_locals proxy:
>
> - Let's start your idea of using the C-level f_locals field to store the 
> "extra" variables.
> - The Python-level f_locals proxy looks in the actual frame "fast" locals and 
> cells, and uses the C-level f_locals field only for extras
> - However, PyEval_GetLocals() doesn't return the proxy.
> - What PyEval_GetLocals() does: it calls PyEval_FastToLocals(), which makes a 
> pass over the frame locals and adds them to the C-level f_locals field; then 
> it returns that field.
> - So the borrowed reference is owned by the frame, which is the same as 
> currently.
> - The proxy only uses the f_locals field for extra variables. If a variable 
> is deleted in the frame but exists in the f_locals field, the proxy reports 
> it as deleted. (This requires some care but can be done, since we have the 
> mapping from proper variable names to frame locals or cells.)
> - We'll still deprecate PyEval_GetLocals() and PyEval_FastToLocals(), but 
> unless the user turns the deprecation warning into an error, they will work 
> for another few releases. Eventually we'll make PyEval_GetLocals() always 
> return an error (similar to Mark's proposal), since it's in the stable ABI.
> - For PyEval_LocalsToFast() I don't care too much whether we keep it (per 
> Mark's proposal) or make it return an error (per yours).

I don't think any of this is crazy, as it's how the PEP 558 reference
implementation already works for individual keys (aside from only
having a documented deprecation of PyEval_GetLocals(), not a
programmatic one)

You don't need to eliminate the cache (and hence break compatibility
with PyEval_GetLocals()) to ensure it can never get out of sync - you
just have to resync it every time you use it, rather than allowing the
frame API consumer to make that call.

The reason I don't like the proxy semantics proposed in PEP 667 is
because it either makes the common case (analysing a frame from a
tracing function while no application code is running) slower in order
to avoid having to worry about cache consistency when trying to
analyse a running frame, or else we have to write and maintain a whole
lot more fast locals proxy specific code to implement the 5 different
dict iteration APIs.

> PS. The mapping from varname to position should be on the code object, not on 
> the frame. This is how Mark does it (though his implementation would need to 
> be extended to take cells into account).

It's taking cells into account that forces the lookup mapping to be on
the frame: different executions of the same code object may reference
different cell objects.

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

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

[Petr Viktorin]

On 26. 08. 21 9:54, Marc-Andre Lemburg wrote:

On 26.08.2021 06:07, Christopher Barker wrote:

I'm working on a PR now. It seems there is little support for keeping the
python2 content in the docs, so I'm re-writing it as though it was never there.
If someone wants to add a note about Python 2, of course that can be added 
later.

Note that "moving the Python 2 content to a section at the end" is not all that
straightforward, as it is pretty mixed in with the text at this point.

But now a question -- the current text reads:

"Code in the core Python distribution should always use UTF-8"

and then:

"In the standard library, non-default encodings should be used only for
test purposes or when a comment or docstring needs to mention an author
name that contains non-ASCII characters ..."

I *think* that's a remnant of the Py2 ASCII encoding days -- but I wanted to
make sure, a bit later on, it says:

"The following policy is prescribed for the
standard library ... In addition, string literals and comments must also be in
ASCII."


For Python 2 code we mandated ASCII for the stdlib, with some exceptions
using the source code encoding for testing purposes or in case e.g.
Martin von Löwis or Marc-André Lemburg wanted to put his name into the code
without escaping part of it ;-)

Note that Python 2 defaults to ASCII as source code encoding.

With UTF-8 as standard source code encoding, this is no longer
necessary.

So the second quote can be changed to "In the standard library, non-default
source code encodings should be used only for test purposes ...".


Is that still correct for string literals and comments? And what about 
docstrings?

It seems to me that if we really are utf-8, then there is no need for those
"textual" elements to be ASCII. e.g they can still contain non-ascii characters,
and escaping those makes things less readable, not more.

So I think that section should now read:

"""
Source File Encoding


Code in the core Python distribution should always use UTF-8, and should not
have an encoding declaration.

In the standard library, non-UTF-8 encodings should be used only for
test purposes.


I think the above should be limited to Python code. In C or other
source files you may well still need a source code encoding.


The following policy is prescribed for the standard library (see PEP
3131): All identifiers in the Python standard library MUST use
ASCII-only identifiers, and SHOULD use English words wherever feasible
(in many cases, abbreviations and technical terms are used which aren't
English). In comment and docstrings, authors whose names tht are not
based on the Latin alphabet (latin-1, ISO/IEC 8859-1 character set)
MUST provide a transliteration of their names in this character set.

Open source projects with a global audience are encouraged to adopt a
similar policy.
"""

But maybe we do want to keep comments, docstrings and literals as ASCII with
escapes?


No need for the stdlib, since UTF-8 is widely accepted by now
and why should people with non-ASCII names not be able to write
their true name ?

You may have noted that I rarely do... the reason is that in the
past, the accent on the "e" caused me too many problems. Perhaps
one of these days, I'll go back to adding it again :-)


I would drop the weirdly specific "(latin-1, ISO/IEC 8859-1 character 
set)" note, and only keep "based on the Latin alphabet".
The Ł in Łukasz's name is not in latin-1, and I don't think it needs 
different treatment than German or French names. (As opposed to a 
Russian or Chinese name, where an an average English speaker isn't able 
to type an approximation of the name on their keyboard.)


- Peťa Viktorin

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

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

[Stephen J. Turnbull]

Christopher Barker writes:

 > PR here:

Thanks for your prompt efforts!  The notes toward a "near future"
agenda are above and beyond.

 > Interesting some of the cruft in there e.g.  still referring to "new style
 > classes" :-)

I think that should also come out "now", but that's a +1 to the idea,
not a suggestion for you to do it.  Maybe I will if nobody gets to it
before the weekend. :-)

Steve

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

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

[Stephen J. Turnbull]

Marc-Andre Lemburg writes:
 > On 26.08.2021 06:07, Christopher Barker wrote:

 > > But now a question -- the current text reads:
 > > 
 > > "Code in the core Python distribution should always use UTF-8"

 > > "The following policy is prescribed for the standard library
 > > ... In addition, string literals and comments must also be in
 > > ASCII."

Alex Martelli had a long, well-reasoned post about why Python's
"official" language (specifically, identifiers and comments) should be
English despite the strong preference for inclusion of our community.
As long as that remains true, I think we should stick to ASCII as a
lowest common denominator, with an exception for proper names and
testing.

 > With UTF-8 as standard source code encoding, this is no longer
 > necessary.
 > 
 > So the second quote can be changed to "In the standard library, non-default
 > source code encodings should be used only for test purposes ...".

+1

 > I think the above should be limited to Python code. In C or other
 > source files you may well still need a source code encoding.

True, but PEP 8 only does apply to Python.  PEP 7 is the style guide
for C.

 > No need for the stdlib, since UTF-8 is widely accepted by now
 > and why should people with non-ASCII names not be able to write
 > their true name ?

+1

While I proposed above that the stated policy should be "ASCII except
for proper names", I also think "although practicality beats purity".
I think such exceptions will be rare enough that "although
practicality" can be left implicit.

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

[Python-Dev] Re: My apologies to the list

[Antoine Pitrou]

On Wed, 25 Aug 2021 12:22:29 -0700
Brett Cannon  wrote:
> I just wanted to apologize for any angst or noise my replies to Marco
> caused folks. I should have known that correcting Marco on how to address
> me would have triggered an outsized reply (the real intent of that overall
> email was to communicate the process of banning someone to the rest of the
> list so people didn't leave faster than we addressed it; obviously didn't
> work). It appears my judgement was more impaired than I realized while I
> have been sick.
> 
> As such, I have amended my rules for when I *don't* read OSS emails (this
> excludes SC business):
> 
>1. At least one day every weekend (to avoid having my whole week ruined
>by mean people)
>2. Outside of work hours one month out of the year (to prevent burn-out)
>3. On vacation (to unplug appropriately)
>4. While I am ill (to prevent impaired judgement)
> 
> I have actually gone as far as to separate my personal email and OSS/
> python.org email accounts into separate email providers so that I can
> enforce this separation cleanly.

For the record, my personal arrangement for years has been to read most
open source mailing-lists using GMane, on a NNTP reader separate from my
main mail client.  This works fine when I don't want to read open
source-related e-mails :-)

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

[Python-Dev] Re: PEP 667: Consistent views of namespaces

[Nick Coghlan]

On Thu, 26 Aug 2021 at 18:29, Nick Coghlan  wrote:
[Guido wrote]
> > PS. The mapping from varname to position should be on the code object, not 
> > on the frame. This is how Mark does it (though his implementation would 
> > need to be extended to take cells into account).
>
> It's taking cells into account that forces the lookup mapping to be on
> the frame: different executions of the same code object may reference
> different cell objects.

Technically, if you design the fast refs mapping so that even cell
references have to do an indirection through the fast locals array,
then you can put the name-to-fast-locals-offset mapping on the code
object. Mine doesn't do that though, it references the cells directly
instead.

I don't think it makes much difference in practice though, and I don't
like the idea of storing a lazily initialised cache on nominally
immutable code objects.

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

[Python-Dev] Re: PEP 667: Consistent views of namespaces

[Nick Coghlan]

On Tue, 24 Aug 2021 at 01:57, Guido van Rossum  wrote:
> On Mon, Aug 23, 2021 at 8:46 AM Mark Shannon  wrote:
>> Can we avoid describing the C structs in any of these PEPs?
>>
>> It confuses readers having Python attributes and "C-level attributes"
>> (C struct fields?).
>> It also restricts the implementation unnecessarily.
>>
>> (E.g. the PyFrameObject doesn't have a `f_locals` field in 3.11:
>> https://github.com/python/cpython/blob/main/Include/cpython/frameobject.h#L7)
>
>
> I'd be happy to. Nick's PEP still references it (and indeed it is very 
> confusing) and I took it from him. And honestly it would be nice to have a 
> specific short name for it, rather than circumscribing it with "an internal 
> dynamic snapshot stored on the frame object " :-)

https://github.com/python/peps/pull/2060/files switches over to
calling it the "frame value cache" in PEP 558, since that's
essentially what it is on optimised frames (even today).

An unrelated issue that came up while working on that update is
something that affects both PEPs: calling "proxy.clear()" is *super
weird* if we make it work the same way as PyEval_LocalsToFast() works
today. Specifically, it can reach out and clear cells in outer frames,
including the __class__ cell used by zero-arg super(). I can't see
anyone being super upset if we decide to change that and say that
proxy.clear() leaves free variables alone, and only clears local
variables and cells owned by that particular frame.

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

[Python-Dev] Re: PEP 667: Consistent views of namespaces

[Guido van Rossum]

On Thu, Aug 26, 2021 at 1:29 AM Nick Coghlan  wrote:

> On Mon, 23 Aug 2021 at 13:07, Guido van Rossum  wrote:
> > But... I also care about backwards compatibility, and I have a crazy
> idea for making PyEval_GetLocals() work in a useful manner without
> compromising the behavior of the f_locals proxy:
> >
> > [snip]
>
> I don't think any of this is crazy, as it's how the PEP 558 reference
> implementation already works for individual keys
>

I'm not sure I understand what it means to be like my idea "for individual
keys". But I'm not sure I care.

(aside from only
> having a documented deprecation of PyEval_GetLocals(), not a
> programmatic one)
>

Yeah, that's a detail. The deprecation could start out silent.


> You don't need to eliminate the cache (and hence break compatibility
> with PyEval_GetLocals()) to ensure it can never get out of sync - you
> just have to resync it every time you use it, rather than allowing the
> frame API consumer to make that call.
>

I don't think eliminating the cache part is breaking compatibility.


> The reason I don't like the proxy semantics proposed in PEP 667 is
> because it either makes the common case (analysing a frame from a
> tracing function while no application code is running) slower in order
> to avoid having to worry about cache consistency when trying to
> analyse a running frame, or else we have to write and maintain a whole
> lot more fast locals proxy specific code to implement the 5 different
> dict iteration APIs.
>

I just think it's weird to write a long PEP to clean up the semantics and
then replace it with such a complicated solution.


> > PS. The mapping from varname to position should be on the code object,
> not on the frame. This is how Mark does it (though his implementation would
> need to be extended to take cells into account).
>
> It's taking cells into account that forces the lookup mapping to be on
> the frame: different executions of the same code object may reference
> different cell objects.
>

But the frame stores the cells at known positions (after all, the index is
embedded in the bytecode). YOu just need to interpret the mapping a bit
differently.

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

[Python-Dev] Re: PEP 667: Consistent views of namespaces

[Guido van Rossum]

On Thu, Aug 26, 2021 at 2:40 AM Nick Coghlan  wrote:

> [snip]
> An unrelated issue that came up while working on that update is
> something that affects both PEPs: calling "proxy.clear()" is *super
> weird* if we make it work the same way as PyEval_LocalsToFast() works
> today. Specifically, it can reach out and clear cells in outer frames,
> including the __class__ cell used by zero-arg super(). I can't see
> anyone being super upset if we decide to change that and say that
> proxy.clear() leaves free variables alone, and only clears local
> variables and cells owned by that particular frame.
>

That would be another weird corner case. The only exception I would make
would be for __class__, which is only a cell for implementation
convenience. But why would anyone write proxy.clear()? That would be like
deleting all local variables -- what would be the use case for that? I
guess to start over with a computation. But there are better ways to do
that. So let's not worry too much about preventing the user from shooting
themselves in the foot -- surely at the global level, "globals().clear()"
will do weird shit too. :-)

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

[Python-Dev] Re: PEP 667: Consistent views of namespaces

[Guido van Rossum]

On Thu, Aug 26, 2021 at 2:31 AM Nick Coghlan  wrote:

> On Thu, 26 Aug 2021 at 18:29, Nick Coghlan  wrote:
> [Guido wrote]
> > > PS. The mapping from varname to position should be on the code object,
> not on the frame. This is how Mark does it (though his implementation would
> need to be extended to take cells into account).
> >
> > It's taking cells into account that forces the lookup mapping to be on
> > the frame: different executions of the same code object may reference
> > different cell objects.
>
> Technically, if you design the fast refs mapping so that even cell
> references have to do an indirection through the fast locals array,
> then you can put the name-to-fast-locals-offset mapping on the code
> object. Mine doesn't do that though, it references the cells directly
> instead.
>
> I don't think it makes much difference in practice though, and I don't
> like the idea of storing a lazily initialised cache on nominally
> immutable code objects.
>

Only the part visible to the user is immutable. The specializing
interpreter stores all sorts of internal mutable data on there -- and at
least since 3.9 we've had the inline cache stored there. So as long as this
mapping is invisible to the user, please let's put it on the code object --
we have a lot more frame objects than code objects, so saving a pointer on
the frame object and adding it to the code object is advantageous. The cost
of the extra indirection is irrelevant, this is always going to be a slow
interface meant for occasional use in a debugger.

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

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

[Christopher Barker]

Thanks all.

The PR is in process, and I believe it includes everything brought up here.

If you have any more thoughts, please post them there.

-CHB

On Thu, Aug 26, 2021 at 1:54 AM Petr Viktorin  wrote:

> On 26. 08. 21 9:54, Marc-Andre Lemburg wrote:
> > On 26.08.2021 06:07, Christopher Barker wrote:
> >> I'm working on a PR now. It seems there is little support for keeping
> the
> >> python2 content in the docs, so I'm re-writing it as though it was
> never there.
> >> If someone wants to add a note about Python 2, of course that can be
> added later.
> >>
> >> Note that "moving the Python 2 content to a section at the end" is not
> all that
> >> straightforward, as it is pretty mixed in with the text at this point.
> >>
> >> But now a question -- the current text reads:
> >>
> >> "Code in the core Python distribution should always use UTF-8"
> >>
> >> and then:
> >>
> >> "In the standard library, non-default encodings should be used only for
> >> test purposes or when a comment or docstring needs to mention an author
> >> name that contains non-ASCII characters ..."
> >>
> >> I *think* that's a remnant of the Py2 ASCII encoding days -- but I
> wanted to
> >> make sure, a bit later on, it says:
> >>
> >> "The following policy is prescribed for the
> >> standard library ... In addition, string literals and comments must
> also be in
> >> ASCII."
> >
> > For Python 2 code we mandated ASCII for the stdlib, with some exceptions
> > using the source code encoding for testing purposes or in case e.g.
> > Martin von Löwis or Marc-André Lemburg wanted to put his name into the
> code
> > without escaping part of it ;-)
> >
> > Note that Python 2 defaults to ASCII as source code encoding.
> >
> > With UTF-8 as standard source code encoding, this is no longer
> > necessary.
> >
> > So the second quote can be changed to "In the standard library,
> non-default
> > source code encodings should be used only for test purposes ...".
> >
> >> Is that still correct for string literals and comments? And what
> about docstrings?
> >>
> >> It seems to me that if we really are utf-8, then there is no need for
> those
> >> "textual" elements to be ASCII. e.g they can still contain non-ascii
> characters,
> >> and escaping those makes things less readable, not more.
> >>
> >> So I think that section should now read:
> >>
> >> """
> >> Source File Encoding
> >> 
> >>
> >> Code in the core Python distribution should always use UTF-8, and
> should not
> >> have an encoding declaration.
> >>
> >> In the standard library, non-UTF-8 encodings should be used only for
> >> test purposes.
> >
> > I think the above should be limited to Python code. In C or other
> > source files you may well still need a source code encoding.
> >
> >> The following policy is prescribed for the standard library (see PEP
> >> 3131): All identifiers in the Python standard library MUST use
> >> ASCII-only identifiers, and SHOULD use English words wherever feasible
> >> (in many cases, abbreviations and technical terms are used which aren't
> >> English). In comment and docstrings, authors whose names tht are not
> >> based on the Latin alphabet (latin-1, ISO/IEC 8859-1 character set)
> >> MUST provide a transliteration of their names in this character set.
> >>
> >> Open source projects with a global audience are encouraged to adopt a
> >> similar policy.
> >> """
> >>
> >> But maybe we do want to keep comments, docstrings and literals as ASCII
> with
> >> escapes?
> >
> > No need for the stdlib, since UTF-8 is widely accepted by now
> > and why should people with non-ASCII names not be able to write
> > their true name ?
> >
> > You may have noted that I rarely do... the reason is that in the
> > past, the accent on the "e" caused me too many problems. Perhaps
> > one of these days, I'll go back to adding it again :-)
>
> I would drop the weirdly specific "(latin-1, ISO/IEC 8859-1 character
> set)" note, and only keep "based on the Latin alphabet".
> The Ł in Łukasz's name is not in latin-1, and I don't think it needs
> different treatment than German or French names. (As opposed to a
> Russian or Chinese name, where an an average English speaker isn't able
> to type an approximation of the name on their keyboard.)
>
> - Peťa Viktorin
>
> ___
> 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/E6B6INCC5IH5477XF5BGXPC3GPIEER5R/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send 

[Python-Dev] Re: Notes on PEP 8

[Skip Montanaro]

>
> However, it has become a de facto standard for all Python code, and in the
> document itself, there is frequent wording akin to "Identifiers used in the
> standard library must be ASCII compatible ...", and even advice for third
> party libraries.
>
> Which I think is acknowledging that PEP 8 is indeed not only about the
> standard library.
>
> So maybe there should be a bit of text about that at the top.
>

This was my thought as I read the original thread yesterday. There are
tools in the wild which base their style recommendations/enforcements on
PEP 8. Heck, there is even a tool in PyPI called "pep8." While 2.x is out
of support, it *is* still used by many organizations. If nothing else, it
would seem to be useful to branch the pep8 repo ("lastpy2" perhaps?) just
before applying Chris's updates. That would allow enterprising folks to
easily fork and reference back to the last point where the PEP 8 text did
mention Python 2.x.

(This no longer applies to me personally, as I have fully gone over to
Python 3, but at my last job there was still plenty of Python 2 code to be
had.)

Just a thought...

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

[Python-Dev] Re: My apologies to the list

[Skip Montanaro]

>
> For the record, my personal arrangement for years has been to read most
> open source mailing-lists using GMane, on a NNTP reader separate from my
> main mail client.  This works fine when I don't want to read open
> source-related e-mails :-)
>

And if you're not an NNTP person (anymore), filters in Gmail (and I assume
other mail readers/apps) allow you to sequester mails into separate folders
which you can ignore if you like.

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

[Python-Dev] Re: [Steering-council] Re: A ban from Core Developer spaces.

[Brett Cannon]

On Thu, Aug 26, 2021 at 12:10 AM Simon Cross 
wrote:

> Hi Thomas,
>
> Could I ask a bit about the thinking behind extending the ban to a
> year?


It wouldn't view it as an extension as much as Ethan took immediate action
while the SC was simultaneously working on what to do about the situation.
So they were separate actions and the SC's action happened to be longer and
broader.


> A year is a long time and to me feels similar to asking someone
> to go away and never come back. It's much longer than is needed to go
> away and think about things.
>

Marco was given a previous 3 month suspension on discuss.python.org (as
Marco himself pointed out on the email thread in question). Speaking for
myself, Marco was given a chance previously to take some time to think
about how he approached communicating and it didn't seem to be enough time.

I will also note that Marco publicly asked me to ban him for life in one of
his emails in the thread as well.


>
> Re the future of python-dev: That sounds a bit ominous. Is the
> Steering Council considering removing python-dev? Eek.
>

I am purposefully not replying to this as I don't want to spark a
conversation on this topic in this email thread.

-Brett


>
> Yours sincerely,
> Simon Cross
> ___
> Steering-council mailing list -- steering-coun...@python.org
> To unsubscribe send an email to steering-council-le...@python.org
> https://mail.python.org/mailman3/lists/steering-council.python.org/
> Member address: br...@python.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/LGK7H7LJEA3EKDRZ7TSCIIREUK5VYTQR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Notes on PEP 8

[Brett Cannon]

On Wed, Aug 25, 2021 at 10:38 PM Christopher Barker 
wrote:

> As I was working on removing Python 2 references from PEP 8 (PR:
> https://github.com/python/peps/pull/2059), I tried to avoid any other
> copy-editing.
>
> However, I noted a few things that maybe could use some attention:
>
> stdlib or not?
> ##
>
> Right at the top, it says:
>
> "This document gives coding conventions for the Python code comprising the
> standard library in the main Python distribution."
>
> However, it has become a de facto standard for all Python code, and in the
> document itself, there is frequent wording akin to "Identifiers used in the
> standard library must be ASCII compatible ...", and even advice for third
> party libraries.
>
> Which I think is acknowledging that PEP 8 is indeed not only about the
> standard library.
>
> So maybe there should be a bit of text about that at the top.
>

I wouldn't be opposed to that personally. I think a lot of people just
think PEP 8 is a doc for the community when it is actually for Python
itself and it happens to be very convenient for others to use. Although we
obviously understand that people do use it in situations outside of the
stdlib, so I don't think saying, "if you're going to use this in a way we
didn't mean it to, here's some advice".

-Brett


>
> Name Mangling
> #
>
> In the sections on "Method Names and Instance Variables" and "Designing
> for Inheritance", the discussion of name mangling (leading __ names) is a
> bit redundant. Nothing incorrect or misleading -- just a copy-editing issue.
>
> Maybe I'll do a copy-editing PR 
>
> -CHB
>
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> 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/WCTRPSZSC2XO4NG5CKMOBLK2P7UUY7RE/
> 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/X2R6TKU3HO6DGCJCCSXEVW6VB5O6KPDT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Notes on PEP 8

[Chris Angelico]

On Fri, Aug 27, 2021 at 3:02 AM Skip Montanaro  wrote:
>>
>> However, it has become a de facto standard for all Python code, and in the 
>> document itself, there is frequent wording akin to "Identifiers used in the 
>> standard library must be ASCII compatible ...", and even advice for third 
>> party libraries.
>>
>> Which I think is acknowledging that PEP 8 is indeed not only about the 
>> standard library.
>>
>> So maybe there should be a bit of text about that at the top.
>
>
> This was my thought as I read the original thread yesterday. There are tools 
> in the wild which base their style recommendations/enforcements on PEP 8. 
> Heck, there is even a tool in PyPI called "pep8." While 2.x is out of 
> support, it *is* still used by many organizations. If nothing else, it would 
> seem to be useful to branch the pep8 repo ("lastpy2" perhaps?) just before 
> applying Chris's updates. That would allow enterprising folks to easily fork 
> and reference back to the last point where the PEP 8 text did mention Python 
> 2.x.
>

The tool isn't part of this change. Third-party tools which happen to
follow PEP 8 to some greater or lesser degree are going to have to
make their own choices about what happens. The document itself is free
to change.

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

[Python-Dev] Re: [Steering-council] Re: A ban from Core Developer spaces.

[Simon Cross]

Hi Brett,

Thank you for the quick reply.

On Thu, Aug 26, 2021 at 8:58 PM Brett Cannon  wrote:
> Marco was given a previous 3 month suspension on discuss.python.org (as Marco 
> himself pointed out on the email thread in question). Speaking for myself, 
> Marco was given a chance previously to take some time to think about how he 
> approached communicating and it didn't seem to be enough time.

"A three month suspension was tried and didn't result in a better
outcome" seems a solid reason for issuing a different suspension this
time. Thank you for the background & explanation.

> I will also note that Marco publicly asked me to ban him for life in one of 
> his emails in the thread as well.

It seemed clear to me that Marco's statement was intended as a
criticism of the banning process, or perhaps a request to be martyred.
Either way, not really a good reason to impose or not impose a
particular ban.

Re python-dev's future:

> I am purposefully not replying to this as I don't want to spark a 
> conversation on this topic in this email thread.

Fair enough -- one topic per thread. However, as someone who engages
primarily through python-dev, I would like some sort of more open
debate on it's future on the list before anything drastic happens to
it.

/me heads off to sleep.

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

[Python-Dev] Re: PEP 667: Consistent views of namespaces

[Nick Coghlan]

On Fri, 27 Aug 2021, 2:33 am Guido van Rossum,  wrote:

> On Thu, Aug 26, 2021 at 2:31 AM Nick Coghlan  wrote:
>
>> On Thu, 26 Aug 2021 at 18:29, Nick Coghlan  wrote:
>> [Guido wrote]
>> > > PS. The mapping from varname to position should be on the code
>> object, not on the frame. This is how Mark does it (though his
>> implementation would need to be extended to take cells into account).
>> >
>> > It's taking cells into account that forces the lookup mapping to be on
>> > the frame: different executions of the same code object may reference
>> > different cell objects.
>>
>> Technically, if you design the fast refs mapping so that even cell
>> references have to do an indirection through the fast locals array,
>> then you can put the name-to-fast-locals-offset mapping on the code
>> object. Mine doesn't do that though, it references the cells directly
>> instead.
>>
>> I don't think it makes much difference in practice though, and I don't
>> like the idea of storing a lazily initialised cache on nominally
>> immutable code objects.
>>
>
> Only the part visible to the user is immutable. The specializing
> interpreter stores all sorts of internal mutable data on there -- and at
> least since 3.9 we've had the inline cache stored there. So as long as this
> mapping is invisible to the user, please let's put it on the code object --
> we have a lot more frame objects than code objects, so saving a pointer on
> the frame object and adding it to the code object is advantageous. The cost
> of the extra indirection is irrelevant, this is always going to be a slow
> interface meant for occasional use in a debugger.
>

OK, that makes sense - I'll add a todo note to the implementation PR.

For the main topic of PEP 667 (reducing the cache consistency question to
purely a matter of PyEval_GetLocals() compatibility), I think I can see a
way to make the extra code complexity of the 5 new custom accessory types
(iterator, reversed iterator, keys set, values multi set, items set)
worthwhile to my mind: write the latter 3 in terms of the first two and the
generic mapping API, and expose them for use in other custom mapping
implementations (either directly in the types module, or as optional C
accelerators for the collections module). (I wouldn't make exposing them
part of the PEP, I'd just aim to write them so only the forward and reverse
iterators were specific to proxy objects)

With that done, popitem() is trivial to rewrite to depend on the iterator
code instead of the cache.

That would leave len() and value comparison as the only proxy operations
that don't adhere to the expected algorithmic complexity of mapping
objects, and writing up the comparison with PEP 667 finally convinced me
that those are quirks that API users could manage more easily than 558's
current lazy caching semantics.

I'd still keep the full value cache under the hood, though, as I don't see
enough benefit in getting rid of it when the cost is an unnecessary API
compatibility break.

However, the PEP 667 write up and your own points *have* persuaded me that
the extra C code needed to offer assuredly consistent views through all the
proxy mapping methods is worthwhile.

That will then leave the proposed C APIs as the only differences between
the PEPs - the Python level behaviour will be aligned with Mark's proposal.

Cheers,
Nick.

P.S. I don't want to rely on Python code anywhere in the fast locals proxy
implementation, as that could cause weird interactions if a trace hook is
enabled during the initial start up of the interpreter and tries to trace
the proxy implementation code.



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

[Python-Dev] Re: Notes on PEP 8

[Barry Warsaw]

On Aug 26, 2021, at 12:05, Brett Cannon  wrote:
> 
> I wouldn't be opposed to that personally. I think a lot of people just think 
> PEP 8 is a doc for the community when it is actually for Python itself and it 
> happens to be very convenient for others to use. Although we obviously 
> understand that people do use it in situations outside of the stdlib, so I 
> don't think saying, "if you're going to use this in a way we didn't mean it 
> to, here's some advice”.

It might be helpful to acknowledge that PEP 8 *in practice* often serves as the 
base style guide for code outside the stdlib.  IME it rarely serves as *the* 
style guide though, since there usually are explicit deviations to adhere to 
organization or personal taste.  I’ve also found some tools that maybe take PEP 
8 a little too far, like it’s the law, or have different interpretations of the 
PEP 8 recommendations.  The other thing to keep in mind is that, at least 
historically, we’ve rejected changes to PEP 8 to keep some deliberate ambiguity 
in the recommendations.  PEP 8 can’t and shouldn’t be so detailed as to not 
give Python programmers some leeway to determine what’s right for them, their 
teams, or their projects.

Cheers,
-Barry





signature.asc
Description: Message signed with OpenPGP
___
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/GJYUXTLXYM4OBHHGHNXWPJYTHFZGQBLP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 667: Consistent views of namespaces

[Guido van Rossum]

On Thu, Aug 26, 2021 at 5:29 PM Nick Coghlan  wrote:

> [snip]
> For the main topic of PEP 667 (reducing the cache consistency question to
> purely a matter of PyEval_GetLocals() compatibility), I think I can see a
> way to make the extra code complexity of the 5 new custom accessory types
> (iterator, reversed iterator, keys set, values multi set, items set)
> worthwhile to my mind: write the latter 3 in terms of the first two and the
> generic mapping API, and expose them for use in other custom mapping
> implementations (either directly in the types module, or as optional C
> accelerators for the collections module). (I wouldn't make exposing them
> part of the PEP, I'd just aim to write them so only the forward and reverse
> iterators were specific to proxy objects)
>

Yes, that makes sense. I wouldn't sweat it though.


> With that done, popitem() is trivial to rewrite to depend on the iterator
> code instead of the cache.
>
> That would leave len() and value comparison as the only proxy operations
> that don't adhere to the expected algorithmic complexity of mapping
> objects, and writing up the comparison with PEP 667 finally convinced me
> that those are quirks that API users could manage more easily than 558's
> current lazy caching semantics.
>

That's what we've been saying. :-)

I'd still keep the full value cache under the hood, though, as I don't see
> enough benefit in getting rid of it when the cost is an unnecessary API
> compatibility break.
>

That's for PyEval_GetLocals(), right? Mark updated PEP 667 to also keep a
reference to whatever it returned on the frame. So then I think the two
PEPs have converged.


> However, the PEP 667 write up and your own points *have* persuaded me that
> the extra C code needed to offer assuredly consistent views through all the
> proxy mapping methods is worthwhile.
>

Right.

That will then leave the proposed C APIs as the only differences between
> the PEPs - the Python level behaviour will be aligned with Mark's proposal.
>

Yeah, I presume that the *new* APIs proposed are just a matter of a little
bikeshedding, nothing major.


> Cheers,
> Nick.
>

Thanks for your flexibility!


> P.S. I don't want to rely on Python code anywhere in the fast locals proxy
> implementation, as that could cause weird interactions if a trace hook is
> enabled during the initial start up of the interpreter and tries to trace
> the proxy implementation code.
>

Of course. But it would still be interesting to have pseudo-code in your
PEP showing the semantics you intend to implement -- that way we can
compare 558 and 667 more easily.

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