[Python-Dev] Looking for a sponsor and feedback on PEP 616: string methods for removing prefixes and suffixes

[Dennis Sweeney]

Hello all! I'm a relatively new contributor looking for a Core Dev sponsor for 
the following PEP:

https://github.com/python/peps/pull/1332

Related:
- Python-Ideas Thread: 
https://mail.python.org/archives/list/python-id...@python.org/thread/RJARZSUKCXRJIP42Z2YBBAEN5XA7KEC3/
- Bug Tracker Issue: https://bugs.python.org/issue39939
- Github PR for implementation: https://github.com/python/cpython/pull/18939

Abstract


This is a proposal to add two new methods, ``cutprefix`` and
``cutsuffix``, to the APIs of Python's various string objects.  In
particular, the methods would be added to Unicode ``str`` objects, 
binary ``bytes`` and ``bytearray`` objects, and
``collections.UserString``. 

If ``s`` is one these objects, and ``s`` has ``pre`` as a prefix, then
``s.cutprefix(pre)`` returns a copy of ``s`` in which that prefix has
been removed.  If ``s`` does not have ``pre`` as a prefix, an 
unchanged copy of ``s`` is returned.  In summary, ``s.cutprefix(pre)``
is roughly equivalent to ``s[len(pre):] if s.startswith(pre) else s``.

The behavior of ``cutsuffix`` is analogous: ``s.cutsuffix(suf)`` is
roughly equivalent to 
``s[:-len(suf)] if suf and s.endswith(suf) else s``.
___
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/XC3D3QGONENQ7PIAUM2SNNEP5BWA6Q4J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Looking for a sponsor and feedback on PEP 616: string methods for removing prefixes and suffixes

[Eric V. Smith]

I'll sponsor it.

Eric

On 3/20/2020 11:29 AM, Dennis Sweeney wrote:

Hello all! I'm a relatively new contributor looking for a Core Dev sponsor for 
the following PEP:

https://github.com/python/peps/pull/1332

Related:
- Python-Ideas Thread: 
https://mail.python.org/archives/list/python-id...@python.org/thread/RJARZSUKCXRJIP42Z2YBBAEN5XA7KEC3/
- Bug Tracker Issue: https://bugs.python.org/issue39939
- Github PR for implementation: https://github.com/python/cpython/pull/18939

Abstract


This is a proposal to add two new methods, ``cutprefix`` and
``cutsuffix``, to the APIs of Python's various string objects.  In
particular, the methods would be added to Unicode ``str`` objects,
binary ``bytes`` and ``bytearray`` objects, and
``collections.UserString``.

If ``s`` is one these objects, and ``s`` has ``pre`` as a prefix, then
``s.cutprefix(pre)`` returns a copy of ``s`` in which that prefix has
been removed.  If ``s`` does not have ``pre`` as a prefix, an
unchanged copy of ``s`` is returned.  In summary, ``s.cutprefix(pre)``
is roughly equivalent to ``s[len(pre):] if s.startswith(pre) else s``.

The behavior of ``cutsuffix`` is analogous: ``s.cutsuffix(suf)`` is
roughly equivalent to
``s[:-len(suf)] if suf and s.endswith(suf) else s``.
___
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/XC3D3QGONENQ7PIAUM2SNNEP5BWA6Q4J/
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/6ZLKLYJV6VTK4ZKM5ZCILSXBJL67L3MS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2020-03-13 - 2020-03-20)
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:
  open7358 ( +1)
  closed 44420 (+70)
  total  51778 (+71)

Open issues with patches: 2883 


Issues opened (44)
==

#39576: Surprising MemoryError in `decimal` with MAX_PREC
https://bugs.python.org/issue39576  reopened by pablogsal

#39958: Deadlock in _PyInterpreterState_DeleteExceptMain with HEAD_LOC
https://bugs.python.org/issue39958  opened by Atle Solbakken

#39959: (Possible) bug on multiprocessing.shared_memory
https://bugs.python.org/issue39959  opened by dxflores

#39960: Using typename.__setattr__ in extension type with Py_TPFLAGS_H
https://bugs.python.org/issue39960  opened by Matthias Braun

#39961: warning: this use of "defined" may not be portable (Mac OS)
https://bugs.python.org/issue39961  opened by clem.wang

#39963: Subclassing slice objects
https://bugs.python.org/issue39963  opened by mariode1

#39966: mock 3.9 bug: Wrapped objects without __bool__ raise exception
https://bugs.python.org/issue39966  opened by aviso

#39967: bdb calls linecache.checkcache, resulting in source being diff
https://bugs.python.org/issue39967  opened by blueyed

#39971: Error on documentation  -  Quick fix.
https://bugs.python.org/issue39971  opened by dxflores

#39975: Group of commands running in Python 3.7.6 Shell, but failing a
https://bugs.python.org/issue39975  opened by rosarion

#39976: Add "**other_popen_kwargs" to subprocess API signatures in doc
https://bugs.python.org/issue39976  opened by ncoghlan

