Re: [Python-ideas] Easily remove characters from a string.

2016-10-22 Thread Simon Mark Holland
Understood, and I agree, I have seen someone make a similar argument for using RegEx. Here are my main points... 1) Speed - Built-in's are faster. 2) Standardisation - It is a common task, that has MANY ways of being completed. 3) Frequent Task - It is to my mind as useful as str.strip() or

Re: [Python-ideas] Deterministic iterator cleanup

2016-10-22 Thread Nick Coghlan
On 23 October 2016 at 02:17, Nick Coghlan wrote: > On 22 October 2016 at 06:59, Chris Barker wrote: >> And then context managers were introduced. And it seems to be there is a >> consensus in the Python community that we all should be using them when >>

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

2016-10-22 Thread Terry Reedy
On 10/22/2016 12:32 PM, Nick Coghlan wrote: On 22 October 2016 at 17:36, Ryan Birmingham wrote: Per the comments in this thread, I believe that a better error message for this case would be a reasonable way to fix the use case around this issue. It can be difficult to

Re: [Python-ideas] Order of loops in list comprehension

2016-10-22 Thread Greg Ewing
C Anthony Risinger wrote: Erlang/Elixir (sorry after 6 years python this is what I do now!) does it the same way as python: >>> [{X, Y} || X <- [1,2,3], Y <- [a,b]]. [{1,a},{1,b},{2,a},{2,b},{3,a},{3,b}] Here X is the outer loop. I think the confusion stems from doing it both ways at the

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

2016-10-22 Thread Chris Angelico
On Sun, Oct 23, 2016 at 3:32 AM, Nick Coghlan wrote: > Looking for particular Unicode confusables when post-processing > SyntaxErrors seems like a reasonable idea to me - that's how we ended > up implementing the heuristic that reports "Missing parenthesis in > call to print"

Re: [Python-ideas] Order of loops in list comprehension

2016-10-22 Thread C Anthony Risinger
On Oct 22, 2016 2:51 AM, "Alexander Heger" wrote: >>> >>> For me the current behaviour does not seem unreasonable as it resembles the order in which you write out loops outside a comprehension >>> >>> >>> That's true, but the main reason for having comprehensions >>> syntax

Re: [Python-ideas] Deterministic iterator cleanup

2016-10-22 Thread Nick Coghlan
On 22 October 2016 at 06:59, Chris Barker wrote: > And then context managers were introduced. And it seems to be there is a > consensus in the Python community that we all should be using them when > working on files, and I myself have finally started routinely using them,

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

2016-10-22 Thread Sven R. Kunze
+1 from me for the idea of a more useful error message (if possible). On 22.10.2016 09:36, Ryan Birmingham wrote: Per the comments in this thread, I believe that a better error message for this case would be a reasonable way to fix the use case around this issue. It can be difficult to notice

Re: [Python-ideas] Order of loops in list comprehension

2016-10-22 Thread Sven R. Kunze
On 22.10.2016 09:50, Alexander Heger wrote: Well, an argument that was often brought up on this forum is that Python should do things consistently, and not in one way in one place and in another way in another place, for the same thing. Like * in list displays? ;-) Here it is about the order

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

2016-10-22 Thread Paul Moore
On 22 October 2016 at 08:17, Chris Angelico wrote: > On Sat, Oct 22, 2016 at 5:49 PM, Ryan Birmingham > wrote: >> this proposed change aims to solve the problem caused when editors, mail >> clients, web browsers, and operating systems over-zealously

[Python-ideas] Easily remove characters from a string.

2016-10-22 Thread Simon Mark Holland
Having researched this as heavily as I am capable with limited experience, I would like to suggest a Python 3 equivalent to string.translate() that doesn't require a table as input. Maybe in the form of str.stripall() or str.replaceall(). My reasoning is that while it is currently possible to

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

2016-10-22 Thread Ryan Birmingham
Per the comments in this thread, I believe that a better error message for this case would be a reasonable way to fix the use case around this issue. It can be difficult to notice that your quotes are curved if you don't know that's what you're looking for. -Ryan Birmingham On 22 October 2016 at

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

2016-10-22 Thread Chris Angelico
On Sat, Oct 22, 2016 at 5:49 PM, Ryan Birmingham wrote: > this proposed change aims to solve the problem caused when editors, mail > clients, web browsers, and operating systems over-zealously replacing > straight quotes with these typographical characters. > A

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

2016-10-22 Thread Steven D'Aprano
On Sat, Oct 22, 2016 at 06:13:35AM +, Jonathan Goble wrote: > Interesting idea. +1 from me; probably can be as simple as just having the > tokenizer interpret curly quotes as the ASCII (straight) version of itself > (in other words, " and the two curly versions of that would all produce the >

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

2016-10-22 Thread Ryan Birmingham
The quotes I intended in this email are just, and where the encoding is appropriate. Internationalization was not the intent of this. I do believe that you have a good point with supporting common quotes in other languages, but I believe that such a change would be large enough to consider a

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

2016-10-22 Thread Steven D'Aprano
On Sat, Oct 22, 2016 at 01:17:58AM -0400, Ryan Birmingham wrote: > Hello everyone, > > I want to start small and ask about smart/curly quote marks (” vs "). Which curly quotes are you going to support? There's Dutch, of course: „…” ‚…’ But how about … ? - English ‘…’ “…” - French « … » “…”

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

2016-10-22 Thread Jonathan Goble
Interesting idea. +1 from me; probably can be as simple as just having the tokenizer interpret curly quotes as the ASCII (straight) version of itself (in other words, " and the two curly versions of that would all produce the same token, and same for single quotes, eliminating any need for