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
str.replace()
.. perhaps a lesser point ...
4) Batteries Included - In this case Python 3 is more obtuse than Python 2
in a task which often showcases Pythons ease of use. (see 'Programming
Foundations with Python's' secret message lesson for an example.)

Those on this list are the least likely to want this functionality, because
each of us could solve this quickly in many different ways, but that
doesn't mean we should.  It is the tasks we don't think about that i
believe often eat up cycles.  Like I said, even is this is a bad idea I
would like to fully grok why.  Thank you all for your time.

On 23 October 2016 at 02:45, David B  wrote:

> 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
> > 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 easily strip()
> > preceding and trailing characters, and even replace() individual
> characters
> > from a string, to replace more than one characters from anywhere within
> the
> > string requires (i believe) at its simplest a command like this :
> >
> > some_string.translate(str.maketrans('','','0123456789'))
> >
> > In Python 2.* however we could say ...
> >
> > some_string.translate(None, '0123456789')
> >
> > My proposal is that if strip() and replace() are important enough to
> > receive modules, then the arguably more common operation (in terms of
> > programming tutorials, if not mainstream development) of just removing
> all
> > instances of specified numbers, punctuation, or even letters etc from a
> > list of characters should also.
> >
> > I wholeheartedly admit that there are MANY other ways to do this
> (including
> > RegEx and List Comprehensions), as listed in the StackOverflow answer
> > below.   However the same could be said for replace() and strip().
> > http://stackoverflow.com/questions/22187233/how-to-
> delete-all-instances-of-a-character-in-a-string-in-python
> >
> > This is my first suggestion and welcome any and all feedback, even if
> this
> > is a silly idea I would really like to know why it is.  I have not seen
> > discussion of this before, but if there is such a discussion I would
> > welcome being directed to it.
> >
> > Thank you for your time.
> > Simon
> >
>
>
> --
> With the simplicity of true nature, there shall be no desire.
> Without desire, one's original nature will be at peace.
> And the world will naturally be in accord with the right Way.  Tao Te Ching
>



-- 

Simon Holland BA Hons
Medan, Indonesia

Mobile : +62 81 26055297
Fax : +62 81 6613280


 [image: Twitter]  [image: LinkedIn]
 [image: YouTube]
 [image: Google Talk]

___
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] 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
>> working on files, and I myself have finally started routinely using them,
>> and teaching newbies to use them -- which is kind of a pain, 'cause I want
>> to have them do basic file reading stuff before I explain what a "context
>> manager" is.
>
> This is actually a case where style guidelines would ideally differ
> between between scripting use cases (let the GC handle it whenever,
> since your process will be terminating soon anyway) and
> library(/framework/application) development use cases (promptly clean
> up after yourself, since you don't necessarily know your context of
> use).
>
> However, that script/library distinction isn't well-defined in
> computing instruction in general, and most published style guides are
> written by library/framework/application developers, so students and
> folks doing ad hoc scripting tend to be the recipients of a lot of
> well-meaning advice that isn't actually appropriate for them :(

