[Python-ideas] Re: dict_items.__getitem__?

[Chris Angelico]

On Thu, Oct 14, 2021 at 8:04 AM Oscar Benjamin
 wrote:
>
> On Wed, 13 Oct 2021 at 18:30, Chris Angelico  wrote:
> >
> > On Thu, Oct 14, 2021 at 1:36 AM Oscar Benjamin
> >  wrote:
> > > Your suggestion is that this is a bug in map() which is a fair
> > > alternative view. Following through to its conclusion your suggestion
> > > is that every possible function like map, filter, and all the iterator
> > > implementations in itertools and in the wild should carefully wrap any
> > > internal non-next function call in try/except to change any potential
> > > StopIteration into a different exception type.
> >
> > Yes, because it is the map function that is leaking StopIteration.
>
> But it is not the map function that *raises* StopIteration. The
> exception "leaks" through map just like *all* exceptions "leak"
> through *all* Python functions in the absence of try/except. This is
> not normally referred to as "leaking" but rather as "propagating" and
> it is precisely the design of exceptions that they should propagate to
> the calling frame. The difference in the case of StopIteration is that
> it can be caught even if there is no try/except.

Wrong. You still won't catch StopIteration unless it is in one very
specific place: a __next__ function. Exactly the same as
AttributeError can be silently caught inside a __getattr__ function.
See my earlier post for full context, but the problem is right here:

def __next__(self):
return self.func(next(self.it))

The problem isn't the transformation function; the problem is that
__next__ is putting two completely different concepts (pumping the
iterator, and calling the transformation function) inside,
effectively, the same exception handling context.

> > > My view is that it would be better to have a basic primitive for
> > > getting an element from an iterable or for advancing an iterator that
> > > does not raise StopIteration in the first place. I would probably call
> > > that function something like "take" rather than "first" though. The
> > > reason I prefer introducing an alternative to next() is because I
> > > think that if both primitives were available then in the majority of
> > > situations next() would not be the preferred option.
> >
> > How will that solve anything though? You still need a way to advance
> > an iterator and get a value from it, or get told that there is no such
> > value. No matter what exception you choose, it will ALWAYS be possible
> > for the same problem to occur. Exceptions like ValueError will,
> > instead of early-aborting a map(), cause something to mistakenly think
> > that it couldn't parse a number, or something like that.
>
> I find it surreal that I am arguing that StopIteration is a uniquely
> problematic exception and that you seem to be arguing that it is not.
> Yet at the same time you are an author of a (successful!) PEP that was
> *entirely* about this very subject:
> https://www.python.org/dev/peps/pep-0479/

I find it surreal that people keep holding up PEP 479, disagreeing
with the document's wording, and assuming that I believe the altered
wording. I don't.

> The first two paragraphs of the rationale from the PEP:
> """
> The interaction of generators and StopIteration is currently somewhat
> surprising, and can conceal obscure bugs. An unexpected exception
> should not result in subtly altered behaviour, but should cause a
> noisy and easily-debugged traceback. Currently, StopIteration raised
> accidentally inside a generator function will be interpreted as the
> end of the iteration by the loop construct driving the generator.
>
> The main goal of the proposal is to ease debugging in the situation
> where an unguarded next() call (perhaps several stack frames deep)
> raises StopIteration and causes the iteration controlled by the
> generator to terminate silently. (Whereas, when some other exception
> is raised, a traceback is printed pinpointing the cause of the
> problem.)
> """
> I agree entirely with the above but every occurence of "generators"
> should have been generalised to "iterators" in order to address the
> problem fully.

No! Generators *ARE* special, because they don't have that same
concept. You can write map safely like this:

def map(func, iterable):
for value in iterable: yield func(value)

Since there's no call to next(), there's no expectation of
StopIteration. Since there's no __next__ function being defined,
there's no expectation that StopIteration has meaning. That's why
generators are different.

> You think this should be fixed in map. I think that the root of the
> problem is next. The PEP discusses changing next:
> https://www.python.org/dev/peps/pep-0479/#converting-the-exception-inside-next
> The idea was rejected on backward compatibility grounds: I am
> proposing that an alternative function could be added which unlike
> changing next would not cause compatibility problems.
>
> Although we may disagree about what is the best way to fix this I
> don't see how we can 

[Python-ideas] Re: Implementing additional string operators

