Non strict strings comparison.With '=' instead '==' like AutoIT

Ideas
22

For anyone reading this historical record, there was a somewhat troubling one-sentence post which was then deleted.

I’m going to disengage from this thread at this point.

Please, @boludoz, take a few minutes to read the CoC. Some handy links:

In particular, the community strongly discourages deleting or making non-trivial edits to posts. It makes conversation on the forums difficult.

Also, I would appreciate it if you took the time to read my post. I did my best to be constructive, to help you learn how to engage with these sorts of ideas carefully, in a way that is likely to be productive – to share what I have learned by experience and by observation of this community.

3 Likes
23

Please, not off-topic here next time.

24

I feel like Python developers want to differentiate themselves from other languages ​​all the time. You can see this in the “throw” vs “swich” example. can’t create anything good that way, it’s a very hostile environment.

25

There’s a reason why assignment expressions don’t use =:

Why not just turn existing assignment into an expression?

C and its derivatives define the = operator as an expression, rather than a statement as is Python’s way. This allows assignments in more contexts, including contexts where comparisons are more common. The syntactic similarity between if (x == y) and if (x = y) belies their drastically different semantics. Thus this proposal uses := to clarify the distinction.

if a = b: can already be intended as an assignment or normal equation, it is a bad idea to make it do anything else.

1 Like
26

I’m using Python and when I do the comparison the output looks like this:

>>> if (3=4):
  File "<stdin>", line 1
    if (3=4):
        ^
SyntaxError: cannot assign to literal here. Maybe you meant '==' instead of '='?

We could also have implemented switch instead of throw if we were thinking about c.

27

Just for transparency, I flagged multiple of OPs posts for violating CoC. To OP: please actually read the CoC, other people messages and try to follow the instruction in the CoC about not overwhelming discussions by posting constantly. The only thing you achieve with that is making fewer people respond to you, and those that do respond are going to do so in the most combative and aggressive form, preventing the discussion from ever having a useful result.

2 Likes
28

Sorry, I try to keep my discussions philosophical but sometimes the inconsistencies get on my nerves.

29

The proposal would be slightly more plausible if a new binary operator such as ~, as in “approximate”, is suggested. It would call the __like__ method of the left operand or the __rlike__ method of the right operand to match the two in some way determined by the types of the two operands, e.g. "abc" ~ "ABC" returns True if we agree that ~ for two strings is to perform a case-insensitive match.

The real problem is that there’s no consensus on exactly what kind of approximation is expected given two types. For two strings, does approximation mean a case-insensitive match, a glob pattern match, a regex match, or a substring match? For a string and a number, does it mean to convert a string to a number, or a number to a string, before a match? Ultimately there’ll be too much guesswork for a ~ b to be readable, and we’re much better served with explicitly named calls.

1 Like
30

What the OP wants to accomplish is usually done like this:

if str1.lower() == str2.lower(): ...

There is nothing actionable here.

2 Likes
31

I am against this. Just write a function to compare as you want to - I think others would have other comparison needs such as:

  • Comparing linux file names
  • Comparing strings with/without ligatures
  • Comparing numeric strings
  • Comparing strings with extra rules for numeric fields within the string
  • …

Your case just reads as your case. I am not convinced that your case should be elevated.

32

Why should it compare by lower() instead of by casefold()?

2 Likes
33
34

I didn’t know about casefold, thanks for the information!

1 Like
35

You’ll also want to know about unicodedata.normalize to catch these:

>>> 'ó' == 'ó'  # "o with acute" vs. "o"+"combining acute"
False

Or maybe it would want to detect confusables too?

>>> 'o' == 'ο'  # Latin "o" vs. Greek omicron
False

As was noted above, Python’s == is not what you want when dealing with human language text. But it’s useful and appropriate for identifiers and programming languages.
The trouble with human-readable text is that “what humans would consider equal” is context-specific, and in most contexts, far from a solved problem. There’s no algorithm, library or function to “just do the right thing”.

3 Likes
36

Good point, I keep forgetting about it!

37

There are also the confusable dashes too.

38

The disadvantage of a.casefold() == b.casefold() is that it creates 2 new strings, so perhaps what’s needed is a function that compares 2 strings without doing that and can short-circuit on the first mismatch. It could let you specify the kind of comparison(s) to handle because there could be more than one kind as mentioned above.

39

I’m going to close this topic as the way you’re discussing this is unproductive and the idea itself is not going to fly.

8 Likes