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/
