[Python-Dev] Re: Championing PEP 467

2019-06-28 Thread Nick Coghlan 
On Wed., 26 Jun. 2019, 4:14 pm Elias Zamaria,  wrote:

> Nick Coghlan, I'm thinking about what you said, over a year ago, about
> finding a new champion for PEP 467. I think it would be a privilege to work
> on something like that, which may be used by millions of people over a
> period of years or decades.
>
> However, I have decided that I no longer have the time or interest.
>
> This PEP has been open but delayed for years. It was originally written in
> 2014 (apparently with the expectation that it would be included in Python
> 3.5). My initial attempt to implement it was in 2016. In 2018, Guido said
> "It's too late for 3.7 period, but there's no reason it can't be considered
> for 3.8.", but now 3.8 is already in beta.
>
> I didn't realize that this would go on for so long. I was working on a
> personal project, and at one point I was wishing for something like the
> proposed iterator methods. I thought the details were already decided and I
> just had to code the thing, which would take a few weeks or maybe a few
> months at most. I did not realize what I was getting myself into.
>

Thank you for your efforts, Elias!

And yeah, the cases where we aren't actually sure what we want to do, and
the status quo is merely more irritating than it could be rather than
outright broken, are tough - it's all too easy for us to go "I'll think
about that some more when I'm less busy", and before we know it a couple of
years have gone by.

Cheers,
Nick.


>
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/3WWXWUMMERUIFJTFY4NB7EWX7LM6J2RN/

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

2019-06-28 Thread Mariatta 
Hi,

I've updated PEP 581 yesterday, adding the "Downsides of GitHub" section.

https://www.python.org/dev/peps/pep-0581/#downsides-of-github

Other parts of the PEP has also been updated to reflect recent changes to
roundup/bpo that happened after PEP 581's acceptance, for example:

- ability to automatically close issues when a PR has been merged. This was
added to bpo after PEP 581's acceptance. I've also created an issue in
devguide so that this can be documented:
https://github.com/python/devguide/issues/502

- Availability of REST API in Roundup/bpo. REST API has been requested in
Roundup for several years, and there was no activity on it since 2016. REST
API has been incorporated to Roundup in February 2019, but it is not yet
incorporated to bpo.

- Availability of CI for Roundup/bpo. There is CI running on Roundup's
unofficial GitHub mirror. But pull requests aren't happening
there. Mercurial patches are still how you would contribute to it.

Please re-read PEP 581 in its entirety.

I plan to update PEP 588 sometime this weekend or next, to incorporate the
discussions and suggestions brought up in Python Language Summit 2019:(
http://pyfound.blogspot.com/2019/05/mariatta-wijaya-lets-use-github-issues.html
)

