[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Thierry Parmentelat]

> On 19 May 2020, at 20:27, Brett Cannon  wrote:
> 
> I'm going to ask that people please try to keep this thread on-topic to the 
> question of using Unicode characters directly for things that we currently 
> use two ASCII characters to represent. Other ideas that spring up from this 
> question are totally welcome to be done as new threads of discussion.

Thank you for re-focusing the discussion

I’d like to express the strong opinion that anything related to a particular 
IDE is not the right answer
I’m not going to switch to jetbrains just to get ligatures or fancy rendering, 
am I ? would you ?

Plus, it’s not only IDE’s, I’m prominently concerned by beginners and students, 
who start reading code on sources like github, or teaching websites, or 
notebooks; one cannot expect all these stacks to go this extra mile, that is 
just not right IMHO


back to the point as phrased by Brett:

I reckon the languages communities have mostly so far stuck to ASCII, probably 
for good reasons, 
but the thing is Unicode has been around for quite some time now, and can be 
deemed generally available
so why not take full advantage of it ? 
It is my feeling that part of the awkwardness of the typing annotations, 
rightfully outlined above, is due to the narrow set of characters at our 
disposal, hence the awkward Iterable[] (this one at least clearly deserves 
better IMHO), and Dict[,] likewise
There has to be nicer and more legible ways to express all these

I tend to start the discussion on typing annotations because they are more 
recent, and clearly more in need of improvement
however like Alex Hall pointed out, using dedicated symbols like 
> quoting   ≤ instead of <=, ≥ instead of >=, ≠ instead of !=,
would make a lot of sense as well 


I also reckon it is still cumbersome to simply enter Unicode characters from a 
keyboard sometimes; I guess if the big players were located in other countries 
that would maybe be different
But that will change over time, no matter the speed, some day that will be for 
granted
So again maybe 2020 is the right time to break that barrier ?


===
PS. it looks like one reasonable thread to spawn off from the earlier exchanges 
here 
is about the definition of an arrow operator for defining function types
I’ll leave it to the person who originally extended the discussion in that 
direction :)
___
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/U3PAVI4QT7LXJKT2MNP7PJ4T6DO7LUQZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Ethan Furman]

On 05/17/2020 12:02 PM, Rob Cliffe via Python-ideas wrote:

On 17/05/2020 19:43, David Mertz wrote:



The API matter is really orthogonal to this.  My point here is that
 Nathan and some other discussants are operating under the assumption
 that: "Everyone really wants strict-zip but they just haven't had a
 way to express it conveniently. They all assume their iterables are
 the same length already, so this just adds a check."

I disagree strongly with that assumption.  I think that the actual
majority of my uses of zip are non-strict.


But a lot of users (including you, in a minority of cases) can, *if
they choose*, benefit from a 'strict' version.
So what is wrong (ceteribus paribus) with making it easy for them to
 do so?


Coefficient of friction.

Importing from a stdlib module is not a hardship, so going from the status quo to "from 
itertools import zip_strict" is already making it "easy for them to do so".

Adding it as a flag makes it too easy (temptingly easy according to the PEP) to 
use zip_strict, so now the pendulum will swing the other direction and we'll 
get spurious errors.  Nothing dissuades from proper safety consciousness like 
spurious errors and excessive warnings. (YMMV)

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

[Python-ideas] Re: Optional keyword arguments

[Rob Cliffe via Python-ideas]

On 17/05/2020 20:17, James Lu wrote:

Many a python programmer have tired to see code written like:

def bar(a1, a2, options=None):
 if options is None:
options = {}
 ... # rest of function

syntax if argument is not passed, evaluate {} and store to options
def foo(options:={}): pass
syntax if argument is not passed or is None, evaluate {} and store to options*
def foo(options?={}): pass

The Zen of Python states "there shouldn't be two ways to do the same thing."

Thus, only one of ":=" or "?=" should be adopted. They should be evalued on:
  - Which encourages writing better code?
  - Which catches mistakes easier?

Do we want to encourage callers to pass None to indicate default arguments?

spam = { data: True } if arg else None
bar(a1, a2, param=spam)

