On Mon, Jan 17, 2022 at 12:16:07PM +1100, Chris Angelico wrote:
Strings behave differently in many many ways. Are there any non-string types that differ?
There are plenty of non-string types which differ :-)
*sigh* I know you love to argue for the sake of arguing, but seriously, can't you read back to your own previous message and get your own context?
Speaking of context, it is not nice of you to strip the context of my very next sentence, in order to make me out to be the bad guy here. "Differ in what way? I don't understand your question." Let me repeat: I do not understand your question. In what way do you think that non-string types differ, that is relevant to the discussion? There are plenty of ways that they differ. I don't see how those differences are meaningful. If you do, please explain. (I see that further on, you made an attempt. Thank you, I will respond to that below.)
With punctuation like parentheses, square brackets, angle brackets, etc, does not ever, to my knowledge, have prefixes.
In another post, I have pointed out a few languages which do something very close to this, e.g. Scheme. A better example is Coconut. Coconut allows an optional 's' prefix on sets, so as to allow `s{}` for an empty set. It also allows the 'f' prefix for frozensets: https://coconut.readthedocs.io/en/v1.1.0/DOCS.html#set-literals But even if it has never been done before, someone has to be the first. There was a time that no language ever used r"..." for raw strings, or f"..." for f-strings. There was a time where there was no language in the world that used slice notation, or {a, b} for sets. There was once a time that no language had list comprehension syntax. And now Python has all those syntactic features. "It has never been done before" is a weak argument, and it is especially weak when it *has* been done before. We have at least three syntactic forms that use an alphabetical prefix on a delimiter. It seems rather dubious that you are happy to use the < and > operators as delimiters, just to avoid a prefix. - There is no precedent in Python of a symbol being used as both an operator and a delimiter: none of ( [ { } ] ) are ever used as operators, and no operator + - etc are ever used as delimiters. But you are happy to make this radical change to the language, even though you agree that it looks pretty awful when used with the < and > operators. - But there is precedent in Python of adding an alphabetic prefix to delimiters: we have b' r' f'. But you are unhappy with making a minor change to the language by putting the prefix on a symbol different from a quote mark, because the data type is not a string or bytes. Your position seems to be: We have used prefixes on delimiters before, therefore we cannot do it again; and we've never used operators as delimiters before, therefore we should do it now. Is that accurate? If not, I apologise for misunderstanding you, but please explain what you mean. These are not rhetorical questions: (1) Why does it matter that string and bytes syntax are the only types that currently use a prefix on a delimiter? Surely delimiters are delimiters, whatever the type they represent. (2) What is so special about the string and bytes types that tells you that it is okay to use a prefix on the delimiter, but other data structures must not do the same?
ONLY strings behave differently. Are there any non-string types which have special behaviour based on a prefix, like you're suggesting for sets?
I am not proposing any special behaviour. This is *syntax*, not behaviour. Frozensets will continue to behave exactly the same as they behave now. If that was not clear, I apologise for giving you the wrong impression. As mentioned above, Coconut already supports this, and some other languages support similar prefixes on delimiters for lists and dicts.
You were concerned that adding a prefix to a delimiter in the form of f{...} would be a bug magnet, but we have had prefixes on delimiters for 30 years in the form of r"..." etc, and it hasn't been a problem.
Yes. ONLY on strings. That's exactly what I said. Strings are different. For starters, we already have multiple different data types that can come from quoted literals, plus a non-literal form that people treat like a literal (f-strings). Is there any non-string type that doesn't follow that pattern?
So... not "ONLY" (your emphasis, not mine) strings. As you say, there are already two different data types, strings and bytes, plus a non-literal executable code (f-strings). Again, I don't understand your point. You have just told us that there are already non-string literals and types that use a prefix on the delimiter, and then you ask me if there are any non-string types that follows that pattern. Haven't you just answered your own question? Sure, bytes and f-strings are quite closely related to regular strings, and frozensets are not. But why does that matter? This is not a rhetorical question. You obviously feel that there is something special or magical about strings that makes it okay to stick a prefix on the opening delimiter, but for the life of me I can't see what it is. Is it just taste? You just don't like the look of `f{}`?
len{mystring} looks a lot like len(mystring), but len"mystring" looks very very different. Or do you treat all punctuation exactly the same way?
Yes it does look different, but what does that have to do with anything? f() and f"" look very similar, and r() and r"" do too. I think this idea that people will confuse f{} for a function call, and extrapolate to using it in arbitrary functions, is unjustified. But even if they do, except in the very special case where the function is called exactly `f`, they will get a SyntaxError. And even then, the error will be pretty obvious. Calling this a "bug magnet" seems to be a gross exaggeration.
You mess up round and square brackets, yes. You might mess up double and single quotes, too, in languages that care. But you aren't going to mess up brackets and quotes.
Then why is this a problem for curly brackets, when you just agreed that it is not a problem for round and square brackets? We don't write b"" or r"" or f"" when we want b() or r[] or f(), or vice versa, but we'll suddenly start confusing f"" and f{}? I think that is pure FUD (Fear, Uncertainty, Doubt). -- Steve