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
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:
>
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
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
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
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,
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
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']
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
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
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
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
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
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
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
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
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
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
> )
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
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
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
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
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
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
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:
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
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
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
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
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
30 matches
Mail list logo