Re: [Python-ideas] More user-friendly version for string.translate()

[Chris Angelico]

On Thu, Oct 27, 2016 at 8:48 AM, Mikhail V  wrote:
> On 26 October 2016 at 20:58, Stephen J. Turnbull
>  wrote:
>>import collections
>>def translate_or_drop(string, table):
>>"""
>>string: a string to process
>>table: a dict as accepted by str.translate
>>"""
>>return string.translate(collections.defaultdict(lambda: None, **table))
>
>>All OK now?
>
> Not really. I tried with a simple example
> intab = "ae"
> outtab = "XM"
> table = string.maketrans(intab, outtab)
> collections.defaultdict(lambda: None, **table)
>
> an this gives me
> TypeError: type object argument after ** must be a mapping, not str
>
> But I probably I misunderstood the idea.

You're 99% of the way to understanding it. Try the exercise again in
Python 3. You don't have string.maketrans (which creates a 256-byte
translation mapping) - instead, you use a dictionary.

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

[Chris Angelico]

On Thu, Oct 27, 2016 at 2:06 PM, Mikhail V  wrote:
> Yep, double quotes , dashes and bullets are very valuable both for typography
> and code (which to the largest part is the same)
> So if just blank out this maximalistic BS:
> ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö
>
> And add few good bullets/blocks, probably arrows, then it would be a
> reasonable set to
> use for most cases.

You've missed out a half a dozen characters needed by Turkish or
Hungarian, and completely missed the point that the Latin script is
*NOT SUFFICIENT* for Python. If you want to argue that we should
restrict the world to 256 characters, go blog somewhere and let people
ignore you there, rather than ignoring you here. Unicode is here to
stay.

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] More user-friendly version for string.translate()

[Chris Barker]

On Wed, Oct 26, 2016 at 5:32 PM, Mikhail V  wrote:

> > (b) has the advantage of adding translation and removal in one fell
> swoop --
> > but if you only want to remove, then you have to make a translation
> table of
> > 1:1 mappings = not hard, but a annoying:
>
> Exactly that is the proposal. And for same exact reason that you point out,
> I also can't give a comment what would be better. It would be indeed
> quite strange from syntactical POV if I just want to remove "all except"
> and must call translate(). So ideally both should exist I think.
>

That kind of violate OWTDI though. Probably one's enough.

and if fact with the use-cases I can think of, and the one you mentioned,
they are really two steps: there are the characters you want to translate,
and the ones you want to keep, but the ones you want to keep are a superset
of the ones you want to translate. so if we added the "remove"option to
.translate(), then you would need to add all the "keep" charactors to your
translate table.

I'm thinking they really are different operations, give them a different
method.

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] More user-friendly version for string.translate()

[Chris Barker]

On Wed, Oct 26, 2016 at 3:48 PM, MRAB  wrote:


> str.replace( ("aaa", "a", "b"), ("b", "bbb", "a")
>>
>> and all sort of other complications!
>>
>>
> 2) Check from the longest to the shortest.
>
> If you're going to pick choice 2, does it have to be 2 tuples/lists? Why
> not a dict instead?
>

then we have a string.translate() that accepts a table of string
replacements, rather than individual character replacements -- maybe a good
idea!


-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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

[Chris Barker]

On Wed, Oct 26, 2016 at 5:10 PM, Mikhail V  wrote:

> 2) a table with characters that are reasonably valuable
> and cover 99% of all programming, communication and typography in latin
> script
>

I think it's called latin-1

And I think you've mentioned numpy - there was a discussion a while back
about having a one-byte-per-character string type (the existing ones are 4
byte unicode and kinda-sort-py2-string/bytes dtype)

perhaps you might want to revive that conversation.

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] A better interactive prompt

[Steven D'Aprano]

On Tue, Oct 25, 2016 at 10:13:54PM +0100, Paul Moore wrote:
> I've seen a lot of syntax proposals recently that are based around
> providing better ways of writing "one liner" styles of code.
[...]
> However, looking at them from the point of view of someone working at
> the interactive prompt, they can seem much more attractive.

I spend a lot of time working at the interactive prompt, and I don't 
agree that these proposals seem more attractive for that reason.


[...]
> But these limitations are not inherent to Python - they are problems
> with the interactive prompt, which is fairly basic[1]. 

It really isn't that basic. But you know that, as your footnote points 
out ;-)


> So maybe it's
> worth looking at the root issue, how to make the interactive prompt
> easier to use[2]?

I'm completely happy with moves to make the REPL better, but it won't 
make a lick of difference. Some people simply like one-liners, and won't 
be happy until they can write an entire application as a single, short 
one-liner. Look at the popularity of Perl. Or for that matter, APL. Some 
people are more concerned with minimizing the amount of vertical space a 
chunk of code users, or horizontal space, or keystrokes.

