[Python-Dev] Re: IRC #python-dev channel is now on Libera Chat (bye bye Freenode)

[Steven D'Aprano]

On Thu, May 27, 2021 at 11:18:16AM +1200, Greg Ewing wrote:
> >On Wed, May 26, 2021 at 8:55 AM Ammar Askar  >> wrote:
> >
> >most
> >recently if your topic mentioned libera.chat, the new freenode owners
> >will take it over, ban anyone from chatting in it and change the topic
> 
> My goodness. Let's hope the new owners eventually learn that behaving
> like spoilt 7-year-olds is no way to run a successful company.

Apple prohibits apps from mentioning competing platforms. If Apple 
doesn't count as a successful company, I'm not sure what is.

https://androidcommunity.com/some-apps-in-apples-app-store-rejected-for-mentioning-pebble-support-20150424/

Reddit likewise shadowbans posts that mention at least one, possibly 
more, competing forums. And let's not forget the tech industry, lead by 
Apple, Google and Amazon, getting Parler banned under the excuse 
that the January 6th Capital rioters planned violent attacks on 
Parler, when the truth was that the great majority of planning took 
place on Facebook, Instagram and YouTube.

https://www.forbes.com/sites/thomasbrewster/2021/02/07/sheryl-sandberg-downplayed-facebooks-role-in-the-capitol-hill-siege-justice-department-files-tell-a-very-different-story/?sh=7a1ab35d10b3

Companies frequently, and often successfully, silence their competition. 
It might be reprehensible but it's hardly a barrier to success.


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

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

[Brett Cannon]

I've gotten some questions privately about my responses on this topic and
so I wanted to take the opportunity to clarify a couple of things.

First, I totally support the technical work that Guido, Eric, and Mark have
planned. This whole line of questions is not meant to act as stop energy
for this specific project in any way. I apologize if that didn't come
across in my emails.

Second, this is totally a process question from my POV. The answer in the
end might be that a PEP is not even necessary and it's more about sharing a
design doc, or maybe it's a PEP as Standards Track, or maybe an
Informational PEP is the right thing in the end; I simply don't know and
hence my questions on this topic. I'm just trying to figure out how we as a
group want to discuss and handle projects of this size going forward in
case getting corporate support to start tackling these bigger projects
becomes more normal.

On Wed, May 26, 2021 at 1:00 PM Brett Cannon  wrote:

>
>
> On Wed, May 26, 2021 at 4:23 AM Mark Shannon  wrote:
>
>> Hi Brett,
>>
>> On 26/05/2021 3:56 am, Brett Cannon wrote:
>> >
>> >
>> > On Tue., May 25, 2021, 12:58 Guido van Rossum, > > > wrote:
>> >
>> > On Tue, May 25, 2021 at 12:34 PM Brett Cannon > > > wrote:
>> >
>> >
>> > I personally think it should be a Standards Track PEP. This PEP
>> > isn't documenting some detail like PEP 13 or some release
>> > schedule, but is instead proposing a rather major change to the
>> > interpreter which a lot of us will need to understand in order
>> > to support the code (and I do realize the entire area of "what
>> > requires a PEP and what doesn't" is very hazy).
>> >
>> >
>> > Does that also mean you think the design should be completely hashed
>> > out and approved by the SC ahead of merging the implementation?
>> > Given the amount of work, that would run into another issue -- many
>> > of the details of the design can't be fixed until the implementation
>> > has proceeded, and we'd end up with a long-living fork of the
>> > implementation followed by a giant merge. My preference (and my
>> > promise at the Language Summit) is to avoid mega-PRs and instead
>> > work on this incrementally.
>> >
>> > Now, we've done similar things before (for example, the pattern
>> > matching implementation was a long-living branch), but the
>> > difference is that for pattern matching, the implementation followed
>> > the design, whereas for the changes to the bytecode interpreter that
>> > we're undertaking here, much of the architecture will be designed as
>> > the implementation proceeds, based on what we learn during the
>> > implementation.
>> >
>> > Or do you think the "Standards Track" PEP should just codify general
>> > agreement that we're going to implement a specializing adaptive
>> > interpreter, with the level of detail that's currently in the PEP?
>> >
>> >
>> > This. Having this as an informational PEP that's already marked as
>> > Active seems off somehow to me. I guess it feels more "we're doing
>> this"
>> > (which I know isn't intended) rather than "this is our plan, what do
>> you
>> > all think? All good?"
>>
>> The PEP is a "we're doing this" document. Maybe it shouldn't be a PEP at
>> all? I've changed its status to "draft" for now.
>>
>
> Thanks!
>
>
>>
>> I want to document what we are doing as publicly as possible and a PEP
>> seems like a good way to do that.
>>
>> I also want to reiterate that the PEP doesn't propose changing the
>> language, libraries, Python API or C API in any way. It is just
>> information about how we plan to speed up the interpreter.
>>
>
> Sure, but it isn't a minor change either; if it was then you would have
> done it already. 😉 This is an architectural shift in how the interpreter
> works, so it isn't a minor thing.
>
>
>> >
>> >
>> > I don't recall other standards track PEPs that don't also spell out
>> > the specification of the proposal in detail.
>> >
>> >
>> > I also am not aware of a PEP that's proposed restructuring the eval
>> loop
>> > like this either. 😉 I'm personally fine with the detail and saying
>> > details may shift as things move forward and lessons are learned based
>> > on the scope and updating the PEP accordingly. But that's just me and I
>> > don't know if others agree (hence the reason I'm suggesting this be
>> > Standards Track).
>>
>> Suppose it were a standards PEP, what would that mean if it were rejected?
>>
>
> Then we don't do it.
>
>
>> Rejection of a PEP is a choice in favor of an alternative, but what is
>> that alternative?
>>
>
> The status quo.
>
>
>> You can't simply say the "status quo" as that would implicitly prevent
>> any development at all on the bytecode interpreter.
>>
>
> I don't think that logic holds; if *your *approach happened to be
> rejected in terms of how to change how the interpreter wor

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

[Victor Stinner]

Hi,

The gilectomy was mentioned earlier in the thread. This project was
created by a core dev who had the permission to push directly his work
into the development branch, but it was done on a work.

Another optimization project example was my experimental "FAT Python"
project. The main idea was to specialize functions with some
assumptions, and check these assumptions at the function entry. I
started in a fork and then wrote 3 PEPs to propose to merge the main
changes into Python development branch:

* PEP 509 -- Add a private version to dict
* PEP 510 -- Specialize functions with guards
* PEP 511 -- API for code transformers

The PEP 509 was accepted since it could be used for other
optimizations: Python now uses the dictionary version to optimize
LOAD_GLOBAL.

The two other PEPs were rejected. Even if I was very disappointed when
they were rejected, it seems like it was a wize choice since I was
never able to make Python significantly faster (like 2x faster). It
was only 10-20% faster on some micro-benchmarks. I also had the
permission to push directly, and I think that it was nice to confront
my design and ideas to the community.

I also understand that optimizing Python is really hard and it
requires a lot of preparation work. It's hard to sell the preparation
work since it only introduces regressions and noise without any
concrete speedup. All of this work is required to implement the real
interesting optimization. Moreover, few people are earger to review a
Python fork with deep and large changes in Python internals. The work
must be re-done step by step with more "atomic" (small) changes to
have a readable Git history.

The Instagram team behind the Cinder project may be interested to
review Mark's work before it's merged into Python development branch.
A design PEP would be more convenient than reviewing an concrete
implementation.

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

[Python-Dev] name for new Enum decorator

[Ethan Furman]

Greetings!

The Flag type in the enum module has had some improvements, but I find it necessary to move one of those improvements 
into a decorator instead, and I'm having a hard time thinking up a name.


What is the behavior?  Well, a name in a flag type can be either canonical (it represents one thing), or aliased (it 
represents two or more things).  To use Color as an example:


class Color(Flag):
RED = 1# 0001
GREEN = 2  # 0010
BLUE = 4   # 0100
PURPLE = RED | BLUE# 0101
WHITE = RED | GREEN | BLUE # 0111

The flags RED, GREEN, and BLUE are all canonical, while PURPLE and WHITE are aliases for certain flag combinations.  But 
what if we have something like:


class Color(Flag):
RED = 1# 0001
BLUE = 4   # 0100
WHITE = 7  # 0111

As you see, WHITE is an "alias" for a value that does not exist in the Flag (0010, or 2).  That seems like it's probably 
an error.  But what about this?


class FlagWithMasks(IntFlag):
DEFAULT = 0x0

FIRST_MASK = 0xF
FIRST_ROUND = 0x0
FIRST_CEIL = 0x1
FIRST_TRUNC = 0x2

SECOND_MASK = 0xF0
SECOND_RECALC = 0x00
SECOND_NO_RECALC = 0x10

THIRD_MASK = 0xF00
THIRD_DISCARD = 0x000
THIRD_KEEP = 0x100

Here we have three flags (FIRST_MASK, SECOND_MASK, THIRD_MASK) that are aliasing values that don't exist, but it seems 
intentional and not an error.


So, like the enum.unique decorator that can be used when duplicate names should be an error, I'm adding a new decorator 
to verify that a Flag has no missing aliased values that can be used when the programmer thinks it's appropriate... but 
I have no idea what to call it.


Any nominations?

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

[Python-Dev] Re: name for new Enum decorator

[Jonathan Goble]

On Thu, May 27, 2021 at 11:34 PM Ethan Furman  wrote:

> So, like the enum.unique decorator that can be used when duplicate names
> should be an error, I'm adding a new decorator
> to verify that a Flag has no missing aliased values that can be used when
> the programmer thinks it's appropriate... but
> I have no idea what to call it.
>
> Any nominations?
>

@prevent_missing_values?
@check_all_values_exist?
@sanity_check?

Just some midnight thoughts from me.
___
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/YSZBK7ZDQ6MP3SPZY67HO34QOU3STHBQ/
Code of Conduct: http://python.org/psf/codeofconduct/