Some of the items brought up during the language summit:
- we're talking with The PSF to get a professional PM to handle the
migration (mentioned by steering council members).
- we should create a playground GitHub issue tracker and copy 100s of
tickets from bpo to there (suggested by Barry Warsaw)
- we should be updating devguide ahead of the actual migration, so core
developers and release managers have time to review and learn the new
workflow. (suggested by Ned Deily)
- Devguide should have a section for "how to triage issues on GitHub"
(sorry I forgot who said this, but it is in my note)
- Some people liked having screencast of "how to do X on GitHub" (similar
to miss-islington's Youtube demo https://www.youtube.com/watch?v=p85YtKKLNno).
It would be good if we can do more of them. (suggested by Davin Potts)


Thanks.

ᐧ
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/WXXY5RY5UV6DGBKANMHCGOW4UIKXVZ6S/

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

2019-06-28 Thread MRAB 

On 2019-06-28 03:40, Glenn Linderman wrote:

On 6/27/2019 3:09 PM, Brett Cannon wrote:

My guess is that without Guido to just ask this will have to go to a PEP as it 
changes a built-in.

How does adding two new methods change a built-in?

Now if an extra parameter were added to modify lstrip, rstrip, and strip 
to make them do something different, yes.


But adding new methods doesn't change anything, unless someone is 
checking for their existence.


My preferred color is  pstrip and sstrip (prefix and suffix strip) since 
lstrip and rstrip mean left and right.


And maybe there should be a psstrip, that takes two parameters, the 
prefix and the suffix to strip.


Such functions would certainly reduce code in a lot of places where I do

if  string.startswith('foo'):
     string = string[ 3: ];

as well as making it more robust, because the string and its length have 
to stay synchronized when changes are made.


lstrip and rstrip remove treat the argument as a set of characters and 
can remove multiple characters, so having additional methods pstrip and 
sstrip with their very similar names but different behaviours could be 
confusing.


I'd prefer to stick with lXXX and rXXX. ldrop and rdrop, maybe?
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/JRKVJHS63GCC5T4UCY7BNB6OU2TPY6GR/

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

2019-06-28 Thread Barry Warsaw 
On Jun 28, 2019, at 09:56, Mariatta  wrote:
> 
> I've updated PEP 581 yesterday, adding the "Downsides of GitHub" section.
> 
> https://www.python.org/dev/peps/pep-0581/#downsides-of-github

Thanks Mariatta!

> I plan to update PEP 588 sometime this weekend or next, to incorporate the 
> discussions and suggestions brought up in Python Language Summit 
> 2019:(http://pyfound.blogspot.com/2019/05/mariatta-wijaya-lets-use-github-issues.html)

One of my biggest concerns is how the bpo-metadata -> GH-labels transition is 
going to work.  Will make label management, discoverability, understanding, and 
use too unwieldy if we simply map all the bpo data to labels?  This might be 
one area where we want to get closer interaction with the GH folks on their 
plans or suggestions.

Thanks for all your work on these PEPs.
-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/3GOKAYPYTUI7X5YBURFXF6UKCZ5UIVAQ/

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

2019-06-28 Thread Glenn Linderman 

On 6/28/2019 10:10 AM, MRAB wrote:

On 2019-06-28 03:40, Glenn Linderman wrote:

On 6/27/2019 3:09 PM, Brett Cannon wrote:
My guess is that without Guido to just ask this will have to go to a 
PEP as it changes a built-in.

How does adding two new methods change a built-in?

Now if an extra parameter were added to modify lstrip, rstrip, and 
strip to make them do something different, yes.


But adding new methods doesn't change anything, unless someone is 
checking for their existence.


My preferred color is  pstrip and sstrip (prefix and suffix strip) 
since lstrip and rstrip mean left and right.


And maybe there should be a psstrip, that takes two parameters, the 
prefix and the suffix to strip.


Such functions would certainly reduce code in a lot of places where I do

if  string.startswith('foo'):
 string = string[ 3: ];

as well as making it more robust, because the string and its length 
have to stay synchronized when changes are made.


lstrip and rstrip remove treat the argument as a set of characters and 
can remove multiple characters, so having additional methods pstrip 
and sstrip with their very similar names but different behaviours 
could be confusing.


I'd prefer to stick with lXXX and rXXX. ldrop and rdrop, maybe?


I was thinking of the change from stripping sets of characters versus 
stripping specific sequences of characters, all being strip operations.


But when you point out the confusion and suggest the change of names, I 
got to thinking about names, and really, the   pstrip/ldrop or 
sstring/rdrop  operations are more like  "replace" than "strip"... there 
has to be an exact match.


So maybe a better solution to the functionality needed would be lreplace 
and rreplace.  On the other hand,  the existing   .replace( prefix, '', 
1 )  almost implements lreplace! It doesn't require it to be a prefix 
though :(  And there is no option for doing the last N replacements, nor 
requiring a single one to be a suffix.  The last N replacements could be 
done by using a negative N, but it would seem an additional parameter or 
new name would be required to do prefix- and suffix-restricted operations.


So my example above could be written as either:

string.lreplace('foo')
string.lreplace('foo', '')

But calling the operations lreplace and rreplace, including the option 
of putting in replacement strings, would actually be quite handy.  Think 
of this:


filename.rreplace('.html', '.css', True )

where the first parameter is the suffix to remove, the second parameter 
is a suffix to replace it with, and the third parameter says to add the 
replacement even if the first parameter is not found/removed.  That's 
another operation I find frequently in batch file processing, that 
otherwise takes several lines.


As Ned noted in another branch of this discussion, it would be good to 
have an update for the 2.7 documentation.  And if new functions are 
added, by any name, it would be good to have the 3.x documentation 
clearly reference in both directions between lstrip and lreplace, and 
between rstrip and rreplace (or whatever names).


___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/GRPEPJIPGOWEFHZLWWRT3DKGX3XWDSAM/

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

2019-06-28 Thread Brett Cannon 
Glenn Linderman wrote:
> On 6/27/2019 3:09 PM, Brett Cannon wrote:
> > My guess is that without Guido to just ask this will
> > have to go to a PEP as it changes a built-in.
> > How does adding two new methods change a built-in?
> > Now if an extra parameter were added to modify lstrip, rstrip, and strip 
> to make them do something different, yes.
> But adding new methods doesn't change anything, unless someone is 
> checking for their existence.

Sure, but the built-ins are so widely used that we don't want to blindly add 
every method idea that someone comes up with either. We all very much share 
ownership of the built-ins, so we should all agree to changes to them, and 
getting agreement means either clear consensus and/or a PEP.

-Brett

> My preferred color is  pstrip and sstrip (prefix and suffix strip) since 
> lstrip and rstrip mean left and right.
> And maybe there should be a psstrip, that takes two parameters, the 
> prefix and the suffix to strip.
> Such functions would certainly reduce code in a lot of places where I do
> if  string.startswith('foo'):
>      string = string[ 3: ];
> as well as making it more robust, because the string and its length have 
> to stay synchronized when changes are made.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/SB6JECL6BUPF4Q37Q5SAGMDOQ2DI2GP5/

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

2019-06-28 Thread Ned Deily 


On Jun 28, 2019, at 12:56, Mariatta  wrote:
> Some of the items brought up during the language summit:
> [...]
> - we should be updating devguide ahead of the actual migration, so core 
> developers and release managers have time to review and learn the new 
> workflow. (suggested by Ned Deily)

Actually, my suggestion was (and remains :) ) that a modified devguide branch 
should be created *first* as part of the migration design process, not later 
during implementation.  It needs to happen anyway but it would be much more 
effective, I think, to have it available up front to help catch any holes 
during the design and review.

P.S. Thanks for doing this, Marietta!

--
  Ned Deily
  [email protected] -- []
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/JPWPWUUYDRWNWALTVT4VIT4L6WMBNIRJ/

[Python-Dev] Summary of Python tracker Issues

2019-06-28 Thread Python tracker 


ACTIVITY SUMMARY (2019-06-21 - 2019-06-28)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7054 (+16)
  closed 42139 (+61)
  total  49193 (+77)

Open issues with patches: 2835 


Issues opened (49)
==

#37359: test_regrtest: test_list_cases() fails on x86 Gentoo Installed
https://bugs.python.org/issue37359  reopened by pablogsal

#37366: Add an "onitem" callback parameter to shutil.rmtree()
https://bugs.python.org/issue37366  opened by Jeffrey.Kintscher

#37367: octal escapes applied inconsistently throughout the interprete
https://bugs.python.org/issue37367  opened by bup

#37368: test_asyncio: test_create_server_ssl_match_failed() failed on 
https://bugs.python.org/issue37368  opened by vstinner

#37369: Issue with pip in venv on Powershell in Windows
https://bugs.python.org/issue37369  opened by bstorm

#37371: Optimize and refactor readline().
https://bugs.python.org/issue37371  opened by shlomif

#37372: datetime.time unpickling fails in case of python2 pickle with 
https://bugs.python.org/issue37372  opened by Justin Blanchard

#37373: Configuration of windows event loop for libraries
https://bugs.python.org/issue37373  opened by Ben.Darnell

#37374: Minidom does not have to escape quote inside text segments
https://bugs.python.org/issue37374  opened by mitar

#37379: Provide triggering AttributeError exception to __getattr__ for
https://bugs.python.org/issue37379  opened by nother

#37380: subprocess.Popen._cleanup() "The handle is invalid" error when
https://bugs.python.org/issue37380  opened by efiop

#37381: Script using ProactorEventLoop does not exit cleanly when subp
https://bugs.python.org/issue37381  opened by cr1901

#37382: Improve conditional check for test_gdb
https://bugs.python.org/issue37382  opened by jdemeyer

#37383: call count in not registered in AsyncMock till the coroutine i
https://bugs.python.org/issue37383  opened by xtreak

#37385: test_multiprocessing fails on AMD64 FreeBSD CURRENT Shared 2.7
https://bugs.python.org/issue37385  opened by vstinner

#37386: [EASY] test_io: test_large_file_ops() failed on AMD64 Windows7
https://bugs.python.org/issue37386  opened by vstinner

#37387: test_compileall fails randomly on Windows when tests are run i
https://bugs.python.org/issue37387  opened by vstinner

#37395: Core interpreter should be linked with libgcc_s.so on Linux
https://bugs.python.org/issue37395  opened by zwol

#37398: contextlib.ContextDecorator decorating async functions
https://bugs.python.org/issue37398  opened by John Belmonte

#37399: XML text behaviour change if there are comments
https://bugs.python.org/issue37399  opened by Dima.Tisnek

#37402: Fatal Python error: Cannot recover from stack overflow issues 
https://bugs.python.org/issue37402  opened by ajung

#37403: Recommend .venv for virtual environment names
https://bugs.python.org/issue37403  opened by brett.cannon

#37404: asyncio sock_recv blocks on ssl sockets.
https://bugs.python.org/issue37404  opened by AkshayTakkar

#37405: socket.getsockname() returns string instead of tuple
https://bugs.python.org/issue37405  opened by Brent Gardner

#37406: Disable runtime checks in release mode
https://bugs.python.org/issue37406  opened by vstinner

#37407: Update imaplib.py to account for additional padding
https://bugs.python.org/issue37407  opened by edwardmbsmith

#37408: [DOC] Precise that Tarfile "format" argument only concerns wri
https://bugs.python.org/issue37408  opened by pakal

#37409: relative import without parent
https://bugs.python.org/issue37409  opened by Ben Lewis2

#37410: [Windows] subprocess: close the handle when the process comple
https://bugs.python.org/issue37410  opened by vstinner

#37412: os.getcwdb() doesn't implement PEP 528 (UTF-8) on Windows
https://bugs.python.org/issue37412  opened by vstinner

#37413: Deprecate sys._enablelegacywindowsfsencoding()?
https://bugs.python.org/issue37413  opened by vstinner

#37415: Error build Python with Intel compiler:  doesn't 
https://bugs.python.org/issue37415  opened by Saszalez

#37416: If threading is not imported from the main thread it sees the 
https://bugs.python.org/issue37416  opened by fabioz

#37421: Some tests leak temporary files
https://bugs.python.org/issue37421  opened by vstinner

#37422: Documentation on the change of __path__ in Python 3
https://bugs.python.org/issue37422  opened by jimli

#37426: getpass.getpass not working with on windows when ctrl+v  is us
https://bugs.python.org/issue37426  opened by Atul Bagga

#37427: sorted() and list.sort() don't accept non-boolean objects with
https://bugs.python.org/issue37427  opened by nodakai

#37428: SSLContext.post_handshake_auth implicitly enables cert validat
https://bugs.python.org/issue37428  opened by christian.heimes

#37429: Python hangs on fork when a logger is in use in a background t
https://bugs.python.org/issue

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

2019-06-28 Thread Carol Willing 
I agree with you, Ned.

Mariatta, I'm happy to work on an initial pass at the devguide in my fork.

On Fri, Jun 28, 2019 at 10:52 AM Ned Deily  wrote:

>
> On Jun 28, 2019, at 12:56, Mariatta  wrote:
> > Some of the items brought up during the language summit:
> > [...]
> > - we should be updating devguide ahead of the actual migration, so core
> developers and release managers have time to review and learn the new
> workflow. (suggested by Ned Deily)
>
> Actually, my suggestion was (and remains :) ) that a modified devguide
> branch should be created *first* as part of the migration design process,
> not later during implementation.  It needs to happen anyway but it would be
> much more effective, I think, to have it available up front to help catch
> any holes during the design and review.
>
> P.S. Thanks for doing this, Marietta!
>
> --
>   Ned Deily
>   [email protected] -- []
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/JPWPWUUYDRWNWALTVT4VIT4L6WMBNIRJ/
>


-- 
*Carol Willing*

Willing Consulting 

*Signature strengths*
*Empathy - Relator - Ideation - Strategic - Learner*
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/YPUM4W7C7SBLJQQVVIM7CKPDBSQN7QOP/