#39978: Vectorcall implementation should conform to PEP 590.
https://bugs.python.org/issue39978  opened by Mark.Shannon

#39981: Default values for AST Nodes
https://bugs.python.org/issue39981  opened by BTaskaya

#39982: FreeBSD: SCTP tests of test_socket fails on AMD64 FreeBSD Shar
https://bugs.python.org/issue39982  opened by vstinner

#39983: test.regrtest: test marked as failed (env changed), but no war
https://bugs.python.org/issue39983  opened by vstinner

#39984: Move some ceval fields from _PyRuntime.ceval to PyInterpreterS
https://bugs.python.org/issue39984  opened by vstinner

#39986: test_os / test_listdir failed as root-directory changed during
https://bugs.python.org/issue39986  opened by Matthias Braun

#39989: Output closing parenthesis in ast.dump() on separate line
https://bugs.python.org/issue39989  opened by serhiy.storchaka

#39990: help should evaluate forward reference
https://bugs.python.org/issue39990  opened by McSinyx

#39994: Redundant code in pprint module.
https://bugs.python.org/issue39994  opened by palakjha

#39995: test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.
https://bugs.python.org/issue39995  opened by vstinner

#39996: test_multiprocessing_fork hangs on AMD64 FreeBSD Shared 3.x
https://bugs.python.org/issue39996  opened by vstinner

#3: Fix some issues with AST node classes
https://bugs.python.org/issue3  opened by serhiy.storchaka

#40001: ignore errors in SimpleCookie
https://bugs.python.org/issue40001  opened by aviramha

#40002: Cookie load error inconsistency
https://bugs.python.org/issue40002  opened by bar.harel

#40003: test.regrtest: add an option to run test.bisect_cmd on failed 
https://bugs.python.org/issue40003  opened by vstinner

#40005: Getting different result in python 2.7 and 3.7.
https://bugs.python.org/issue40005  opened by Bharatsolanki

#40006: enum: Add documentation for _create_pseudo_member_ and composi
https://bugs.python.org/issue40006  opened by cool-RR

#40007: An attempt to make asyncio.transport.writelines (selector) use
https://bugs.python.org/issue40007  opened by tzickel

#40010: Inefficient signal handling in multithreaded applications
https://bugs.python.org/issue40010  opened by vstinner

#40011: Tkinter widget events are of type Tuple
https://bugs.python.org/issue40011  opened by Hênio Tierra Sampaio

#40012: Avoid Python 2 documentation to appear in Web search results
https://bugs.python.org/issue40012  opened by bittner

#40013: CSV DictReader parameter documentation
https://bugs.python.org/issue40013  opened by Moshe Sambol

#40014: os.getgrouplist() can fail on macOS
https://bugs.python.org/issue40014  opened by corona10

#40016: Clarify flag case in `re` module
https://bugs.python.org/issue40016  opened by cool-RR

#40017: Please support CLOCK_TAI in the time module.
https://bugs.python.org/issue40017  opened by r3owen

#40018: test_ssl fails with OpenSSL 1.1.1e
https://bugs.python.org/issue40018  opened by benjamin.peterson

#40019: test_gdb  should better detect when Python is optimized
https://bugs.python.org/issue40019  opened by vstinner

#40020: growable_comment_array_add leaks, causes crash
https://bugs.python.org/issue40020  opened by Alexander Riccio

#40022: 关于列表的基础算法问题
https://bugs.python.org/issue40022  opened by yepan Li

#4

[Python-Dev] Re: Proliferation of tstate arguments.

[Victor Stinner]

Le jeu. 19 mars 2020 à 02:17, Kyle Stanley  a écrit :
> Agreed; a PEP (even if it's just informational) would go a long way in 
> helping to clear up some misunderstandings.

I am still moving blindly in the darkness of CPython internals and so
I don't feel comfortable to write a PEP which would mean that I know
what I am doing :-)

I fixed dozens of bugs in the Python finalization related to
subinterpreters and daemon threads:
https://bugs.python.org/issue33608#msg364670

I managed to make pending calls (Py_AddPendingCall) per-interpreter,
but it was really painful.

So far, I have no strong opinion about passing explicitly tstate vs
"implicit" TLS (Thread Local Storage) variable. I mean, I don't feel
that I have enough feedback to see which option is the best.

All I can say is that passing explicitly tstate helps me to validate
that the code is *correct*. It helps me to understand where tstate
comes from and helps me to understand if tstate is valid or not.

It wasn't an issue in Python 3.7 where most critical structures lives
in _PyRuntime which is shared by all subinterpreters. It became a big
deal in Python 3.9 where more and more critical structures are
"per-interpreter" and becomes invalid during Python finalization. For
example, in Python 3.8, PyThreadState structures of daemon threads are
never freed.

There are still too many functions which don't work properly with
subinterpreters. There are still a few design issues that needs to be
addressed.

Most functions of the C API don't even specify in their documentation
if they require the GIL to be held.