versus

bar(a1, a2, { data: True }) if arg else bar(a1, a2)

versus

_ = foo.curry(a1, a2)
_({data: True}) if arg else _(a1, a2)

Since Python is a strongly typed language, it seems more consistent to me that
this code should throw an error:
def getoptions():
 ... # code to get options
 # whoops! missing return statement
 #return os.environ
foo(a1, a2, param=getoptions())

:= should be adopted because it catches mistakes more quickly.

On the other hand, ?= replaces the "if kwarg is not None: kwarg = ..." idiom.

(I propose adopting only ":=". I show "?=" as a strawman.)
This seems to have some merit.  It is quite common, I believe, to want 
an argument's default value to
be evaluated on each call (and beginners are often confused when it 
isn't), and to use the idiom James quotes:


def bar(a1, a2, options=None):
if options is None:
   options = {}

Allowing `options:={}` will confuse beginners, but many of them are already 
confused.:-)



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

[Python-ideas] Re: str.strip: argument maxstrip

[David Mertz]

On Tue, May 19, 2020 at 8:43 PM Cameron Simpson  wrote:

> >salt = salt.rstrip("=", maxstrip=2)
> >assert not salt.endswith("=")
>
> Reiterating the Python 3.9 suggestion, what about:
>
>   salt2 = salt.cutsuffix(('==', '='))
>

You'd have to call cutsuffix twice.  Valid base64 might end in one, two, or
zero '=', but the result wants to have none.  Actually, no... even two
calls won't always do the right thing.  I'm happy to have the new method
.cutsuffix() , but I don't think it addresses this case.

I was going to suggest an example about dynamically built path components
that may or may not end in '/'.  However:

A. I couldn't find an example in my own code easily, even though I know
I've fiddled with that
B. Someone would scold me for playing with strings rather than using
Pathlib (they'd be right, I realize... but I am sinful in my quick-script
ways).

I'll let someone else, like the OP, advance the case more.  I kinda like
it, but it's not a big deal for me.

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/365KHHD2XJHCQVT7HU6SRBED5GNXIZDP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[James Lu]

The "if arg is None: arg = " pattern occurs in the standard library eighty-five 
(85) times.

This command was used to find the count:
~/cpython/Lib$ perl -wln -e "/(?s)^(\s*)[^\n]if ([a-zA-Z_]+) is 
None:(\n)?\s+\2\s*=\s*/s and print" **
___
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/GWAJ62PZHDIS37NJ6WW4FCGDMDNMLPQK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: str.strip: argument maxstrip

[Cameron Simpson]

On 19May2020 15:43, David Mertz  wrote:
I may be misunderstanding, but it sounds like = is not acceptable in 
the

final result, so it's not enough to remove only 2 of 4 ='s. You want to
make sure nothing messed up your string. So if the code existed, what you'd
want is:




```
assert salt.count("=") <= 2
salt = salt.rstrip("=", "")
assert "=" not in salt
```



I think the code I'd want, if the new parameter existed, would be:

salt = salt.rstrip("=", maxstrip=2)
assert not salt.endswith("=")


Reiterating the Python 3.9 suggestion, what about:

 salt2 = salt.cutsuffix(('==', '='))

I appreciate this isn't as _general_ as a maxstrip param, but it seems 
to neatly address the single use case you've found.


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

[Python-ideas] Re: str.strip: argument maxstrip

[David Mertz]

On Tue, May 19, 2020 at 3:50 PM Alex Hall  wrote:

> Anyway, you could write:
> assert not salt.endswith("=" * 3)  # at most 2 ='s allowed
> salt = salt.rstrip("=")
>

Yes, I *could* write that.  It feels a bit more  cryptic than the version I
mentioned.  But it's fine.

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/LPRFI4KS7FFK2MOJV7LZUCGWTKSH7TSQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Eric V. Smith]

On 5/19/2020 4:53 PM, Rob Cliffe via Python-ideas wrote:
I have already replied to the OP and to the list, but there seems to 
be a problem with my posts getting through,

so let me try again.  Apologies if you see this twice:

To strip at most 1 character from the end:
    txt[:-1] + txt[-1:].rstrip(chars)
