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
> s
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 programming editor shouldn't mangle
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
>
>
>> 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 in the first place is so that it can be read
>> declaratively -- as a desc
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 eas
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 replacing
>> straight quotes with these typogr
On Sat, Oct 22, 2016 at 10:09 PM, Paul Moore wrote:
> While I agree that it's important for new programmers to learn
> precision, there are a lot of environments where smart quotes get
> accidentally inserted into code.
>
> * Pasting code into MS Word documents for reference (even if you then
> fo
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 20 October 2016 at 07:02, Nathaniel Smith wrote:
> The first change is to replace the outer for loop with a while/pop
> loop, so that if an exception occurs we'll know which iterables remain
> to be processed:
>
> def chain(*iterables):
> try:
> while iterables:
> for el
+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 t
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,
> and teaching newbies t
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 in the first place
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 notice that your quotes are curved if you don't know
> that's what
I would use list comprehension even if there were some other way to
translate as it is straight forward.
On 10/22/16, Simon Mark Holland wrote:
> 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
>
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" when folks attempt 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 sam
On 10/22/2016 3:16 AM, Steven D'Aprano wrote:
I would be happy to see improved error messages for smart quotes:
py> s = ‘abcd’
File "", line 1
s = ‘abcd’
^
SyntaxError: invalid character in identifier
The above *is* the improved (and regressed) 3.6 version ;-)
In 3.5.2 (o
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 notice that your quotes ar
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
>> working on files, and I myself have finally
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
str.r
20 matches
Mail list logo