One good example is Py_AddPendingCall(). The documentation says that
it's safe to call it without holding the GIL. Except that right now,
there is no reliable way to get the correct interpreter in this case
(correct me if I'm wrong!). The function uses
PyGILState_GetThisThreadState() which may return a Python thread state
of the wrong interpreter :-( Again, the PyGILState API should be fixed
to support subinterpreters.

I'm not even sure that I discovered all borders of the problem. I only
started my list of issues.

I would prefer to continue to experiment passing tstate explicitly in
internal C APIs until most blocker issues will be fixed. Once early
work on running two subinterpreters in parallel will start working
(one "GIL" per interpreter), I will be more open to reconsider using a
TLS variable.

We are not so far from being able to *experiment* one "GIL" per
interpreter. I succeeded to move the first half of
_PyRuntimeState.ceval into a new PyInterpreterState.ceval:
pending_calls, eval_breaker and tracing_possible. Moving eval_breaker
was tricky, since it's tidely coupled to the GIL which currently
remains shared by all interpreters. By the way, I took the opportunity
to optimized the bytecode evaluation loop (ceval), eval_breaker was
not properly set in multithreaded applications:

"Inefficient signal handling in multithreaded applications"
https://bugs.python.org/issue40010

The main interpreter benefits of this optimization as well, not only
subinterpreters ;-)

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

[Python-Dev] PEP 616 -- String methods to remove prefixes and suffixes

[Dennis Sweeney]

Browser Link: https://www.python.org/dev/peps/pep-0616/

PEP: 616
Title: String methods to remove prefixes and suffixes
Author: Dennis Sweeney 
Sponsor: Eric V. Smith 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 19-Mar-2020
Python-Version: 3.9
Post-History: 30-Aug-2002


Abstract


This is a proposal to add two new methods, ``cutprefix`` and
``cutsuffix``, to the APIs of Python's various string objects.  In
particular, the methods would be added to Unicode ``str`` objects, 
binary ``bytes`` and ``bytearray`` objects, and
``collections.UserString``. 

If ``s`` is one these objects, and ``s`` has ``pre`` as a prefix, then
``s.cutprefix(pre)`` returns a copy of ``s`` in which that prefix has
been removed.  If ``s`` does not have ``pre`` as a prefix, an 
unchanged copy of ``s`` is returned.  In summary, ``s.cutprefix(pre)``
is roughly equivalent to ``s[len(pre):] if s.startswith(pre) else s``.

The behavior of ``cutsuffix`` is analogous: ``s.cutsuffix(suf)`` is
roughly equivalent to 
``s[:-len(suf)] if suf and s.endswith(suf) else s``.


Rationale
=

There have been repeated issues [#confusion]_ on the Bug Tracker 
and StackOverflow related to user confusion about the existing 
``str.lstrip`` and ``str.rstrip`` methods.  These users are typically
expecting the behavior of ``cutprefix`` and ``cutsuffix``, but they 
are surprised that the parameter for ``lstrip`` is interpreted as a
set of characters, not a substring.  This repeated issue is evidence
that these methods are useful, and the new methods allow a cleaner
redirection of users to the desired behavior.

As another testimonial for the usefulness of these methods, several
users on Python-Ideas [#pyid]_ reported frequently including similar
functions in their own code for productivity.  The implementation
often contained subtle mistakes regarding the handling of the empty
string (see `Specification`_).


Specification
=

The builtin ``str`` class will gain two new methods with roughly the
following behavior::

def cutprefix(self: str, pre: str, /) -> str:
if self.startswith(pre):
return self[len(pre):]
return self[:]

def cutsuffix(self: str, suf: str, /) -> str:
if suf and self.endswith(suf):
return self[:-len(suf)]
return self[:]

The only difference between the real implementation and the above is
that, as with other string methods like ``replace``, the 
methods will raise a ``TypeError`` if any of ``self``, ``pre`` or 
``suf`` is not an instace of ``str``, and will cast subclasses of
``str`` to builtin ``str`` objects.

Note that without the check for the truthyness of ``suf``, 
``s.cutsuffix('')`` would be mishandled and always return the empty 
string due to the unintended evaluation of ``self[:-0]``.

Methods with the corresponding semantics will be added to the builtin 
``bytes`` and ``bytearray`` objects.  If ``b`` is either a ``bytes``
or ``bytearray`` object, then ``b.cutsuffix()`` and ``b.cutprefix()``
will accept any bytes-like object as an argument.

Note that the ``bytearray`` methods return a copy of ``self``; they do
not operate in place.

The following behavior is considered a CPython implementation detail,
but is not guaranteed by this specification::

>>> x = 'foobar' * 10**6
>>> x.cutprefix('baz') is x is x.cutsuffix('baz')
True
>>> x.cutprefix('') is x is x.cutsuffix('')
True

That is, for CPython's immutable ``str`` and ``bytes`` objects, the 
methods return the original object when the affix is not found or if
the affix is empty.  Because these types test for equality using 
shortcuts for identity and length, the following equivalent 
expressions are evaluated at approximately the same speed, for any 
``str`` objects (or ``bytes`` objects) ``x`` and ``y``::

>>> (True, x[len(y):]) if x.startswith(y) else (False, x)
>>> (True, z) if x != (z := x.cutprefix(y)) else (False, x)


The two methods will also be added to ``collections.UserString``, 
where they rely on the implementation of the new ``str`` methods.


Motivating examples from the Python standard library


The examples below demonstrate how the proposed methods can make code
one or more of the following:

Less fragile:
The code will not depend on the user to count the length of a
literal.
More performant:
The code does not require a call to the Python built-in 
``len`` function.
More descriptive:
The methods give a higher-level API for code readability, as
opposed to the traditional method of string slicing.


refactor.py
---

- Current::

if fix_name.startswith(self.FILE_PREFIX):
fix_name = fix_name[len(self.FILE_PREFIX):]

- Improved::

fix_name = fix_name.cutprefix(self.FILE_PREFIX)


c_annotations.py:
-

- Current::

if name.startswith("c."):
name = name[2:]

- Imp

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Ethan Furman]

On 03/20/2020 11:52 AM, Dennis Sweeney wrote:

Browser Link: https://www.python.org/dev/peps/pep-0616/

PEP: 616
Title: String methods to remove prefixes and suffixes


Thank you, Dennis, for putting this together!  And Eric for sponsoring.  :)

Overall I think it's a good idea, but...


Alternative Method Names


 ``stripprefix``
 Users may benefit from the mnemonic that "strip" means working
 with sets of characters, while other methods work with
 substrings, so re-using "strip" here should be avoided.


Um, what mnemonic?

I am strongly opposed to the chosen names of `cut*` -- these methods do 
basically the same thing as the existing `strip` methods (remove something from 
either end of a string), and so should have similar names:

- the existence of `stripsuffix` is a clue/reminder that `strip` doesn't work 
with substrings

- if all of these similar methods have similar names they will be grouped 
together in the documentation making discovery of the correct one much easier.


So for this iteration of the PEP, I am

-1

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

[Python-Dev] Re: [bpo-22699] Cross-compiling and fixing sysconfig

[Matthias Klose]

distutils is pretty indifferent to whether it's building native or cross. The
idea is to run the host python with the target's sysconfig to provide the tools
needed for cross compilation.  Yes, there are problems if third-party modules
are using the sys module to reason about the target architecture.

On 3/19/20 9:34 PM, Ivan Pozdeev via Python-Dev wrote:
> Last time I checked, distutils didn't support compilation for anything but the
> running Python instance, nor was it intended to. Should it?
> If not, the efforts look misplaced, you should rather use a toolchain that 
> does...
> 
> On 19.03.2020 23:22, Steve Dower wrote:
>> So over on https://bugs.python.org/issue22699 I've been talking to myself as 
>> I
>> figure out all the ways that cross-compiling (on Ubuntu, targeting another
>> Linux distro via an SDK) fails.
>>
>> In short, it's either because sysconfig can't provide details about any
>> CPython install other than the currently running one, or it's because our
>> setup.py (for building the CPython extension modules) uses sysconfig.
>>
>> Either way, I'm not about to propose a rewrite to fix either of them without
>> finding those who are most involved in these areas. Please come join me on 
>> the
>> bug.
>>
>> Thanks,
>> 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/6DBYMDCDLOS245XK57BD3E2GXGVDMBPX/
>>
>> 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/YOM5OZ5UGLP3WP6ZLNXH2SU7WJSELPBM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Requesting review on PEP 615 C Extension Reference Implementation

[Paul Ganssle]

Hi all,

The past few weeks I've been working on adding a C extension to the
reference implementation for PEP 615 (Support for the IANA Time Zone
Database in the Standard Library - PEP link
), but I've had some trouble
inducing anyone to review the code
. There's
about 2200 lines of C code there that's passing all the tests for the
pure Python implementation (which has 100% code coverage) - would anyone
be interested in taking a look before I merge it into the reference
implementation repo? Any little bit of review (including incremental
reviews) would help:

https://github.com/pganssle/zoneinfo/pull/15

Note: You'll need to click "Load diff" on the zoneinfo_module.c file to
see the actual code, because the diff is so large. The stuff that's
immediately visible in the diff is the more straightforward code.

I'll note that I am also happy to accept review comments about other
parts of the repo, not just the C code, but the C code is a priority
since errors there tend to be less forgiving.

Thanks!
Paul



signature.asc
Description: OpenPGP digital signature
___
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/MWL4Q2KRYEZ2GYK63LCBLOPJBD2FO7XY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Dennis Sweeney]