To strip at most N characters:
    txt[:-N] + txt[-N:].rstrip(chars)


Assuming N==0 means "don't do anything", you'll to test for that case.

Eric



Rob Cliffe

On 18/05/2020 19:32, Caleb Donovick wrote:
Certainly the way default arguments work with mutable types is not 
the most intuitive and I think your complaint has some merit.


However how would you define the following to work:

def foo():
    cons = [set(), [], (),]
    funs = []
    for ds in cons:
        def g(arg:=ds):
            return arg
        funs.append(g)
    return funs

How would you evaluate "ds" in the context of the call?
If it were to have the same observable behavior as def g(arg=ds) 
except that you would get "fresh" reference on each invocation you 
would get the following:


assert [f() for f in foo()]  == [set(), [], ()]

Note it cannot be a simple syntactic transform because:

class _MISSING: pass
def foo():
    cons = [set(), [], (),]
    funs = []
    for ds in cons:
        def g(arg=_MISSING):
            if arg is _MISSING:
                arg = eval('ds') # equivalent to arg = ds so does not 
produce a fresh reference

            return arg
        funs.append(g)
      return funs

assert [f() for f in foo()]  == [(), (), ()]

Granted the way closures work (especially in the context of loops) is 
also a pretty unintuitive, but stands as a barrier to easily 
implementing your desired behavior.
And even if that wasn't the case we still have the issue that 
eval('ds') doesn't give you a fresh reference.


Wouldit implicitly deepcopy ds?  e.g.:

class _MISSING: pass
def build_g(default):
    def g(arg=_MISSING):
        if arg is _MISSING:
            arg =  deepcopy(default)
        return arg
    return g

def foo():
    cons = [set(), [], (),]
    funs = []
    for ds in cons:
        g = build_g(ds)
        funs.append(g)
      return funs

What if ds doesn't implement __deepcopy__?


On Mon, May 18, 2020 at 7:11 AM Richard Damon 
mailto:rich...@damon-family.org>> wrote:


On 5/18/20 9:06 AM, James Lu wrote:
> "There should be one-- and preferably only one --obvious way to
do it."

*obvious*

multiple ways are allowed as long as there is one clear preference.

-- 
Richard Damon

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


___
Python-ideas mailing list --python-ideas@python.org
To unsubscribe send an email topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-ideas@python.org/message/YE77WSNCGMLNVCTTD472WFWAELURMHSF/
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/QG6OFYNNE3LX45BIQ244NW2A7TVHHF6L/
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/VUP2WS35NR5JSSBHTTOLFNX66253L5OO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Rob Cliffe via Python-ideas]

I have already replied to the OP and to the list, but there seems to be 
a problem with my posts getting through,

so let me try again.  Apologies if you see this twice:

To strip at most 1 character from the end:
    txt[:-1] + txt[-1:].rstrip(chars)
To strip at most N characters:
    txt[:-N] + txt[-N:].rstrip(chars)

Rob Cliffe

On 18/05/2020 19:32, Caleb Donovick wrote:
Certainly the way default arguments work with mutable types is not the 
most intuitive and I think your complaint has some merit.


However how would you define the following to work:

def foo():
    cons = [set(), [], (),]
    funs = []
    for ds in cons:
        def g(arg:=ds):
            return arg
        funs.append(g)
    return funs

How would you evaluate "ds" in the context of the call?
If it were to have the same observable behavior as def g(arg=ds) 
except that you would get "fresh" reference on each invocation you 
would get the following:


assert [f() for f in foo()]  == [set(), [], ()]

Note it cannot be a simple syntactic transform because:

class _MISSING: pass
def foo():
    cons = [set(), [], (),]
    funs = []
    for ds in cons:
        def g(arg=_MISSING):
            if arg is _MISSING:
                arg = eval('ds') # equivalent to arg = ds so does not 
produce a fresh reference

            return arg
        funs.append(g)
      return funs

assert [f() for f in foo()]  == [(), (), ()]