Pondering this overnight, I realised there's a case where folks using
Python primarily as a scripting language can still run into many of
the resource management problems that arise in larger applications:
IPython notebooks, where the persistent kernel can keep resources
alive for a surprisingly long time in the absence of a reference
counting GC. Yes, they have the option of just restarting the kernel
(which many applications don't have), but it's still a nicer user
experience if we can help them avoid having those problems arise in
the first place.

This is likely mitigated in practice *today* by IPython users mostly
being on CPython for access to the Scientific Python stack, but we can
easily foresee a future where the PyPy community have worked out
enough of their NumPy compatibility and runtime redistribution
challenges that it becomes significantly more common to be using
notebooks against Python kernels that don't use automatic reference
counting.

I'm significantly more amenable to that as a rationale for pursuing
non-syntactic approaches to local resource management than I am the
notion of pursuing it for the sake of high performance application
development code.

Chris, would you be open to trying a thought experiment with some of
your students looking at ways to introduce function-scoped
deterministic resource management *before* introducing with
statements? Specifically, I'm thinking of a progression along the
following lines:

# Cleaned up whenever the interpreter gets around to cleaning up
the function locals
def readlines_with_default_resource_management(fname):
return open(fname).readlines()

# Cleaned up on function exit, even if the locals are still
referenced from an exception traceback
# or the interpreter implementation doesn't use a reference counting GC
from local_resources import function_resource

def readlines_with_declarative_cleanup(fname):
   return function_resource(open(fname)).readlines()

# Cleaned up at the end of the with statement
def readlines_with_imperative_cleanup(fname):
with open(fname) as f:
return f.readlines()

The idea here is to change the requirement for new developers from
"telling the interpreter what to *do*" (which is the situation we have
for context managers) to "telling the interpreter what we *want*"
(which is for it to link a managed resource with the lifecycle of the
currently running function call, regardless of interpreter
implementation details)

Under that model, Inada-san's recent buffer snapshotting proposal
would effectively be an optimised version of the one liner:

def snapshot(data, limit, offset=0):
return bytes(function_resource(memoryview(data))[offset:limit])

The big refactoring benefit that this feature would offer over with
statements is that it doesn't require a structural change to the code
- it's just wrapping an existing expression in a new function call
that says "clean this up promptly when the function terminates, even
if it's still part of a reference cycle, or we're not using a
reference counting GC".

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] 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 notice that your quotes are curved if you don't know
that's what you're looking for.


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 run Python 2 code under Python 3.

At the moment, tokenizer and parser errors are some of the most
beginner-hostile ones we offer, since we don't have any real context
when raising them - it's just a naive algorithm saying "This isn't the
text I expected to see next". By contrast, later in the code
generation pipeline, we have more information about what the user was
trying to do, and can usually offer better errors.

What Guido pointed out when I was working on the "print" heuristic is
that we actually get a second go at this: the *exception constructor*
usually has access to the text that the tokenizer or parser couldn't
handle, and since it isn't on the critical performance path for
anything, we can afford to invest some time in looking for common
kinds of errors and try to nudge folks in a better direction when we
think they've tripped over one of them.


(Continuing my response to Steven saying "improved error messages ... 
(especially in IDLE)")


IDLE compiles()s and exec()s user code within separate try-except 
blocks, the latter usually being in a separate processes.  Runtime 
tracebacks and exceptions are sent back to IDLE's Shell to be printed 
just as in a console (except for colorizing).  Compile errors are 
handled differently.  Tracebacks are tossed after extracting the file, 
line, and column (the last from the ^ marker). The latter are used to 
tag text with a red background.  For shell input, the exception is 
printed normally.  For editor input, it is displayed in a messagebox 
over the editor window.


My point is that IDLE already intercepts exceptions and, for 
SyntaxErrors, does simple modifications (hopefully enhancements) *in 
Python*.  So it could be an easy place to prototype, in Python, more 
advanced enhancements.  Experimental enhancements could be made 
optional, and could supplement rather than replace the original message. 
 They could also be added and modified in bugfix releases.


I will say more about explaining exceptions better in another post.

--
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] 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 same time.


If the semicolon syntax I suggested were available,
you'd be able to choose either order, and maybe even
mix them in the one comprehension. Not sure if that's
a good thing or not...

--
Greg
___
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] 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" when folks attempt to run Python 2 code under Python 3.
>

+1, big time. There are a few tricks you can easily teach people
("syntax error on line X might actually be on the previous line"), but
the more that the language can help with, the better.

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] 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 in the first place is so that it can be read
>>> declaratively -- as a description of the list you want,
>>> rather than a step-by-step sequence of instructions for
>>> building it up.
>>>
>>> If you have to stop and mentally transform it into nested
>>> for-statements, that very purpose is undermined.
>>
>> Exactly.
>
>
> 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.  Here it is about the
order of loop execution.  The current behaviour in comprehension is that is
ts being done the same way as in nested for loops.  Which is easy enough to
remember.  Same way, everywhere.