Of course we *should* care about these things! We may disagree about the 
relative weight we give to these factors, not that they are important. 
There's always going to be tension between those who want to save just 
one more line and those who think oh no not another cryptic symbol to 
memorize.

I think the Python community has managed to fit itself into a nice 
position in the "Goldilocks Zone" of syntax: not too much, not too 
little. But there's always going to be disagreements over precisely how 
much is too much, and a better REPL isn't going to stop that.

There's space for lots of languages in the world, and I'm glad there is 
room for those who love Perl one-liners to write Perl. I just don't want 
them turning Python into a second-rate Perl :-)


> But that's something of a solved problem. IPython offers a rich
> interactive environment, for people who find the limitations of the
> standard interactive prompt frustrating. Would it be worth the
> standard Python documentation promoting IPython for that role?

IPython is no panacea. It's too rich, too powerful for many users. Not 
everybody wants to replace their regular shell (say, bash) with IPython. 
And some of us don't like IPython's [in] [out] prompts and all those 
unnecessary blank lines.

We *should* promote third-party REPLs like IPython and BPython as 
alternatives for power users.

http://bpython-interpreter.org/


But we shouldn't use that as an excuse to neglect the standard REPL, 
which is pretty good. For my uses, there's not a lot that I think is 
missing: Python's REPL on Linux with readline is pretty darn good. 
Perhaps the main feature that I miss is this:

http://bugs.python.org/issue8


> Maybe
> even, if IPython is available, allowing the user to configure Python
> to use it by default as the interactive prompt 

I feel that is more something that people should configure their 
personal desktop or shell environment for, e.g. by setting up an alias.



> (a bit like readline,
> but I dislike the way you can't switch off readline integration if
> it's installed)? 

This comment surprises me. To me, that's like saying "I dislike the way 
you can't switch off breathing" -- readline is almost indispensible. The 
REPL experience without line editing (apart from backspace) and history 
is *horrible*. Why would you want to switch it off?

My hobby is collecting old Python versions, some of which are old enough 
that they don't support readline. (Or were never configured correctly 
for readline.) I don't use them often, but when I do, the experience is 
painful.



> Ideally, if IPython was more readily available, fewer
> users would be frustrated with Python's existing multi-line
> constructs. And those that were, would have the option of looking into
> custom IPython magic commands, before being forced to request language
> changes.

I don't think that the interactive prompt is what drives these requests. 
I think they are usually driven by differences in the weight people give 
to certain desirable characteristics of code.

Some people have a higher tolerance towards terse special syntax; some 
people have a higher tolerance towards verbosity. Neither is completely 
wrong (although I feel that COBOL-like verbosity is probably less 
harmful than extremely terse languages like specialist code-golf 
languages). There will always be disagreements.


> [1] On the other hand, the interactive prompt is a huge part of what
> makes Python so great - these days, when I have to code in languages
> that don't have an interactive prompt, it drives me nuts. And even
> those that do, typically don't have one as good as Python's (in spite
> of the fact that this whole mail is about needing to improve the
> Python REPL).

Exactly.



-- 
Steve

Re: [Python-ideas] More user-friendly version for string.translate()

[Mikhail V]

On 27 October 2016 at 00:17, Chris Barker  wrote:
> I"ve lost track of what (If anything) is actually being proposed here... so
> I"m going to try a quick summary:
>
>
> 1) an easy way to spell "remove all the characters other than these"
>
> I think that's a good idea. What with unicode having an enormous number of
> code points, it really does make sense to have a way to specify only what
> you want, rather than what you don't want.
>
> Back in the good old days of 1-byte chars, it wasn't hard to build up a full
> 256 element translate table -- not so much anymore. And one of the whole
> points of str.translate() is good performance.
>
>  a) a new method:
>
>str.remove_all_but(sequence_of_chars)
>   (naming TBD)
>
> b) a new flag in translate (Kind of like the decode keywords)
>
>   str.translate(table, missing='ignore'|'remove')
>
>
> (b) has the advantage of adding translation and removal in one fell swoop --
> but if you only want to remove, then you have to make a translation table of
> 1:1 mappings = not hard, but a annoying:

Exactly that is the proposal. And for same exact reason that you point out,
I also can't give a comment what would be better. It would be indeed
quite strange from syntactical POV if I just want to remove "all except"
and must call translate(). So ideally both should exist I think.

Mikhail
___
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] A better interactive prompt

