[Python-ideas] Re: Implementing string unary operators

2021-10-20 Thread Steven D'Aprano
On Wed, Oct 20, 2021 at 11:30:50AM +0900, Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
> 
>  > Ironically, Ricky's in-fun suggestion that we use the tilde operator for 
>  > swapcase was the only suggestion in these two threads that actually met 
>  > the invariant for an inverse that ~~x == x.
> 
> You forgot about Turkish,

Yes I did, Turkish (and a couple of other Turkic languages) have dotted 
and dottless I, and their case rules differ from the default Unicode 
rules.


> I think it is, that has three cases (the
> third is called "title case".  Just another Joke that Broke because
> Unicode!

The Unicode titlecase algorithm is used for languages where digraphs 
like Lj, Nj, or Dz are classified as single letters of the alphabet. For 
example, the Polish word Dziewczyna uses the Dz digraph as the first 
letter. If you use the Unicode code point U+01F3 we get:

'dziewczyna'.upper()  # returns 'DZIEWCZYNA'
'dziewczyna'.title()  # returns 'Dziewczyna'

In case the glyphs don't show up for you, they are dz for the lowercase, 
DZ for the uppercase, and Dz for the titlecase.

swapcase() doesn't use titlecase. Titlecased characters remain 
unchanged when you use swapcase() on them.

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


[Python-ideas] Re: Implementing string unary operators

2021-10-19 Thread Stephen J. Turnbull
Steven D'Aprano writes:

 > Ironically, Ricky's in-fun suggestion that we use the tilde operator for 
 > swapcase was the only suggestion in these two threads that actually met 
 > the invariant for an inverse that ~~x == x.

You forgot about Turkish, I think it is, that has three cases (the
third is called "title case".  Just another Joke that Broke because
Unicode!


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


[Python-ideas] Re: Implementing string unary operators

2021-10-19 Thread Chris Angelico
On Wed, Oct 20, 2021 at 12:02 PM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2021-10-20 at 11:48:30 +1100,
> Chris Angelico  wrote:
>
> > TBH swapcase is a bit of a minefield if you don't know what language
> > you're working with.
>
> [...]
>
> > The most logical "negation" of a string would be reversing it, which
> > WOULD be... well, reversible. But that doesn't need an operator, since
> > it already has slice notation.
>
> Slice notation is also a minefield; [some] explosives are combining
> characters.

True, but since all of Python's indexing, slicing, etc, is defined by
codepoints, what that really means is that slicing/reversing a string
can cause peculiar behaviours. But that's true of many other types of
characters too; if you mix LTR and RTL text, with some directionless
text in between, you'll see some very peculiar behaviour when you
reverse it (try getting an English word, some ASCII digits, and an
Arabic word - the digits are the same ones that both languages use).
So I don't think combining characters are unique here.

"Reversing" text means many different things depending on context.

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


[Python-ideas] Re: Implementing string unary operators

2021-10-19 Thread 2QdxY4RzWzUUiLuE
On 2021-10-20 at 11:48:30 +1100,
Chris Angelico  wrote:

> TBH swapcase is a bit of a minefield if you don't know what language
> you're working with.

[...]

> The most logical "negation" of a string would be reversing it, which
> WOULD be... well, reversible. But that doesn't need an operator, since
> it already has slice notation.

Slice notation is also a minefield; [some] explosives are combining
characters.
___
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/W4P7XRM5C4DFSZUUSWEZAEA7HAC7ODEI/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-ideas] Re: Implementing string unary operators

2021-10-19 Thread Chris Angelico
On Wed, Oct 20, 2021 at 11:35 AM Steven D'Aprano  wrote:
>
> On Wed, Oct 20, 2021 at 11:10:52AM +1100, Chris Angelico wrote:
> > On Wed, Oct 20, 2021 at 11:02 AM Steven D'Aprano  
> > wrote:
> > > Ironically, Ricky's in-fun suggestion that we use the tilde operator for
> > > swapcase was the only suggestion in these two threads that actually met
> > > the invariant for an inverse that ~~x == x.
> > >
> >
> > >>> x = "ß"
> >
> > :) Okay, so it's *mostly* an invariant.
>
> Hah, well spotted!
>
> Ironically, there is an uppercase eszett, 'ẞ', although font support for
> it may still be limited. (Come on font designers, it has only been
> official in Unicode since 2008 and in German orthography in 2017).
>