A strict interpretation by this logic would also require the [x ...] part
to be at the end, like [... x] since that's how it would look in a nested
for loop (inside deepest loop).

I personally agree with what many others have said, in that comprehension
order is not intuitive as is. I still page fault about it after many years
of using.

Is there a way to move the expression bit to the end in a backcompat way?
It might be a completely different syntax though (I think both colons and
semicolons were suggested).

FWIW, 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 same time. We
retain the for loop order but then hoist the expression to the top. Ideally
we'd either not do that, or reverse the for loop order.
___
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] 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,
> and teaching newbies to use them -- which is kind of a pain, 'cause I want
> to have them do basic file reading stuff before I explain what a "context
> manager" is.

This is actually a case where style guidelines would ideally differ
between between scripting use cases (let the GC handle it whenever,
since your process will be terminating soon anyway) and
library(/framework/application) development use cases (promptly clean
up after yourself, since you don't necessarily know your context of
use).

However, that script/library distinction isn't well-defined in
computing instruction in general, and most published style guides are
written by library/framework/application developers, so students and
folks doing ad hoc scripting tend to be the recipients of a lot of
well-meaning advice that isn't actually appropriate for them :(

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] 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 that your quotes are curved if you don't
know that's what you're looking for.

-Ryan Birmingham

On 22 October 2016 at 03:16, Steven D'Aprano > wrote:

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
> same token, and same for single quotes, eliminating any need for 
additional
> changes further down the chain).

There's a lot more than two. At least nineteen (including the ASCII
ones): 〝〞〟＂＇"'«»‘’‚‛“”„‟‹›


> This would help with copying and pasting
> code snippets from a source that may have auto-formatted the quotes 
without
> the original author realizing it.

Personally, I think that we should not encourage programmers to take a
lazy, slap-dash attitude to coding. Precision is important to
programmers, and there is no limit to how imprecise users can be. Should
we also guard against people accidentally using prime marks or ornaments
(dingbats):

′″‴‵‶‷ ❛❜❝❞❮❯

as well? If not, what makes them different from other accidents of
careless programmers?

I don't think we should be trying to guess what programmers mean, nor do
I think that we should be encouraging programmers to use word processors
for coding. Use the right tool for the right job, and even Notepad is
better for the occasional programmer than Microsoft Office or
LibreOffice. Programming is hard, requiring precision and care, and we
don't do beginners any favours by making it easy for them to be
imprecise and careless.

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

(especially in IDLE), but I'm very dubious about the idea of using
typographical quote marks for strings. At the very least, Python should
not lead the way here. Let some other language experiment with this
first, and see what happens. Python is a mature, established language,
not an experimental language.

Of course, there's nothing wrong with doing an experimental branch of
Python supporting this feature, to see what happens. But that doesn't
mean we should impose it as an official language rule.



--
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/





___
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] 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 of loop execution.  The current behaviour 
in comprehension is that is ts being done the same way as in nested 
for loops.


It still would. Just read it from right to left. The order stays the same.


Which is easy enough to remember.  Same way, everywhere.


I am sorry but many disagree with you on this thread.

I still don't understand why the order needs to be one-way anyway. 
Comprehensions are a declarative construct, so it should be possible to 
mix those "for .. in .."s up in an arbitrary order.


Cheers,
Sven
___
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] 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 replacing
>> straight quotes with these typographical characters.
>>
>
> A programming editor shouldn't mangle your quotes, and a word
> processor sucks for editing code anyway, so I'd rule those out. When
> does an operating system change your quotes? It's really just mail and
> web where these kinds of issues happen. Any web site that's actually
> designed for code is, like a programmer's editor, going to be
> quote-safe; and it's not hard to configure a mail client to not mess
> with you.
>
> How strong is this use-case, really?

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
format the code as visibly code, the smart quote translation has
already happened). That's remarkably common in the sorts of
environments I deal in, where code gets quoted in documents, and then
later copied out to be reused.
* Tutorial/example material prepared by non-programmers, again using
tools that are too "helpful" in auto-converting to smart quotes.