[Steven D'Aprano]

On Wed, Oct 26, 2016 at 02:40:36PM -0700, Nikolaus Rath wrote:

> It also imposes a significant burden on scripting. 

"It" being a configurable REPL.

> I often have elements like this in shell scripts:
> 
> output=$(python < import h5py
> with h5py.File('foo', 'r') as fh:
>  print((fh['bla'] * fh['com']).sum())
> EOF
> )
> 
> If this now starts up IPython, it'll be *significantly* slower.

Surely this won't be a real problem in practice. Unless you give -i as a 
command line switch, calling Python as a script shouldn't need to 
run the REPL.

But even if it did, if Python's REPL was configurable, there has to be a 
way to configure it. And presumably by default it would fall back to the 
standard vanilla REPL. So "python" in your shell script will probably 
refer to "the system Python, using the default REPL" rather than 
whatever personalised Python + REPL your own personal environment sets 
up for when you type "python" at the shell prompt.

And if not, then something like this:

output=$(python --use-std-repl 

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

[Chris Angelico]

On Thu, Oct 27, 2016 at 10:18 AM, Steven D'Aprano  wrote:
> Not unless they want to get in trouble from the Académie française. They
> should write them « like this ».

« comme ça » ?

(Okay, I'm done)

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

[Steven D'Aprano]

On Wed, Oct 26, 2016 at 08:59:20AM +1100, Chris Angelico wrote:

> So should French programmers write string literals «like this»?

Not unless they want to get in trouble from the Académie française. They 
should write them « like this ».

*wink*



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

[Steven D'Aprano]

On Wed, Oct 26, 2016 at 03:37:54AM +0200, Mikhail V wrote:

> Extended ASCII

There are over 200 different, mutually incompatible, so-called 
"extended ASCII" code pages and encodings.

And of course it is ludicruous to think that you can fit all the world's 
characters into only 8-bits. There are more than 40,000 just from China 
alone, which makes it impossible to fit into 16-bits.


> So we all must repent now and get back to 8-bit charcters.

Please stop wasting everyone's time trying to set the clock back to the 
1980s.


-- 
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] A better interactive prompt

[Tim Mitchell]

Mark,
Windows folk do not type

pip install ipython

On windows it's much easier:

1) install pycharm (because it has UI for installing packages)
2) Go to settings > project interpreter
3) select the python interpeter you want to use
4) click the + button
5) search through the entire pypi listing for IPython
6) click install package

(Off topic I know - but I couldn't resist!)


>>
>>
> I'll just say that on Windows 10 I have ConEmu installed, and I edit the
> startup file to point me to umpteen different places where I want to work.
> Ipython is one of them.  Of course it is extremely difficult to install.
> My understanding is that on Windows folk find it difficult to type:-
>
> pip install ipython
>
> What have I missed?
>
> --
>
> Mark Lawrence
>
>
___
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] More user-friendly version for string.translate()

[MRAB]

On 2016-10-26 23:17, Chris Barker wrote:

I"ve lost track of what (If anything) is actually being proposed here...
so I"m going to try a quick summary:


1) an easy way to spell "remove all the characters other than these"

I think that's a good idea. What with unicode having an enormous number
of code points, it really does make sense to have a way to specify only
what you want, rather than what you don't want.

Back in the good old days of 1-byte chars, it wasn't hard to build up a
full 256 element translate table -- not so much anymore. And one of the
whole points of str.translate() is good performance.

 a) a new method:

   str.remove_all_but(sequence_of_chars)
  (naming TBD)

b) a new flag in translate (Kind of like the decode keywords)

  str.translate(table, missing='ignore'|'remove')


c) pass a function that returns the replacement:

def replace(c):
return c.upper() if c.isalpha() else ''

str.translate(replace)

The replacement function could be called only on distinct codepoints.



(b) has the advantage of adding translation and removal in one fell
swoop -- but if you only want to remove, then you have to make a
translation table of 1:1 mappings = not hard, but a annoying:

table = {c:c for c in sequence_of_chars}

I'm on the fence about what I personally prefer.

2) (in another thread, but similar enough) being able to pass in more
than one string to replace:

str.replace( old=seq_of_strings, new=seq_of_strings )

I know I've wanted this a lot, and certainly from a performance
perspective, it could be a nice bonus.

But: It overlaps a lot with str.translate -- at least for single
character replacements. so really why? so it would really only make
sense if supported multi-char strings:

str.replace(old = ("aword", "another_word"), ("something", "something
else"))

However: a string IS a sequence of strings, so we'd have confusion about
that:

str.replace("this", "four")

Does the user want the word "this" replaced with the word "four" -- or
do they want each character replaced?

Maybe we'd need a .replace_many() method? ugh!

There are also other issues with what to di with repeated / overlapping
cahractors:

str.replace( ("aaa", "a", "b"), ("b", "bbb", "a")

and all sort of other complications!


Possible choices are:

1) Use the given order.

2) Check from the longest to the shortest.

If you're going to pick choice 2, does it have to be 2 tuples/lists? Why 
not a dict instead?



THAT I think could be nailed down by defining the "order of operations"
Does it lop through the entire string for each item? or through each
item for each point in the string? note that if you loop thorugh the
entire string for each item, you might as well have written the loop
yourself:

for old, new in sip(old_list, new_list):
s = s.replace(old, new))

