[Python-ideas] The Mailing List Digest Project
As proposed on python-ideas, i setup a repo to turn mail threads into articles. here is the repo https://github.com/Abdur-rahmaanJ/py-mailing-list-summary i included a script to build .md to .html (with syntax highlighting) here is the index https://abdur-rahmaanj.github.io/py-mailing-list-summary/ included 3 articles as a start if you want to contribute an article, just follow existing .md format and put it in the .md folder planning to go across ideas, list and dev i can tell you, it's a really enjoyable experience. psst. we can enhance some html later -- Abdur-Rahmaan Janhangeer Mauritius ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A directive for indentation type, stricter indentation parsing.
Just as to your example, you can try `textwrap.dedent` At 2019-03-26 00:32:26, "Mikhail V" wrote: >Not a proposal yet, but some thoughts: >I think it would help in a longer perspective if a user could >include a directive in the header of the source code file that >defines indentation character(s) for this source file. So this >source would be parsed strictly by this char (or sequence). > >E.g.: > ># indent "\t" >... > >Would force the Python parser to use exactly 1 tab for 1 indent level. > ># indent "" >... > >Would accordingly force the parser to use exactly 4 spaces for >1 indent level. > >Frankly I don't have much proof in hand for that will be a good >addition, but intuitively I suppose it would help with some possible >future features and in general, ease the development of source >processors. > >One possible example: if a potential future feature would require >a statement, and moreover require it to be indentation-aware? >Lets take e.g. a multi-line string: > >s = """ >Hello >world >""" >print (s) > >>>> > >Hello >world > > >Here it is not so intuitive (unless you already know) how the string would >be parsed (given that Python blocks are actually indentation-based). >So if one would want to try introduce a new indent-aware string type and >look into possible parsing disambiguation scenarios - it will be not an >easy task. >E.g. say one proposes a syntax for auto-unindented string block: > >s = !!! >Hello >world >print (s) >>>> >Hello >world > >(no leading newline, no leading indent in resulting string, which is a bit more >expected result IMO). > >Then it seems one can define the parsing rule unambiguously _only_ >if one has a strictly defined character sequence for the indent level >(e.g. 1 tab or 4 spaces, but not both). >Thus it seems such a directive would be a prerequisite for such feature. > >And in general, I think it could help to make automatic conversions from one >type of indentation to other easier. > > > >Mikhail >___ >Python-ideas mailing list >Python-ideas@python.org >https://mail.python.org/mailman/listinfo/python-ideas >Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
Dan Sommers wrote: So what it is "hello" - "world"? If we were to implement the entire group, it would be an element that can't be written in any simpler form. We could do that by representing a string as a sequence of signed substrings, and performing cancellations whereever possible during concatenation. But that would be a huge amount of machinery just to provide a cute notation for removing a prefix or suffix, with little in the way of other obvious applications. -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
On Mon, 25 Mar 2019 at 17:49, Anders Hovmöller wrote: > > > All of this would be well served by a 3rd party library on PyPI. Strings > > already have plenty of methods (probably too many). Having `stringtools` > > would be nice to import a bunch of simple functions from. > > I respectfully disagree. This isn't javascript where we are OK with millions > of tiny dependencies. Python is batteries included and that's a great thing. > This is just a tiny battery that was overlooked :) While batteries included is a very good principle (and one I've argued for strongly in the past) it's also important to remember that Python is a mature language, and the days of being able to assume that "most people" will be on a recent version are gone. Adding these functions to the stdlib would mean that *only* people using Python 3.8+ would have access to them (and in particular, library authors wouldn't be able to use them until they drop support for all versions older than 3.8). Having the functions as an external library makes them accessible to *every* Python user. As with everything, it's a trade-off. IMO, in this case the balance is in favour of a 3rd party library (at least initially - it's perfectly possible to move the library into the stdlib later if it becomes popular). Paul ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A directive for indentation type, stricter indentation parsing.
On Mon, Mar 25, 2019 at 9:33 AM Mikhail V wrote: > Not a proposal yet, but some thoughts: > I think it would help in a longer perspective if a user could > include a directive in the header of the source code file that > defines indentation character(s) for this source file. So this > source would be parsed strictly by this char (or sequence). > This is more of a linter thing than a language thing, so I would propose you take it to the code-quality mailing list. -Brett > > E.g.: > > # indent "\t" > ... > > Would force the Python parser to use exactly 1 tab for 1 indent level. > > # indent "" > ... > > Would accordingly force the parser to use exactly 4 spaces for > 1 indent level. > > Frankly I don't have much proof in hand for that will be a good > addition, but intuitively I suppose it would help with some possible > future features and in general, ease the development of source > processors. > > One possible example: if a potential future feature would require > a statement, and moreover require it to be indentation-aware? > Lets take e.g. a multi-line string: > > s = """ > Hello > world > """ > print (s) > > >>> > > Hello > world > > > Here it is not so intuitive (unless you already know) how the string would > be parsed (given that Python blocks are actually indentation-based). > So if one would want to try introduce a new indent-aware string type and > look into possible parsing disambiguation scenarios - it will be not an > easy task. > E.g. say one proposes a syntax for auto-unindented string block: > > s = !!! > Hello > world > print (s) > >>> > Hello > world > > (no leading newline, no leading indent in resulting string, which is a bit > more > expected result IMO). > > Then it seems one can define the parsing rule unambiguously _only_ > if one has a strictly defined character sequence for the indent level > (e.g. 1 tab or 4 spaces, but not both). > Thus it seems such a directive would be a prerequisite for such feature. > > And in general, I think it could help to make automatic conversions from > one > type of indentation to other easier. > > > > Mikhail > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] META: Is a PEP a good place to record Python's core design decisions and coding principles?
On Sun, Mar 24, 2019 at 10:34 AM Jonathan Fine wrote: > Guido van Rossum wrote: > >> I think this belongs in a personal blog, not on python-ideas and >> definitely not in a PEP. >> > > I don't agree, but I will accept that judgement, as if Guido still had > BDFL status. > To help add more weight to what Guido said, it doesn't belong here and it only belongs in a PEP if that PEP is justifying the feature to begin with. IOW we don't need a PEP justifying every design decision that we have prior to the PEP process. -Brett > -- > Jonathan > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
> All of this would be well served by a 3rd party library on PyPI. Strings > already have plenty of methods (probably too many). Having `stringtools` > would be nice to import a bunch of simple functions from. I respectfully disagree. This isn't javascript where we are OK with millions of tiny dependencies. Python is batteries included and that's a great thing. This is just a tiny battery that was overlooked :) / Anders ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
On 3/25/2019 10:55 AM, David Mertz wrote: All of this would be well served by a 3rd party library on PyPI. Strings already have plenty of methods (probably too many). Having `stringtools` would be nice to import a bunch of simple functions from. I agree. -- Terry Jan Reedy ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
On 3/25/2019 6:22 AM, Jonathan Fine wrote: Instead of naming these operations, we could use '+' and '-', with semantics: # Set the values of the variables. >>> a = 'hello ' >>> b = 'world' >>> c = 'hello world' # Some values between the variables. >>> a + b == c True >>> a == c - b True >>> b = -a + c True Summary: using '-' for trimming works well for postfixes, badly for prefixes, and not at all for infixes. Clever but not too practical since trimming prefixes seems to be more common than trimming postfixes. -- Terry Jan Reedy ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] A directive for indentation type, stricter indentation parsing.
Not a proposal yet, but some thoughts: I think it would help in a longer perspective if a user could include a directive in the header of the source code file that defines indentation character(s) for this source file. So this source would be parsed strictly by this char (or sequence). E.g.: # indent "\t" ... Would force the Python parser to use exactly 1 tab for 1 indent level. # indent "" ... Would accordingly force the parser to use exactly 4 spaces for 1 indent level. Frankly I don't have much proof in hand for that will be a good addition, but intuitively I suppose it would help with some possible future features and in general, ease the development of source processors. One possible example: if a potential future feature would require a statement, and moreover require it to be indentation-aware? Lets take e.g. a multi-line string: s = """ Hello world """ print (s) >>> Hello world Here it is not so intuitive (unless you already know) how the string would be parsed (given that Python blocks are actually indentation-based). So if one would want to try introduce a new indent-aware string type and look into possible parsing disambiguation scenarios - it will be not an easy task. E.g. say one proposes a syntax for auto-unindented string block: s = !!! Hello world print (s) >>> Hello world (no leading newline, no leading indent in resulting string, which is a bit more expected result IMO). Then it seems one can define the parsing rule unambiguously _only_ if one has a strictly defined character sequence for the indent level (e.g. 1 tab or 4 spaces, but not both). Thus it seems such a directive would be a prerequisite for such feature. And in general, I think it could help to make automatic conversions from one type of indentation to other easier. Mikhail ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] I'm saying goodbye for a bit
Hi I've been active recently in some threads, that have become a bit heated. To help things cool down, I won't be posting for a while. I don't know how long, but certainly not until Wednesday 3 April. You can of course contact me off-list if you want. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
All of this would be well served by a 3rd party library on PyPI. Strings
already have plenty of methods (probably too many). Having `stringtools`
would be nice to import a bunch of simple functions from.
On Mon, Mar 25, 2019 at 10:45 AM Alex Grigoryev wrote:
> strip_prefix and strip_suffix I think are the best names from all and work
> perfectly with auto completion. Common use case:
>
> " mailto:ma...@gmail.com".strip().strip_prefix("mailto:;)
>
>
> On Mar 25 2019, at 4:40 pm, Anders Hovmöller wrote:
>
>
> Earlier, Anders wrote:
> I propose naming them strip_prefix() and strip_suffix() and just skip the
> one that does both sides since it makes no sense to me.
>
> This is good, except I prefer subtract_prefix(a, b), truncate_suffix etc.
> And for the two step process prefix_subtractor(a)(b) etc.
>
>
> I don't understand the logic for "subtract". That's not a thing for
> non-numbers.
>
> If you don't think "strip" is good, then I suggest "remove". Or one could
> also consider "without" since we're talking about something that removes
> /if present/ (making subtract even worse! Subtract doesn't stop at zero).
> So "without_prefix()".
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> [image: Sent from Mailspring]
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
strip_prefix and strip_suffix I think are the best names from all and work
perfectly with auto completion. Common use case:
" mailto:ma...@gmail.com".strip().strip_prefix("mailto:;)
On Mar 25 2019, at 4:40 pm, Anders Hovmöller wrote:
>
> > Earlier, Anders wrote:
> > I propose naming them strip_prefix() and strip_suffix() and just skip the
> > one that does both sides since it makes no sense to me.
> >
> > This is good, except I prefer subtract_prefix(a, b), truncate_suffix etc.
> > And for the two step process prefix_subtractor(a)(b) etc.
> I don't understand the logic for "subtract". That's not a thing for
> non-numbers.
> If you don't think "strip" is good, then I suggest "remove". Or one could
> also consider "without" since we're talking about something that removes /if
> present/ (making subtract even worse! Subtract doesn't stop at zero). So
> "without_prefix()".
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
On Mon, Mar 25, 2019 at 7:30 AM Rhodri James wrote: > On 25/03/2019 12:01, Jonathan Fine wrote: > > Chris Angelico asked: what does a negative string look like? > > > > This is a very good question. It looks a bit like a negative number. > > They really don't. Negative numbers are well defined in terms of being > the additive inverse of natural numbers. String concatenation doesn't > have a well-defined inverse, as you demonstrated by not actually trying > to define it. It strikes me that following this line of reasoning is at > best a category error. > I assume the whole proposal was a pastiche of the proposal to add a + operator for dictionaries. Jonathan needs to come clean before more people waste their time discussing this. -- --Guido van Rossum (python.org/~guido) ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
Rhodri James wrote: > They really don't. Negative numbers are well defined in terms of being > the additive inverse of natural numbers. String concatenation doesn't > have a well-defined inverse, > In an earlier post I showed (assuming some knowledge of group theory) that for strings in the two letters 'a' and 'b', allowing negative strings give rise to what mathematicians call the free group on 2 letters, which is an enormous object. If you want the math, look at https://en.wikipedia.org/wiki/Free_group#Construction [Except previously I linked to the wrong part of the page.] Free groups are a difficult concept, usually introduced at post-graduate level. If you can tell me you understand that concept, I'm happy on that basis to explain how it provides string concatenation with a well-defined inverse. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
> Earlier, Anders wrote: > I propose naming them strip_prefix() and strip_suffix() and just skip the one > that does both sides since it makes no sense to me. > > This is good, except I prefer subtract_prefix(a, b), truncate_suffix etc. And > for the two step process prefix_subtractor(a)(b) etc. I don't understand the logic for "subtract". That's not a thing for non-numbers. If you don't think "strip" is good, then I suggest "remove". Or one could also consider "without" since we're talking about something that removes /if present/ (making subtract even worse! Subtract doesn't stop at zero). So "without_prefix()". ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
Earlier, Anders wrote: I propose naming them strip_prefix() and strip_suffix() and just skip the one that does both sides since it makes no sense to me. This is good, except I prefer subtract_prefix(a, b), truncate_suffix etc. And for the two step process prefix_subtractor(a)(b) etc. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
On 25/03/2019 12:01, Jonathan Fine wrote: Chris Angelico asked: what does a negative string look like? This is a very good question. It looks a bit like a negative number. They really don't. Negative numbers are well defined in terms of being the additive inverse of natural numbers. String concatenation doesn't have a well-defined inverse, as you demonstrated by not actually trying to define it. It strikes me that following this line of reasoning is at best a category error. -- Rhodri James *-* Kynesim Ltd ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
Here, concisely, is my view of the situation and my preferences. Mostly, I
won't give supporting arguments or evidence.
We can TRUNCATE either PRE or the POST, and similarly SUBTRACT.
SUBTRACT can raise a ValueError.
TRUNCATE always returns a value.
Interactive examples (not tested)
>>> from somewhere import post_subtract
>>> sub_ed = post_subtract('ed')
>>> sub_ed('fred')
>>> 'fr'
>>> sub_ed('lead')
ValueError
Similarly
>>> trunc_ed('fred')
'fr'
>>> trunc_ed('lead')
'lead'
Can be 'combined into one'
>>> pre_truncate('app')('applet)
'let'
>>> pre_truncate('app')('paper')
'paper'
Possibly
1. Allow pre_truncate('app', 'applet'), perhaps with different spelling.
2. Allow '-' as a symbol for subtract. (Likely to be controversial.)
I'm not particularly attached to the names. But I definitely think
3. None of these are string methods. (So pure Python implementation
automatically backports.)
4. Encourage a 'two-step' process. This allow separation of concerns, and
encourage good names.
Supporting argument.
When we write
pre_subtract(suffix, s)
the suffix has a special meaning. For example, it's the header. So in one
module define and test a routine remove_header. And in another module use
remove_header. That way, the user of remove_header only needs to know the
business purpose of the command. And the implementer needs to know only the
value of the header.
If the specs change, and the implementer needs to use regular expressions,
then this does not affect the user of remove_header.
I hope this helps. Maybe others would like to express their preferences.
--
Jonathan
--
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
I think this is a terrible idea. I also think it's a mistake that python uses +
for string concatenation and * for string repeat. You end up with type errors
far from the first place you could have had the crash! That ship has obviously
sailed buy we shouldn't make even more mistakes in the same vain because we
have some Stockholm syndrome with the current state of the language, or for a
misplaced ideal of consistency.
> On 25 Mar 2019, at 11:22, Jonathan Fine wrote:
>
> Instead of naming these operations, we could use '+' and '-', with semantics:
>
> # Set the values of the variables.
> >>> a = 'hello '
> >>> b = 'world'
> >>> c = 'hello world'
>
> # Some values between the variables.
> >>> a + b == c
> True
> >>> a == c - b
> True
> >>> b = -a + c
> True
>
># Just like numbers except.
> >>> a + b == b + a
> False
>
> This approach has both attractions and problems. And also decisions. The main
> issue, I think come to this. Suppose we have
> a, A = ('a', -'a')
> b, B = ('b', -'b')
> a + A == A + a == ''
> b + B == B + b == ''
> A + '' == '' + A == A
> B + '' == '' + B == B
> together with unrestricted addition of a, A, b, B then we have what
> mathematicians call the free group on 2 letters, which is an enormous object.
> If you want the math, look at,
> https://en.wikipedia.org/wiki/Free_group#Examples
>
> We've made a big mistake, I think, if we allow Python programmers to
> accidentally encounter this free group. One way to look at this, is that we
> want to cut the free group down to a useful size. One way is
>>>> 'hello ' - 'world' == 'hello' # I like to call this truncation.
>True
> Another way is
> >>> 'hello' - 'world' # I like to call this subtraction.
>ValueError: string s1 does not end with s2, so can't be subtracted
>
> I hope this little discussion helps with naming things. I think this is
> enough for now.
>
> --
> Jonathan
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
On 3/25/19 7:01 AM, Jonathan Fine wrote:
Chris Angelico asked: what does a negative string look like?
This is a very good question. It looks a bit like a negative number.
>>> 2 + 2
4
>>> len('aa' + 'bb')
4
>>> len(-'bb')
-2 # Odd, I must confess.
>>> 5 + (-1)
4
>>> len('hello')
5
>>> len(-'o')
-1
>>> 'hello' + (-'o')
'hell'
>>> len('hello' + (-'o'))
4
Grade school: How can I possible have -3 apples in my bag.
University: How can I possibly be overdrawn in my bank account.
Negative strings are similar to negative numbers except:
For numbers a + b == b + a
For strings a + b != b + a
It is the non-commuting that make negative strings difficult. This is a bit
like computer programming. It's not enough to have the correct lines of
code (or notes). They also have to be put in the right order.
In the abstract, I believe I understand what Jonathan is
saying, and in the concrete, I understand Chris's objection.
Ridding a string of some of the graphemes from one end, or
the other, or both, or elsewhere, is one or more different
operations on the same underlying data type. We just went
through this with dictionaries.
So what it is "hello" - "world"?
"hello" because it doesn't end in "world"?
"hello" because it doesn't begin with "world"?
"he" because that's "hello" with all the graphemes also in
"world" removed?
"he" because that's "hello" with all the graphemes also in
"world" removed from the end?
"hello" because that's "hello" with all the graphemes also
in "world" removed from the begining?"
And once we pick one of those results, what operator(s)
produce the others and don't lead to perl or APL?
And no matter how much Python I learn, I still can't divide
by zero or by an empty string. ;-)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
More on negative strings. They are easier, if they only use one character.
Red Queen: What's one and one and one and one and one and one and one and
one and one and one and one and one and one?
Alice: I don't know. I lost count.
Red Queen: She can't do arithmetic.
3 --> 'aaa'
2 --> 'aa'
1 --> 'a'
0 --> ''
-1 -> -'a'
-2 -> -'aa'
-3 -> -'aaa'
Negative strings are easier if we can rearrange the order of the letters.
Like anagrams.
>>> ''.join(sorted('forty five'))
' effiortvy'
>>> ''.join(sorted('over fifty'))
' effiortvy'
Instead of counting (positively and negatively) just the letter 'a', we do
the whole alphabet.
By when order matters, we get an enormous free group, which Python
programmers by accident see.
I hope this helps.
--
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
Chris Angelico asked: what does a negative string look like?
This is a very good question. It looks a bit like a negative number.
>>> 2 + 2
4
>>> len('aa' + 'bb')
4
>>> len(-'bb')
-2 # Odd, I must confess.
>>> 5 + (-1)
4
>>> len('hello')
5
>>> len(-'o')
-1
>>> 'hello' + (-'o')
'hell'
>>> len('hello' + (-'o'))
4
Grade school: How can I possible have -3 apples in my bag.
University: How can I possibly be overdrawn in my bank account.
Negative strings are similar to negative numbers except:
For numbers a + b == b + a
For strings a + b != b + a
It is the non-commuting that make negative strings difficult. This is a bit
like computer programming. It's not enough to have the correct lines of
code (or notes). They also have to be put in the right order.
I hope this helps. I do this sort of math all the time, and enjoy it. Your
experience may be different.
--
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
On Mon, Mar 25, 2019 at 9:24 PM Jonathan Fine wrote: > > Instead of naming these operations, we could use '+' and '-', with semantics: > > # Set the values of the variables. > >>> a = 'hello ' > >>> b = 'world' > >>> c = 'hello world' > > # Some values between the variables. > >>> a + b == c > True > >>> a == c - b > True > >>> b = -a + c > True > The semantics are rather underdefined here. What *exactly* does string subtraction do? Is a-b equivalent to a.replace(b, "") or something else? Also you imply that it's possible to negate a string and then add it, but... what does a negative string look like? *confused* ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] New explicit methods to trim strings
Instead of naming these operations, we could use '+' and '-', with
semantics:
# Set the values of the variables.
>>> a = 'hello '
>>> b = 'world'
>>> c = 'hello world'
# Some values between the variables.
>>> a + b == c
True
>>> a == c - b
True
>>> b = -a + c
True
# Just like numbers except.
>>> a + b == b + a
False
This approach has both attractions and problems. And also decisions. The
main issue, I think come to this. Suppose we have
a, A = ('a', -'a')
b, B = ('b', -'b')
a + A == A + a == ''
b + B == B + b == ''
A + '' == '' + A == A
B + '' == '' + B == B
together with unrestricted addition of a, A, b, B then we have what
mathematicians call the free group on 2 letters, which is an enormous
object. If you want the math, look at,
https://en.wikipedia.org/wiki/Free_group#Examples
We've made a big mistake, I think, if we allow Python programmers to
accidentally encounter this free group. One way to look at this, is that we
want to cut the free group down to a useful size. One way is
>>> 'hello ' - 'world' == 'hello' # I like to call this truncation.
True
Another way is
>>> 'hello' - 'world' # I like to call this subtraction.
ValueError: string s1 does not end with s2, so can't be subtracted
I hope this little discussion helps with naming things. I think this is
enough for now.
--
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