Thanks for the feedback!

I meant mnemonic as in the broader sense of "way of remembering things", not 
some kind of rhyming device or acronym. Maybe "mnemonic" isn't the perfect 
word. I was just trying to say that the structure of how the methods are named 
should how their behavior relates to one another, which it seems you agree with.

Fair enough that ``[l/r]strip`` and the proposed methods share the behavior of 
"removing something from the end of a string". From that perspective, they're 
similar. But my thought was that ``s.lstrip("abc")`` has extremely similar 
behavior when changing "lstrip" to "rstrip" or "strip" -- the argument is 
interpreted in the exactly same way (as a character set) in each case. Looking 
at how the argument is used, I'd argue that ``lstrip``/``rstrip``/``strip`` are 
much more similar to each other than they are to the proposed methods, and that 
the proposed methods are perhaps more similar to something like 
``str.replace``. But it does seem pretty subjective what the threshold is for 
behavior similar enough to have related names -- I see where you're coming from.

Also, the docs at ( 
https://docs.python.org/3/library/stdtypes.html?highlight=lstrip#string-methods 
) are alphabetical, not grouped by "similar names", so even ``lstrip``, 
``strip``, and ``rstrip`` are already in different places. Maybe the name 
"stripprefix" would be more discoverable when "Ctrl-f"ing the docs, if it 
weren't for the following addition in the linked PR:

 .. method:: str.lstrip([chars])