and at least if the length of the string si long-ish, and the number of
replacements short-ish -- performance would be fine.


*** So the question is -- is there support for these enhancements? If
so, then it would be worth hashing ot the details.

But the next question is -- does anyone care enough to manage that
process -- it'll be a lot of work!

NOTE: there has also been a fair bit of discussion in this thread about
ordinals vs characters, and unicode itself -- I don't think any of that
resulted in any possible proposals...


[snip]

___
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] A better interactive prompt

[Mark Lawrence via Python-ideas]

On 26/10/2016 20:24, Paul Moore wrote:

On 26 October 2016 at 18:25, Nick Coghlan  wrote:

The built-in REPL serves two quite divergent use cases, and I think
we're well past the point where we can't readily support both use
cases with a single implementation:

- a minimalist interactive environment, that is *always* present, even
if parts of the interpreter (most notably the import system) aren't
working or have been deliberately disabled
- a day-to-day working environment for Python developers

The prevalence of the latter use case then leads to it also being used
as a tool for introducing new developers to Python.


Thinking a little further about this, I think the reason I don't use
IPython more, is because my muscle memory types "python" (or more
often, "py") when I want an interactive prompt. And I do that for the
reason you mention - it's always there.

So I think that it would be really useful to be able to plug in a new
REPL, when it's available. This has a number of benefits:

1. We don't need to worry about incorporating any complex REPL code
into Python. The default REPL can remain simple.
2. Users can choose their preferred REPL, core Python doesn't have to
get involved in UI decisions.

The downside, of course, is that the default behaviour is inconsistent
- new users could attend a course where IPython was preinstalled, but
then struggle when back at the office because no-one told them how to
set it up.



I'll just say that on Windows 10 I have ConEmu installed, and I edit the 
startup file to point me to umpteen different places where I want to 
work. Ipython is one of them.  Of course it is extremely difficult to 
install.  My understanding is that on Windows folk find it difficult to 
type:-


pip install ipython

What have I missed?

--

Mark Lawrence

___
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] A better interactive prompt

[Nathaniel Smith]

On Wed, Oct 26, 2016 at 3:16 PM, Cody Piersall  wrote:
> On Wed, Oct 26, 2016 at 4:48 PM, Paul Moore  wrote:
>> Good point. We could, of course, detect when stdin is non-interactive,
>> but at that point the code is starting to get unreasonably complex, as
>> well as having way too many special cases. So I agree, that probably
>> kills the proposal.
>
> Isn't that check really just an isatty() check?  Or is that not
> reliable enough for some reason?  Here's some code that performs that
> check, and works on Linux and Windows:

It might or might not be an isatty() check (it's actually a bit more
complicated, there's -i and various other things to take into
account), but it hardly matters -- Python already has well-defined
logic for deciding whether it should launch an interactive REPL or
not. If we were going to do this, we'd keep that logic in place while
swapping out the actual start_a_REPL() call with something else. There
might be showstoppers here but I don't think this is one of them :-)

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
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] A better interactive prompt

[Cody Piersall]

On Wed, Oct 26, 2016 at 4:48 PM, Paul Moore  wrote:
> Good point. We could, of course, detect when stdin is non-interactive,
> but at that point the code is starting to get unreasonably complex, as
> well as having way too many special cases. So I agree, that probably
> kills the proposal.

Isn't that check really just an isatty() check?  Or is that not
reliable enough for some reason?  Here's some code that performs that
check, and works on Linux and Windows:

#include 

#ifdef _WIN32
#  include 
#  define isatty _isatty
#  define fileno _fileno
#else
#  include 
#endif

int main( void ) {
/* If stdin is a tty, you would launch the user's configured REPL*/
if(isatty(fileno(stdin)))
printf("stdin has not been redirected to a file\n");
/* Otherwise, launch the default REPL (or maybe don't launch a REPL at all,
 * and just treat stdin as a file */
else
printf("stdin has been redirected to a file\n");
}
___
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] More user-friendly version for string.translate()

[Mikhail V]

On 26 October 2016 at 20:58, Stephen J. Turnbull
 wrote:
>import collections
>def translate_or_drop(string, table):
>"""
>string: a string to process
>table: a dict as accepted by str.translate
>"""
>return string.translate(collections.defaultdict(lambda: None, **table))

>All OK now?

