Re: [Python-ideas] Fix default encodings on Windows
On 19 August 2016 at 08:05, Chris Barker wrote: > On Thu, Aug 18, 2016 at 6:23 AM, Steve Dower wrote: >> >> "You consistently ignore Makefiles, .ini, etc." >> >> Do people really do open('makefile', 'rb'), extract filenames and try to >> use them without ever decoding the file contents? > > > I'm sure they do :-( > > But this has always confused me - back in the python2 "good old days" text > and binary mode were exactly the same on *nix -- so folks sometimes fell > into the trap of opening binary files as text on *nix, and then it failing > on Windows but I can't image why anyone would have done the opposite. > > So in porting to py3, they would have had to *add* that 'b' (and a bunch of > b'filename') to keep the good old bytes is text interface. > > Why would anyone do that? For a fair amount of *nix-centric code that primarily works with ASCII data, adding the 'b' prefix is the easiest way to get into the common subset of Python 2 & 3. However, this means that such code is currently relying on deprecated functionality on Windows, and if we actually followed through on the deprecation with feature removal, Steve's expectation (which I agree with) is that many affected projects would just drop Windows support entirely, rather than changing their code to use str instead of bytes (at least under Python 3 on Windows). The end result of Steve's proposed changes should be that such code would typically do the right thing across all of Mac OS X, Linux and WIndows, as long as the latter two are configured to use "utf-8" as their default locale encoding or active code page (respectively). Linux and Windows would still both have situations encountered with ssh environment variable forwarding and with East Asian system configurations that have the potential to result in mojibake, where these challenges come up mainly with network communications on Linux, and local file processing on Windows. The reason I like Steve's proposal is that it gets us to a better baseline situation for cross-platform compatibility (including with the CLR and JVM API models), and replaces the status quo with three smaller as yet unsolved problems: - network protocol interoperability on Linux systems configured with a non UTF-8 locale - system access on Linux servers with a forwarded SSH environment that doesn't match the server settings - processing file contents on Windows systems with an active code page other than UTF-8 For Linux, our answer is basically "UTF-8 is really the only system locale that works properly for other reasons, so we'll essentially wait for non-UTF-8 Linux systems to slowly age out of humanity's collective IT infrastructure" For Windows, our preliminary answer is the same as the situation on Linux, which is why Stephen's concerned by the proposal - it reduces the incentive for folks to support Windows *properly*, by switching to modeling paths as text the way pathlib does. However, it seems to me that those higher level pathlib APIs are the best way to encourage future code to be more WIndows friendly - they sweep a lot of these messy low level concerns under the API rug, so more Python 3 native code will use str paths by default, with bytes paths mainly showing in Python 2/3 compatible code bases and some optimised data processing code. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Fix default encodings on Windows
On Thu, Aug 18, 2016 at 3:25 PM, Steve Dower wrote: > allow us to change locale.getpreferredencoding() to utf-8 on Windows _bootlocale.getpreferredencoding would need to be hard coded to return 'utf-8' on Windows. _locale._getdefaultlocale() itself shouldn't return 'utf-8' as the encoding because the CRT doesn't allow it as a locale encoding. site.aliasmbcs() uses getpreferredencoding, so it will need to be modified. The codecs module could add get_acp and get_oemcp functions based on GetACP and GetOEMCP, returning for example 'cp1252' and 'cp850'. Then aliasmbcs could call get_acp. Adding get_oemcp would also help with decoding output from subprocess.Popen. There's been discussion about adding encoding and errors options to Popen, and what the default should be. When writing to a pipe or file, some programs use OEM, some use ANSI, some use the console codepage if available, and far fewer use Unicode encodings. Obviously it's better to specify the encoding in each case if you know it. Regarding the locale module, how about modernizing _locale._getdefaultlocale to return the Windows locale name [1] from GetUserDefaultLocaleName? For example, it could return a tuple such as ('en-UK', None) and ('uz-Latn-UZ', None) -- always with the encoding set to None. The CRT accepts the new locale names, but it isn't quite up to speed. It still sets a legacy locale when the locale string is empty. In this case the high-level setlocale could call _getdefaultlocale. Also _parse_localename, which is called by getlocale, needs to return a tuple with the encoding as None. Currently it raises a ValueError for Windows locale names as defined by [1]. [1]: https://msdn.microsoft.com/en-us/library/dd373814 ___ 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] Let’s make escaping in f-literals impossible
On 19 August 2016 at 06:07, Terry Reedy wrote: > It seems to me that that this is at least somewhat a strawman issue. > > If you want to prohibit backslashed quote reuse in expressions, as in > f'{x.partition(\'-\')[0]}', that is okay with me, as this is unnecessary* > and arguably bad. The third alternative above is better. What breaks > colorizers, and what I therefore object to, is the innovation of adding > magical escaping of ' or " without \. > > Or add a new style rule to PEP 8. > > F-strings: avoid unnecessary escaping in the expression part of f-strings. > Good: f"{x.partition('-')[0]}" > Bad: f'{x.partition(\'-\')[0]}' > > Then PEP-8 checkers will flag such usage. +1. While substantial IDEs like PyCharm or PTVS may use a full-scale parser to do syntax highlighting, I suspect that many tools just use relatively basic regex parsing (Vim certainly does). For those tools, unescaped nested quotes will likely be extremely difficult, if not impossible, to parse correctly. Whereas the current behaviour is "just" standard string highlighting. So if the Python parser were to change as proposed, I'd still argue strongly for a coding style that never uses any construct that would be interpreted differently from current behaviour (i.e., the changed behaviour should essentially be irrelevant). Given this, I thing the argument to change, whether it's theoretically an improvement or not, is irrelevant, and practicality says there's no point in bothering. (Python's parser is intentionally simple, to make it easy for humans and tools to parse Python code - I'm not sure the proposed change to syntax meets that guideline for simple syntax). 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] Let’s make escaping in f-literals impossible
On 8/19/2016 1:16 AM, Terry Reedy wrote: On 8/18/2016 8:27 PM, Eric V. Smith wrote: So something that parses or scans a Python file and currently understands u, b, and r to be string prefixes, just needs to add f to the prefixes it uses, and it can now at least understand f-strings (and fr-strings). It doesn't need to implement a full-blown expression parser just to find out where the end of a f-string is. Indeed, IDLE has one prefix re, which has changed occasionally and which I need to change for 3.6, and 4 res for the 4 unprefixed strings, which have been the same, AFAIK, for decades. It that prefixes all 4 string res with the prefix re and o or's the results together to get the 'string' re. For something else that would become significantly more complicated to implement, you need look no further than the stdlib's own tokenizer module. So Python itself would require changes to parsers/lexers in Python/ast.c, IDLE, and Lib/tokenizer.py. In addition it would require adding tokens to Include/tokens.h and the generated Lib/token.py, and everyone using those files would need to adapt. Not that it's impossible, of course. But don't underestimate the amount of work this proposal would cause to the many places in and outside of Python that examine Python code. Eric. ___ 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] Let’s make escaping in f-literals impossible
On 19 August 2016 at 18:27, Eric V. Smith wrote: > For something else that would become significantly more complicated to > implement, you need look no further than the stdlib's own tokenizer module. > So Python itself would require changes to parsers/lexers in Python/ast.c, > IDLE, and Lib/tokenizer.py. In addition it would require adding tokens to > Include/tokens.h and the generated Lib/token.py, and everyone using those > files would need to adapt. > > Not that it's impossible, of course. But don't underestimate the amount of > work this proposal would cause to the many places in and outside of Python > that examine Python code. And if folks want to do something more clever than regex based single colour string highlighting, Python's own AST module is available to help them out: >>> tree = ast.parse("f'example{parsing:formatting}and trailer'") >>> ast.dump(tree) "Module(body=[Expr(value=JoinedStr(values=[Str(s='example'), FormattedValue(value=Name(id='parsing', ctx=Load()), conversion=-1, format_spec=Str(s='formatting')), Str(s='and trailer')]))])" Extracting the location of the field expression for syntax highlighting: >>> ast.dump(tree.body[0].value.values[1].value) "Name(id='parsing', ctx=Load())" (I haven't shown it in the example, but AST nodes have lineno and col_offset fields so you can relocate the original source code for processing) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Consider having collections.abc.Sequence implement __eq__ and __ne__
I mean zip(self, other) On Friday, August 19, 2016 at 6:46:57 AM UTC-4, Neil Girdhar wrote: > > Both Mapping and Set provide __eq__ and __ne__. I was wondering why not > have Sequence do the same? > > > class Sequence(Sized, Reversible, Container): > > def __eq__(self, other): > if not isinstance(other, Sequence): > return NotImplemented > if len(self) != len(other): > return False > for a, b in self, other: > if a != b: > return False > return True > ___ 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] Consider having collections.abc.Sequence implement __eq__ and __ne__
Both Mapping and Set provide __eq__ and __ne__. I was wondering why not have Sequence do the same? class Sequence(Sized, Reversible, Container): def __eq__(self, other): if not isinstance(other, Sequence): return NotImplemented if len(self) != len(other): return False for a, b in self, other: if a != b: return False return True ___ 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] Consider having collections.abc.Sequence
Could use all(a==b for zip(seq,seq2)) -- Arkadiusz Bulski -- ___ 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] Consider having collections.abc.Sequence
Arek Bulski wrote: > Could use all(a==b for zip(seq,seq2)) Or even `all(itertools.starmap(operator.eq, zip(a, b)))` if you prefer, but this isn’t about how easy or clever or obfuscated one can write that; it’s about convenience. ABCs expose the lowest common denominator for concrete classes of their kind, and having __eq__ makes sense for Sequence (I’m surprised that it’s not already in). I think we can skip the Python-ideas thread and go straight to opening an issue and submitting a patch :) Neil, care to do that? -Emanuel ___ 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] Consider having collections.abc.Sequence
Right, of course that's better. On Fri, Aug 19, 2016 at 8:01 AM Arek Bulski wrote: > Could use all(a==b for zip(seq,seq2)) > > -- Arkadiusz Bulski -- > ___ 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] Consider having collections.abc.Sequence
Sure. http://bugs.python.org/issue27802 On Friday, August 19, 2016 at 8:36:39 AM UTC-4, Emanuel Barry wrote: > > Arek Bulski wrote: > > > Could use all(a==b for zip(seq,seq2)) > > > > Or even `all(itertools.starmap(operator.eq, zip(a, b)))` if you prefer, > but this isn’t about how easy or clever or obfuscated one can write that; > it’s about convenience. ABCs expose the lowest common denominator for > concrete classes of their kind, and having __eq__ makes sense for Sequence > (I’m surprised that it’s not already in). > > > > I think we can skip the Python-ideas thread and go straight to opening an > issue and submitting a patch :) Neil, care to do that? > > > > -Emanuel > ___ 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] Fix default encodings on Windows
On Fri, Aug 19, 2016 at 12:30 AM, Nick Coghlan wrote: > > So in porting to py3, they would have had to *add* that 'b' (and a bunch > of > > b'filename') to keep the good old bytes is text interface. > > > > Why would anyone do that? > > For a fair amount of *nix-centric code that primarily works with ASCII > data, adding the 'b' prefix is the easiest way to get into the common > subset of Python 2 & 3. > Sure -- but it's entirely unnecessary, yes? If you don't change your code, you'll get py2(bytes) strings as paths in py2, and py3 (Unicode) strings as paths on py3. So different, yes. But wouldn't it all work? So folks are making an active choice to change their code to get some perceived (real?) performance benefit??? However, as I understand it, py3 string paths did NOT "just work" in place of py2 paths before surrogate pairs were introduced (when was that?) -- so are we dealing with all of this because some (a lot, and important) libraries ported to py3 early in the game? What I'm getting at is whether there is anything other than inertia that keeps folks using bytes paths in py3 code? Maybe it wouldn't be THAT hard to get folks to make the switch: it's EASIER to port your code to py3 this way! -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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] Let’s make escaping in f-literals impossible
On 8/19/2016 2:07 AM, אלעזר wrote: בתאריך יום ו׳, 19 באוג' 2016, 08:29, מאת Terry Reedy mailto:tjre...@udel.edu>>: On 8/18/2016 8:18 PM, Steven D'Aprano wrote: > On Fri, Aug 19, 2016 at 02:17:29AM +1000, Chris Angelico wrote: > >> Format codes are just text, > > I really think that is wrong. They're more like executable code. > > https://www.python.org/dev/peps/pep-0498/#expression-evaluation I agree with you here. I just note that the strings passed to exec, eval, and compile are also executable code strings (and nothing but!). But I don't remember a suggestion that *they* should by colored as anything other than a string. But these are objects of type str, not string literals. If they were, I guess someone would have suggested such coloring. I was referring to strings created by string literals in the code sitting in an editor. -- 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] Let’s make escaping in f-literals impossible
On 8/18/2016 11:05 AM, Philipp A. wrote: Hi, I originially posted this via google groups, which didn’t make it through to the list proper, sorry! Read it here please: https://groups.google.com/forum/#!topic/python-ideas/V1U6DGL5J1s Hi, Philipp. I'm including your original proposal here, so that it's archived properly. Here's what you'd like to have work: f'foo{repr('bar\n') * 3}baz' == 'foo"bar\n""bar\n""bar\n"baz' We've had this discussion before, but I can't find it in the archives. It's possible it happened off-list. The problem I have with your proposal is that it greatly complicates the implementation and it makes it harder for humans to reason about the code (for the same reasons). This is not just an ease of implementation issue: it's a cognitive burden issue. As it currently stands, Python strings, of all 'flavors' (raw, unicode, binary, and f-), are parsed the same way: an optional prefix, one or three quote characters, the body of the string, then matching quote characters. This is sufficiently simple that it can be (and often is) implemented with regular expressions. You also need to support combinations of prefixes, like raw f-strings (fr or rf). With your proposal, it's much more difficult to find the end of an f-string. I do not think this is a reasonable requirement. For example, consider the following: f'a{func({'a{':1,'3}':[{}, ')', '{']})}b' A regex will not be able to deal with the matching braces needed to find the end of the expression. You need to keep track of the nesting level of parens, braces, brackets, and quotes (at least those, I might have left something off). The way this currently is written in Python 3.6a4: f"a{func({'a{':1,'3}':[{}, ')', '{']})}b" It's trivially easy to find the end of the string. It's easy for both humans and the parsers. Now admittedly in order to execute or syntax highlight the existing f-strings, you need to perform this parsing. But of the 3 parsers that ship with Python (ast.c, tokenize.py, IDLE), only ast.c needs to do that currently. I don't think tokenize.py ever will, and IDLE might (but could use the ast module). I think many parsers (e.g. python-mode.el, etc.) will just be able to simply consume the f-strings without looking inside them and move one, and we shouldn't unnecessarily complicate them. My arguments are basically: 1. f-literals are semantically not strings, but expressions. 2. Their escape sequences in the code parts are fundamentally both detrimental and superfluous (they’re only in for convenience, as confirmed by Guido in the quote below) I disagree that they're detrimental and superfluous. I'd say they're consistent with all other strings. 3. They’re detrimental because Syntax highlighters are (by design) unable to handle this part of Python 3.6a4’s grammar. This will cause code to be highlighted as parts of a string and therefore overlooked. i’m very sure this will cause bugs. I disagree. 4. The fact that people see the embedded expressions as somehow “part of the string” is confusing. My poposal is to redo their grammar: They shouldn’t be parsed as strings and post-processed, but be their own thing. This also opens the door to potentially extend to with something like JavaScript’s tagged templates) Without the limitations of the string tokenization code/rules, only the string parts would have escape sequences, and the expression parts would be regular python code (“holes” in the literal). Below the mentioned quote and some replies to the original thread: Guido van Rossum mailto:gu...@python.org>> schrieb am Mi., 17. Aug. 2016 um 20:11 Uhr: The explanation is honestly that the current approach is the most straightforward for the implementation (it's pretty hard to intercept the string literal before escapes have been processed) and nobody cares enough about the edge cases to force the implementation to jump through more hoops. I really don't think this discussion should be reopened. If you disagree, please start a new thread on python-ideas. I really think it should. Please look at python code with f-literals. if they’re highlighted as strings throughout, you won’t be able to spot which parts are code. if they’re highlighted as code, the escaping rules guarantee that most highlighters can’t correctly highlight python anymore. i think that’s a big issue for readability. Maybe I'm the odd man out, but I really don't care if my editor ever syntax highlights within f-strings. I don't plan on putting anything more complicated than variable names in my f-strings, and I think PEP 8 should recommend something similar. Brett Cannon mailto:br...@python.org>> schrieb am Mi., 17. Aug. 2016 um 20:28 Uhr: They are still strings, there is just post-processing on the string itself to do the interpolation. Sounds hacky to me. I’d rather see a proper parser for them, which of course would make my vision easy. You're saying i
Re: [Python-ideas] Let’s make escaping in f-literals impossible
I don't think we should take action now. Would it make sense, as a precaution, to declare the PEP provisional for one release? Then we can develop a sense of whether the current approach causes real problems. We could also emit some kind of warning if the expression part contains an escaped quote, since that's where a potential change would cause breakage. (Or we could leave that to the linters.) -- --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] Let’s make escaping in f-literals impossible
On Sat, Aug 20, 2016 at 4:43 AM, Eric V. Smith wrote: > Maybe I'm the odd man out, but I really don't care if my editor ever syntax > highlights within f-strings. I don't plan on putting anything more > complicated than variable names in my f-strings, and I think PEP 8 should > recommend something similar. I'd go further than "variable names", and happily include attribute access, subscripting (item access), etc, including a couple of levels of same: def __repr__(self): return f"{self.__class__.__name__}(foo={self.foo!r}, spam={self.spam!r})" But yes, I wouldn't put arbitrarily complex expressions into f-strings. Whether PEP 8 needs to explicitly say so or not, I would agree with you that it's a bad idea. 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] Let’s make escaping in f-literals impossible
On 19Aug2016 1157, Guido van Rossum wrote: I don't think we should take action now. Would it make sense, as a precaution, to declare the PEP provisional for one release? Then we can develop a sense of whether the current approach causes real problems. We could also emit some kind of warning if the expression part contains an escaped quote, since that's where a potential change would cause breakage. (Or we could leave that to the linters.) After reading the responses, I like the idea of explicitly discouraging any sort of string escapes within the expression (whether quotes or special characters), but think it's best left for the linters and style guides. Basically, avoid writing a literal f'{expr}' where you'd need to modify expr at all to rewrite it as: >>> x = expr >>> f'{x}' We will almost certainly be looking to enable code completions and syntax highlighting in Visual Studio within expressions, and we can't easily process the string and then parse it for this purpose, but I think we'll be able to gracefully degrade in cases where escapes that are valid in strings are not valid in code. Cheers, Steve ___ 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] Let’s make escaping in f-literals impossible
On 19 August 2016 at 19:43, Eric V. Smith wrote: > Maybe I'm the odd man out, but I really don't care if my editor ever syntax > highlights within f-strings. I don't plan on putting anything more > complicated than variable names in my f-strings, and I think PEP 8 should > recommend something similar. I agree entirely with this. You're definitely not alone. 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] Let’s make escaping in f-literals impossible
On Fri, Aug 19, 2016 at 1:43 PM, Eric V. Smith wrote: > > > With your proposal, it's much more difficult to find the end of an > f-string. I do not think this is a reasonable requirement. > > For example, consider the following: > f'a{func({'a{':1,'3}':[{}, ')', '{']})}b' > > A regex will not be able to deal with the matching braces needed to > find the end of the expression. You need to keep track of the nesting > level of parens, braces, brackets, and quotes (at least those, I might > have left something off). > > The way this currently is written in Python 3.6a4: > f"a{func({'a{':1,'3}':[{}, ')', '{']})}b" > > It's trivially easy to find the end of the string. It's easy for both > humans and the parsers. > It might be harder to find the end of an f-string in one shot, but I think that's the crux of the issue: to a reader/developer, is an f-string conceptually one thing or a compound thing? To me (someone who would like to see f-string expressions appear like normal expressions, without extra quoting, and proper syntax highlighting *always*, just like shell), this argument is essentially the same as trying to use a regex to find a closing bracket or brace or parse HTML. It's only hard (disregarding any underlying impl details) because that view regards f-strings as singular things with only one "end", when in reality an f-string is much much more like a compound expression that just happens to look like a string. If one rejects the notion that an f-string is "one thing", the boundaries can then be defined as either an unescaped closing quote an unescaped opening curly brace. When that boundary is met, the highlighter switches to normal python syntax parsing just like it would have at the real end of the string. It also starts looking for a closing curly brace to denote the start of "another" string. There is a difference however in that f-string "expressions" also support format specifications. These are not proper Python expressions to begin with so they don't have any existing highlights. Not sure what they should look like I really think it should. Please look at python code with f-literals. if >> they’re highlighted as strings throughout, you won’t be able to spot >> which parts are code. if they’re highlighted as code, the escaping rules >> guarantee that most highlighters can’t correctly highlight python >> anymore. i think that’s a big issue for readability. >> > > Maybe I'm the odd man out, but I really don't care if my editor ever > syntax highlights within f-strings. I don't plan on putting anything more > complicated than variable names in my f-strings, and I think PEP 8 should > recommend something similar. > If things aren't highlighted properly I can't see them very well. If f-strings look like other strings in my editor I will absolutely gloss over them as normal strings, expecting no magic, until I later realize some other way. Since I spend significant amounts of time reading foreign code I could see this being quite obnoxious. It might be sufficient to highlight the entire f-string a different color, but honestly I don't think an f-string should ever ever... ever misrepresent itself as a "string", because it's not. It's code that outputs a string, in a compact and concise way. Proper syntax highlighting is one of the most important things in my day-to-day development. I loved the idea of f-strings when they were discussed previously, but I haven't used them yet. If they hide what they really doing under the guise of being a string, I personally will use them much less, despite wanting to, and understanding their value. When I look at a string I want to immediately know just how literal it really is. ___ 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] Let’s make escaping in f-literals impossible
On Fri, Aug 19, 2016 at 3:11 PM, C Anthony Risinger wrote: > > > When I look at a string I want to immediately know just how literal it > really is. > To further this point, editors today show me \n and \t and friends in a different color, because they are escapes, and this visually tells me the thing going into the string at that point is not what is literally in the code. A raw string does not highlight these because they are no longer escapes, and what you see is what you get. Probably f-strings will be used most in short strings, but they'll also be used for long, heredoc-like triple-quoted strings. It's not going to be fun picking expressions out of that when the wall-of-text contains no visual cues. ___ 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] Let’s make escaping in f-literals impossible
I don't think I've ever used a syntax highlighter than changed color of \n in a string. I get the concept, but I haven't suffered for the absence of that. Moreover, although I haven't yet used them, I really doubt I want extra syntax highlighting in f-strings beyond simply the color strings appear as. Well, maybe a uniform distinction for f-string vs. some other kind of string, but nothing internal to the string. YMMV, but that would be my preference in my text editor. Curly braces are perfectly good visual distinction to me. On Aug 19, 2016 1:25 PM, "C Anthony Risinger" wrote: > On Fri, Aug 19, 2016 at 3:11 PM, C Anthony Risinger > wrote: >> >> >> When I look at a string I want to immediately know just how literal it >> really is. >> > > To further this point, editors today show me \n and \t and friends in a > different color, because they are escapes, and this visually tells me the > thing going into the string at that point is not what is literally in the > code. A raw string does not highlight these because they are no longer > escapes, and what you see is what you get. > > Probably f-strings will be used most in short strings, but they'll also be > used for long, heredoc-like triple-quoted strings. It's not going to be fun > picking expressions out of that when the wall-of-text contains no visual > cues. > > ___ > 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] Let’s make escaping in f-literals impossible
On Fri, Aug 19, 2016 at 3:39 PM, David Mertz wrote: > I don't think I've ever used a syntax highlighter than changed color of \n > in a string. I get the concept, but I haven't suffered for the absence of > that. > > Moreover, although I haven't yet used them, I really doubt I want extra > syntax highlighting in f-strings beyond simply the color strings appear as. > Well, maybe a uniform distinction for f-string vs. some other kind of > string, but nothing internal to the string. > > YMMV, but that would be my preference in my text editor. Curly braces are > perfectly good visual distinction to me. > At least vim does this and so does Sublime Text IIRC. Maybe I spend a lot of time writing shell code too, but I very much appreciate the extra visual cue. The only real point I'm trying to make is that expressions within an f-string are an *escape*. They escape the normal semantics of a string literal and instead do something else for a while. Therefore, the escaped sections should not look like (or need to conform to) the rest of the string and they should not require quoting as if it were still within the string, because I escaped it already! ___ 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] Let’s make escaping in f-literals impossible
Ok. My .vimrc is probably different from yours. I'm sure you are right I *could* make that happen. But I haven't so far. On Aug 19, 2016 1:50 PM, "C Anthony Risinger" wrote: > On Fri, Aug 19, 2016 at 3:39 PM, David Mertz wrote: > >> I don't think I've ever used a syntax highlighter than changed color of >> \n in a string. I get the concept, but I haven't suffered for the absence >> of that. >> >> Moreover, although I haven't yet used them, I really doubt I want extra >> syntax highlighting in f-strings beyond simply the color strings appear as. >> Well, maybe a uniform distinction for f-string vs. some other kind of >> string, but nothing internal to the string. >> >> YMMV, but that would be my preference in my text editor. Curly braces are >> perfectly good visual distinction to me. >> > At least vim does this and so does Sublime Text IIRC. Maybe I spend a lot > of time writing shell code too, but I very much appreciate the extra visual > cue. > > The only real point I'm trying to make is that expressions within an > f-string are an *escape*. They escape the normal semantics of a string > literal and instead do something else for a while. Therefore, the escaped > sections should not look like (or need to conform to) the rest of the > string and they should not require quoting as if it were still within the > string, because I escaped it already! > ___ 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] Let’s make escaping in f-literals impossible
On 19 August 2016 at 21:50, C Anthony Risinger wrote: > The only real point I'm trying to make is that expressions within an > f-string are an *escape*. They escape the normal semantics of a string > literal and instead do something else for a while. Therefore, the escaped > sections should not look like (or need to conform to) the rest of the string > and they should not require quoting as if it were still within the string, > because I escaped it already! So, to me f'{x.partition(' + ')[0]}' reads as a string concatenation. I'm not sure how you'd expect a syntax highlighter to make it look like anything else, to be honest (given that you're arguing *not* to highlight the whole of the content of the f-string the same way). The *real* solution is not to write something like this, instead write f"{x.partition(' + ')[0]}" That makes it easy for *humans* to read. Computers parsing it is irrelevant. Once you do that, the proposal here (that unescaped quotes can be used in an f-string) also becomes irrelevant - this expression parses exactly the same way under both the current code and the proposed approach. And that's generally true - code that is clearly written should, in my mind, work the same way regardless. So the proposal ends up being merely "choose your preference as to which form of badly-written code is a syntax error". So the only relevance of syntax highlighting is how badly it fails when handling badly-written or syntactically incorrect code. And detecting an f-string just like you detect any other string, is *much* better behaved in that situation. Detecting a closing quote is simple, and isn't thrown off by incorrect nesting. If you want the *content* of an f-string to be highlighted as an expression, Vim can do that, it can apply specific syntax when in another syntax group such as an f-string, and I'm sure other editors can do this as well - but you should do that once you've determined where the f-string starts and ends. 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/
[Python-ideas] discontinue iterable strings
standard python should discontinue to see strings as iterables of characters - length-1 strings. I see this as one of the biggest design flaws of python. It may have seem genius at the time, but it has passed it usefulness for practical language use. For example, numpy has no issues >>> np.array('abc') array('abc', dtype='>> list('abc') ['a', 'b', 'c'] Numpy was of course design a lot later, with more experience in practical use (in mind). Maybe a starting point for transition that latter operation also returns ['abc'] in the long run, could be to have an explicit split operator as recommended use, e.g., 'abc'.split() 'abc'.split('') 'abc'.chars() 'abc'.items() the latter two could return an iterator whereas the former two return lists (currently raise exceptions). Similar for bytes, etc. ___ 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] discontinue iterable strings
This would introduce a major inconsistency. To do this, you would need to also strip string’s of their status as sequences (in collections.abc, Sequence is a subclass of Iterable). Thus, making string’s no longer iterable would also mean you could no longer take the length or slice of a string. While I believe your proposal was well intentioned, IMHO it would cause a giant inconsistency in Python (why would one of our core sequences not be iterable?) - Ed > On Aug 19, 2016, at 11:13 PM, Alexander Heger wrote: > > standard python should discontinue to see strings as iterables of characters > - length-1 strings. I see this as one of the biggest design flaws of python. > It may have seem genius at the time, but it has passed it usefulness for > practical language use. For example, numpy has no issues > > >>> np.array('abc') > array('abc', dtype=' > whereas, as all know, > > >>> list('abc') > ['a', 'b', 'c'] > > Numpy was of course design a lot later, with more experience in practical use > (in mind). > > Maybe a starting point for transition that latter operation also returns > ['abc'] in the long run, could be to have an explicit split operator as > recommended use, e.g., > > 'abc'.split() > 'abc'.split('') > 'abc'.chars() > 'abc'.items() > > the latter two could return an iterator whereas the former two return lists > (currently raise exceptions). > Similar for bytes, etc. > > > > ___ > 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] discontinue iterable strings
On Fri, Aug 19, 2016, at 23:13, Alexander Heger wrote: > Numpy was of course design a lot later, with more experience in practical > use (in mind). The meaning of np.array('abc') is a bit baffling to someone with no experience in numpy. It doesn't seem to be a one-dimensional array containing 'abc', as your next statement suggests. It seem to be a zero-dimensional array? > Maybe a starting point for transition that latter operation also returns > ['abc'] in the long run Just to be clear, are you proposing a generalized list(obj: non-iterable) constructor that returns [obj]? ___ 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] Let’s make escaping in f-literals impossible
On Fri, Aug 19, 2016 at 6:09 PM, Paul Moore wrote: > On 19 August 2016 at 21:50, C Anthony Risinger wrote: > > The only real point I'm trying to make is that expressions within an > > f-string are an *escape*. They escape the normal semantics of a string > > literal and instead do something else for a while. Therefore, the escaped > > sections should not look like (or need to conform to) the rest of the > string > > and they should not require quoting as if it were still within the > string, > > because I escaped it already! > > So, to me > > f'{x.partition(' + ')[0]}' > > reads as a string concatenation. I'm not sure how you'd expect a > syntax highlighter to make it look like anything else, to be honest > (given that you're arguing *not* to highlight the whole of the content > of the f-string the same way). > The two string parts are string-colored and the x.partition bits would look like any other code in the file. It won't look like concatenation at that point. Examples referencing f'{one_expr_and_no_real_string_in_here}' feel somewhat crafted to confuse because the start and end quotes are directly adjacent to the expression. str(...) is the same complexity. Usage in the wild will have plenty of string-stuff on one or both sides, otherwise, why? Shell or Ruby code is probably more representative of how f-strings will be used. I know a couple people have mentioned they won't/don't care about highlighting in an f-string, but I honestly don't know a single person that would prefer this, except maybe one devops guy I know that does everything on old-school green text because why not. I've also spent hours and hours staring at--and sometimes editing--code on barebones servers/containers and I've come to respect the role colors play in my ability to quickly scan and read code. > The *real* solution is not to write something like this, instead write > > f"{x.partition(' + ')[0]}" > Why? Why should I have to care what kind of quote I used at the start of the string? I thought I "escaped" the string at the `{` and now my brain has moved on to the expression? Am I still "inside" the string? etc... It's not the highlighting I care about per se, I think we have a small UX failure here. In a quality editor, everything about the {...} will tell me I'm writing a Python expression. It'll be colored like an expression. It'll do fancy completion like an expression. Aw shucks, it *IS* a Python expression! Except for one tiny detail: I'm not allowed to use the quote I use in 95% of all my Python code--without thinking--because I already used it at the string start :-( It's like this weird invisible ruh-roh-still-in-a-string state hangs over you despite everything else suggesting otherwise (highlighting and whatever fanciness helps people output code). The only time I personally use a different quote is when it somehow makes the data more amenable to the task at hand. The data! The literal data! Not the expressions I'm conveniently inlining with the help of f-strings. When I do it's a conscious decision and comes with a reason. Otherwise I'll use one type of quote exclusively (which depends on the lang, but more and more, it's simply doubles). The appeal of f-strings is the rapid inlining of whatever plus string data. "Whatever" is typically more complex than a simple attribute access or variable reference, though not much more complex eg. `object.method(key, "default")`. If I have to water it down for people to find it acceptable (such as creating simpler variables ahead-of-time) I'd probably just keep using .format(...). Because what I have gained with an f-string? The problem I have is the very idea that while inlining expressions I'm still somehow inside the string, and I have to think about that. It's not a *huge* overhead for an experienced, most-handsome developer such as myself, but still falls in that 5% territory (using a quote because I must vs. the one used 95%). Since f-string are fabulous, I want to use them all the time! Alas, now I have to think about flip-flopping quotes. I don't know what it's like to be taught programming but this seems like a possible negative interaction for new people (learning and using [one] quote combined with easy string building). I know it's not *that* big of deal to switch quotes. I believe this simpler implementation out the gate (not a dig! still great!) will come at the cost of introducing a small Python oddity requiring explanation. Not just because it's at odds with other languages, but because it's at odds with what the editor is telling the user (free-form expression). tl;dr, UX is weaker when the editor implies a free-form expression in every possible way, but the writer can't use the quote they always use, and I think strings will be common in f-string expression sections. -- C Anthony ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Condu
Re: [Python-ideas] Let’s make escaping in f-literals impossible
On Fri, Aug 19, 2016, at 19:09, Paul Moore wrote: > So, to me > > f'{x.partition(' + ')[0]}' > > reads as a string concatenation. I'm not sure how you'd expect a > syntax highlighter to make it look like anything else, to be honest One possible syntax highlighting scheme: - f' and ' are hilighted in pink, along with any plain text content of the string. - - Incidentally, any backslash escapes, not shown here, are highlighted in orange. - { and } are hilighted in blue; along with format specifiers, maybe, or maybe they get another color. - The code inside the expression is highlighted in orange. - Any keywords, builtins, constants, etc, within the expression are highlighted in their usual colors. - - In this example in particular, ' + ' and 0 are highlighted in pink. A pink + is a character within a string, a gray or orange + is an operator. In terms of Vim's basic syntax groups: - C = Constant [pink] - P = PreProc [blue], by precedent as use for the $(...) delimiters in sh) - S = Special [orange], by precedent as use for the content within $(...) in sh, and longstanding near-universal precedent, including in python, for backslash escapes. These would, naturally, have separate non-basic highlight groups, in case a particular user wanted to change one of them. f'foo {x.partition(' + ')[0]:aaa} bar\n' CCPCSSCSPSSC > (given that you're arguing *not* to highlight the whole of the content > of the f-string the same way). I'm not sure what you mean by "the same way" here, I haven't followed the discussion closely enough to know what statement by whom you're referring to here. ___ 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] discontinue iterable strings
This is a feature, not a flaw. From: Python-ideas [mailto:python-ideas-bounces+tritium-list=sdamon@python.org] On Behalf Of Alexander Heger Sent: Friday, August 19, 2016 11:14 PM To: python-ideas Subject: [Python-ideas] discontinue iterable strings standard python should discontinue to see strings as iterables of characters - length-1 strings. I see this as one of the biggest design flaws of python. It may have seem genius at the time, but it has passed it usefulness for practical language use. For example, numpy has no issues >>> np.array('abc') array('abc', dtype='>> list('abc') ['a', 'b', 'c'] Numpy was of course design a lot later, with more experience in practical use (in mind). Maybe a starting point for transition that latter operation also returns ['abc'] in the long run, could be to have an explicit split operator as recommended use, e.g., 'abc'.split() 'abc'.split('') 'abc'.chars() 'abc'.items() the latter two could return an iterator whereas the former two return lists (currently raise exceptions). Similar for bytes, etc. ___ 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] Let’s make escaping in f-literals impossible
On 08/19/2016 08:57 PM, C Anthony Risinger wrote: [...] The appeal of f-strings is the rapid inlining of whatever plus string data. "Whatever" is typically more complex than a simple attribute access or variable reference, though not much more complex eg. `object.method(key, "default")`. If I have to water it down for people to find it acceptable (such as creating simpler variables ahead-of-time) I'd probably just keep using .format(...). Because what I have gained with an f-string? I suspect f-strings are in the same category as lambda -- if it's that complex, use the other tools instead. At this point I don't see this changing. If you want to make any headway you're going to have to do it with a complete alternate implementation, and even then I don't think you have good odds. -- ~Ethan~ ___ 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] discontinue iterable strings
On Aug 19, 2016 11:14 PM, "Alexander Heger" wrote: > > standard python should discontinue to see strings as iterables of characters - length-1 strings. I see this as one of the biggest design flaws of python. It may have seem genius at the time, but it has passed it usefulness for practical language use. I'm bothered by it whenever I want to write code that takes a sequence and returns a sequence of the same type. But I don't think that the answer is to remove the concept of strings as sequences. And I don't want strings to be sequences of character code points, because that's forcing humans to think on the implementation level. Please explain the problem with the status quo, preferably with examples where it goes wrong. > For example, numpy has no issues > > >>> np.array('abc') > array('abc', dtype=' whereas, as all know, > > >>> list('abc') > ['a', 'b', 'c'] > > Numpy was of course design a lot later, with more experience in practical use (in mind). Numpy is for numbers. It was designed with numbers in mind. Numpy's relevant experience here is wy less than general Python's. ___ 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] discontinue iterable strings
On Sat, Aug 20, 2016, at 01:47, Franklin? Lee wrote: > That says, "This is a 0-length array of 3-char Unicode strings." Numpy > doesn't recognize the string as a specification of an array. Try > `np.array(4.)` and you'll get (IIRC) `array(4., dtype='float')`, which > has > shape `()`. Numpy probably won't let you index either one. What can you > even do with it? In my poking around I found that you can index it with [()] or access with .item() and .itemset(value). Still seems more like a party trick than the well-reasoned practical implementation choice he implied it was. ___ 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] Let’s make escaping in f-literals impossible
On 2016-08-19 13:11, C Anthony Risinger wrote: It might be harder to find the end of an f-string in one shot, but I think that's the crux of the issue: to a reader/developer, is an f-string conceptually one thing or a compound thing? To me (someone who would like to see f-string expressions appear like normal expressions, without extra quoting, and proper syntax highlighting *always*, just like shell), this argument is essentially the same as trying to use a regex to find a closing bracket or brace or parse HTML. It's only hard (disregarding any underlying impl details) because that view regards f-strings as singular things with only one "end", when in reality an f-string is much much more like a compound expression that just happens to look like a string. Personally I think that is a dangerous road to go down. It seems it would lead to the practice of doing all sorts of complicated things inside f-strings, which seems like a bad idea to me. In principle you could write your entire program in an f-string, but that doesn't mean we need to accommodate the sort of syntax highlighting that would facilitate that. To me it seems more prudent to just say that f-strings are (as the name implies) strings, and leave it at that. If I ever get to the point where what I'm doing in the f-string is so complicated that I really need syntax highlighting for it to look good, I'd take that as a sign that I should move some of that code out of the f-string into ordinary expressions. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown ___ 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] discontinue iterable strings
On 20 August 2016 at 15:47, Franklin? Lee wrote: On Aug 19, 2016 11:14 PM, "Alexander Heger" wrote: > > standard python should discontinue to see strings as iterables of characters - length-1 strings. I see this as one of the biggest design flaws of python. It may have seem genius at the time, but it has passed it usefulness for practical language use. I'm bothered by it whenever I want to write code that takes a sequence and returns a sequence of the same type. But I don't think that the answer is to remove the concept of strings as sequences. And I don't want strings to be sequences of character code points, because that's forcing humans to think on the implementation level. Please explain the problem with the status quo, preferably with examples where it goes wrong. > For example, numpy has no issues > > >>> np.array('abc') > array('abc', dtype='>> a = np.array('abc') >>> a[()] 'abc' >>> a[()][2] 'c' The point is it does not try to disassemble it into elements as it would do with other iterables >>> np.array([1,2,3]) array([1, 2, 3]) >>> np.array([1,2,3]).shape (3,) Numpy is for numbers. It was designed with numbers in mind. Numpy's relevant experience here is wy less than general Python's. But it does deal with strings as monolithic objects, doing away with many of the pitfalls of strings in Python. And yes, it does a lot about memory management, so it is fully aware of strings and bytes ... ___ 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] discontinue iterable strings
This would introduce a major inconsistency. To do this, you would need to also strip string’s of their status as sequences (in collections.abc, Sequence is a subclass of Iterable). Thus, making string’s no longer iterable would also mean you could no longer take the length or slice of a string. you can always define __len__ and __index__ independently. I do this for many objects. But it is a point I have not considered. While I believe your proposal was well intentioned, IMHO it would cause a giant inconsistency in Python (why would one of our core sequences not be iterable?) Yes, I am aware it will cause a lot of backward incompatibilities, but this is based on all the lengthy discussions about "string but not iterable" type determinations. If sting was not iterable, a lot of things would also be easier. You could also argue why an integer cannot be iterated over its bits? As had been noted, is one of few objects of which the component can be the object itself. 'a'[0] == 'a' I do not iterate over strings so often that it could not be done using, e.g., str.chars(): for c in str.chars(): print(c) On 20 August 2016 at 13:24, Edward Minnix wrote: > This would introduce a major inconsistency. To do this, you would need to > also strip string’s of their status as sequences (in collections.abc, > Sequence is a subclass of Iterable). Thus, making string’s no longer > iterable would also mean you could no longer take the length or slice of a > string. > > While I believe your proposal was well intentioned, IMHO it would cause a > giant inconsistency in Python (why would one of our core sequences not be > iterable?) > > - Ed > > > On Aug 19, 2016, at 11:13 PM, Alexander Heger wrote: > > > > standard python should discontinue to see strings as iterables of > characters - length-1 strings. I see this as one of the biggest design > flaws of python. It may have seem genius at the time, but it has passed it > usefulness for practical language use. For example, numpy has no issues > > > > >>> np.array('abc') > > array('abc', dtype=' > > > whereas, as all know, > > > > >>> list('abc') > > ['a', 'b', 'c'] > > > > Numpy was of course design a lot later, with more experience in > practical use (in mind). > > > > Maybe a starting point for transition that latter operation also returns > ['abc'] in the long run, could be to have an explicit split operator as > recommended use, e.g., > > > > 'abc'.split() > > 'abc'.split('') > > 'abc'.chars() > > 'abc'.items() > > > > the latter two could return an iterator whereas the former two return > lists (currently raise exceptions). > > Similar for bytes, etc. > > > > > > > > ___ > > 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/ > ___ 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] Let’s make escaping in f-literals impossible
On 2016-08-19 20:57, C Anthony Risinger wrote: In a quality editor, everything about the {...} will tell me I'm writing a Python expression. It'll be colored like an expression. It'll do fancy completion like an expression. Aw shucks, it*IS* a Python expression! Except for one tiny detail: I'm not allowed to use the quote I use in 95% of all my Python code--without thinking--because I already used it at the string start :-( It's like this weird invisible ruh-roh-still-in-a-string state hangs over you despite everything else suggesting otherwise But it IS inside a string. That's why it's an f-string. The essence of your argument seems to be that you want expressions inside f-strings to act just like expressions outside of f-strings. But there's already a way to do that: just write the expression outside of the f-string. Then you can assign it to a variable, and refer to the variable in the f-string. The whole point of f-strings is that they allow expressions *inside strings*. It doesn't make sense to pretend those expressions are not inside strings. It's true that the string itself "isn't really a string" in the sense that it's put together at runtime rather than being a constant, but again, the point of f-strings is to make things like that writable as strings in source code. If you don't want to write them as strings, you can still concatenate separate string values or use various other solutions. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown ___ 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] discontinue iterable strings
> > > That says, "This is a 0-length array of 3-char Unicode strings." Numpy > > doesn't recognize the string as a specification of an array. Try > > `np.array(4.)` and you'll get (IIRC) `array(4., dtype='float')`, which > > has > > shape `()`. Numpy probably won't let you index either one. What can you > > even do with it? > > In my poking around I found that you can index it with [()] or access > with .item() and .itemset(value). Still seems more like a party trick > than the well-reasoned practical implementation choice he implied it > was. my apologies about the confusion, the dim=() was not the point, but rather that numpy treats the string as a monolithic object rather than disassembling it as it would do with other iterables. I was just trying to give the simplest possible example. Numpy still does >>> np.array([[1,2],[3,4]]) array([[1, 2], [3, 4]]) >>> np.array([[1,2],[3,4]]).shape (2, 2) but not here >>> np.array(['ab','cd']) array(['ab', 'cd'], dtype='>> np.array(['ab','cd']).shape (2,) -Alexander ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/