Return a copy of the string with leading characters removed.  The 
*chars*
argument is a string specifying the set of characters to be removed.  
If  omitted
or ``None``, the *chars* argument defaults to removing whitespace.  The 
*chars*
argument is not a prefix; rather, all combinations of its values are 
stripped::

   >>> '   spacious   '.lstrip()
   'spacious   '
   >>> 'www.example.com'.lstrip('cmowz.')
   'example.com'

+  See :meth:`str.cutprefix` for a method that will remove a single prefix
+  string rather than all of a set of characters.
___
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/55QJHR6PP4IWFLBRTFL4TZX5QOBJQFO5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Dennis Sweeney]

Dennis Sweeney wrote:
> to say that the structure of how the methods are named should how their 
> behavior relates

...should be a reminder of how...
___
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/IFGANJGTE5RQ5J6FBJJNAWY7HRZSRED5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Eric Fahlgren]

On Fri, Mar 20, 2020 at 11:56 AM Dennis Sweeney 
wrote:

> If ``s`` is one these objects, and ``s`` has ``pre`` as a prefix, then
> ``s.cutprefix(pre)`` returns a copy of ``s`` in which that prefix has
> been removed.  If ``s`` does not have ``pre`` as a prefix, an
> unchanged copy of ``s`` is returned.  In summary, ``s.cutprefix(pre)``
> is roughly equivalent to ``s[len(pre):] if s.startswith(pre) else s``.
>

The second sentence above unambiguously states that cutprefix returns 'an
unchanged *copy*', but the example contradicts that and shows that 'self'
may be returned and not a copy.  I think it should be reworded to
explicitly allow the optimization of returning self.
___
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/SVDEUYYJSI6RRHEOZ54CD55FJRY5N4KM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Dennis Sweeney]

For clarity, I'll change

 If ``s`` does not have ``pre`` as a prefix, an unchanged copy of ``s`` is 
returned.

to

If ``s`` does not have ``pre`` as a prefix, then ``s.cutprefix(pre)`` 
returns ``s`` or an unchanged copy of ``s``.

For consistency with the Specification section, I'll also change

s[len(pre):] if s.startswith(pre) else s

to

s[len(pre):] if s.startswith(pre) else s[:]

and similarly change the ``cutsuffix`` snippet.
___
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/ULKK7K47QKFHXFXKNEAVF2UVNV6ZJNSD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Victor Stinner]

Hi Dennis,

Thanks for writing a proper PEP. It easier to review a specification
than an implementation.


Le ven. 20 mars 2020 à 20:00, Dennis Sweeney
 a écrit :
> Abstract
> 
>
> This is a proposal to add two new methods, ``cutprefix`` and
> ``cutsuffix``, to the APIs of Python's various string objects.

It would be nice to describe the behavior of these methods in a short
sentence here.


>  In
> particular, the methods would be added to Unicode ``str`` objects,
> binary ``bytes`` and ``bytearray`` objects, and
> ``collections.UserString``.


IMHO the abstract should stop here. You should move the above text in
the Specification section. The abstract shouldn't go into details.

> If ``s`` is one these objects, and ``s`` has ``pre`` as a prefix, then
> ``s.cutprefix(pre)`` returns a copy of ``s`` in which that prefix has
> been removed.  If ``s`` does not have ``pre`` as a prefix, an
> unchanged copy of ``s`` is returned.  In summary, ``s.cutprefix(pre)``
> is roughly equivalent to ``s[len(pre):] if s.startswith(pre) else s``.
>
> The behavior of ``cutsuffix`` is analogous: ``s.cutsuffix(suf)`` is
> roughly equivalent to
> ``s[:-len(suf)] if suf and s.endswith(suf) else s``.

(...)

> The builtin ``str`` class will gain two new methods with roughly the
> following behavior::
>
> def cutprefix(self: str, pre: str, /) -> str:
> if self.startswith(pre):
> return self[len(pre):]
> return self[:]

I'm not sure that I'm comfortable with not specifying if the method
must return the string unmodified or return a copy if it doesn't start
with the prefix. It can subtle causes: see the "Allow multiple
prefixes" example which expects that it doesn't return a copy.
Usually, PyPy does its best to mimick exactly CPython behavior anyway,
since applications rely on CPython exact behavior (even if it's bad
thing). Hopefully, Python 3.8 started to emit a SyntaxWarning when
"is" operator is used to compare an object to a string (like: x is
"abc").