Not really. I tried with a simple example
intab = "ae"
outtab = "XM"
table = string.maketrans(intab, outtab)
collections.defaultdict(lambda: None, **table)

an this gives me
TypeError: type object argument after ** must be a mapping, not str

But I probably I misunderstood the idea. Anyway this code does not make
much sence to me, I would never in life understand what is meant here.
And in my not so big, but not so small, Python experience I *never* had
an occasion using collections or lambda.

>sets as a single, universal character set.  As it happens, although
>there are differences of opinion over how to handle Unicode in Python,
>there is consensus that Python does have to handle Unicode flexibly,
>effectively and efficiently.
>

I was merely talking about syntax and sources files standard, not about unicode
strings. No doubt one needs some way to store different glyph sets.

So I was talking about that if one defines a syntax and has good intentions
for readability in mind, there is not so many rationale to adopt the syntax
to current "hybrid" system: 7-bit and/or multibyte paradigm.
Again this a too far going discussion, but one should not probably much
look ahead on those. The situation is not so good in this sense that most
standard software is  attached to this strange paradigm
(even those which does not have anything
to do with multi-lingual typography).
So IMO something gone wrong with those standard characters.

>If you insist on bucking it, you'll
>have to do it pretty much alone, perhaps even maintaining your own
>fork of Python.

As for me I would take the path of developing of own IDE which will enable
typografic quality rendering and of course all useful glyphs, such as
curly quotes,
bullets, etc, which all is fundamental to any possible improvements of
cognitive qualities of code. And I'll stay in 8-bit boundaries, thats for sure.
So if Python will take the path of "unicode" code input (e.g. for some
punctuaion characters)
this would only add a minor issue for generating valid Python source
files in this case.


Mikhail
___
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] A better interactive prompt

[Paul Moore]

On 26 October 2016 at 22:40, Nikolaus Rath  wrote:
> It also imposes a significant burden on scripting. I often have elements
> like this in shell scripts:
>
> output=$(python < import h5py
> with h5py.File('foo', 'r') as fh:
>  print((fh['bla'] * fh['com']).sum())
> EOF
> )
>
> If this now starts up IPython, it'll be *significantly* slower.

Good point. We could, of course, detect when stdin is non-interactive,
but at that point the code is starting to get unreasonably complex, as
well as having way too many special cases. So I agree, that probably
kills the proposal.

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/

Re: [Python-ideas] A better interactive prompt

[Nikolaus Rath]

On Oct 26 2016, Paul Moore  
wrote:
> Thinking a little further about this, I think the reason I don't use
> IPython more, is because my muscle memory types "python" (or more
> often, "py") when I want an interactive prompt. And I do that for the
> reason you mention - it's always there.
>
> The downside, of course, is that the default behaviour is inconsistent
> - new users could attend a course where IPython was preinstalled, but
> then struggle when back at the office because no-one told them how to
> set it up.

It also imposes a significant burden on scripting. I often have elements
like this in shell scripts:

output=$(python 

Re: [Python-ideas] A better interactive prompt

[Paul Moore]

On 26 October 2016 at 22:11, Todd  wrote:
> Isn't this what aliases are for?  Just set "python" to be an alias for
> "ipython" for your interactive shell.

I hadn't thought of that option. I might give it a try. Although I'm
not sure how I'd set up a Powershell function (I'm on Windows) that
would wrap the launcher (which selects the version of Python to use)
and invoke IPython. I'll give it a go, though.

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/

Re: [Python-ideas] A better interactive prompt

[Todd]

On Wed, Oct 26, 2016 at 3:24 PM, Paul Moore  wrote:

> On 26 October 2016 at 18:25, Nick Coghlan  wrote:
> > The built-in REPL serves two quite divergent use cases, and I think
> > we're well past the point where we can't readily support both use
> > cases with a single implementation:
> >
> > - a minimalist interactive environment, that is *always* present, even
> > if parts of the interpreter (most notably the import system) aren't
> > working or have been deliberately disabled
> > - a day-to-day working environment for Python developers
> >
> > The prevalence of the latter use case then leads to it also being used
> > as a tool for introducing new developers to Python.
>
> Thinking a little further about this, I think the reason I don't use
> IPython more, is because my muscle memory types "python" (or more
> often, "py") when I want an interactive prompt. And I do that for the
> reason you mention - it's always there.
>
> So I think that it would be really useful to be able to plug in a new
> REPL, when it's available. This has a number of benefits:
>
>
Isn't this what aliases are for?  Just set "python" to be an alias for
"ipython" for your interactive shell.