[Serhiy Storchaka]

13.10.21 22:03, Marc-Andre Lemburg пише:
> Some examples:
> - removal of file extensions
> - removal of end tags
> - removal of units
> - removal of currencies
> - removal of standard suffixes
> - removal of wildcard patterns
> etc.
> 
> I find lots of such uses in the code bases I work with.

I did not have opportunity to use removesuffix yet. The problem is that
almost always when I need to remove a suffix or prefix, I need to know
whether it was removed or no. removesuffix does not help, it does not
even make the code shorter. And I need to support versions older than 3.9.


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2NMOTTVSCYOSCLNB3VMSC25LUAN552UH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dict_items.__getitem__?

[Oscar Benjamin]

On Wed, 13 Oct 2021 at 18:30, Chris Angelico  wrote:
>
> On Thu, Oct 14, 2021 at 1:36 AM Oscar Benjamin
>  wrote:
> > Your suggestion is that this is a bug in map() which is a fair
> > alternative view. Following through to its conclusion your suggestion
> > is that every possible function like map, filter, and all the iterator
> > implementations in itertools and in the wild should carefully wrap any
> > internal non-next function call in try/except to change any potential
> > StopIteration into a different exception type.
>
> Yes, because it is the map function that is leaking StopIteration.

But it is not the map function that *raises* StopIteration. The
exception "leaks" through map just like *all* exceptions "leak"
through *all* Python functions in the absence of try/except. This is
not normally referred to as "leaking" but rather as "propagating" and
it is precisely the design of exceptions that they should propagate to
the calling frame. The difference in the case of StopIteration is that
it can be caught even if there is no try/except.

> > My view is that it would be better to have a basic primitive for
> > getting an element from an iterable or for advancing an iterator that
> > does not raise StopIteration in the first place. I would probably call
> > that function something like "take" rather than "first" though. The
> > reason I prefer introducing an alternative to next() is because I
> > think that if both primitives were available then in the majority of
> > situations next() would not be the preferred option.
>
> How will that solve anything though? You still need a way to advance
> an iterator and get a value from it, or get told that there is no such
> value. No matter what exception you choose, it will ALWAYS be possible
> for the same problem to occur. Exceptions like ValueError will,
> instead of early-aborting a map(), cause something to mistakenly think
> that it couldn't parse a number, or something like that.

I find it surreal that I am arguing that StopIteration is a uniquely
problematic exception and that you seem to be arguing that it is not.
Yet at the same time you are an author of a (successful!) PEP that was
*entirely* about this very subject:
https://www.python.org/dev/peps/pep-0479/

The first two paragraphs of the rationale from the PEP:
"""
The interaction of generators and StopIteration is currently somewhat
surprising, and can conceal obscure bugs. An unexpected exception
should not result in subtly altered behaviour, but should cause a
noisy and easily-debugged traceback. Currently, StopIteration raised
accidentally inside a generator function will be interpreted as the
end of the iteration by the loop construct driving the generator.

The main goal of the proposal is to ease debugging in the situation
where an unguarded next() call (perhaps several stack frames deep)
raises StopIteration and causes the iteration controlled by the
generator to terminate silently. (Whereas, when some other exception
is raised, a traceback is printed pinpointing the cause of the
problem.)
"""
I agree entirely with the above but every occurence of "generators"
should have been generalised to "iterators" in order to address the
problem fully.

You think this should be fixed in map. I think that the root of the
problem is next. The PEP discusses changing next:
https://www.python.org/dev/peps/pep-0479/#converting-the-exception-inside-next
The idea was rejected on backward compatibility grounds: I am
proposing that an alternative function could be added which unlike
changing next would not cause compatibility problems.

Although we may disagree about what is the best way to fix this I
don't see how we can disagree that StopIteration is a uniquely
problematic exception to raise (as you seem to argue above).

--
Oscar
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/M5CD7FP5ETIZRFPENZX3PO63BQ7NJ5IZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Structure Pattern for annotation

[David Mertz, Ph.D.]

I find myself using exactly that "picture of the data" approach informally
for code I don't plan on formally type checking (but want to show intent).

E.g.

def myfun(data: {str: [CustomType]}) -> [(int, OtherType)]: ...

Maybe it's a bad habit, but it feels easier to parse visually than the real
`typing.py` stuff.