So in my experience this problem is pretty common. However, I view it
as a chance to teach correct use of quotes in programming, rather than
something to gloss over or "do what I mean" with.

-1 from me.

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] 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 easily strip()
preceding and trailing characters, and even replace() individual characters
from a string, to replace more than one characters from anywhere within the
string requires (i believe) at its simplest a command like this :

some_string.translate(str.maketrans('','','0123456789'))

In Python 2.* however we could say ...

some_string.translate(None, '0123456789')

My proposal is that if strip() and replace() are important enough to
receive modules, then the arguably more common operation (in terms of
programming tutorials, if not mainstream development) of just removing all
instances of specified numbers, punctuation, or even letters etc from a
list of characters should also.

I wholeheartedly admit that there are MANY other ways to do this (including
RegEx and List Comprehensions), as listed in the StackOverflow answer
below.   However the same could be said for replace() and strip().
http://stackoverflow.com/questions/22187233/how-to-delete-all-instances-of-a-character-in-a-string-in-python

This is my first suggestion and welcome any and all feedback, even if this
is a silly idea I would really like to know why it is.  I have not seen
discussion of this before, but if there is such a discussion I would
welcome being directed to it.

Thank you for your time.
Simon
___
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] 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 03:16, Steven D'Aprano  wrote:

> 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
> > same token, and same for single quotes, eliminating any need for
> additional
> > changes further down the chain).
>
> There's a lot more than two. At least nineteen (including the ASCII
> ones): 〝〞〟＂＇"'«»‘’‚‛“”„‟‹›
>
>
> > This would help with copying and pasting
> > code snippets from a source that may have auto-formatted the quotes
> without
> > the original author realizing it.
>
> Personally, I think that we should not encourage programmers to take a
> lazy, slap-dash attitude to coding. Precision is important to
> programmers, and there is no limit to how imprecise users can be. Should
> we also guard against people accidentally using prime marks or ornaments
> (dingbats):
>
> ′″‴‵‶‷ ❛❜❝❞❮❯
>
> as well? If not, what makes them different from other accidents of
> careless programmers?
>
> I don't think we should be trying to guess what programmers mean, nor do
> I think that we should be encouraging programmers to use word processors
> for coding. Use the right tool for the right job, and even Notepad is
> better for the occasional programmer than Microsoft Office or
> LibreOffice. Programming is hard, requiring precision and care, and we
> don't do beginners any favours by making it easy for them to be
> imprecise and careless.
>
> 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
>
> (especially in IDLE), but I'm very dubious about the idea of using
> typographical quote marks for strings. At the very least, Python should
> not lead the way here. Let some other language experiment with this
> first, and see what happens. Python is a mature, established language,
> not an experimental language.
>
> Of course, there's nothing wrong with doing an experimental branch of
> Python supporting this feature, to see what happens. But that doesn't
> mean we should impose it as an official language rule.
>
>
>
> --
> 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/
>
___
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] 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 programming editor shouldn't mangle your quotes, and a word
processor sucks for editing code anyway, so I'd rule those out. When
does an operating system change your quotes? It's really just mail and
web where these kinds of issues happen. Any web site that's actually
designed for code is, like a programmer's editor, going to be
quote-safe; and it's not hard to configure a mail client to not mess
with you.

How strong is this use-case, really?

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] 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
> same token, and same for single quotes, eliminating any need for additional
> changes further down the chain).

There's a lot more than two. At least nineteen (including the ASCII 
ones): 〝〞〟＂＇"'«»‘’‚‛“”„‟‹›


> This would help with copying and pasting
> code snippets from a source that may have auto-formatted the quotes without
> the original author realizing it.

Personally, I think that we should not encourage programmers to take a 
lazy, slap-dash attitude to coding. Precision is important to 
programmers, and there is no limit to how imprecise users can be. Should 
we also guard against people accidentally using prime marks or ornaments 
(dingbats):

′″‴‵‶‷ ❛❜❝❞❮❯

as well? If not, what makes them different from other accidents of 
careless programmers?