Granted the way closures work (especially in the context of loops) is 
also a pretty unintuitive, but stands as a barrier to easily 
implementing your desired behavior.
And even if that wasn't the case we still have the issue that 
eval('ds') doesn't give you a fresh reference.


Wouldit implicitly deepcopy ds?  e.g.:

class _MISSING: pass
def build_g(default):
    def g(arg=_MISSING):
        if arg is _MISSING:
            arg = deepcopy(default)
        return arg
    return g

def foo():
    cons = [set(), [], (),]
    funs = []
    for ds in cons:
        g = build_g(ds)
        funs.append(g)
      return funs

What if ds doesn't implement __deepcopy__?


On Mon, May 18, 2020 at 7:11 AM Richard Damon 
mailto:rich...@damon-family.org>> wrote:


On 5/18/20 9:06 AM, James Lu wrote:
> "There should be one-- and preferably only one --obvious way to
do it."

*obvious*

multiple ways are allowed as long as there is one clear preference.

-- 
Richard Damon

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

[Python-ideas] Re: str.strip: argument maxstrip

[Alex Hall]

On Tue, May 19, 2020 at 9:43 PM David Mertz  wrote:

> Currently, I'd probably program my intention like this.  Let's assume this
> is something where the '=' is allowed in the middle.
>

Getting increasingly hypothetical...

Anyway, you could write:

```
assert not salt.endswith("=" * 3)  # at most 2 ='s allowed
salt = salt.rstrip("=")
```
___
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/T6T5WGL5OIQYWYHVFOHVAXLH3UDEBPUG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: str.strip: argument maxstrip

[David Mertz]

>
> I may be misunderstanding, but it sounds like = is not acceptable in the
> final result, so it's not enough to remove only 2 of 4 ='s. You want to
> make sure nothing messed up your string. So if the code existed, what you'd
> want is:


> ```
> assert salt.count("=") <= 2
> salt = salt.rstrip("=", "")
> assert "=" not in salt
> ```
>

I think the code I'd want, if the new parameter existed, would be:

salt = salt.rstrip("=", maxstrip=2)
assert not salt.endswith("=")

That feels *slightly* better than your version.  This version would allow
there to be '=' in the middle of the string (albeit, such would not be
base64, but some other kind of thing).  Obviously, I've managed to program
Python without this switch for 20+ years.  But I think I'd use it
occasionally.

Currently, I'd probably program my intention like this.  Let's assume this
is something where the '=' is allowed in the middle.

if salt.endswith("=="):
salt = salt[-2:]
elif salt.endswith("="):
salt = salt[-1:]
assert not salt.endswith("=")

The version you suggested, as mentioned, would not handle a format where
'=' was permitted in the middle.

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/7PAEOO7CHS3NM2GUEDBXGLJL4L3SSJ2J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: str.strip: argument maxstrip

[Alex Hall]

On Tue, May 19, 2020 at 2:58 PM computermaster360 . <
computermaster...@gmail.com> wrote:

> I often find myself in a need of stripping only a specified amount of
> characters from a string (most commonly a single character). I have been
> implementing this in an ad-hoc manner, which is quite inelegant:
>
> def rstrip1(txt, chars):
>   if txt is None:
> return None
>   elif any(txt.endswith(c) for c in chars):
> return txt[:-1]
>   else:
> return txt
>

If you want to remove at most one instance of one specific character, then
I believe in Python 3.9 you will be able to write `txt.removesuffix(char)`
- see https://www.python.org/dev/peps/pep-0616/.

For removing one of several possible characters, the potential API for that
has currently been rejected:
https://www.python.org/dev/peps/pep-0616/#accepting-a-tuple-of-affixes
___
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/LPME7YJEL2YOTSAV3ON4QEWJ3NHT5QJ6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: str.strip: argument maxstrip

[Alex Hall]

On Tue, May 19, 2020 at 8:49 PM David Mertz  wrote:

> elif fmt == "PBKDF2_SHA256":
> h = base64.b64encode(base64.b64decode(text)[:32])
> # a terrible hack follows, use "adapted base64" alphabet
> (using . instead of + and with no padding)
> h = h.rstrip("=").replace("+", ".")
> salt = base64.b64encode(salt)
> salt = salt.rstrip("=").replace("+", ".")
>
> We actually know that base64 code should only produce at most 2 '='s as
> padding.  In this instance, the encoding comes immediately before the
> stripping.  However, perhaps some code would pass the encoded string and
> you wouldn't be as confident locally that extra '='s hadn't snuck in.
>
> If it existed, I think these lines would be good candidates for 'maxstrip'.
>

 Not a very strong ending 🤣

I may be misunderstanding, but it sounds like = is not acceptable in the
final result, so it's not enough to remove only 2 of 4 ='s. You want to
make sure nothing messed up your string. So if the code existed, what you'd
want is:

```
assert salt.count("=") <= 2
salt = salt.rstrip("=", "")
assert "=" not in salt
```
___
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/TI3RETFLVKRWA6JMQCCDBVHZXESJCMYL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Christopher Barker]

On Tue, May 19, 2020 at 11:31 AM Brett Cannon  wrote:

> I'm going to ask that people please try to keep this thread on-topic to
> the question of using Unicode characters directly for things that we
> currently use two ASCII characters to represent.
>

Indeed -- and also: please refer to earlier conversations on this list and
elsewhere -- this is NOT a new idea!

I'd suggest also that the question at hand be more global: Should Python be
extended to allow non-ascii characters in syntax? Rather than one or two
specific ones.

ON a related note, another way to get "Nicer" multi-character operatores is
lignatures. Jet BRains has put out a font with a pretty full set:

https://www.jetbrains.com/lp/mono/#ligatures

(you can use that font with most Editors / IDEs -- works great with
Sublime, for instance)

That way, it's still two ascii characters, but it looks like one nifty
symbol in your editor.

Maybe no need to complicate Python? ;-)

-CHB



-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/G2RJ2F2X6X5KGUONSQACXCFRQEDQRGHC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: str.strip: argument maxstrip

[David Mertz]

I did a couple greps of my git/ directory to see if I found examples.
Given that there are a couple ways one might achieve the effect now, I
don't necessarily find everything.  But here's something in software I did
not write myself.

This is from ./JohnTheRipper/run/sspr2john.py.  I found another example in
a different file, but looking at it I'm pretty sure it is actually a
potential bug (it has a comment similar to "Is this safe?" which I won't
bother showing.

elif fmt == "PBKDF2_SHA256":
h = base64.b64encode(base64.b64decode(text)[:32])
# a terrible hack follows, use "adapted base64" alphabet (using
. instead of + and with no padding)
h = h.rstrip("=").replace("+", ".")
salt = base64.b64encode(salt)
salt = salt.rstrip("=").replace("+", ".")

We actually know that base64 code should only produce at most 2 '='s as
padding.  In this instance, the encoding comes immediately before the
stripping.  However, perhaps some code would pass the encoded string and
you wouldn't be as confident locally that extra '='s hadn't snuck in.

If it existed, I think these lines would be good candidates for 'maxstrip'.

On Tue, May 19, 2020 at 2:07 PM Henk-Jaap Wagenaar <
wagenaarhenkj...@gmail.com> wrote:

> David (or somebody else) could you give us some, as real as possible,
> examples? This will strengthen the case for it!
>
> I am confident they exist and are pretty plentiful but I myself am coming
> up blank thinking about it for a few minutes and documenting them would be
> good for discussion.
>

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/ULBSV3U2SDUPXY7NBA6XO4PLE3N4UWUS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Ensuring asserts are always on in a file

[Brett Cannon]

The closest you may ever get to something like this is a clean separation
of -O flags instead of the current -O/-OO options. That way you can flip on
everything *but* assertion removal. But a per-file directive I don't see
happening, and even the flag separation has never caught on enough for
anyone to put in the effort to get a PoC working since the only people who
ask for this are people wanting permanent asserts and that leads the usual
"you're doing it wrong" comments. Probably best/only way to motivate it is
to open up -O in a way to allow for more optimizations, but once again
that's a lot of work.

On Sun, May 17, 2020 at 2:08 PM Alex Hall  wrote:

> Some people (like myself, or the coworkers of [this person](
> https://mail.python.org/archives/list/python-ideas@python.org/thread/PLXOXKACKGXN4ZKISDVXLKMFIETWTF63/))
> just like to use asserts as a convenient way to check things. We don't want
> asserts to ever be turned off. Maybe there could be some kind of compiler
> directive which means "in this file, even with -O, keep the asserts". Maybe
> the line `assert __debug__`?
> ___
> 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/TQKXSCMH7JYCHAE3XN7MCSWVA2UJ4R5G/
> 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/W7BNFTTJZ56NKGLEIBQGQVOGFAXZWUUK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: str.strip: argument maxstrip

[Alex Hall]

On Tue, May 19, 2020 at 8:10 PM Henk-Jaap Wagenaar <
wagenaarhenkj...@gmail.com> wrote:

> David (or somebody else) could you give us some, as real as possible,
> examples? This will strengthen the case for it!
>
> I am confident they exist and are pretty plentiful but I myself am coming
> up blank thinking about it for a few minutes and documenting them would be
> good for discussion.
>

I agree, I can't think of use cases for this.

Another way to solve this:

```
>>> re.sub(r"[123]{,4}$", "", "abc123123")
'abc12'
```
___
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/YASMSLVYHOH4VN5UJDCLFLV6XCGVYOFP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Brett Cannon]

I'm going to ask that people please try to keep this thread on-topic to the
question of using Unicode characters directly for things that we currently
use two ASCII characters to represent. Other ideas that spring up from this
question are totally welcome to be done as new threads of discussion.

On Sun, May 17, 2020 at 6:42 PM MRAB  wrote:

> On 2020-05-18 02:25, Greg Ewing wrote:
> > On 18/05/20 1:59 am, Paul Sokolovsky wrote:
> >> But even
> >> {(int): str} is a better type annotation for a function than
> >> Callable[[int], str].
> >
> > I don't agree -- it looks more like some kind of dict type, and
> > would be better reserved for that purpose.
> >
> >> And if we e.g. talk about making "->" a special operator which would
> >> allow it to appear in other contexts
> >
> > Or maybe we could leverage the new walrus operator and write
> >
> >   str := (int)
> >
> It would be closer to the existing annotation if we could write:
>
>  [int] -> str
> ___
> 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/77OWDBQPQKDDQ3CGHUC4PY6ODI3LUBY3/
> 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/BWFXZOADEX2ZEBJHOHHZIBX2LFR5AFBG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: str.strip: argument maxstrip

[Henk-Jaap Wagenaar]

David (or somebody else) could you give us some, as real as possible,
examples? This will strengthen the case for it!

I am confident they exist and are pretty plentiful but I myself am coming
up blank thinking about it for a few minutes and documenting them would be
good for discussion.

On Tue, 19 May 2020 at 18:59, David Mertz  wrote:

> I think this would be useful, and doesn't break any backward
> compatibility.  I would have use for it from time to time myself.
>
> On Tue, May 19, 2020 at 9:01 AM computermaster360 . <
> computermaster...@gmail.com> wrote:
>
>> I often find myself in a need of stripping only a specified amount of
>> characters from a string (most commonly a single character). I have been
>> implementing this in an ad-hoc manner, which is quite inelegant:
>>
>> def rstrip1(txt, chars):
>>   if txt is None:
>> return None
>>   elif any(txt.endswith(c) for c in chars):
>> return txt[:-1]
>>   else:
>> return txt
>>
>> I would appreciate if str.split, str.lstrip, str.rsplit functions had a
>> `maxstrip` argument, similar to the `maxsplit` argument of `str.split`,
>> which would specify the maximum count of characters to be removed from the
>> string. In case of `str.split` this maximum would apply to each side of the
>> string separately.
>>
>> Am I the only one who is surprised such functionality is not implemented
>> already??
>> ___
>> 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/NSUFM4YA6E65ASDPJZPSJWBS2XEDRDFU/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> The dead increasingly dominate and strangle both the living and the
> not-yet born.  Vampiric capital and undead corporate persons abuse
> the lives and control the thoughts of homo faber. Ideas, once born,
> become abortifacients against new conceptions.
> ___
> 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/ZRR3MEKM336G3P3744V6JLFFNPWW7A7N/
> 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/IN3RMY654FYLF4CI4TLXSNJC445VNHQC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: str.strip: argument maxstrip

[David Mertz]

I think this would be useful, and doesn't break any backward
compatibility.  I would have use for it from time to time myself.

On Tue, May 19, 2020 at 9:01 AM computermaster360 . <
computermaster...@gmail.com> wrote:

> I often find myself in a need of stripping only a specified amount of
> characters from a string (most commonly a single character). I have been
> implementing this in an ad-hoc manner, which is quite inelegant:
>
> def rstrip1(txt, chars):
>   if txt is None:
> return None
>   elif any(txt.endswith(c) for c in chars):
> return txt[:-1]
>   else:
> return txt
>
> I would appreciate if str.split, str.lstrip, str.rsplit functions had a
> `maxstrip` argument, similar to the `maxsplit` argument of `str.split`,
> which would specify the maximum count of characters to be removed from the
> string. In case of `str.split` this maximum would apply to each side of the
> string separately.
>
> Am I the only one who is surprised such functionality is not implemented
> already??
> ___
> 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/NSUFM4YA6E65ASDPJZPSJWBS2XEDRDFU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/ZRR3MEKM336G3P3744V6JLFFNPWW7A7N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: str.strip: argument maxstrip

[computermaster360 .]

Jonathan Goble wrote:
> > Do you mean "str.strip, str.lstrip, str.rstrip"?

Yes, I meant that.
___
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/MPB57NPS3J4FLACVIKIHYXDKQ2UBVKMB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: str.strip: argument maxstrip

[Rob Cliffe via Python-ideas]

To strip at most 1 character from the end:
    txt[:-1] + txt[-1:].rstrip(chars)
To strip at most N characters:
    txt[:-N] + txt[-N:].rstrip(chars)
Given that, I think yours is too much of a niche case to change anything 
in Python

Rob Cliffe

On 19/05/2020 12:44, computermaster360 . wrote:

I often find myself in a need of stripping only a specified amount of 
characters from a string (most commonly a single character). I have been 
implementing this in an ad-hoc manner, which is quite inelegant:

def rstrip1(txt, chars):
   if txt is None:
 return None
   elif any(txt.endswith(c) for c in chars):
 return txt[:-1]
   else:
 return txt

I would appreciate if str.split, str.lstrip, str.rsplit functions had a 
`maxstrip` argument, similar to the `maxsplit` argument of `str.split`, which 
would specify the maximum count of characters to be removed from the string. In 
case of `str.split` this maximum would apply to each side of the string 
separately.

Am I the only one who is surprised such functionality is not implemented 
already??
___
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/NSUFM4YA6E65ASDPJZPSJWBS2XEDRDFU/
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/R5MV36GXCYPU2VEMNHOS3VWXB4AOJXOM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: str.strip: argument maxstrip

[Jonathan Goble]

On Tue, May 19, 2020 at 9:00 AM computermaster360 . <
computermaster...@gmail.com> wrote:

> I often find myself in a need of stripping only a specified amount of
> characters from a string (most commonly a single character). I have been
> implementing this in an ad-hoc manner, which is quite inelegant:
>
> def rstrip1(txt, chars):
>   if txt is None:
> return None
>   elif any(txt.endswith(c) for c in chars):
> return txt[:-1]
>   else:
> return txt
>
> I would appreciate if str.split, str.lstrip, str.rsplit functions had a
> `maxstrip` argument, similar to the `maxsplit` argument of `str.split`,
> which would specify the maximum count of characters to be removed from the
> string. In case of `str.split` this maximum would apply to each side of the
> string separately.
>

Do you mean "str.strip, str.lstrip, str.rstrip"?
___
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/YCNJK447WGKI4ZM5PIDZJHIVZ5CWXM65/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] str.strip: argument maxstrip