On Wed, Oct 13, 2021, 4:35 PM Abdulla Al Kathiri <
alkathiri.abdu...@gmail.com> wrote:

> Hello,
>
> Today I found myself write a function that returns a tuple of list of list
> of strings (tuple[list[list[str]], list[list[str]]]). Wouldn’t it easier to
> read to write it like the following:
> ([[str]], [[str]])?
> Similarly for TypedDict, replace the following..
>
> class Movie(TypedDict):
> name: str
> year: int
>
> with
> {‘name’: str, ‘year’: int}
> dict[str, int] will be {str: int}
> set[int] will be {int}.
> This is similar to the new proposed Callable alternative (i.e., (int,
> float) -> float) since it mimics the structure of a function.
>
> Also, Annotated[float, “seconds”] can be replaced with something like
> float #seconds indicating whatever comes after the hashtag is just extra
> information similar to a normal comment in the code.
> Imagine you could replace the following
> def func(d: dict[Annotated[str, “product label”], Annotated[list[float],
> “prices from 2000 to 2015”]])…
> With
> def func(d: {str # product label: [float] # prices from 2000 to 2015})…
> Abdulla
> Sent from my iPhone
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/D6LHXDXPN6K27KV6MZBLG66ZSGCNDRG7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HYBIYHKE4ZAKTV33VB4AE37MG576KYH5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing additional string operators

[Serhiy Storchaka]

13.10.21 22:53, Peter Ludemann пише:
> [*] Floating point x+y isn't always y+x, but floating point is its own 
> problematic world.

AFAIK floating point x+y is always y+x, but (x+y)+z is not always x+(y+z).

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NNR3OD5KBCX2FAMOT5DBVGBZFDDKVMUC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Structure Pattern for annotation

[Abdulla Al Kathiri]

Hello, 

Today I found myself write a function that returns a tuple of list of list of 
strings (tuple[list[list[str]], list[list[str]]]). Wouldn’t it easier to read 
to write it like the following:
([[str]], [[str]])? 
Similarly for TypedDict, replace the following..
class Movie(TypedDict):
name: str
year: int
with 
{‘name’: str, ‘year’: int}
dict[str, int] will be {str: int} 
set[int] will be {int}. 
This is similar to the new proposed Callable alternative (i.e., (int, float) -> 
float) since it mimics the structure of a function. 

Also, Annotated[float, “seconds”] can be replaced with something like float 
#seconds indicating whatever comes after the hashtag is just extra information 
similar to a normal comment in the code. 
Imagine you could replace the following 
def func(d: dict[Annotated[str, “product label”], Annotated[list[float], 
“prices from 2000 to 2015”]])… 
With 
def func(d: {str # product label: [float] # prices from 2000 to 2015})… 
Abdulla 
Sent from my iPhone___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/D6LHXDXPN6K27KV6MZBLG66ZSGCNDRG7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing additional string operators

[Peter Ludemann]

MRAB wrote:

> From a mathematical point of view, x-y is equivalent to x+(-y).

>From a mathematical point of view, x+y is equivalent to y+x, but I suppose 
>that ship has sailed a long long time ago. ("++", "--", etc. would have been 
>better choices for operators)[*]

Anyway, if you're going to add these operators for strings, I suggest also 
adding them for lists. And also make them work with the new match syntax.

[*] Floating point x+y isn't always y+x, but floating point is its own 
problematic world.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/L54PEC35IQ7SLZANDQQEEGARXRININS5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing additional string operators

[Marc-Andre Lemburg]

On 13.10.2021 20:47, Paul Moore wrote:
> On Wed, 13 Oct 2021 at 19:02, <2qdxy4rzwzuui...@potatochowder.com> wrote:
> 
>> So aside from filename extensions, what are the real use cases for
>> suffix removal?  Plurals?  No, too locale-dependent and too many
>> exceptions.  Whitespace left over from external data?  No, there's
>> already other functions for that (and regexen and actual parsers if
>> they're not good enough).  Directory traversal?  No, that's what path
>> instances and the os module are for.
> 
> I think this is a good point. Is removesuffix really useful enough to
> warrant having an operator *as well as* a string method? It was only
> added in 3.9, so we've been managing without it at all for years,
> after all...

Sure, but that's not evidence that this kind of operation is not
common.

Some examples:
- removal of file extensions
- removal of end tags
- removal of units
- removal of currencies
- removal of standard suffixes
- removal of wildcard patterns
etc.

I find lots of such uses in the code bases I work with.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Oct 13 2021)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/L66YTUILBF2RUVVPGDQIBZCHKUPWQSHS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing additional string operators

[Paul Moore]

On Wed, 13 Oct 2021 at 19:02, <2qdxy4rzwzuui...@potatochowder.com> wrote:

> So aside from filename extensions, what are the real use cases for
> suffix removal?  Plurals?  No, too locale-dependent and too many
> exceptions.  Whitespace left over from external data?  No, there's
> already other functions for that (and regexen and actual parsers if
> they're not good enough).  Directory traversal?  No, that's what path
> instances and the os module are for.

I think this is a good point. Is removesuffix really useful enough to
warrant having an operator *as well as* a string method? It was only
added in 3.9, so we've been managing without it at all for years,
after all...

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WFS5LM2ZMBUZS7VWELVIFHRNPYXYZN5I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing additional string operators

[Abdur-Rahmaan Janhangeer]

Greetings list,

Looking at the examples, I'm not sure how well this would play out
in the context of just using variables, though:

s = a - s
s = a / c
s = a ~ p

By adding such operators we could potentially make math functions
compatible with strings by the way of duck typing, giving some
really weird results, instead of errors.

Well, i think that since everything in Python is an object, this example can
apply to anything. Like you need to put it in context. It's not a problem
per se.

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YP2ANQJOZT4N2FREMHFH57M53F6UTFWC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing additional string operators

[2QdxY4RzWzUUiLuE]

On 2021-10-14 at 04:34:24 +1100,
Chris Angelico  wrote:

> On Thu, Oct 14, 2021 at 2:21 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> >
> > On 2021-10-14 at 00:00:25 +0900,
> > "Stephen J. Turnbull"  wrote:
> >
> > > Chris Angelico writes:
> > >
> > >  > +1, although it's debatable whether it should be remove suffix or
> > >  > remove all. I'd be happy with either.
> > >
> > > If by "remove all" you mean "efefef" - "ef" == "", I think that's a
> > > footgun.  Similarly for "efabcd" - "ef" == "abcdef" - "ef".
> >
> > I don't know whether it qualifies as prior art, but in Erlang (a
> > language emphatically *not* known for its string handling), strings are
> > lists of codepoints, and the list subtraction operator¹ is spelled "--":
> >
> > The list subtraction operator -- produces a list that is a copy of
> > the first argument. The procedure is a follows: for each element in
> > the second argument, the first occurrence of this element (if any)
> > is removed.
> >
> > Example:
> >
> > 2> [1,2,3,2,1,2]--[2,1,2].
> > [3,1,2]
> >
> > And from my interactive prompt:
> >
> > 4> "abcdef" -- "ef".
> > "abcd"
> > 5> "abcdef" -- "ab".
> > "cdef"
> >
> > ¹ http://erlang.org/doc/reference_manual/expressions.html#list-operations
> 
> It definitely counts as prior art. Another language that allows string
> subtraction is Pike:
> 
> > "abcdef" - "ab";
> (1) Result: "cdef"
> 
> I don't think it's quite such a foot-gun as you might think; but on
> the other hand, I'm also quite happy to see string subtraction defined
> in terms of removesuffix, since that IS a closer inverse to string
> addition. It'd end up being one of those cases where both behaviours
> are useful, and I'd just have to change gears when coding in multiple
> languages. (Which has to happen anyway. There's plenty of little
> differences, like modulo with negative numbers.)

The footgun is coding in multiple languages.  You're in a maze of twisty
little passages, all different.  ;-)  Just remember to use your clutch
when you change gears.

So aside from filename extensions, what are the real use cases for
suffix removal?  Plurals?  No, too locale-dependent and too many
exceptions.  Whitespace left over from external data?  No, there's
already other functions for that (and regexen and actual parsers if
they're not good enough).  Directory traversal?  No, that's what path
instances and the os module are for.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LRUGCVPQDCFKVW52OD2F5S34BVYS2TWA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing additional string operators

[Chris Angelico]

On Thu, Oct 14, 2021 at 2:21 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2021-10-14 at 00:00:25 +0900,
> "Stephen J. Turnbull"  wrote:
>
> > Chris Angelico writes:
> >
> >  > +1, although it's debatable whether it should be remove suffix or
> >  > remove all. I'd be happy with either.
> >
> > If by "remove all" you mean "efefef" - "ef" == "", I think that's a
> > footgun.  Similarly for "efabcd" - "ef" == "abcdef" - "ef".
>
> I don't know whether it qualifies as prior art, but in Erlang (a
> language emphatically *not* known for its string handling), strings are
> lists of codepoints, and the list subtraction operator¹ is spelled "--":
>
> The list subtraction operator -- produces a list that is a copy of
> the first argument. The procedure is a follows: for each element in
> the second argument, the first occurrence of this element (if any)
> is removed.
>
> Example:
>
> 2> [1,2,3,2,1,2]--[2,1,2].
> [3,1,2]
>
> And from my interactive prompt:
>
> 4> "abcdef" -- "ef".
> "abcd"
> 5> "abcdef" -- "ab".
> "cdef"
>
> ¹ http://erlang.org/doc/reference_manual/expressions.html#list-operations

It definitely counts as prior art. Another language that allows string
subtraction is Pike:

> "abcdef" - "ab";
(1) Result: "cdef"

I don't think it's quite such a foot-gun as you might think; but on
the other hand, I'm also quite happy to see string subtraction defined
in terms of removesuffix, since that IS a closer inverse to string
addition. It'd end up being one of those cases where both behaviours
are useful, and I'd just have to change gears when coding in multiple
languages. (Which has to happen anyway. There's plenty of little
differences, like modulo with negative numbers.)

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WSOIV7UMSJUASPLW67VUOVQF326P5EWI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dict_items.__getitem__?

[Chris Angelico]

On Thu, Oct 14, 2021 at 1:36 AM Oscar Benjamin
 wrote:
> Your suggestion is that this is a bug in map() which is a fair
> alternative view. Following through to its conclusion your suggestion
> is that every possible function like map, filter, and all the iterator
> implementations in itertools and in the wild should carefully wrap any
> internal non-next function call in try/except to change any potential
> StopIteration into a different exception type.

Yes, because it is the map function that is leaking StopIteration.

> My view is that it would be better to have a basic primitive for
> getting an element from an iterable or for advancing an iterator that
> does not raise StopIteration in the first place. I would probably call
> that function something like "take" rather than "first" though. The
> reason I prefer introducing an alternative to next() is because I
> think that if both primitives were available then in the majority of
> situations next() would not be the preferred option.

How will that solve anything though? You still need a way to advance
an iterator and get a value from it, or get told that there is no such
value. No matter what exception you choose, it will ALWAYS be possible
for the same problem to occur. Exceptions like ValueError will,
instead of early-aborting a map(), cause something to mistakenly think
that it couldn't parse a number, or something like that.

Try replacing your map() with one of my safer versions. (Or, of
course, replacing your remove_header with a version that isn't itself
buggy.) The problem will disappear.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FGSAIJP3SHLPD5XUZBBCX2MCZIZT3IVS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing additional string operators

[MRAB]

On 2021-10-13 16:26, Marc-Andre Lemburg wrote:

On 13.10.2021 17:11, Guido van Rossum wrote:

Maybe we should only accept operators as aliases for existing methods.

x-y could mean x.removesuffix(y)


That was the idea, yes, in particular to make it similar to "+",
which adds to the end of the string, so that:

s = x - oldend + newend

works as expected.


I don't think x~y is intuitive enough to use.


True.

I tried to find an operator that looked similar to "-", but
"~" would only work as unary operator, a Chris correctly pointed
out, and even if it were a binary one, it would look too
similar to "-" and also doesn't play well when used on a single
line.

s = newstart + (x ~ oldstart)

So I withdraw that proposal.


From a mathematical point of view, x-y is equivalent to x+(-y).

That leads me to me "negative" strings that, when added to a string, 
remove characters instead of adding them.


For example:

"abcdef" - "ef" == "abcdef" + (-"ef") == "abcd"

and also:

(-"ab") + "abcdef" == "cdef"

Voilà! An alternative to .removeprefix. :-)


On Wed, Oct 13, 2021 at 8:03 AM Stephen J. Turnbull mailto:stephenjturnb...@gmail.com>> wrote:

Chris Angelico writes:

 > +1, although it's debatable whether it should be remove suffix or
 > remove all. I'd be happy with either.

If by "remove all" you mean "efefef" - "ef" == "", I think that's a
footgun.  Similarly for "efabcd" - "ef" == "abcdef" - "ef".

Steve




___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VLB465I7UGTLLFVSJWQAUPVPARIDVKUI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing additional string operators

[Marc-Andre Lemburg]

On 13.10.2021 17:11, Guido van Rossum wrote:
> Maybe we should only accept operators as aliases for existing methods.
> 
> x-y could mean x.removesuffix(y)

That was the idea, yes, in particular to make it similar to "+",
which adds to the end of the string, so that:

s = x - oldend + newend

works as expected.

> I don't think x~y is intuitive enough to use.

True.

I tried to find an operator that looked similar to "-", but
"~" would only work as unary operator, a Chris correctly pointed
out, and even if it were a binary one, it would look too
similar to "-" and also doesn't play well when used on a single
line.

s = newstart + (x ~ oldstart)

So I withdraw that proposal.

> On Wed, Oct 13, 2021 at 8:03 AM Stephen J. Turnbull 
>  > wrote:
> 
> Chris Angelico writes:
> 
>  > +1, although it's debatable whether it should be remove suffix or
>  > remove all. I'd be happy with either.
> 
> If by "remove all" you mean "efefef" - "ef" == "", I think that's a
> footgun.  Similarly for "efabcd" - "ef" == "abcdef" - "ef".
> 
> Steve
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Oct 13 2021)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TFUOXQAHBYZFON2BU2MQ62HI4HKNLCZX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing additional string operators

[2QdxY4RzWzUUiLuE]

On 2021-10-14 at 00:00:25 +0900,
"Stephen J. Turnbull"  wrote:

> Chris Angelico writes:
> 
>  > +1, although it's debatable whether it should be remove suffix or
>  > remove all. I'd be happy with either.
> 
> If by "remove all" you mean "efefef" - "ef" == "", I think that's a
> footgun.  Similarly for "efabcd" - "ef" == "abcdef" - "ef".

I don't know whether it qualifies as prior art, but in Erlang (a
language emphatically *not* known for its string handling), strings are
lists of codepoints, and the list subtraction operator¹ is spelled "--":