Yes (and it shows up fine in both my web browser and my terminals),
but that only makes swapcase worse.

>>> s = "ẞ"
>>> print(s := s.swapcase())
ß
>>> print(s := s.swapcase())
SS
>>> print(s := s.swapcase())
ss

Fortunately, you can always rely on casefold to make things consistent:

>>> "ẞ".casefold() == "ß".casefold() == "SS".casefold() == "ss".casefold()
True

TBH swapcase is a bit of a minefield if you don't know what language
you're working with.

>>> "Iİıi".swapcase()
'ii̇II'

I'm not sure I've ever used it in production. Normally it's just
upper(), lower(), or title() for conversions, and casefold() for
comparisons.

The most logical "negation" of a string would be reversing it, which
WOULD be... well, reversible. But that doesn't need an operator, since
it already has slice notation.

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


[Python-ideas] Re: Implementing string unary operators

2021-10-19 Thread Ricky Teachey
I'm here all week. Tip your wait staff.

Also, genuine apologies if mine was perceived as mean-sarcastic. It was
definitely sarcastic but I hoped it was fun enough in tone not to seem
mean-spirited. I apologize sincerely and without reservation and I would do
it better next time. :)

On Tue, Oct 19, 2021, 8:35 PM Steven D'Aprano  wrote:

> On Wed, Oct 20, 2021 at 11:10:52AM +1100, Chris Angelico wrote:
> > On Wed, Oct 20, 2021 at 11:02 AM Steven D'Aprano 
> wrote:
> > > Ironically, Ricky's in-fun suggestion that we use the tilde operator
> for
> > > swapcase was the only suggestion in these two threads that actually met
> > > the invariant for an inverse that ~~x == x.
> > >
> >
> > >>> x = "ß"
> >
> > :) Okay, so it's *mostly* an invariant.
>
> Hah, well spotted!
>
> Ironically, there is an uppercase eszett, 'ẞ', although font support for
> it may still be limited. (Come on font designers, it has only been
> official in Unicode since 2008 and in German orthography in 2017).
>
> --
> 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/BSSSU5FWJDGWIJBCWQK7VMVAG5O2SJ7Q/
> 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/5XYGJNATVNV2VCUE66ODQL5OY7PBDVYX/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-ideas] Re: Implementing string unary operators

2021-10-19 Thread Steven D'Aprano
On Tue, Oct 12, 2021 at 05:30:13PM -0700, Guido van Rossum wrote:

> I would also like to remind various other posters that sarcasm is *not* a
> good way to welcome newbies. The name of the list is python-ideas, not
> python-ideas-to-shoot-down-sarcastically.

Guido, it isn't fair of you to jump into this thread and start scolding 
us for being sarcastic. Jelle's accusation that we "mostly" replied to 
Jerimiah with sarcasm was inaccurate.

The regulars here (especially Chris) spent a lot of time and effort 
trying to get Jerimiah to understand the need to justify the association 
between ord(), or some other arbitrary function, with the unary plus 
operator (or any other arbitrary operator). It is not nice to dismiss 
that effort as sarcastically shooting the idea down.


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


[Python-ideas] Re: Implementing string unary operators

2021-10-19 Thread Steven D'Aprano
On Wed, Oct 20, 2021 at 11:10:52AM +1100, Chris Angelico wrote:
> On Wed, Oct 20, 2021 at 11:02 AM Steven D'Aprano  wrote:
> > Ironically, Ricky's in-fun suggestion that we use the tilde operator for
> > swapcase was the only suggestion in these two threads that actually met
> > the invariant for an inverse that ~~x == x.
> >
> 
> >>> x = "ß"
> 
> :) Okay, so it's *mostly* an invariant.

Hah, well spotted!

Ironically, there is an uppercase eszett, 'ẞ', although font support for 
it may still be limited. (Come on font designers, it has only been 
official in Unicode since 2008 and in German orthography in 2017).

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


[Python-ideas] Re: Implementing string unary operators

2021-10-19 Thread Chris Angelico
On Wed, Oct 20, 2021 at 11:02 AM Steven D'Aprano  wrote:
> Ironically, Ricky's in-fun suggestion that we use the tilde operator for
> swapcase was the only suggestion in these two threads that actually met
> the invariant for an inverse that ~~x == x.
>

