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

2016-10-26 Thread 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

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

2016-10-26 Thread 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: >

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

2016-10-26 Thread 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

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

2016-10-26 Thread 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

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

2016-10-26 Thread 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

Re: [Python-ideas] A better interactive prompt

2016-10-26 Thread 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,

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

2016-10-26 Thread 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

Re: [Python-ideas] A better interactive prompt

2016-10-26 Thread 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']

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

2016-10-26 Thread 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

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

2016-10-26 Thread 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

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

2016-10-26 Thread 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

Re: [Python-ideas] A better interactive prompt

2016-10-26 Thread 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

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

2016-10-26 Thread 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

Re: [Python-ideas] A better interactive prompt

2016-10-26 Thread 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

Re: [Python-ideas] A better interactive prompt

2016-10-26 Thread 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

Re: [Python-ideas] A better interactive prompt

2016-10-26 Thread 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

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

2016-10-26 Thread 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

Re: [Python-ideas] A better interactive prompt

2016-10-26 Thread 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 > )

Re: [Python-ideas] A better interactive prompt

2016-10-26 Thread 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

Re: [Python-ideas] A better interactive prompt

2016-10-26 Thread 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

Re: [Python-ideas] A better interactive prompt

2016-10-26 Thread 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

Re: [Python-ideas] Fwd: unpacking generalisations for list comprehension

2016-10-26 Thread 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

Re: [Python-ideas] A better interactive prompt

2016-10-26 Thread 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

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

2016-10-26 Thread 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

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

2016-10-26 Thread 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:

Re: [Python-ideas] A better interactive prompt

2016-10-26 Thread 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

Re: [Python-ideas] Deterministic iterator cleanup

2016-10-26 Thread 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

Re: [Python-ideas] Deterministic iterator cleanup

2016-10-26 Thread 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

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

2016-10-26 Thread 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

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

2016-10-26 Thread 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