[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

[Steve Holden]

Full marks to the SC for transparency. That's a healthy sign that the
community acknowledges its disciplinary processes must also be open to
scrutiny, and rather better than dealing with matters in a Star Council.

Kind regards,
Steve


On Fri, Oct 9, 2020 at 12:10 AM Thomas Wouters  wrote:

>
> Stefan did indeed receive, and was notified of, a 1-year ban from core
> development. This action was based on advice from the Conduct WG and our
> own deliberations. We wanted to have a discussion with him before we made
> this public. The SC sent him an email with details (quoted below), three
> weeks ago, CC'ing the Conduct WG. We had a brief back-and-forth last week.
> Unfortunately (and without telling us), Stefan apparently declined to
> address the matter in the way we asked.
>
> For the record, the Steering Council followed the PEP 13 procedure for
> ejecting a core developer (
> https://www.python.org/dev/peps/pep-0013/#ejecting-core-team-members) and
> voted unanimously to eject Stefan, as we told Stefan we would do if he
> chose not to address the concerns we outlined below.
>
> Our original message to Stefan:
> """
> Dear Stefan,
>
> The Python Steering Council and the PSF Conduct Working Group have
> received reports of your ongoing behavior in the Python core developer
> community. The Steering Council agrees with the Conduct Working Group’s
> findings that this behavior is unacceptable. While we appreciate your
> valuable technical contributions to CPython, that does not exempt you from
> the expected standards of behavior and the Code of Conduct.
>
> Specifically, your behavior has displayed:
>
> * Disrespectful, hostile, and unwelcoming communication in tone and content
> * Harassment by needlessly adding people to issues
> * A disregard of the directions and authority of the release manager
>
> Some examples of the problematic behavior include:
>
> * https://bugs.python.org/issue36839#msg344544
> * https://bugs.python.org/issue40874#msg372616
> * https://bugs.python.org/issue40874#msg372917
> * https://bugs.python.org/issue40874#msg372922
> * https://bugs.python.org/issue39542#msg372983
>
> We are also aware that this is not new behavior. We know the PSF Conduct
> WG warned you on April 23, 2020 about your previous violations of the Code
> of Conduct.
>
> As such, we are taking the action of suspending your participation in
> Python's development for 12 months starting today. You will lose access to:
>
> * Python-committers
> * Python-dev
> * Python-ideas
> * Core-mentorship
> * bugs.python.org
> * discuss.python.org
> * The Python organization on GitHub
>
> Along with the 12-month suspension, you will need to meet additional
> conditions in good faith:
>
> * Please acknowledge that you have read and understand the Code of Conduct
> and promise to abide by it going forward
> * You write an apology to your fellow core developers for your actions
> which we will publish on your behalf when announcing your suspension
> * Acknowledge that future reinstatement will include a zero-tolerance
> conduct policy in regards to your future behavior
>
> We offer you 14 days from today to meet these conditions and submit them
> to the Steering Council via email.
>
> If you choose not to satisfy these conditions, the 12-month suspension
> will become a permanent ejection from the Python core developer community
> as per the procedures outlined in PEP 13.  You are then free to go through
> the Python core developer election process also as outlined in PEP 13,
> however the Steering Council will not consider approving any positive
> outcome of that vote until the 12-month suspension has elapsed.
>
> - The Python Steering Council
> """
>
> On behalf of the Steering Council,
> Thomas.
>
> On Wed, Oct 7, 2020 at 11:48 PM Antoine Pitrou  wrote:
>
>>
>> Hello,
>>
>> Apparently, Stefan Krah (core developer and author of the C _decimal
>> module) was silently banned or moderated from posting to python.org
>> mailing-lists.  He asked me to forward the following message:
>>
>>
>>
>> ==
>> Hello,
>>
>> Today I have left the Python organization.  It wasn't an easy decision,
>> after all there are so many amazing people here.
>>
>> My vision of how development should be handled differs from many people
>> who are currently active.  Other projects are more aligned with my
>> preferences, so I prefer to focus my energies elsewhere.
>>
>> Having a shared understanding of what constitutes politeness is
>> important and eliminates all sources of friction that sometimes result
>> in losing one's patience.
>>
>> All the best,
>>
>> Stefan Krah
>>
>> 
>>
>>
>> Best regards
>>
>> Antoine.
>> ___
>> python-committers mailing list -- python-committ...@python.org
>> To unsubscribe send an email to python-committers-le...@python.org
>>

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

[Steven D'Aprano]

On Tue, Oct 13, 2020 at 11:17:33AM +0100, Steve Holden wrote:
> Full marks to the SC for transparency. That's a healthy sign that the
> community acknowledges its disciplinary processes must also be open to
> scrutiny, and rather better than dealing with matters in a Star Council.

The SC didn't say anything until Antoine posted an open letter from 
Stefan to the list.

There is tension between the requirements of openness and privacy, and I 
don't have a good answer for where the balance should be. But it seems 
to me that giving "full marks for transparency" for a decision made 
behind closed doors that we only found about about because one of the 
parties was able to announce their ban via a third party is a remarkably 
soft grade.


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

[Python-Dev] Re: [python-committers] Re: Re: Resignation from Stefan Krah

[Thomas Wouters]

On Tue, Oct 13, 2020 at 1:32 PM Steven D'Aprano  wrote:

> On Tue, Oct 13, 2020 at 11:17:33AM +0100, Steve Holden wrote:
> > Full marks to the SC for transparency. That's a healthy sign that the
> > community acknowledges its disciplinary processes must also be open to
> > scrutiny, and rather better than dealing with matters in a Star Council.
>
> The SC didn't say anything until Antoine posted an open letter from
> Stefan to the list.
>

We didn't say anything because, as I mentioned, we wanted to discuss the
matter with Stefan before we did so. Also, as I mentioned, we had a
back-and-forth with Stefan, and were not aware he had already decided not
to comply with our requests or the Code of Conduct. Had he let us know, we
would've posted pretty much the same information a few days later.

There is tension between the requirements of openness and privacy, and I
> don't have a good answer for where the balance should be. But it seems
> to me that giving "full marks for transparency" for a decision made
> behind closed doors that we only found about about because one of the
> parties was able to announce their ban via a third party is a remarkably
> soft grade.
>

The SC had already discussed how public to be about this, and we were
always going to publish our decision as well as our initial correspondence
to Stefan. Posting his replies is not up to us, and posting our replies to
him without that context feels unfair and inappropriate. However, the
Conduct WG was copied on all the correspondence. This was not
backroom justice.

The SC does have to balance openness and privacy, and also fairness, the
health of the code base, the health of the community, personal feelings of
individual contributors, the perceptions our actions and decisions and
silence create for the individuals involved, the other core developers, and
the Python community at large. We're also still figuring out the process
and standards we want to set for this kind of thing, because it is fairly
new to the core developer community.

-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
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/4FXU6ZZRLZ6274QSEMXWDXZM6XTKH2W5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Shutting down Import-SIG mailing list?

[Eric V. Smith]

Would anyone care if Import-SIG was shut down? It gets a few spam emails 
per day that need to be cleaned up. It hasn't had any real messages for 
a couple of years. I think if the discussions were moved to python-dev 
it wouldn't be a noticeable increase in traffic.


We'd want to keep it around for the archives, but not for new postings. 
I don't know what's involved in that from a technical perspective.


Eric

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

[Python-Dev] Re: Shutting down Import-SIG mailing list?

[Barry Warsaw]

Seems fine to me.  It’s an easy process; just ask postmaster@ and they can shut 
the list down, retaining the archives read-only for posterity.

-Barry

> On Oct 13, 2020, at 09:26, Eric V. Smith  wrote:
> 
> Would anyone care if Import-SIG was shut down? It gets a few spam emails per 
> day that need to be cleaned up. It hasn't had any real messages for a couple 
> of years. I think if the discussions were moved to python-dev it wouldn't be 
> a noticeable increase in traffic.
> 
> We'd want to keep it around for the archives, but not for new postings. I 
> don't know what's involved in that from a technical perspective.
> 
> Eric
> 
> ___
> 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/BDFNTHCKXOV7FQUKUCWUPZ22EV6D7QTC/
> Code of Conduct: http://python.org/psf/codeofconduct/



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

[Python-Dev] Changing Python's string search algorithms

[Tim Peters]

Fredrik Lundh crafted our current string search algorithms, and
they've served us very well.  They're nearly always as fast as
dumbest-possible brute force search, and sometimes much faster. This
was bought with some very cheap one-pass preprocessing of the pattern
(the substring to search _for_), to compute a single integer "skip",
and a single 32-bit bitmask, which can sometimes be used to skip over
areas where it can prove matches are doomed to fail.

Unlike most "fancier than brute" algorithms, it does not build
preprocessing tables of size proportional to the length of the
pattern, or to the size of the alphabet. The extra space is O(1), and
tiny, independent of pattern and alphabet size.

A weakness is that worst-case search time is proportional to the
product of the lengths of the inputs. This can be so for searches that
succeed as well as for those that fail.  This was recently
dramatically illustrated by this bug report:

https://bugs.python.org/issue41972

where a single large string search consumed well over 3 hours of CPU
time before it succeeded. It "should take" a fraction of a second.

While it was news to me, Dennis Sweeney was aware of that other
algorithms requiring only O(1) extra space are now well known with
worst-case linear time. That's really quite remarkable :-) They do
require fancier (but still linear-time) preprocessing, so can't always
be a pure win.

So this message: string (which includes byte) search is an extremely
common operation, across all kinds of applications, so changes here
need as many eyeballs on them as they can get. What's typical? What's
important? What doesn't matter? What about reverse searches ("rfind")?
How can we quantify the acceptable region of tradeoffs?

My guess is that searches for substrings less than 50 characters long
in strings under ten thousand characters are most important for most
apps, but I just pulled that guess out of my butt. I'm also guessing
that searches for multi-million-character substrings (like in the bug
report above) are rare indeed, and that any change sparing them from
quadratic-time disaster would be "way more than good enough".

But I don't know. If you can help, Dennis already has a preliminary PR
implementing one of the newer algorithms, augmented with Fredrik's
unique ideas:

https://github.com/python/cpython/pull/22679

By "help" I don't necessarily mean code review - it could, e.g., be a
huge help to test-drive it on your own critical string-slinging apps.
Faster? Slower? A wash? Wrong answer? Crash?

Due to the natures of the old and new algorithms, neither will be
faster or slower in all cases, the newer one should never be
dramatically slower than the old one, the new one will be
spectacularly faster in some cases, and "in general" it seems
impossible to guess in advance. It depends on the value the fancier
preprocessing can extract from the pattern versus the higher
preprocessing cost, and that in turn depends on details of exactly
what the patterns and texts to be searched 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/ECAZN35JCEE67ZVYHALRXDP4FILGR53Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Shutting down Import-SIG mailing list?

[Brett Cannon]

Shut it down! 😉

On Tue, Oct 13, 2020 at 9:46 AM Barry Warsaw  wrote:

> Seems fine to me.  It’s an easy process; just ask postmaster@ and they
> can shut the list down, retaining the archives read-only for posterity.
>
> -Barry
>
> > On Oct 13, 2020, at 09:26, Eric V. Smith  wrote:
> >
> > Would anyone care if Import-SIG was shut down? It gets a few spam emails
> per day that need to be cleaned up. It hasn't had any real messages for a
> couple of years. I think if the discussions were moved to python-dev it
> wouldn't be a noticeable increase in traffic.
> >
> > We'd want to keep it around for the archives, but not for new postings.
> I don't know what's involved in that from a technical perspective.
> >
> > Eric
> >
> > ___
> > 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/BDFNTHCKXOV7FQUKUCWUPZ22EV6D7QTC/
> > 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/XN2PBDL5JTUVCTH2XJUQTFV7ZYJ3B7XC/
> 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/L2C4NPSSGLRRQY2ZNB564MJ4HO2CHRMU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Shutting down Import-SIG mailing list?

[Eric V. Smith]

Okay, I've sent in the request. Thanks!

Eric

On 10/13/2020 5:50 PM, Brett Cannon wrote:

Shut it down! 😉

On Tue, Oct 13, 2020 at 9:46 AM Barry Warsaw > wrote:


Seems fine to me.  It’s an easy process; just ask postmaster@ and
they can shut the list down, retaining the archives read-only for
posterity.

-Barry

> On Oct 13, 2020, at 09:26, Eric V. Smith mailto:e...@trueblade.com>> wrote:
>
> Would anyone care if Import-SIG was shut down? It gets a few
spam emails per day that need to be cleaned up. It hasn't had any
real messages for a couple of years. I think if the discussions
were moved to python-dev it wouldn't be a noticeable increase in
traffic.
>
> We'd want to keep it around for the archives, but not for new
postings. I don't know what's involved in that from a technical
perspective.
>
> Eric
>
> ___
> 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/BDFNTHCKXOV7FQUKUCWUPZ22EV6D7QTC/
> 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/XN2PBDL5JTUVCTH2XJUQTFV7ZYJ3B7XC/
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/L2C4NPSSGLRRQY2ZNB564MJ4HO2CHRMU/
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/BFUCJWIBN4GBOT24O6LM7E5KVGYFT2ZO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Changing Python's string search algorithms

[Larry Hastings]

On 10/13/20 9:54 AM, Tim Peters wrote:

Due to the natures of the old and new algorithms, neither will be
faster or slower in all cases, the newer one should never be
dramatically slower than the old one, the new one will be
spectacularly faster in some cases, and "in general" it seems
impossible to guess in advance. It depends on the value the fancier
preprocessing can extract from the pattern versus the higher
preprocessing cost, and that in turn depends on details of exactly
what the patterns and texts to be searched are.



My off-the-top-of-my-head reaction: I've always assumed that most string 
searching is tiny.  Like, searching for a < 10 character string in a < 
256 character string.  That's what I'm always doing, at least.  So while 
I'd obviously like to see us address the pathological cases cited--and 
thanks to Dennis Sweeney for the PRs!--I'd hope that it doesn't make 
these small searches any slower.  Your email didn't give me a sense of 
how much additional preprocessing these new algorithms require; the fact 
that they're O(1) space suggests they aren't bad.  But if you do lots 
and lots of dinky searches surely it would add up.


Looking at the PR, I see there's a special case for searching for a 
single character, and then cases for forward-search and reverse-search.  
I was wondering if I'd find a heuristic like "if the string you're 
searching in is < 2k, use the old search algorithm".  Is that worth 
pursuing?  It doesn't seem like the maintenance cost would be that high; 
I don't think anybody has touched that code in years.  (No surprise, the 
Effbot did a good job.)



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

[Python-Dev] Re: Changing Python's string search algorithms

[David Mertz]

I'm sure that the large majority of the string searches I've done are in
Larry's tiny category.

However, I also think that big data needs are increasing, and things like
FASTA files can be enormously large texts that one has good reasons to
search on.

If there is a heuristic switch between algorithms, it seems like it should
threshold on needle, not on haystack. Or possibly some more complex
function of both. But if I understand the two-way approach correctly (which
I probably don't), there's not really much gain for small needle.

On Wed, Oct 14, 2020, 12:09 AM Larry Hastings  wrote:

>
> On 10/13/20 9:54 AM, Tim Peters wrote:
>
> Due to the natures of the old and new algorithms, neither will be
> faster or slower in all cases, the newer one should never be
> dramatically slower than the old one, the new one will be
> spectacularly faster in some cases, and "in general" it seems
> impossible to guess in advance. It depends on the value the fancier
> preprocessing can extract from the pattern versus the higher
> preprocessing cost, and that in turn depends on details of exactly
> what the patterns and texts to be searched are.
>
>
> My off-the-top-of-my-head reaction: I've always assumed that most string
> searching is tiny.  Like, searching for a < 10 character string in a < 256
> character string.  That's what I'm always doing, at least.  So while I'd
> obviously like to see us address the pathological cases cited--and thanks
> to Dennis Sweeney for the PRs!--I'd hope that it doesn't make these small
> searches any slower.  Your email didn't give me a sense of how much
> additional preprocessing these new algorithms require; the fact that
> they're O(1) space suggests they aren't bad.  But if you do lots and lots
> of dinky searches surely it would add up.
>
> Looking at the PR, I see there's a special case for searching for a single
> character, and then cases for forward-search and reverse-search.  I was
> wondering if I'd find a heuristic like "if the string you're searching in
> is < 2k, use the old search algorithm".  Is that worth pursuing?  It
> doesn't seem like the maintenance cost would be that high; I don't think
> anybody has touched that code in years.  (No surprise, the Effbot did a
> good job.)
>
>
> */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/D5GYO2FVUW762RGZ5NMYKYM7PPWWRDIS/
> 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/4IEDAS5QAHF53IV5G3MRWPQAYBIOCWJ5/
Code of Conduct: http://python.org/psf/codeofconduct/