>>> x = "ß"

:) Okay, so it's *mostly* an invariant.

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


[Python-ideas] Re: Implementing string unary operators

2021-10-19 Thread Steven D'Aprano
On Tue, Oct 12, 2021 at 05:10:45PM -0700, Jelle Zijlstra wrote:

> Your other post mostly attracted sarcastic replies, so I'll be more direct:
> It's highly unlikely that this will go anywhere.

Jelle, the second part of your sentence may be true, but the first part 
is not. It is unfair and inaccurate to say that the other post "mostly" 
attracted sarcastic replies.

There was exactly one post that used sarcasm, by Ricky, and that was not 
biting or aggressive sarcasm, but just a bit of humour: that using unary 
operators for swapcase and titlecase could save a lot of typing.

Ironically, Ricky's in-fun suggestion that we use the tilde operator for 
swapcase was the only suggestion in these two threads that actually met 
the invariant for an inverse that ~~x == x.


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


[Python-ideas] Re: Implementing string unary operators

2021-10-14 Thread Jeremiah Vivian
(gonna test highlighting)
\>
___
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/2XMG555Y6TQ2FT4U62I75GPGU63KHYJ4/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-ideas] Re: Implementing string unary operators

2021-10-14 Thread Jeremiah Vivian
Now I didn't expect this thread to blow up in replies with alternatives, 
specifically `str1 / str2` for 'str1.split(str2)' and `seq1 * str` for 
'str.join(seq1)'.
___
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/LDLAZEXSYIVPECOODKEKGUHY3QSW6N3E/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-ideas] Re: Implementing string unary operators

2021-10-13 Thread 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

2021-10-13 Thread 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/


[Python-ideas] Re: Implementing string unary operators

2021-10-12 Thread Stephen J. Turnbull
It was written:

 > How is `int(string, 16)` "inverting"?

It's the inverse of f"{number:x}", of course.  Mappings between types
are ubiquitous, and (more or less) invertible ones are not uncommon.

It's an honest question, but I suggest we let slightly odd usage,
especially in scare quotes, pass.  It's not essential to understand
the proposal.

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


[Python-ideas] Re: Implementing string unary operators

2021-10-12 Thread Steven D'Aprano
On Wed, Oct 13, 2021 at 12:05:35AM -, MarylandBall Productions wrote:

> 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

How is `int(string, 16)` "inverting"?

Inverting means to flip or reverse, not to convert to another type. Even 
if it did, why convert to an int, rather than a float, or a list, or 
bytes, or any other type?

You could maybe make an argument for ~"Hello" to invert it by reversing 
horizontally "olleH" but even that would be pretty weak.

> ~string will be a confusing operation to many users.

I think it would be *all* users. I doubt that anyone could predict that 
the ~ operator converts to int using base 16 just by looking at the 
expression in isolation.

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


[Python-ideas] Re: Implementing string unary operators

2021-10-12 Thread Steven D'Aprano
On Tue, Oct 12, 2021 at 11:50:27PM -, Jeremiah Vivian wrote:

> I posted a previous thread about overloading the unary `+` operator in 
> strings with `ord`, and that expanded to more than just the unary `+` 
> operator. So I'm saying now, there should be these implementations:

Did you actually read people's comments in that other thread? If you did 
read that thread, you should have understood that before anyone takes 
your proposal seriously, you **must** justify why the unary operators 
should do what you want them to do.

So far, you have suggested:

+"s" == ord("s")
+string = int(string)
+string = string.lstrip()

with no justification for any of these beyond an *assumption* that 
calling the function ord() might be slower than using a unary operator. 
(That might be true, maybe, but I doubt it would be significantly 
slower.)

The point of my earlier email was to make it clear to you how random and 
arbitrary the choice of ord() for unary plus was, not to convince you to 
choose a different random and arbitrary choice.

What part of `+string` do you think CLEARLY and OBVIOUSLY means "convert 
the string to an int? Why would `-string` mean "convert to an int using 
octal" and `~string` mean base 16? Why not the other way?

Why map `+string` to lstrip() and `-string` to rstrip() instead of the 
other way? All these choices seem random and arbitrary.