Personally, my muscle memory is trained to always type "ipython3".  I only
type "python" or "python3" when I specifically want a vanilla shell (such
as for trying things out without all my default imports, which I know could
be done with profiles but that is even more typing).  Having "python3"
somehow changed to "ipython3" automatically would make things more
difficult for me since I would need to do something more complicated to get
back the vanilla shell when I need it.
___
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] Fwd: unpacking generalisations for list comprehension

[Sjoerd Job Postmus]

On Thu, Oct 27, 2016 at 03:27:07AM +1100, Steven D'Aprano wrote:
> I think that there is zero hope of consistency for * the star operator. 
> That horse has bolted. It is already used for:
> 
> - ...
> - "zero or more of the previous element" in regular expressions
> - "zero or more of any character" in globbing
> - ...

After having read this multiple times, I still can't really understand
why these two matter to the discussion at hand. It's also used to mark
emphasised text in Markdown, lists in Markdown. You can also use it for
footnotes in plain text. It also has a special meaning in robots.txt
files.

Yes, I agree with you that the meaning of the asterisk symbol is quite
overloaded on the syntax level already. But I think that mentioning
regexes and globbing is a bit of a red herring.
___
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] A better interactive prompt

[Paul Moore]

On 26 October 2016 at 18:25, Nick Coghlan  wrote:
> The built-in REPL serves two quite divergent use cases, and I think
> we're well past the point where we can't readily support both use
> cases with a single implementation:
>
> - a minimalist interactive environment, that is *always* present, even
> if parts of the interpreter (most notably the import system) aren't
> working or have been deliberately disabled
> - a day-to-day working environment for Python developers
>
> The prevalence of the latter use case then leads to it also being used
> as a tool for introducing new developers to Python.

Thinking a little further about this, I think the reason I don't use
IPython more, is because my muscle memory types "python" (or more
often, "py") when I want an interactive prompt. And I do that for the
reason you mention - it's always there.

So I think that it would be really useful to be able to plug in a new
REPL, when it's available. This has a number of benefits:

1. We don't need to worry about incorporating any complex REPL code
into Python. The default REPL can remain simple.
2. Users can choose their preferred REPL, core Python doesn't have to
get involved in UI decisions.

The downside, of course, is that the default behaviour is inconsistent
- new users could attend a course where IPython was preinstalled, but
then struggle when back at the office because no-one told them how to
set it up.

> One possible path towards improving the situation might be to look at
> the PyPy REPL (which is presumably implemented in RPython) and see if
> that would be suitable for incorporation into CPython as a frozen
> module (perhaps with some modifications). That has the advantage of
> making the REPL much easier to iterate on (since you can use the
> non-frozen version for development), while still making it available
> at runtime as part of the core Python binary.

I've never used the PyPy REPL, so I can't speak to its features. But
this seems to me to simply be a matter of incremental improvement to
the standard REPL, That's no bad thing, but as you pointed out at the
start, we can't support both of our use cases with a single
implementation, so this doesn't solve the fundamental problem - it
merely alters the breakpoint at which people need to learn not to fire
up the REPL, but rather to start up IPython, or bpython, or their
environment of choice. And it doesn't do much for people who (like me)
type "python" instinctively, and only realise they needed something
better part way through their session.

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/

Re: [Python-ideas] More user-friendly version for string.translate()

[Stephen J. Turnbull]

Mikhail V writes:

 > >That said, multiple methods is a valid option for the API.
 > 
 > Certainly I like the look of distinct functions more.
 > It allows me to visually parse the code effectively,
 > so e.g. for str.remove() I would not need to look
 > in docs to understand what the function does.

OK, as I said, you're in accord with Guido on that.  His rationale is
somewhat different, but that's OK.

 > Just in some cases I need to convert them to numpy arrays back and
 > forth, so this unicode vanity worries me a bit.

I think you're borrowing trouble you actually don't have.  Either way,
the rest of the world *needs* Unicode to do their work, and it's not
going to go away.  On the positive side, turning a string into a list
of codepoints is trivial:

[ord(c) for c in string]

 > So I am just not the one who believes in these maximalistical "we
 > need over 9000 glyphs" talks.

But you don't need to believe in it.  What you do need to believe is
that the rest of us believe that we need the union of our character
sets as a single, universal character set.  As it happens, although
there are differences of opinion over how to handle Unicode in Python,
there is consensus that Python does have to handle Unicode flexibly,
effectively and efficiently.

Believe me, it *is* a consensus.  If you insist on bucking it, you'll
have to do it pretty much alone, perhaps even maintaining your own
fork of Python.

___
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] More user-friendly version for string.translate()

[Stephen J. Turnbull]

Mikhail V writes:

 > I need translate() which drops non-defined chars. Please :)

import collections
def translate_or_drop(string, table):
"""
string: a string to process
table: a dict as accepted by str.translate
"""
return string.translate(collections.defaultdict(lambda: None, **table))

