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
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
>>
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
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
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"
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
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,
+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
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
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
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
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
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
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
>
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
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 « … » “…”
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
17 matches
Mail list logo