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
>
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
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
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
>>
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
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
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.
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
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
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
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
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,
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
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.
>
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
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
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
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
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
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
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
>
> 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
>
> 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),
23 matches
Mail list logo