[computermaster360 .]

I often find myself in a need of stripping only a specified amount of 
characters from a string (most commonly a single character). I have been 
implementing this in an ad-hoc manner, which is quite inelegant:

def rstrip1(txt, chars):
  if txt is None:
return None
  elif any(txt.endswith(c) for c in chars):
return txt[:-1]
  else:
return txt

I would appreciate if str.split, str.lstrip, str.rsplit functions had a 
`maxstrip` argument, similar to the `maxsplit` argument of `str.split`, which 
would specify the maximum count of characters to be removed from the string. In 
case of `str.split` this maximum would apply to each side of the string 
separately.

Am I the only one who is surprised such functionality is not implemented 
already??
___
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/NSUFM4YA6E65ASDPJZPSJWBS2XEDRDFU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Rob Cliffe via Python-ideas]

On 17/05/2020 19:43, David Mertz wrote:
On Sun, May 17, 2020 at 2:09 PM Nathan Schneider > wrote:


If you want a better metaphor: Some door handles include
locks, others do not.  "Strict" ones have locks.  So yes, it's
possible to leave the lock in the unlocked position, and then
it functions pretty much the same as one without a lock.  But
likewise, it's possible to leave the door in the locked
position when you don't have the key on you, and you face a
significant inconvenience that serves no purpose.