I suggest to always require to return the unmodified string. Honestly,
it's not hard to guarantee and implement this behavior in Python!

IMHO you should also test if pre is non-empty just to make the intent
more explicit.

Note: please rename "pre" to "prefix".

In short, I propose:

 def cutprefix(self: str, prefix: str, /) -> str:
 if self.startswith(prefix) and prefix:
 return self[len(prefix):]
 else:
 return self

I call startswith() before testing if pre is non-empty to inherit of
startswith() input type validation. For example, "a".startswith(b'x')
raises a TypeError.

I also suggest to avoid/remove the duplicated "rough specification" of
the abstract: "s[len(pre):] if s.startswith(pre) else s". Only one
specification per PEP is enough ;-)


> The two methods will also be added to ``collections.UserString``,
> where they rely on the implementation of the new ``str`` methods.

I don't think that mentioning "where they rely on the implementation
of the new ``str`` methods" is worth it. The spec can leave this part
to the implementation.


> Motivating examples from the Python standard library
> 
>
> The examples below demonstrate how the proposed methods can make code
> one or more of the following: (...)

IMO there are too many examples. For example, refactor.py and
c_annotations.py are more or less the same. Just keep refactor.py.

Overall, 2 or 3 examples should be enough.


> Allow multiple prefixes
> ---
>
> Some users discussed the desire to be able to remove multiple
> prefixes, calling, for example, ``s.cutprefix('From: ', 'CC: ')``.
> However, this adds ambiguity about the order in which the prefixes are
> removed, especially in cases like ``s.cutprefix('Foo', 'FooBar')``.
> After this proposal, this can be spelled explicitly as
> ``s.cutprefix('Foo').cutprefix('FooBar')``.

I like the ability to specify multiple prefixes or suffixes. If the
order is an issue, only allow tuple and list types and you're done.

I don't see how disallowing s.cutprefix(('Foo', 'FooBar')) but
allowing s.cutprefix('Foo').cutprefix('FooBar') prevents any risk of
mistake.

I'm sure that there are many use cases for cutsuffix() accepting
multiple suffixes. IMO it makes the method even more attractive and
efficient.

Example to remove newline suffix (Dos, Unix and macOS newlines):
line.cutsuffix(("\r\n", "\n", "\r")). It's not ambitious: "\r\n" is
tested first explicitly, then "\r".


> Remove multiple copies of a prefix
> --
>
> This is the behavior that would be consistent with the aforementioned
> expansion of the ``lstrip/rstrip`` API -- repeatedly applying the
> function until the argument is unchanged.  This behavior is attainable
> from the proposed behavior via the following::
>
> >>> s = 'foo' * 100 + 'bar'
> >>> while s != (s := s.cutprefix("foo")): pass
> >>> s
> 'bar'

Well, even

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[MRAB]

On 2020-03-20 21:49, Dennis Sweeney wrote:

For clarity, I'll change

  If ``s`` does not have ``pre`` as a prefix, an unchanged copy of ``s`` is 
returned.

to

 If ``s`` does not have ``pre`` as a prefix, then ``s.cutprefix(pre)`` 
returns ``s`` or an unchanged copy of ``s``.

For consistency with the Specification section, I'll also change

 s[len(pre):] if s.startswith(pre) else s

to

 s[len(pre):] if s.startswith(pre) else s[:]

and similarly change the ``cutsuffix`` snippet.


If ``s`` is immutable, why return a copy when the original will do?

s[len(pre) : ] if pre and s.startswith(pre) else s

s[ : -len(suf)] if suf and s.endswith(suf) else s
___
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/AP6L5H4H3E3RP6FZD4NS6NTLNV4KCQMM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] (no subject)

[Dennis Sweeney]

Thanks for the review!

> In short, I propose:
>  def cutprefix(self: str, prefix: str, /) -> str:
>  if self.startswith(prefix) and prefix:
>  return self[len(prefix):]
>  else:
>  return self
> 
> I call startswith() before testing if pre is non-empty to inherit of
> startswith() input type validation. For example, "a".startswith(b'x')
> raises a TypeError.

This still erroneously accepts tuples and and would return return str
subclasses unchanged. If we want to make the Python be the spec with accuracy 
about type-checking, then perhaps we want:

def cutprefix(self: str, prefix: str, /) -> str:
if not isinstance(prefix, str):
raise TypeError(f'cutprefix() argument must be str, '
f'not {type(prefix).__qualname__}')
self = str(self)
prefix = str(prefix)
if self.startswith(prefix):
return self[len(prefix):]
else:
return self

I like the idea to always require these to return the unmodified string. Is 
there a reason this isn't specified by the ``replace()`` or ``strip`` methods?

For accepting multiple prefixes, I can't tell if there's a consensus about 
whether ``s = s.cutprefix("a", "b", "c")``
should be the same as

