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.tra
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 g
On 27 October 2016 at 03:51, Chris Barker wrote:
> 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
Yep, double qu
On Wed, Oct 26, 2016 at 10:16 PM, Cody Piersall wrote:
> Isn't that check really just an isatty() check? Or is that not
> reliable enough for some reason?
It's not reliable in Windows. There are no tty devices, so the C
runtime's implementation of isatty() instead returns true for
character devi
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. An
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?
>
the
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
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, the
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
On 27 October 2016 at 01:13, Steven D'Aprano wrote:
> 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
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 mailing list
Python-ideas@py
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 f
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
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 environme
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
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 cas
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 t
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 O
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 sta
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 do
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
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
On 26 October 2016 at 21:43, Nikolaus Rath wrote:
>> 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 rem
On Oct 26 2016, 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 interact
Am Freitag, 14. Oktober 2016 23:11:48 UTC-7 schrieb Nick Coghlan:
>
>
> Regarding the spelling details, my current preferences are as follows:
>
> * None-coalescing operator: x ?or y
> * None-severing operator: x ?and y
> * None-coalescing augmented assignment: x ?= y
> * None-severing attribut
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 characte
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, eve
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
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
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 m
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
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
> ExitStac
On Wed, Oct 26, 2016 at 01:25:48AM +0100, Rob Cliffe wrote:
> (2) This is admittedly a somewhat tangential argument, but: I didn't
> really know what "yield from" meant. But when I read in an earlier post
> that someone had proposed "yield *" for it, I had a Eureka moment.
Are you aware that
On 26 October 2016 at 01:59, Yury Selivanov wrote:
> But how would it help with a partial iteration over generators
> with a "with" statement inside?
>
>def it():
>with open(file) as f:
>for line in f:
>yield line
>
> Nathaniel proposal addresses this by fix
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 dict
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
h
39 matches
Mail list logo