The list subtraction operator -- produces a list that is a copy of
the first argument. The procedure is a follows: for each element in
the second argument, the first occurrence of this element (if any)
is removed.

Example:

2> [1,2,3,2,1,2]--[2,1,2].
[3,1,2]

And from my interactive prompt:

4> "abcdef" -- "ef".
"abcd"
5> "abcdef" -- "ab".
"cdef"

¹ http://erlang.org/doc/reference_manual/expressions.html#list-operations
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WGIJAJSVR4XKXV4F34QFUIC65T7HE4N7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing additional string operators

[Ricky Teachey]

On Wed, Oct 13, 2021, 11:01 AM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:

Chris Angelico writes:

 > +1, although it's debatable whether it should be remove suffix or
 > remove all. I'd be happy with either.

If by "remove all" you mean "efefef" - "ef" == "", I think that's a
footgun.  Similarly for "efabcd" - "ef" == "abcdef" - "ef".

Steve


Maybe it should be "remove the first one" rather than a suffix.

Then for removal of multiple substrings, you could allow the RHS to be a
sequence of substrings:

>>> "efaxefef" - "ef"
"axefef"
>>> "efaxefef" - ["ef", "ax"]
"efef"
>>> "efaxefef" - ["ef"]*3
"ax"

BTW these are interesting ideas and I'm just exploring the possibilities.
Not proposing or agreeing with anything.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/E3OWMUU7C2P2WT53PYWDMVWNKHCZR7WF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing additional string operators