You have still not posted any solid justification for why strings should 
support unary operators. You haven't even said "because I'm lazy and 
don't want to type a function name". At least that would be a reason. A 
bad reason, but still better than no reason at all.

So let me be completely frank:

- I think you have zero chance of this proposal being accepted.

- But if you were to have *any* chance at all, even one in a hundred 
  million, you need to start by giving some good reasons why unary
  operators should be used for strings at all.

- You need to justify the choices. What part of `~string` will make the 
  average Python programmer think of converting to an int in hex, or 
  striping whitespace?

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


[Python-ideas] Re: Implementing string unary operators

2021-10-12 Thread Guido van Rossum
On Tue, Oct 12, 2021 at 5:21 PM Jeremiah Vivian <
nohackingofkrow...@gmail.com> wrote:

> So I guess I'll just have to keep this to myself.
>

I know this is disappointing, but in this case I agree with Jelle -- this
particular idea does not fit well in Python's design, it looks like an
attempt at saving one opcode (or a few characters to type) for a relatively
rare use case.

However, I recommend that you don't give up! There are many ways Python can
still use improvement, and a few more attempts will help you calibrate your
ideas with what might be acceptable.

I would also like to remind various other posters that sarcasm is *not* a
good way to welcome newbies. The name of the list is python-ideas, not
python-ideas-to-shoot-down-sarcastically.

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


[Python-ideas] Re: Implementing string unary operators

2021-10-12 Thread Jeremiah Vivian
> "inverting" the string to another type
...That doesn't make any sense.
___
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/QTOXNA2SEHK72C2XYCFYUD2LZGMODVSC/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-ideas] Re: Implementing string unary operators

2021-10-12 Thread Chris Angelico
On Wed, Oct 13, 2021 at 11:21 AM MarylandBall Productions
 wrote:
>
> 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.
>

Can you give another example of where you invert something into
another type? I don't understand the analogy you're making here.

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


[Python-ideas] Re: Implementing string unary operators

2021-10-12 Thread Jeremiah Vivian
So I guess I'll just have to keep this to myself.
___
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/RQLGBJT6MW6QVKDLMYOGY5EJWWVHECWA/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-ideas] Re: Implementing string unary operators

2021-10-12 Thread 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.
___
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/LXE4ONWIOS7K5AHIZCVKQ4XF4CBV55UB/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-ideas] Re: Implementing string unary operators

2021-10-12 Thread Jelle Zijlstra
El mar, 12 oct 2021 a las 16:51, Jeremiah Vivian (<
nohackingofkrow...@gmail.com>) escribió:

> I posted a previous thread about overloading the unary `+` operator in
> strings with `ord`, and that expanded to more than just the unary `+`
> operator. So I'm saying now, there should be these implementations:
> > +string - `int(string, 10)` (or just `int(string)`)
> > -string - `int(string, 8)`
> > ~string - `int(string, 16)`
>
> Or:
> > +string - `string.lstrip()`
> > -string - `string.rstrip()`
> > ~string - `string.strip()`
>
> If anyone has better ideas, they can post it here.
>
Your other post mostly attracted sarcastic replies, so I'll be more direct:
It's highly unlikely that this will go anywhere.

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 don't think any of these proposals come close to meeting those criteria.


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


[Python-ideas] Re: Implementing string unary operators

2021-10-12 Thread Chris Angelico
On Wed, Oct 13, 2021 at 10:53 AM Jeremiah Vivian
 wrote:
>
> I posted a previous thread about overloading the unary `+` operator in 
> strings with `ord`, and that expanded to more than just the unary `+` 
> operator. So I'm saying now, there should be these implementations:
> > +string - `int(string, 10)` (or just `int(string)`)
> > -string - `int(string, 8)`
> > ~string - `int(string, 16)`
>
> Or:
> > +string - `string.lstrip()`
> > -string - `string.rstrip()`
> > ~string - `string.strip()`
>
> If anyone has better ideas, they can post it here.

Better idea: Just don't.

These are incredibly arbitrary and have very little association with
their symbols. They don't even have the "cute" value of constructing a
path by dividing a path by a string, or constructing an email address
using matrix multiplication.

Don't search for a meaning for some combination of symbols. Start with
meaning, and then think about the best way to spell it. In each of
these cases, the existing spelling is FAR better than anything
involving an operator.

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