I don't know if there's anything specifically stopping this, but from what I
understand, the precise moment that a finalizer gets called is unspecified, so
relying on any sort of behavior there is undefined and non-portable.
Implementations like PyPy don't always use reference counting, so their
I'm essentially writing to ask: how do you use lltrace? Does anyone rely on the
particular format of the output? Would some of these improvements be helpful to
you? What else could make it more helpful?
Thanks,
Dennis Sweeney
___
Python-Dev
Like others expressed, I don't like the idea of the typing and non-typing parts
of Python separating.
Has anyone considered adding a new special method like `__arrow__` or
something, that would be user-definable, but also defined for tuples and types
as returning a Callable? For example `int ->
STORE_FAST can also be caused by the assignment to a loop variable, so
STORE/LOAD pairs can come about with things like this:
>>> def f():
... for x in stuff:
... x.work()
...
...
>>> from dis import dis
>>> dis(f)
2 0 LOAD_GLOBAL
I think the C implementation of PyAiter_Check was a translation of the Python
code `isinstance(..., collections.abc.AsyncIterator)`, but I agree that it
would be more consistent to just check for __anext__. There were comments at
the time here: https://github.com/python/cpython/pull/8895#discuss
Here's my attempt at some heuristic motivation:
Try to construct a needle that will perform as poorly as possible when
using the naive two-nested-for-loops algorithm. You'll find that if
there isn't some sort of vague periodicity in your needle, then you
won't ever get *that* unlucky; each particu
Worth noting is that there is an existing loop-breaking mechanism,
but only for the newest exception being raised. In particular, option (4)
is actually the current behavior if the the most recent exception
participates in a cycle:
Python 3.9.0b1
>>> A, B, C, D, E = map(Exception, "ABCDE"
What about "balanced", "uniform", or "rectangular"?
___
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:/
Hello all,
It seems that most of the discussion has settled down, but I didn't quite
understand from reading PEP 1 what the next step should be -- is this an
appropriate time to open an issue on the Steering Council GitHub repository
requesting pronouncement on PEP 616?
Best,
Dennis
__
Sure -- I can add in a short list of those major changes.
Best,
Dennis
___
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
PEP 616 -- String methods to remove prefixes and suffixes
is available here: https://www.python.org/dev/peps/pep-0616/
Changes:
- Only accept single affixes, not tuples
- Make the specification more concise
- Make fewer stylistic prescriptions for usage
- Fix typos
A reference implementation GitH
> > One may also continue using ``startswith()``
> > and ``endswith()``
> > methods for control flow instead of testing the lengths as above.
> >
> > That's worse, in a sense, since "foofoobar".removeprefix("foo") returns
> "foobar" which still starts with "foo".
I meant that startswith might be
I like how that would take the pressure off of the Python sample. How's
something like this?
Specification
=
The builtin ``str`` class will gain two new methods which will behave
as follows when ``type(self) is str``::
def removeprefix(self: str, prefix: str,
I was trying to start with the the intended behavior of the str class, then
move on to generalizing to other classes, because I think completing a single
example and *then* generalizing is an instructional style that's easier to
digest, whereas intermixing all of the examples at once can get con
I appreciate the input and attention to detail!
Using the ``str()`` constructor was sort of what I had thought originally, and
that's why I had gone overboard with "casting" in one iteration of the sample
code. When I realized that this isn't quite "casting" and that ``__str__`` can
be overridd
> I don't understand that list bit -- surely, if I'm bothering to implement
> removeprefix and removesuffix in my subclass, I would also want
> to
> return self to keep my subclass? Why would I want to go through the extra
> overhead of either calling my own __getitem__ method, or have the
> str._
> I imagine it's an implementation detail of which ones depend on
> ``__getitem__``.
If we write
class MyStr(str):
def __getitem__(self, key):
raise ZeroDivisionError()
then all of the assertions from before still pass, so in fact *none* of
the methods rely on ``__getite
I was surprised by the following behavior:
class MyStr(str):
def __getitem__(self, key):
if isinstance(key, slice) and key.start is key.stop is key.end:
return self
return type(self)(super().__getitem__(key))
my_foo = MyStr("foo")
MY_FO
I'm removing the tuple feature from this PEP. So now, if I understand
correctly, I don't think there's disagreement about behavior, just about
how that behavior should be summarized in Python code.
Ethan Furman wrote:
> > It appears that in CPython, self[:] is self is true for base
> > str
> > o
There were at least two comments suggesting keeping it to one affix at a time:
https://mail.python.org/archives/list/python-dev@python.org/message/GPXSIDLKTI6WKH5EKJWZEG5KR4AQ6P3J/
https://mail.python.org/archives/list/python-dev@python.org/message/EDWFPEGQBPTQTVZV5NDRC2DLSKCXVJPZ/
But I didn't
It seems that there is a consensus on the names ``removeprefix`` and
``removesuffix``. I will update the PEP accordingly. I'll also simplify sample
Python implementation to primarily reflect *intent* over strict type-checking
correctness, and I'll adjust the accompanying commentary accordingly.
Steven D'Aprano wrote:
> On Tue, Mar 24, 2020 at 08:14:33PM -, Dennis Sweeney wrote:
> > I think then maybe it would be preferred to
> > use the something like the following in the PEP:
> > def cutprefix(self, prefix, /):
> > if isinstance(prefix, str)
I think my confusion is about just how precise this sort of "reference
implementation" should be. Should it behave with ``str`` and ``tuple``
subclasses exactly how it would when implemented? If so, I would expect the
following to work:
class S(str): __len__ = __getitem__ = __iter__ = None
Steven D'Aprano wrote:
> Having confirmed that prefix is a tuple, you call tuple() to
> make a copy of it in order to iterate over it. Why?
>
> Having confirmed that option is a string, you call str() on
> it to (potentially) make a copy. Why?
This was an attempt to ensure no one can do funny bu
This should be fixed now.
___
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/
Much appreciated! I will add that single quote and change those snippets to::
>>> s = 'FooBar' * 100 + 'Baz'
>>> prefixes = ('Bar', 'Foo')
>>> while len(s) != len(s := s.cutprefix(prefixes)): pass
>>> s
'Baz'
and::
>>> s = 'FooBar' * 100 + 'Baz'
>>> prefixes = ('Bar', 'Foo')
>>> while s.
Here's an updated version.
Online: https://www.python.org/dev/peps/pep-0616/
Source: https://raw.githubusercontent.com/python/peps/master/pep-0616.rst
Changes:
- More complete Python implementation to match what the type checking in
the C implementation would be
- Clarified that returnin
I like "removeprefix" and "removesuffix". My only concern before had been
length, but three more characters than "cut***fix" is a small price to pay for
clarity.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python
Is there a proven use case for anything other than the empty string as the
replacement? I prefer your "replacewhatever" to another "stripwhatever" name,
and I think it's clear and nicely fits the behavior you proposed. But should we
allow a naming convenience to dictate that the behavior should
> But Dennis, welcome to the wonderful world of change proposals, where
> you will experience insane amounts of pushback and debate on the
> finest points of bikeshedding, whether or not people actually even
> support the proposal at all...
Lol -- thanks!
In my mind, another reason that I like in
Even then, it seems that prefix is an established computer science term:
[1] https://en.wikipedia.org/wiki/Substring#Prefix
[2] Cormen, Thomas H.; Leiserson, Charles E.; Rivest, Ronald L. (1990).
Introduction to Algorithms (1st ed.). Chapter 15.4: Longest common subsequence
And a quick search re
Hi Victor. I accidentally created a new thread, but I intended everything below
as a response:
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:
>
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
> start
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
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-
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 on
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
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:
38 matches
Mail list logo