For some of us, strictness is a property that users often want
when they use zip(), whether they are properly enforcing it or
not—so giving them a really easy way to opt into it would help
avoid bugs. (Personally, I cannot remember the last time I
actually wanted non-strict zip.)
I think David is saying that he more often wants non-strict zip,
and it would be tempting and dangerous to make strict-zip too easy
to use for those who aren't thinking carefully about their code,
so it would be better to bury strict-zip in itertools for the
power users who really know they need it. (Is that a fair summary?)


The API matter is really orthogonal to this.  My point here is that 
Nathan and some other discussants are operating under the assumption 
that: "Everyone really wants strict-zip but they just haven't had a 
way to express it conveniently. They all assume their iterables are 
the same length already, so this just adds a check."


I disagree strongly with that assumption.  I think that the actual 
majority of my uses of zip are non-strict.

David, you have made this point at great length - we get it.
But it seems clear to me (YMMV) that you are in a small minority.
And nobody is suggesting changing the default behaviour of zip. Your 
code won't break.
But a lot of users (including you, in a minority of cases) can, *if they 
choose*, benefit from a 'strict' version.

So what is wrong (ceteribus paribus) with making it easy for them to do so?
___
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/O4N4JHH67RQJVVCNETJJK6ZVT5MFLOPJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Optional keyword arguments

[Henk-Jaap Wagenaar]

I think only using the first third of the quote makes your argument too
terse Steven.

To include the second part: "There should be one-- and preferably only one"
which implies "It is preferable there is exactly one qualified pilot in the
cockpit", and we arrive (if abbreviated) at what James said.

However, to use the full quote as inspiration: "There must be at least one
qualified pilot in the cockpit and there should not be a tie for seniority"
and it flips again!

Regardless Steven, I don't think it matters (except for setting the record
straight[1]), they are not essential to his proposal? He uses this idea in
his argument to say we should adopt *one* of := and ?=. Firstly, I think
his application there is correct (if you assume at least one would be
adopted, I think only one would be) but secondly I think his email has a
strong air of false dichotomy: Python could well adopt a different solution
or no solution at all and those are perfectly acceptable outcomes and I
would advocate "no solution" as I prefer it over his two proposals.

[1] https://xkcd.com/386/

On Tue, 19 May 2020 at 01:33, Steven D'Aprano  wrote:

> On Mon, May 18, 2020 at 01:06:22PM -, James Lu wrote:
>
> > "There should be one-- and preferably only one --obvious way to do it."
>
> Yes?
>
> "There should be one" does not mean the same thing as "there shouldn't
> be two".
>
> "There should be one qualified pilot in the cockpit of the plane at all
> times during the flight" is not the same as "There should not be two
> qualified pilots in the cockpit".
>
>
>
> --
> Steven
> ___
> 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/IA32WCRDPACLI6R562GDPETV6WQRUBSV/
> 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/5BXCVMWNZKW3EAQKPRMBMNF6UD6VSPQY/
Code of Conduct: http://python.org/psf/codeofconduct/