[Guido van Rossum]

Maybe we should only accept operators as aliases for existing methods.

x-y could mean x.removesuffix(y)

I don't think x~y is intuitive enough to use.

On Wed, Oct 13, 2021 at 8:03 AM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:

> Chris Angelico writes:
>
>  > +1, although it's debatable whether it should be remove suffix or
>  > remove all. I'd be happy with either.
>
> If by "remove all" you mean "efefef" - "ef" == "", I think that's a
> footgun.  Similarly for "efabcd" - "ef" == "abcdef" - "ef".
>
> Steve
>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/UGRD4QCDGRPOOCDMLPZ7EXWJFKM22AGO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XASP7G7O74AHFNBLVFQN6WKFDYEHCUEZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing additional string operators

[Stephen J. Turnbull]

Chris Angelico writes:

 > +1, although it's debatable whether it should be remove suffix or
 > remove all. I'd be happy with either.

If by "remove all" you mean "efefef" - "ef" == "", I think that's a
footgun.  Similarly for "efabcd" - "ef" == "abcdef" - "ef".

Steve


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UGRD4QCDGRPOOCDMLPZ7EXWJFKM22AGO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: dict_items.__getitem__?

[Oscar Benjamin]

On Tue, 12 Oct 2021 at 12:50, Chris Angelico  wrote:
>
> On Tue, Oct 12, 2021 at 10:24 PM Oscar Benjamin
>  wrote:
> >
> > On Tue, 12 Oct 2021 at 11:48, Chris Angelico  wrote:
> >>
> >> ValueError is no safer. The first() function would have, as its API,
> >> "returns the first element or raises ValueError if there is none". So
> >> now the caller of first() has to use try/except to handle the case
> >> where there is no value. Failing to do so is *just as buggy* as
> >> leaking a StopIteration.
> >>
> >> A leaky StopIteration is a majorly confusing bug inside a __next__
> >> function, because StopIteration is part of that function's API.
> >
> > On the contrary: a __next__ function is the only place where it could 
> > possibly be valid to raise StopIteration. The fact that next raises 
> > StopIteration which passes through to the caller can be useful in this 
> > situation and this situation alone:
> > https://github.com/python/cpython/blob/b37dc9b3bc9575adc039c6093c643b7ae5e917e1/Lib/csv.py#L111
> >
> > In any other situation it would be better to call first() and have 
> > something like ValueError instead.
> >
>
> Yes, but that's an example of __next__ specifically chaining to next()
> - exactly like defining __getattr__ to look for an attribute of
> something else (maybe you're writing a proxy of some sort). You expect
> that a bubbling-up exception is fundamentally equivalent to one you
> raise yourself.
>
> Please give a real example of where calling first() and getting
> ValueError is safer than calling next(iter(x)) and getting
> StopIteration. So far, I am undeterred in believing that the two
> exceptions have equivalent effect if the caller isn't expecting them.

I think that the situation where I first came across this was
something analogous to wanting to separate the header line of a CSV
file:

csvfiles = [
['name', 'joe', 'dave'],
['name', 'steve', 'chris'],
[],  # whoops, empty csv file
['name', 'oscar'],
]

def remove_header(csvfile):
it = iter(csvfile)
next(it)
return it

# print all names from all csv files
for names in map(remove_header, csvfiles):
for name in names:
print(name)

If you run the above you get

$ python t.py
joe
dave
steve
chris

The data following the empty file (i.e. "oscar") was silently
discarded. The context where I found this was something that took much
longer to run and was harder to check and debug etc. I have not
personally made the same mistake again because I have since been
automatically wary of any usage of next(). I couldn't possibly count
the number of times I've seen unsafe usage of next in code suggestions
on mailing lists like this though (see all the examples above in this
thread).

The problem is that the erroneous case which is the empty file leads
to a StopIteration. Unlike a normal exception though, a StopIteration
can be caught without try/except. In the above it is the *for-loop*
that swallows the exception. Had it been literally any other exception
type then you would have been looking at a Traceback instead of
silently discarded data:

$ python t.py
joe
dave
steve
chris
Traceback (most recent call last):
  File "t.py", line 21, in 
for names in map(remove_header, csvfiles):
  File "t.py", line 18, in remove_header
first(it)
  File "t.py", line 14, in first
raise ValueError from None
ValueError

Your suggestion is that this is a bug in map() which is a fair
alternative view. Following through to its conclusion your suggestion
is that every possible function like map, filter, and all the iterator
implementations in itertools and in the wild should carefully wrap any
internal non-next function call in try/except to change any potential
StopIteration into a different exception type.

My view is that it would be better to have a basic primitive for
getting an element from an iterable or for advancing an iterator that
does not raise StopIteration in the first place. I would probably call
that function something like "take" rather than "first" though. The
reason I prefer introducing an alternative to next() is because I
think that if both primitives were available then in the majority of
situations next() would not be the preferred option.

--
Oscar
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SYXMROAL4B5GR5NQ5VHLXDU4IXYNS4UV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing additional string operators

[Chris Angelico]

On Wed, Oct 13, 2021 at 7:57 PM Marc-Andre Lemburg  wrote:
>
> The idea to use "-" in the context of strings may have some
> merrit. Not as unary minus, but as sequence operation and
> shorthand for str.removesuffix(x):
>
> s = 'abc' + 'def' - 'ef' + 'gh'
>
> giving
>
> s == 'abcdgh'
>
> Removing suffixes from strings is a rather common operation.

+1, although it's debatable whether it should be remove suffix or
remove all. I'd be happy with either.

> Removing prefixes is common as well, so perhaps "~" could be
> mapped to str.removeprefix():
>
> s = 'abcdef' ~ 'abc'
>
> giving
>
> s == 'def'

Less obvious but convenient also. Unfortunately, tilde is a unary
operator, so this won't actually work.

> In a similar way, "/" could be mapped to str.split(), since that's
> probably even more common:
>
> l = 'a,b,c,d' / ','
>
> giving:
>
> l == ['a', 'b', 'c', 'd']

Definitely. In any language that supports this, I use it frequently.
It should be matched with seq*str to join:

["a", "b", "c","d"] * ","

to give "a,b,c,d".

> Looking at the examples, I'm not sure how well this would play out
> in the context of just using variables, though:
>
> s = a - s
> s = a / c
> s = a ~ p

In my experience, there's often one constant and one variable involved, such as:

lines = data / "\n"
words = line / " "
outputfile = inputfile - ".md" + ".html"

> By adding such operators we could potentially make math functions
> compatible with strings by the way of duck typing, giving some
> really weird results, instead of errors.

Maybe, but I wouldn't consider that to be a particularly high
priority. If they work, great, if they don't, so be it. The math
module itself is primarily focused on float math, not even int.

+1.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/62GRB66EL4MSJPRHJMF6D5BNYFEZW3CJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Implementing additional string operators

[Marc-Andre Lemburg]

The idea to use "-" in the context of strings may have some
merrit. Not as unary minus, but as sequence operation and
shorthand for str.removesuffix(x):

s = 'abc' + 'def' - 'ef' + 'gh'

giving

s == 'abcdgh'

Removing suffixes from strings is a rather common operation.

Removing prefixes is common as well, so perhaps "~" could be
mapped to str.removeprefix():

s = 'abcdef' ~ 'abc'

giving

s == 'def'

In a similar way, "/" could be mapped to str.split(), since that's
probably even more common:

l = 'a,b,c,d' / ','

giving:

l == ['a', 'b', 'c', 'd']


Looking at the examples, I'm not sure how well this would play out
in the context of just using variables, though:

s = a - s
s = a / c
s = a ~ p

By adding such operators we could potentially make math functions
compatible with strings by the way of duck typing, giving some
really weird results, instead of errors.

Cheers,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Oct 13 2021)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IPOPOUJ7MDOQ3QXXXZWO726725EDNJPY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing string unary operators

[Serhiy Storchaka]

13.10.21 03:10, Jelle Zijlstra пише:
> To get a new operator on a builtin type, you'll have to show that:
> - It's a common operation;
> - There's no convenient way to do it already; and
> - The meaning of the operator is reasonably clear to a reader of the code.
> 
> Recent examples of new features that met that bar are dict |
> in https://www.python.org/dev/peps/pep-0584
>  and matrix multiply
> in https://www.python.org/dev/peps/pep-0465/
> .

I think it fails two first criteria. It is not enough common operation
and we already did have convenient ways to do it.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EAKLSXOIE54FAJ3XSYTL3CEMQSEURD4M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Implementing string unary operators

[Serhiy Storchaka]

13.10.21 03:05, MarylandBall Productions пише:
> I would think `~string` could be good for a shorthand way to convert a string 
> to an integer, considering you’re “inverting” the string to another type, 
> though a downside to this would be that explicit is always better than 
> implicit and ~string will be a confusing operation to many users.

Then it should be a shorthand for json.loads().

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FLACCH36WYOPFLQTEWHFFGKCLPZZDV3X/
Code of Conduct: http://python.org/psf/codeofconduct/