I don't think we should be trying to guess what programmers mean, nor do 
I think that we should be encouraging programmers to use word processors 
for coding. Use the right tool for the right job, and even Notepad is 
better for the occasional programmer than Microsoft Office or 
LibreOffice. Programming is hard, requiring precision and care, and we 
don't do beginners any favours by making it easy for them to be 
imprecise and careless.

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

(especially in IDLE), but I'm very dubious about the idea of using 
typographical quote marks for strings. At the very least, Python should 
not lead the way here. Let some other language experiment with this 
first, and see what happens. Python is a mature, established language, 
not an experimental language.

Of course, there's nothing wrong with doing an experimental branch of 
Python supporting this feature, to see what happens. But that doesn't 
mean we should impose it as an official language rule.



-- 
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] 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 PEP.
I am aware that there are other unicode characters, even in English with
the Quotation_Mark character property, but 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.

-Ryan Birmingham

On 22 October 2016 at 02:35, Steven D'Aprano  wrote:

> 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 « … » “…”
>
> - Swiss «…» ‹…›
>
> - Hebrew „…” ‚…’
>
> - Hungarian „…” »…«
>
> - Icelandic „…“ ‚…‘
>
> - Japanese 「…」 『…』
>
> - Polish „…” «…» »…«
>
> - Swedish ”…” ’…’ »…» »…«
>
> to mention only a few. I think it would be unfair to all the non-Dutch
> programmers if we only supported Dutch quotation marks, but as you can
> see, supporting the full range of internationalised curly quotes is
> difficult.
>
>
> > Although most languages do not support these characters as quotation
> marks,
> > I believe that cPython should, if possible.
>
> You say "most" -- do you know which programming languages support
> typographical quotation marks for strings? It would be good to see a
> survey of which languages support this feature, and how they cope with
> the internationalisation problem.
>
> I think this is likely to be just too hard. There's a reason why
> programming has standardized on the lowest common denominator for
> quotation marks '' "" and occasionally `` as well.
>
>
> --
> 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/
>
___
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] 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 « … » “…”

- Swiss «…» ‹…›

- Hebrew „…” ‚…’

- Hungarian „…” »…«

- Icelandic „…“ ‚…‘

- Japanese 「…」 『…』

- Polish „…” «…» »…«

- Swedish ”…” ’…’ »…» »…«

to mention only a few. I think it would be unfair to all the non-Dutch 
programmers if we only supported Dutch quotation marks, but as you can 
see, supporting the full range of internationalised curly quotes is 
difficult.


> Although most languages do not support these characters as quotation marks,
> I believe that cPython should, if possible.

You say "most" -- do you know which programming languages support 
typographical quotation marks for strings? It would be good to see a 
survey of which languages support this feature, and how they cope with 
the internationalisation problem.

I think this is likely to be just too hard. There's a reason why 
programming has standardized on the lowest common denominator for 
quotation marks '' "" and occasionally `` as well.


-- 
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] 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 additional
changes further down the chain). This would help with copying and pasting
code snippets from a source that may have auto-formatted the quotes without
the original author realizing it.

On Sat, Oct 22, 2016 at 1:46 AM Ryan Birmingham 
wrote:

> I was thinking of using them only as possibly quotes characters, as
> students and beginners seem to have difficulties due to this quote-mismatch
> error. That OSX has smart quotes enabled by default makes this a worthwhile
> consideration, in my opinion.
>
> -Ryan Birmingham
>
> On 22 October 2016 at 01:34, Ethan Furman  wrote:
>
> On 10/21/2016 10:17 PM, Ryan Birmingham wrote:
>
> I want to start small and ask about smart/curly quote marks (” vs ").
>  Although most languages do not support these characters as quotation
>  marks, I believe that cPython should, if possible. I'm willing to write
>  the patch, of course, but I wanted to ask about this change, if it has
>  come up before, and if there are any compatibility issues that I'm not
>  seeing here.
>
>
> What is the advantage of supporting them?  New behavior, or just more
> possible quotes characters?
>
> --
> ~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/
>
>
> ___
> 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/