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
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
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
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-strin
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/tokeni
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 n
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):
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/
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
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/pytho
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 cle
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
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 real
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 tha
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
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
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
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 simi
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 a
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
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
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
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
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 lo
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.arra
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.
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
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
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 hilighte
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
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
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 lang
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 probabl
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 appe
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,
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.
yo
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 n
>
> > 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 ca
38 matches
Mail list logo