All OK now?

___
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] A better interactive prompt

[Nick Coghlan]

On 26 October 2016 at 09:15, Nathaniel Smith  wrote:
> Incidentally, PyPy's built-in REPL handles multi-line constructs like
> IPython does, rather than like how the CPython built-in REPL does.
>
> There are a lot of logistic issues that would need to be dealt with
> before CPython could consider making a third-party REPL the default or
> anything like it... it looks like IPython's dependency tree is all
> pure-Python, which makes it more viable, but it's still a lot of code
> and on a very different development cycle than CPython. bpython
> appears to depend on greenlet, which is a whole other issue... OTOH it
> seems a little quixotic to spend lots of resources improving the
> built-in REPL when there are much better ones with vibrant developer
> communities.

The built-in REPL serves two quite divergent use cases, and I think
we're well past the point where we can't readily support both use
cases with a single implementation:

- a minimalist interactive environment, that is *always* present, even
if parts of the interpreter (most notably the import system) aren't
working or have been deliberately disabled
- a day-to-day working environment for Python developers

The prevalence of the latter use case then leads to it also being used
as a tool for introducing new developers to Python.

The problem is that of these two use cases, the current default REPL
is really only *good* at the first one - for the latter, it's instead
only "frequently good enough",  since there are much better
alternatives out there that can depend on the whole Python ecosystem
rather than having to make the assumption that they should still
basically work even if the import system isn't currently set up to
bring in external modules.

One possible path towards improving the situation might be to look at
the PyPy REPL (which is presumably implemented in RPython) and see if
that would be suitable for incorporation into CPython as a frozen
module (perhaps with some modifications). That has the advantage of
making the REPL much easier to iterate on (since you can use the
non-frozen version for development), while still making it available
at runtime as part of the core Python binary.

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] Deterministic iterator cleanup

[Nick Coghlan]

On 26 October 2016 at 08:48, Nathaniel Smith  wrote:
> If it takes a strong reference, then suddenly we're pinning all
> iterators in memory until the end of the enclosing function, which
> will often look like a memory leak. I think this would break a *lot*
> more existing code than the for-scoped-iterclose proposal does, and in
> more obscure ways that are harder to detect and warn about ahead of
> time.

It would take a strong reference, which is another reason why
close_resources() would be an essential part of the explicit API
(since it would drop the references in addition to calling the
__exit__() and close() methods of the declared resources), and also
yet another reason why you've convinced me that the only implicit API
that would ever make sense is one that was scoped specifically to the
iteration process.

However, I still think the explicit-API-only suggestion is a much
better path to pursue than any implicit proposal - it will give folks
that see it for the first something to Google, and it's a general
purpose technique rather than being restricted specifically to the
cases where the resource to be managed and the iterator being iterated
over are one and the same object.

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] Deterministic iterator cleanup

[Nick Coghlan]

On 26 October 2016 at 08:25, Nathaniel Smith  wrote:
> On Sat, Oct 22, 2016 at 9:02 AM, Nick Coghlan  wrote:
>> At this point your code is starting to look a whole lot like the code
>> in contextlib.ExitStack.__exit__ :)
>
> One of the versions I tried but didn't include in my email used
> ExitStack :-). It turns out not to work here: the problem is that we
> effectively need to enter *all* the contexts before unwinding, even if
> trying to enter one of them fails. ExitStack is nested like (try (try
> (try ... finally) finally) finally), and we need (try finally (try
> finally (try finally ...)))

Regardless of any other outcome from this thread, it may be useful to
have a "contextlib.ResourceSet" as an abstraction for collective
management of resources, regardless of whatever else happens. As you
say, the main difference is that the invocation of the cleanup
functions wouldn't be nested at all and could be called in an
arbitrary order (if that's not sufficient for a particular use case,
then you'd need to define an ExitStack for the items where the order
of cleanup matters, and then register *that* with the ResourceSet).