for prefix in ["a", "b", "c"]:
s = s.cutprefix(prefix)

or

for prefix in ["a", "b", "c"]:
if s.startwith(prefix):
s = s.cutprefix(prefix)
break

The latter seems to be harder for users to implement through other means, and 
it's the behavior that test_concurrent_futures.py has implemented now, so maybe 
that's what we want. Also, it seems more elegant to me to accept variadic 
arguments, rather than a single tuple of arguments. Is it worth it to match the 
related-but-not-the-same API of "startswith" if it makes for uglier Python? My 
gut reaction is to prefer the varargs, but maybe someone has a different 
perspective.

I can submit a revision to the PEP with some changes tomorrow.
___
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/GXGP5T5KC6ZEBZ5AON4G3MHIKO6MAU35/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Nathaniel Smith]

On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney
 wrote:
> This is a proposal to add two new methods, ``cutprefix`` and
> ``cutsuffix``, to the APIs of Python's various string objects.

The names should use "start" and "end" instead of "prefix" and
"suffix", to reduce the jargon factor and for consistency with
startswith/endswith.

-n

-- 
Nathaniel J. Smith -- https://vorpus.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/R4ND2KANMLS74AVKHUJ5BI5JM5QW5IC2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Cameron Simpson]

On 20Mar2020 13:57, Eric Fahlgren  wrote:

On Fri, Mar 20, 2020 at 11:56 AM Dennis Sweeney 
wrote:


If ``s`` is one these objects, and ``s`` has ``pre`` as a prefix, then
``s.cutprefix(pre)`` returns a copy of ``s`` in which that prefix has
been removed.  If ``s`` does not have ``pre`` as a prefix, an
unchanged copy of ``s`` is returned.  In summary, ``s.cutprefix(pre)``
is roughly equivalent to ``s[len(pre):] if s.startswith(pre) else s``.



The second sentence above unambiguously states that cutprefix returns 'an
unchanged *copy*', but the example contradicts that and shows that 'self'
may be returned and not a copy.  I think it should be reworded to
explicitly allow the optimization of returning self.


My versions of these (plain old functions) return self if unchanged, and 
are explicitly documented as doing so.


This has the concrete advantage that one can test for nonremoval if the 
suffix with "is", which is very fast, instead of == which may not be.


So one writes (assuming methods):

   prefix = cutsuffix(s, 'abc')
   if prefix is s:
   ... no change
   else:
   ... definitely changed, s != prefix also

I am explicitly in favour of returning self if unchanged.

Cheers,
Cameron Simpson 
___
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/YJPASLMACS2Y7B2PIQVASW3EY5Q2EAL3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proliferation of tstate arguments.

[Stephen J. Turnbull]

Victor Stinner writes:
 > Le jeu. 19 mars 2020 à 02:17, Kyle Stanley  a écrit :
 > > Agreed; a PEP (even if it's just informational) would go a long way in 
 > > helping to clear up some misunderstandings.
 > 
 > I am still moving blindly in the darkness of CPython internals and so
 > I don't feel comfortable to write a PEP which would mean that I know
 > what I am doing :-)

That's OK, you're not Dutch. :-)  Or are you? :-) :-)

 > So far, I have no strong opinion about passing explicitly tstate vs
 > "implicit" TLS (Thread Local Storage) variable. I mean, I don't feel
 > that I have enough feedback to see which option is the best.
 > 
 > All I can say is that passing explicitly tstate helps me to validate
 > that the code is *correct*. It helps me to understand where tstate
 > comes from and helps me to understand if tstate is valid or not.

That makes a lot of sense, as a strategy for doing the work.  It
should be pretty straightforward to convert the tstate argument to a
thread-local tstate.

But ... this sounds to me like work that should be done on a branch.

I'm sure you considered that, but I also expect others will feel the
same way.  Perhaps this is a good opportunity to document why it's not
being done on a branch.

 > There are still too many functions which don't work properly with
 > subinterpreters. There are still a few design issues that needs to
 > be addressed.

Are subinterpreters in use in production?  If so, and especially if
these use cases are unpatched vs. master, that would be justification
for pushing to master since you are clearly fixing problems with
subinterpreter use.  If not, I still tend to think this work should be
on a branch, at least until the tstate argument vs. thread-local
tstate question is resolved.

I realize that these are all abstract arguments in favor of work on a
branch.  I think it would be useful if you could provide concrete
reasons why work on master is a better way to proceed.  I wouldn't be
surprised if some of the examples of bugs and improvements you've
already given would be involved, and I just don't understand the
implications without explanation.

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

[Python-Dev] Re: Changing layout of f_localsplus in frame objects

[Nick Coghlan]

On Wed., 18 Mar. 2020, 3:24 am Skip Montanaro, 
wrote:

> (Apologies if you're seeing this twice. I first posted to the
> discourse instance.)
>
> I first worked on a register-based virtual machine in the 1.5.2
> timeframe. That was before PEP 227 (closures) landed. Prior to that,
> local variables and the stack were contiguous in the f_localsplus
> array. Based on a comment at the time from Tim Peters (which I recall
> but can no longer find), the number of required registers won’t be any
> greater than the maximum extent of the stack. (It makes sense, and
> worked for me at the time.) That allowed me to repurpose the stack
> space as my registers and treat the full f_localsplus array as a
> single large “register file,” eliminating LOAD_FAST_REG and
> STORE_FAST_REG instructions completely, which I believe was a major
> win.
>
> I want to rearrange the current f_localsplus to make locals and stack
> neighbors again. My first look at the code suggested there is no good
> reason it can’t be done, but figured Jeremy Hylton must have had a
> good reason to prefer the current layout which places cells and frees
> in the middle.
>
> While the necessary changes didn’t look extensive, they did look a bit
> tedious to get right, which I have confirmed. My first attempt to
> reorganize f_localsplus from locals/cells/frees/stack to
> locals/stack/cells/frees has been an abysmal failure. I’ve found a
> couple mistakes and corrected them. Implementing those corrections
> caused the types of failures to change (convincing me they were
> necessary), but did not eliminate them entirely (so, necessary, but
> not sufficient). I’ve clearly missed something. I’m also fairly
> ignorant about recent changes to the language (big understatement), so
> thought that before going any further, I would see if anyone with
> better current knowledge of frame objects knew of a reason why my
> desired layout change wouldn’t work.
>

I'm not aware of any fundamental reason it wouldn't work, but I would
expect the FastToLocals and LocalsToFast functions to require some
non-trivial adjustments to cope with the layout change (it's been a while
since I looked at the unmodified version of that code, but my recollection
is that it expects the locals and cell variables to be next to each other
so it can iterate over them as a single C array, rather than looping over
them separately).

Cheers,
Nick.


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

[Python-Dev] Re: Changing layout of f_localsplus in frame objects

[Skip Montanaro]

> ... I would expect the FastToLocals and LocalsToFast functions to require 
> some non-trivial adjustments ...

Thanks, Nick. I'm making precisely that change in a few places in
frameobject.c. One loop for locals, another for cells & frees, a third
for the stack (where the active stack is involved).

So far, my second go-round is proceeding better (fingers crossed). I
have added a new slot to the _frame struct (f_cellvars), initialized
once at creation, then referenced elsewhere. I'm also rerunning the
test suite more frequently. Once I've tweaked everything, all that
will remain (in theory) to effect my change is to tweak the
initialization of f_valuestack and f_cellvars. (If an extra slot is
determined to be too space-expensive, a macro or inline function would
suffice.)

Aside: To speed up my testing it would be kinda nice if you could tell
regrtest, "Just run X% of the tests at random plus any which failed on
the previous run," but it's not horrible as-is. If it doesn't already
exist (implying I didn't just miss it), perhaps it could be a good
"easy" feature request for core dev novitiates.

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

[Python-Dev] Re: Proliferation of tstate arguments.

[Nick Coghlan]

On Wed., 18 Mar. 2020, 8:36 pm Mark Shannon,  wrote:

>
>
> On 17/03/2020 7:00 pm, Steve Dower wrote:
> > On 17Mar2020 1803, Chris Angelico wrote:
> >> On Wed, Mar 18, 2020 at 3:50 AM Mark Shannon  wrote:
> >>> The accessibility of a thread-local variable is a strict superset of
> >>> that of a function-local variable.
> >>>
> >>> Therefore storing the thread state in a thread-local variable is at
> >>> least as capable as passing thread-state as a parameter.
> >>>
> >>
> >> And by that logic, globals are even more capable. I don't understand
> >> your point. Isn't the purpose of the tstate parameters to avoid the
> >> problem of being unable to have multiple tstates within the same OS
> >> thread? I think I've missed something here.
> >
> > You haven't. Separating the Python thread from the "physical" thread is
> > indeed the point.
>
> That seems like a strawman argument; maybe I'm misunderstanding Steve.
> It seems to me that Steve is implying that using thread-local variables
> somehow prevents that separation. It does not.
>
> The point I'm making is that adding `tstate` parameters everywhere is
> unnecessary. Using a thread local variable is much less intrusive and is
> at least as capable.
>

And that's why the primary public API will still work that way.

What the tstate work is doing is taking what are currently global functions
that work on implicitly passed state and effectively turning them into
C-style methods of the tstate struct.

The idea is to make it so that most internal APIs won't care about the
currently active thread state, they will instead operate on the tstate that
they're given. In the cases where it does matter, they'll either enforce
the equivalence through debug assertions or explicit checks, or else
they'll take care of changing the state themselves (rather than relying on
the caller to do it).

The way things are now, it's like instead of defining a normal Python class
instance and calling methods on it, we were instead defining a whole host
of module level functions that directly manipulated passive data-only class
instances stored in a thread local.

The state we're trying to get to is more akin to the way Decimal context
objects work: there's an active one stored in the thread local state, and
functions for retrieving and changing the active context, but once you
*have* a reference to a context object, you can use it directly via its
methods without needing to activate it first.

Cheers,
Nick.


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