[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

[Glenn Linderman]

On 7/2/2019 12:56 PM, Terry Reedy wrote:

On 7/2/2019 12:16 AM, Glenn Linderman wrote:

On 7/1/2019 8:28 PM, Terry Reedy wrote:


I did not read much of the thread, but the proposal is to wrap a 
near-trivial expression (2 operations) or replace a current method 
call with a method call than is more or less the same len as what it 
replaces.


>>> 'prefix_more_suffix'[len('prefix'):]  # if know s begins with p
'_more_suffix'

>>> 'prefix_more_suffix'.replace('prefix', '')
'_more_suffix'

>>> 'prefix_more_suffix'.strip_pre('prefix')  # proposed


Your example isn't equivalent: .replace would replace multiple 
instances of prefix, not necessarily at the beginning. The .strip_pre 
(however spelled) would strip one instance, only if it is at the 
beginning.


I left out the slightly longer regex which does exactly that.

>>> re.sub('^prefix', '', 'prefix_more_suffix')
'_more_suffix'
>>> re.sub('^prefix', '', 'Xprefix_more_suffix')
'Xprefix_more_suffix'

or with minor variation, deletes only suffixes.

>>> re.sub('suffix$', '', 'prefix_more_suffix')
'prefix_more_'

Are these special cases, which can be easily generalized to match more 
than one string, and to replace rather than delete, special enough to 
merit a new method each.  This remains to be demonstrated.


The more I thought about this, the more I think a more functional 
goal is a variation of replace that works only on one end or the 
other, rather than a variation of strip. I outlined that in a 
different branch in this thread.


To me, a new parameter to str.replace would have a lower bar to 
acceptance.


two extra boolean parameters has been suggested; alternatives would be a 
single string or flag parameter. replace already accepts a count 
parameter for maximum number of replacements from the start. One could 
extend that to pass a negative count parameter to mean how many from the 
end, which is similar to negative indexing for slices, which wouldn't 
even need an extra parameter, but also wouldn't restrict it to the exact 
front or end.  Together with one extra boolean to declare the 
replacement must be at the very front (for positive count) or very end 
(for negative count), would also allow removal of repeated prefixes or 
suffixes, although I'm not sure that would be a common case:


text = 'Hello Hello Hello Is this Fred?'
text.replace('Hello ', '', 2, True )

would leave one Hello.

Of course it wouldn't have that effect with a non-empty replacement:

text.replace('Hello ', 'Greetings', 2, True )

would leave two Hello.


The other documentation issue I noticed is that the 2nd and 3rd 
parameters to startswith and endswith are not fully documented. 
Typically startswith and endswitch are in the logic prior to the 
strip/replace operation, and typically only use the first parameter, 
but looking at their documentation as part of this discussion, I 
found it lacking.


File an issue?  Preferably with a suggested change.

To suggest a change, I'd first have run lots of experiments to figure 
out what they do... and what the edge conditions are... or, I'd have to 
read the implementation to figure it out. I've never used anything but 
the first parameter and reading the documentation for the other two 
raises more questions than it answers.  But I'll open the issue, maybe 
someone can quickly answer the questions I raise, but the terseness of 
the description of the parameters leaves a lot of room for speculation.


https://bugs.python.org/issue37490
___
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/JNSATSGJG37LLDWIO5AKBU5DSTBKUHXF/

[Python-Dev] [RELEASE] Python 3.7.4rc2 is now available for testing

[Ned Deily]

Python 3.7.4rc2 is now available. 3.7.4rc2 is the second release
preview of the next maintenance release of Python 3.7, the latest
feature release of Python. Assuming no further critical problems are
found prior to 2019-07-08, no code changes are planned between this
release candidate and the final release. The release candidate is
intended to give you the opportunity to test the new security and bug
fixes in 3.7.4. Because of the small number of changes between rc1,
the original release preview, and rc2, we are planning on an
abbreviated exposure cycle so we can get the final release to you as
soon as possible. We strongly encourage you to test your projects and
report issues found to https://bugs.python.org/ as soon as possible.
Please keep in mind that this is a preview release and, thus, is not
recommended for production environments.

You can find the release files, a link to the changelog, and more
information here:

https://www.python.org/downloads/release/python-374rc2/

--
  Ned Deily
  n...@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/OFNLRRAT4WIILKBKCNMI2YQ5HSS5N4ES/

[Python-Dev] [RELEASE] Python 3.6.9 security-fix release is now available

[Ned Deily]

Python 3.6.9 is now available. 3.6.9 is the first security-only-fix
release of Python 3.6. Python 3.6 has now entered the security fix
phase of its life cycle. Only security-related issues are accepted and
addressed during this phase. We plan to provide security fixes for
Python 3.6 as needed through 2021, five years following its initial
release. Security fix releases are produced periodically as needed and
only provided in source code form; binary installers are not provided.

We urge you to consider upgrading to the latest release of Python
3.7, the current fully-supported version.

You can find the release files, a link to the changelog, and more
information here:

https://www.python.org/downloads/release/python-369/
https://www.python.org/downloads/

--
  Ned Deily
  n...@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/2RNGWKRLOI5DJYNAJ75B2WH6VOHTMPSE/

[Python-Dev] Re: PEP 581 has been updated with "Downsides of GitHub" section

[Greg Ewing]

Gregory P. Smith wrote:
But a /separate/ issue is that we /should not try/ to cater to people 
who cannot use a modern up to date self updating trustworthy web browser.


If developers really want people to keep their systems secure, they
need to provide updates that *only* fix security issues, and don't
also change a bunch of other things to the point that the new
version won't work on the same system that the old one did.

--
Greg
___
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/O7RYRNRNZIO7GQALHMM7WCTO7OPIYIZJ/

[Python-Dev] Re: Annoying user on GitHub

[Brett Cannon]

GitHub actually provides a bot for this: https://probot.github.io/apps/lock/ . 
If people want to turn this one we can discuss it at 
https://github.com/python/core-workflow/.
___
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/J6THTAO4CTYZK5UTUCKVLV6XIZ7HOSES/

[Python-Dev] Re: PEP 581 has been updated with "Downsides of GitHub" section

[Gregory P. Smith]

On Mon, Jul 1, 2019 at 9:01 AM Steven D'Aprano  wrote:

> On Sat, Jun 29, 2019 at 10:26:04AM -0500, Skip Montanaro wrote:
> > > You have missed at least one: the minimum technology requirement for
> > > using Github is a lot more stringent than for Roundup. Github's minimum
> > > system requirements are higher, and it doesn't degrade as well, so
> > > moving to Github will make it much harder for those who are using older
> > > technology. If not exclude them altogether.
> >
> > Is that Git or GitHub? If the latter, more JavaScript bits or something
> else?
>
> I'm referring to Github. I expect it is probably Javascript. Clicking
> hyperlinks is fine, but things like buttons with dropdown menus, the
> hamburger icon, the Clone/Download button etc do nothing when I click on
> them.
>
> For what it's worth, I'm not using an ad blocker but I am using a
> moderately old Firefox.
>

Document this kind of thing, that is fine.

But a *separate* issue is that we *should not try* to cater to people who
cannot use a modern up to date self updating trustworthy web browser.

A browser more than a few months old is a security risk; *we* are not going
to enforce that concept, but we shouldn't go out of our way to support it
either.
The same goes for anyone who disables javascript or uses a content
modifying plugins or extensions in their browser.  Problems caused by that
have a simple solution, it isn't on us to untangle.

-gps
___
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/NNRODVYN2DRDJ66TETY7JB5ZAHA4CUIK/

[Python-Dev] Re: Change SystemError to NOT inherit from Exception

[Brett Cannon]

There's two issues with this idea.

One, backwards-compatibility, especially since the only good way to handle this 
would be to modify the exception-handling code to recognize this specific case 
during deprecation.

But two, this would be a semantic shift of what classes directly inherit from 
`BaseException`. If you look at 
https://docs.python.org/3/library/exceptions.html#exception-hierarchy you will 
see that the only classes that inherit directly are ones that represent control 
flow. Adding `SystemError` to that list would make it a unique error condition 
that doesn't inherit from `Exception`.
___
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/3VRHKHDIFO74Z6CLUX4G7VES6XJHLOTT/

[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

[Steve Holden]

On Tue, Jul 2, 2019 at 4:24 PM  wrote:

> It seems to me that the desired behavior here is closest to
> 'str.replace()' out of all the options discussed, just with the constraint
> of being limited to either the start or the end of the string. (Thus the
> .lreplace() and .rreplace() option suggested by Glenn.)
>
> The minimal change (which actually also is pretty general?) I think would
> be to add 'only_start' and 'only_end' keyword arguments to str.replace(),
> both defaulting to False. If, e.g., 'only_start' is passed True, each
> repetition of 'old' at the start of 's' is replaced by 'new', with the
> number of replacements limited by the existing optional 'count'. Similar
> behavior for 'only_end'=True.  Probably best to raise a ValueError(?) if
> both 'only_start'=True and 'only_end'=True?
>
> Taking swapping a file extension as an example of a particular
> transformation of interest, it would be achieved with something like
> s.replace(".htm", ".html", only_end=True).
>
> -Brian


Just to add my own touch of colour to the bike shed, I'd suggest that more
naturally-usable names for those arguments, should they be added, would be
at_start and at_end.

regards
 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/IVIUHDKO7WWORNFNUQDGDVVH2LYUKLXI/

[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

[Terry Reedy]

On 7/2/2019 12:16 AM, Glenn Linderman wrote:

On 7/1/2019 8:28 PM, Terry Reedy wrote:


I did not read much of the thread, but the proposal is to wrap a 
near-trivial expression (2 operations) or replace a current method 
call with a method call than is more or less the same len as what it 
replaces.


>>> 'prefix_more_suffix'[len('prefix'):]  # if know s begins with p
'_more_suffix'

>>> 'prefix_more_suffix'.replace('prefix', '')
'_more_suffix'

>>> 'prefix_more_suffix'.strip_pre('prefix')  # proposed


Your example isn't equivalent: .replace would replace multiple instances 
of prefix, not necessarily at the beginning. The .strip_pre (however 
spelled) would strip one instance, only if it is at the beginning.


I left out the slightly longer regex which does exactly that.

>>> re.sub('^prefix', '', 'prefix_more_suffix')
'_more_suffix'
>>> re.sub('^prefix', '', 'Xprefix_more_suffix')
'Xprefix_more_suffix'

or with minor variation, deletes only suffixes.

>>> re.sub('suffix$', '', 'prefix_more_suffix')
'prefix_more_'

Are these special cases, which can be easily generalized to match more 
than one string, and to replace rather than delete, special enough to 
merit a new method each.  This remains to be demonstrated.


The more I thought about this, the more I think a more functional goal 
is a variation of replace that works only on one end or the other, 
rather than a variation of strip. I outlined that in a different branch 
in this thread.


To me, a new parameter to str.replace would have a lower bar to acceptance.

The other documentation issue I noticed is that the 2nd and 3rd 
parameters to startswith and endswith are not fully documented. 
Typically startswith and endswitch are in the logic prior to the 
strip/replace operation, and typically only use the first parameter, but 
looking at their documentation as part of this discussion, I found it 
lacking.


File an issue?  Preferably with a suggested change.

--
Terry Jan Reedy

___
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/DR6US5L6I2NCUSXH5VTWC7DGQHEZ65PE/

[Python-Dev] Re: Annoying user on GitHub

[Terry Reedy]

On 7/2/2019 12:09 PM, Steve Dower wrote:

Maybe there's also a way to automatically lock conversations on commits 
and old issues?


I occasionally add comments both to closed issues and merged commits. 
For commits, 'Thank you' or 'See # for followup' are examples


Obviously we can lock them manually, but simply disallowing conversation 
in places where we don't want to have to pay attention to will force 
people towards the places where we are paying attention.


--
Terry Jan Reedy
___
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/5URHUWYJ7DCFPIUNFESFWNEUIOTU3AOH/

[Python-Dev] Re: Annoying user on GitHub

[Ivan Pozdeev via Python-Dev]

On 02.07.2019 19:09, Steve Dower wrote:

On 02Jul2019 0840, Mariatta wrote:
I've used the "Report abuse" feature on GitHub for such situations. Most of the time I see the user suspended, and the associated 
comments deleted.

Our GitHub admins can delete comments too.

On Tue, Jul 2, 2019, 1:42 AM Victor Stinner mailto:vstin...@redhat.com>> wrote:

    Hi,

    Sometimes, I get an email notification about strange comments
    (unrelated
    or make no sense) on commits made 6 months ago if not longer.
    Usually, I
    go to the user profile page and I click on "Block or report user":
    "Report abuse". I'm not sure what happens in this case. I never checks
    if these strange comments are removed by GitHub.


Maybe there's also a way to automatically lock conversations on commits and old 
issues?


https://github.com/apps/lock

But I'm solidary with Victor that unless this is a sizeable problem, it would 
do more harm than good.

Obviously we can lock them manually, but simply disallowing conversation in places where we don't want to have to pay attention to will 
force people towards the places where we are paying attention.


Cheers,
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/X5TYHVAORL72RFZLYIPFZR72FS2OLIRI/


--
Regards,
Ivan
___
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/AFUAX5W67PB4OKXMQWOPFSOLZAWPY5CB/

[Python-Dev] Re: PEP 581 has been updated with "Downsides of GitHub" section

[Lysandros Nikolaou]

Note that there also is a Github CLI at https://github.com/node-gh/gh#issues,
which brings Github Issues to the terminal and which I use regularly. It,
of course, has dependencies and a learning curve of its own, but it might
be a viable alternative for those, whose browsers do not support the Github
web interface. Just mentioning it, so that it's out there.

Of course, I'm sure there are other alternatives as well.

On Mon, Jul 1, 2019 at 6:03 PM Steven D'Aprano  wrote:

> On Sat, Jun 29, 2019 at 10:26:04AM -0500, Skip Montanaro wrote:
> > > You have missed at least one: the minimum technology requirement for
> > > using Github is a lot more stringent than for Roundup. Github's minimum
> > > system requirements are higher, and it doesn't degrade as well, so
> > > moving to Github will make it much harder for those who are using older
> > > technology. If not exclude them altogether.
> >
> > Is that Git or GitHub? If the latter, more JavaScript bits or something
> else?
>
> I'm referring to Github. I expect it is probably Javascript. Clicking
> hyperlinks is fine, but things like buttons with dropdown menus, the
> hamburger icon, the Clone/Download button etc do nothing when I click on
> them.
>
> For what it's worth, I'm not using an ad blocker but I am using a
> moderately old Firefox.
>
>
> --
> Steven
> ___
> 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/U5GPRST2G5JOPFFFRKP3RHBFOLV4CGDQ/
>
___
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/DVTFWFGKKS6ZD3FPAEEN2CZBTAKIKUBU/

[Python-Dev] Re: PEP 581 has been updated with "Downsides of GitHub" section

[Mariatta]

If loading GitHub website is a technical problem, then it is a pre-existing
condition not caused by PEP 581.

On Sat, Jun 29, 2019, 12:47 AM Steven D'Aprano  wrote:

> You have missed at least one: the minimum technology requirement for
> using Github is a lot more stringent than for Roundup. Github's minimum
> system requirements are higher, and it doesn't degrade as well, so
> moving to Github will make it much harder for those who are using older
> technology. If not exclude them altogether.
>
> I'd submit a PR for this except, well, see above...
>
>
> ᐧ
___
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/IOZECILKHOZIIA5E3SC2SGSNRK6DGOUK/

[Python-Dev] Re: Annoying user on GitHub

[Victor Stinner]

It happens very rarely, like less than 10 spam commits per year. Maybe 
less than 5, I don't know. I don't think it's worth it to bother with 
locking conversations.


Victor

Le 02/07/2019 à 18:09, Steve Dower a écrit :

On 02Jul2019 0840, Mariatta wrote:
I've used the "Report abuse" feature on GitHub for such situations. 
Most of the time I see the user suspended, and the associated comments 
deleted.

Our GitHub admins can delete comments too.

On Tue, Jul 2, 2019, 1:42 AM Victor Stinner > wrote:


    Hi,

    Sometimes, I get an email notification about strange comments
    (unrelated
    or make no sense) on commits made 6 months ago if not longer.
    Usually, I
    go to the user profile page and I click on "Block or report user":
    "Report abuse". I'm not sure what happens in this case. I never 
checks

    if these strange comments are removed by GitHub.


Maybe there's also a way to automatically lock conversations on commits 
and old issues?


Obviously we can lock them manually, but simply disallowing conversation 
in places where we don't want to have to pay attention to will force 
people towards the places where we are paying attention.


Cheers,
Steve


--
Night gathers, and now my watch begins. It shall not end until my death.
___
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/X53KJU4ZYQATKFC5ACTJPFCQFF6MWWHZ/

[Python-Dev] Re: Annoying user on GitHub

[C. Titus Brown]

> On Jul 2, 2019, at 9:09 AM, Steve Dower  wrote:
> 
> On 02Jul2019 0840, Mariatta wrote:
>> I've used the "Report abuse" feature on GitHub for such situations. Most of 
>> the time I see the user suspended, and the associated comments deleted.
>> Our GitHub admins can delete comments too.
>> On Tue, Jul 2, 2019, 1:42 AM Victor Stinner > > wrote:
>>Hi,
>>Sometimes, I get an email notification about strange comments
>>(unrelated
>>or make no sense) on commits made 6 months ago if not longer.
>>Usually, I
>>go to the user profile page and I click on "Block or report user":
>>"Report abuse". I'm not sure what happens in this case. I never checks
>>if these strange comments are removed by GitHub.
> 
> Maybe there's also a way to automatically lock conversations on commits and 
> old issues?
> 
> Obviously we can lock them manually, but simply disallowing conversation in 
> places where we don't want to have to pay attention to will force people 
> towards the places where we are paying attention.

Hi Steve et al.,

I think this is eminently do-able via the GitHub API. Happy to put together a 
script if people are interested. Is there a repo being used for github magic?

(I did a lot of this on a recent project - 
http://ivory.idyll.org/blog/2019-github-project-reporting.html - the PyGithub 
package is excellent.)

best,
—titus

___
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/KGJ4DXRDZ2F5FBXGNOUYE5BKA55UV7RX/

[Python-Dev] Re: Annoying user on GitHub

[Steve Dower]

On 02Jul2019 0840, Mariatta wrote:
I've used the "Report abuse" feature on GitHub for such situations. Most 
of the time I see the user suspended, and the associated comments deleted.

Our GitHub admins can delete comments too.

On Tue, Jul 2, 2019, 1:42 AM Victor Stinner > wrote:


Hi,

Sometimes, I get an email notification about strange comments
(unrelated
or make no sense) on commits made 6 months ago if not longer.
Usually, I
go to the user profile page and I click on "Block or report user":
"Report abuse". I'm not sure what happens in this case. I never checks
if these strange comments are removed by GitHub.


Maybe there's also a way to automatically lock conversations on commits 
and old issues?


Obviously we can lock them manually, but simply disallowing conversation 
in places where we don't want to have to pay attention to will force 
people towards the places where we are paying attention.


Cheers,
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/X5TYHVAORL72RFZLYIPFZR72FS2OLIRI/

[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

[Steve Dower]

On 02Jul2019 0707, brian.sk...@gmail.com wrote:

Taking swapping a file extension as an example of a particular transformation of interest, it would 
be achieved with something like s.replace(".htm", ".html", only_end=True).


Please don't use string functions for file system paths, they are not 
reliable cross-platform.


Use pathlib or (if you need pre-3.4 compatibility) os.path:

>>> p = Path(...)
>>> p = p.with_suffix(".html") if p.match("*.htm") else p

>>> p = "..."
>>> p0, p1 = os.path.splitext(p)
>>> p = (p0 + ".html") if os.path.normcase(p1) == 
os.path.normcase(".htm") else p


Cheers,
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/3WW6WMTM42A7SCYGSKFUCCOMNFIU36VF/

[Python-Dev] Re: Annoying user on GitHub

[Mariatta]

I've used the "Report abuse" feature on GitHub for such situations. Most of
the time I see the user suspended, and the associated comments deleted.
Our GitHub admins can delete comments too.

On Tue, Jul 2, 2019, 1:42 AM Victor Stinner  wrote:

> Hi,
>
> Sometimes, I get an email notification about strange comments (unrelated
> or make no sense) on commits made 6 months ago if not longer. Usually, I
> go to the user profile page and I click on "Block or report user":
> "Report abuse". I'm not sure what happens in this case. I never checks
> if these strange comments are removed by GitHub.
>
> Victor
>
> Le 02/07/2019 à 03:26, Mariatta a écrit :
> > I've reported the user to GitHub. Ticket ID: 297185
> >
> > On Mon, Jul 1, 2019, 5:40 PM Guido van Rossum  > > wrote:
> >
> > There's a user on GitHub ('experimentalles') who has created random
> > PRs on several projects (e.g.
> > https://github.com/python/peps/pull/1116). Can we ban them? The PRs
> > look the work of a vandal or a bot, not of a clueless human.
> >
> > --
> > --Guido van Rossum (python.org/~guido )
> > /Pronouns: he/him/his //(why is my pronoun here?)/
> > <
> http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/
> >
> > ___
> > 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/4DLHMWMNWLB3YKDLCMW4KRHZZBUEH3H2/
> >
> >
> > ___
> > 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/KIJUE2RBLBLMKMC5QUQ3B5R6NDFOMAOH/
> >
> ___
> 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/4HJ7EB64KNNBZH2MWSVYRWQSCHUZUIBI/
>
___
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/VDLYPUQXGKKAZIXMAEYFW2YCPFMW6AB6/

[Python-Dev] Re: PEP 581 has been updated with "Downsides of GitHub" section

[Mariatta]

That's being considered in PEP 588:
https://www.python.org/dev/peps/pep-0588/#a-github-account-should-not-be-a-requirement

It was a consideration since PEP 581 was written, but got moved to 588.


On Tue, Jul 2, 2019, 8:13 AM Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:

> Le 28/06/2019 à 18:56, Mariatta a écrit :
> > Hi,
> >
> > I've updated PEP 581 yesterday, adding the "Downsides of GitHub" section.
> >
> > https://www.python.org/dev/peps/pep-0581/#downsides-of-github
>
> Hi,
>
> another missing point: the necessity to register an account with a third
> party's social network, and accept their terms of service. For this
> matter, a GH account is different from a BPO account because it is not
> controlled by the PSF, and must be unique across projects. While I
> understand this privacy concern is not shared by most core devs, it
> should still be acknowledged.
>
> Cheers,
> Baptiste
> ___
> 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/CQGNNFT7HQXC7YJ5ASKAOZYVXZ32DYEX/
>
___
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/SYEQ7HYUA4QGQAUS5V2QYMJGK66NI3RT/

[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

[brian . skinn]

It seems to me that the desired behavior here is closest to 'str.replace()' out 
of all the options discussed, just with the constraint of being limited to 
either the start or the end of the string. (Thus the .lreplace() and 
.rreplace() option suggested by Glenn.)

The minimal change (which actually also is pretty general?) I think would be to 
add 'only_start' and 'only_end' keyword arguments to str.replace(), both 
defaulting to False. If, e.g., 'only_start' is passed True, each repetition of 
'old' at the start of 's' is replaced by 'new', with the number of replacements 
limited by the existing optional 'count'. Similar behavior for 'only_end'=True. 
 Probably best to raise a ValueError(?) if both 'only_start'=True and 
'only_end'=True?

Taking swapping a file extension as an example of a particular transformation 
of interest, it would be achieved with something like s.replace(".htm", 
".html", only_end=True).

-Brian
___
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/N3VNJHO467YT53ZVIAAGKEWOYISJ4VTY/

[Python-Dev] RES: Re: 3.7.3 Compile error on CentOS 7 (but 3.6.8 Compiles OK)

[Carlos Sotto Maior (UOL)]

Victor, Thanks a bunch! Issue closed! It saved my day!

The FIX: "sudo yum install -y libffi-devel", fixed the 3.7.3 compile error!

Have a great day!

Carlos

-Mensagem original-
De: Victor Stinner  
Enviada em: terça-feira, 2 de julho de 2019 07:26
Para: Charalampos Stratakis 
Cc: python-dev@python.org
Assunto: [Python-Dev] Re: 3.7.3 Compile error on CentOS 7 (but 3.6.8 Compiles 
OK)

FYI I also created an issue to suggest to avoid ctypes to get the glibc version 
in pip ;-)
https://github.com/pypa/pip/issues/6675

In the past, we reported multiple times issues to pip when ctypes is not 
avialable (for different reasons), but it seems to be a lost battle: 
ctypes is commonly used (directly by pip, or by pip dependencies), so instead 
we try to ensure that ctypes is built on buildbots.

Victor

Le 02/07/2019 à 11:12, Charalampos Stratakis a écrit :
> 
> 
> - Original Message -
>> From: "Victor Stinner" 
>> To: python-dev@python.org
>> Sent: Tuesday, July 2, 2019 10:41:40 AM
>> Subject: [Python-Dev] Re: 3.7.3 Compile error on CentOS 7 (but 3.6.8 
>> Compiles OK)
>>
>> Hi,
>>
>> Le 02/07/2019 à 06:22, cso...@uol.com.br a écrit :
>>> I am trying to compile Python 3 on Centos7  and I am getting
>>> "ModuleNotFoundError: No module named '_ctypes'"
>>
>> I'm not sure that you are asking on the right mailing list. Anyway.
>>
>> Red Hat provides precompiled Python 3.6 for Centos 7:
>> https://www.softwarecollections.org/en/scls/rhscl/rh-python36/
>>
>> About your error, you likely miss some header files, like libffi-devel:
>>
>>  sudo yum install -y libffi-devel
> 
> That issue has been reported some times before as well at bpo.
> 
> Maybe providing a proper error message for the missing libffi headers would 
> be good, as the current one is quite cryptic.
> 
>>
>> Victor
>> --
>> Night gathers, and now my watch begins. It shall not end until my death.
>> ___
>> 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/M
>> ERA4UA2KLZJVQ7IEMNYOTD7FCSZY24I/
>>
> 

--
Night gathers, and now my watch begins. It shall not end until my death.
___
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/2UF4RQHQHF4DZ4XI2K4VT7KJMKIZM6GL/
___
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/LPZEY7SR2QKIKKMUNTLIJ3LA3PXOHNWC/

[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

[Brian Skinn]

It seems to me that the desired behavior is closest to 'str.replace()' out
of all the options, just with the constraint of being limited to either the
start or the end of the string. (Thus the .lreplace() and .rreplace()
option suggested by Glenn earlier in the thread.)

The minimal change (which actually also seems pretty general) seems to me
to be adding *only_start* and *only_end* keyword arguments to
str.replace(), both defaulting to False. If, e.g., *only_start* is passed
True, each repetition of *old* at the start of *str* is replaced by a copy
of *new*, with the number of replacements limited by the existing optional
*count*. Similar behavior for *only_end*=True.  Probably best to raise a
ValueError(?) if both *only_start*=True and *only_end*=True?

Taking swapping a file extension as an example of a particular
transformation of interest, it would be achieved with something like
s.replace(".htm", ".html", only_end=True).

-Brian


--
>
> Date: Tue, 2 Jul 2019 14:33:57 +1000
> From: Chris Angelico 
> Subject: [Python-Dev] Re: strip behavior provides inconsistent results
> with certain strings
> To: python-dev 
> Message-ID:
>  x64_vdym9jaj0z9n19te7dk+navvoxoih7...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Tue, Jul 2, 2019 at 2:28 PM Glenn Linderman 
> wrote:
> >
> >> A method could raise instead of returning the string as-is if the
> prefix is not really a prefix.  How often is this needed?  The most common
> end deletions are whitespace, which the current .strip handles correctly.
> >
> > raising wouldn't be helpful in most of the situations where I use this
> logic... it would require a more complex flow control than the  if
> startswith path in the current situation.
> >
> > Yes, I use strip more frequently, but if startswith: chop_prefix
> operation (and the other end too) happens an awful lot.
>
> If the method accepts a tuple of prefixes and will remove the first
> one found (or the longest, or whatever) and raises if none found, you
> could get the "chop only if present" behaviour by including an empty
> string as one of the possible prefixes.
>
> 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/SCZH4SYCM2Z2UXTKYMAIMHGRUKGKD2FU/

[Python-Dev] Re: PEP 581 has been updated with "Downsides of GitHub" section

[Baptiste Carvello]

Le 28/06/2019 à 18:56, Mariatta a écrit :
> Hi,
> 
> I've updated PEP 581 yesterday, adding the "Downsides of GitHub" section.
> 
> https://www.python.org/dev/peps/pep-0581/#downsides-of-github

Hi,

another missing point: the necessity to register an account with a third
party's social network, and accept their terms of service. For this
matter, a GH account is different from a BPO account because it is not
controlled by the PSF, and must be unique across projects. While I
understand this privacy concern is not shared by most core devs, it
should still be acknowledged.

Cheers,
Baptiste
___
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/CQGNNFT7HQXC7YJ5ASKAOZYVXZ32DYEX/

[Python-Dev] Re: 3.7.3 Compile error on CentOS 7 (but 3.6.8 Compiles OK)

[Victor Stinner]

FYI I also created an issue to suggest to avoid ctypes to get the glibc 
version in pip ;-)

https://github.com/pypa/pip/issues/6675

In the past, we reported multiple times issues to pip when ctypes is not 
avialable (for different reasons), but it seems to be a lost battle: 
ctypes is commonly used (directly by pip, or by pip dependencies), so 
instead we try to ensure that ctypes is built on buildbots.


Victor

Le 02/07/2019 à 11:12, Charalampos Stratakis a écrit :



- Original Message -

From: "Victor Stinner" 
To: python-dev@python.org
Sent: Tuesday, July 2, 2019 10:41:40 AM
Subject: [Python-Dev] Re: 3.7.3 Compile error on CentOS 7 (but 3.6.8 Compiles 
OK)

Hi,

Le 02/07/2019 à 06:22, cso...@uol.com.br a écrit :

I am trying to compile Python 3 on Centos7  and I am getting
"ModuleNotFoundError: No module named '_ctypes'"


I'm not sure that you are asking on the right mailing list. Anyway.

Red Hat provides precompiled Python 3.6 for Centos 7:
https://www.softwarecollections.org/en/scls/rhscl/rh-python36/

About your error, you likely miss some header files, like libffi-devel:

 sudo yum install -y libffi-devel


That issue has been reported some times before as well at bpo.

Maybe providing a proper error message for the missing libffi headers would be 
good, as the current one is quite cryptic.



Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
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/MERA4UA2KLZJVQ7IEMNYOTD7FCSZY24I/





--
Night gathers, and now my watch begins. It shall not end until my death.
___
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/2UF4RQHQHF4DZ4XI2K4VT7KJMKIZM6GL/

[Python-Dev] Re: 3.7.3 Compile error on CentOS 7 (but 3.6.8 Compiles OK)

[Charalampos Stratakis]

- Original Message -
> From: "Victor Stinner" 
> To: python-dev@python.org
> Sent: Tuesday, July 2, 2019 10:41:40 AM
> Subject: [Python-Dev] Re: 3.7.3 Compile error on CentOS 7 (but 3.6.8 Compiles 
> OK)
> 
> Hi,
> 
> Le 02/07/2019 à 06:22, cso...@uol.com.br a écrit :
> > I am trying to compile Python 3 on Centos7  and I am getting
> > "ModuleNotFoundError: No module named '_ctypes'"
> 
> I'm not sure that you are asking on the right mailing list. Anyway.
> 
> Red Hat provides precompiled Python 3.6 for Centos 7:
> https://www.softwarecollections.org/en/scls/rhscl/rh-python36/
> 
> About your error, you likely miss some header files, like libffi-devel:
> 
> sudo yum install -y libffi-devel

That issue has been reported some times before as well at bpo.

Maybe providing a proper error message for the missing libffi headers would be 
good, as the current one is quite cryptic.

> 
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> 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/MERA4UA2KLZJVQ7IEMNYOTD7FCSZY24I/
> 

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
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/GSEAOBVOUQ4NVZD2IXYFW44S4KPDCBNG/

[Python-Dev] Re: PyAPI_FUNC() is needed to private APIs?

[Victor Stinner]

Le 02/07/2019 à 06:35, Inada Naoki a écrit :

I wanted to discuss about only when PyAPI_FUNC() is needed,
not about which function should be public.


On Unix, PyAPI_FUNC() or extern is basically the same currently:

   #define PyAPI_FUNC(RTYPE) RTYPE
   #define PyAPI_DATA(RTYPE) extern RTYPE

On Windows, PyAPI_FUNC() exports the symbol in the Python DLL 
("dllexport"), whereas by default symbols are not exported (cannot by 
used outside Python binary). Without PyAPI_FUNC(), a symbol cannot be 
used on Windows. Macros when building Python:


   #define PyAPI_FUNC(RTYPE) __declspec(dllexport) RTYPE
   #define PyAPI_DATA(RTYPE) extern __declspec(dllexport) RTYPE

Macros when using Python headers:

   #define PyAPI_FUNC(RTYPE) __declspec(dllimport) RTYPE
   #define PyAPI_DATA(RTYPE) extern __declspec(dllimport) RTYPE

Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
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/IF4RVTIWNQQE5I3MSVKLZM6LYVLNFGRY/

[Python-Dev] Re: 3.7.3 Compile error on CentOS 7 (but 3.6.8 Compiles OK)

[Victor Stinner]

Hi,

Le 02/07/2019 à 06:22, cso...@uol.com.br a écrit :

I am trying to compile Python 3 on Centos7  and I am getting "ModuleNotFoundError: 
No module named '_ctypes'"


I'm not sure that you are asking on the right mailing list. Anyway.

Red Hat provides precompiled Python 3.6 for Centos 7:
https://www.softwarecollections.org/en/scls/rhscl/rh-python36/

About your error, you likely miss some header files, like libffi-devel:

   sudo yum install -y libffi-devel

Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
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/MERA4UA2KLZJVQ7IEMNYOTD7FCSZY24I/

[Python-Dev] Re: Annoying user on GitHub

[Victor Stinner]

Hi,

Sometimes, I get an email notification about strange comments (unrelated 
or make no sense) on commits made 6 months ago if not longer. Usually, I 
go to the user profile page and I click on "Block or report user": 
"Report abuse". I'm not sure what happens in this case. I never checks 
if these strange comments are removed by GitHub.


Victor

Le 02/07/2019 à 03:26, Mariatta a écrit :

I've reported the user to GitHub. Ticket ID: 297185

On Mon, Jul 1, 2019, 5:40 PM Guido van Rossum > wrote:


There's a user on GitHub ('experimentalles') who has created random
PRs on several projects (e.g.
https://github.com/python/peps/pull/1116). Can we ban them? The PRs
look the work of a vandal or a bot, not of a clueless human.

-- 
--Guido van Rossum (python.org/~guido )

/Pronouns: he/him/his //(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/4DLHMWMNWLB3YKDLCMW4KRHZZBUEH3H2/


___
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/KIJUE2RBLBLMKMC5QUQ3B5R6NDFOMAOH/


___
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/4HJ7EB64KNNBZH2MWSVYRWQSCHUZUIBI/