>> A potentially more fruitful direction of research to pursue for 3.7
>> would be the notion of "frame local resources", where each Python
>> level execution frame implicitly provided a lazily instantiated
>> ExitStack instance (or an equivalent) for resource management.
>> Assuming that it offered an "enter_frame_context" function that mapped
>> to "contextlib.ExitStack.enter_context", such a system would let us do
>> things like:
>
> So basically a 'with expression', that gives up the block syntax --
> taking its scope from the current function instead -- in return for
> being usable in expression context? That's a really interesting, and I
> see the intuition that it might be less disruptive if our implicit
> iterclose calls are scoped to the function rather than the 'for' loop.
>
> But having thought about it and investigated some... I don't think
> function-scoping addresses my problem, and I don't see evidence that
> it's meaningfully less disruptive to existing code.
>
> First, "my problem":
>
> Obviously, Python's a language that should be usable for folks doing
> one-off scripts, and for paranoid folks trying to write robust complex
> systems, and for everyone in between -- these are all really important
> constituencies. And unfortunately, there is a trade-off here, where
> the changes we're discussing effect these constituencies differently.
> But it's not just a matter of shifting around a fixed amount of pain;
> the *quality* of the pain really changes under the different
> proposals.
>
> In the status quo:
> - for one-off scripts: you can just let the GC worry about generator
> and file handle cleanup, re-use iterators, whatever, it's cool
> - for robust systems: because it's the *caller's* responsibility to
> ensure that iterators are cleaned up, you... kinda can't really use
> generators without -- pick one -- (a) draconian style guides (like
> forbidding 'with' inside generators or forbidding bare 'for' loops
> entirely), (b) lots of auditing (every time you write a 'for' loop, go
> read the source to the generator you're iterating over -- no
> modularity for you and let's hope the answer doesn't change!), or (c)
> introducing really subtle bugs.

(Note: I've changed my preferred API name from "function_resource" +
"frame_resource" to the general purpose "scoped_resource" - while it's
somewhat jargony, which I consider unfortunate, the goal is to make
the runtime scope of the resource match the lexical scope of the
reference as closely as is feasible, and if folks are going to
understand how Python manages references and resources, they're going
to need to learn the basics of Python's scope management at some
point)

Given your points below, the defensive coding recommendation here would be to

- always wrap your iterators in scoped_resource() to tell Python to
clean them up when the function is done
- explicitly call close_resources() after the affected for loops to
clean the resources up early

You'd still be vulnerable to resource leaks in libraries you didn't
write, but would have decent control over your own code without having
to make overly draconian changes to your style guide - you'd only need
one new rule, which is "Whenever you're iterating over something, pass
it through scoped_resource first".

To simplify this from a forwards compatibility perspective (i.e. so it
can implicitly adjust when an existing type gains a cleanup method),
we'd make scoped_resource() quite permissive, accepting arbitrary
objects with the following behaviours:

- if it's a context manager, enter it, and register the exit callback
- if it's not a context manager, but has a close() method, register
the close method
- otherwise, pass it straight through without taking any other action

This would allow folks to always declare something as a scoped

Re: [Python-ideas] f-string, for dictionaries

[Steven D'Aprano]

On Tue, Oct 25, 2016 at 09:11:06PM +0200, Michel Desmoulin wrote:
> We have a syntax to create strings with variables automatically inferred 
> from its context:
> 
> >>> name = "Guido"
> >>> print(f'Hello {name}')
> Hello Guido


> Similarly, I'd like to suggest a similar feature for building dictionaries:
> 
> >>> foo = 1
> >>> bar = 2
> >>> {:bar, :foo}
> {'bar': 1, 'foo', 2}

How often do you do this? Under what circumstances do you do this?

If your code is like my code, the answer is: very rarely; and it is so 
long since I've needed anything like this I don't recall why. I don't 
think this is a common operation.

So even though writing:

{'spam': spam, 'eggs': eggs}

or even:

dict(spam=spam, eggs=eggs)

is a bit of an annoyance, it doesn't happen often enough to matter, and 
its better to just write what you want explicitly rather than have to 
learn another special syntax for something you use so rarely you'll 
probably never remember it. Or at least, *I'll* never remember it. It 
will be just one more cryptic and strange syntax to confuse beginners 
and intermediate users with:

# I never remember which one to use...
{:spam, :eggs}
{spam:, eggs:}
{spam, eggs}



> And a similar way to get the content from the dictionary into variables:
> 
> >>> values = {'bar': 1, 'foo', 2}
> >>> {:bar, :foo} = values
> >>> bar
> 1
> >>> foo
> 2

Check the archives:

https://mail.python.org/pipermail/python-ideas/2016-May/040430.html

https://mail.python.org/pipermail/python-ideas/2008-March/001511.html
https://mail.python.org/pipermail/python-ideas/2008-April/001513.html




-- 
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] More user-friendly version for string.translate()

[Steven D'Aprano]

On Wed, Oct 26, 2016 at 04:29:13AM +0200, Mikhail V wrote:

> I need translate() which drops non-defined chars. Please :)
> No optimisation, no new syntax. deal?

I still wonder whether this might be worth introducing as a new 
string method, or an option to translate. But the earliest that will 
happen is Python 3.7, so in the meantime, something like this should 
be enough:

# untested
keep = "abcdßαβπд∞"
text = "..."
# Find all the characters in text that are not in keep:
delchars = set(text) - set(keep)
delchars = ''.join(delchars)
text = text.translate(str.maketrans("", "", delchars))



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