+1, especially given that reduce is not something you use very often.
You loop and you filter everyday, but you definitely don't need the
cumulative result of a sequence everyday. Python already have good any,
all, sum and string concatenation stories so most of the FP usual
suspect are taken c
Le 22/10/2016 à 10:34, Simon Mark Holland a écrit :
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
+1. It's easier to implement, safer, and will educate. It has a real
added value.
Le 22/10/2016 à 09:36, Ryan Birmingham a écrit :
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 diff
On Sat, Oct 22, 2016 at 9:17 AM, Nick Coghlan wrote:
> This is actually a case where style guidelines would ideally differ
> between between scripting use cases ... and
> library(/framework/application) development use cases
>
Hmm -- interesting idea -- and I recall Guido bringing something lik
Hello all,
I would be happy to see a somewhat more general and user friendly
version of string.translate function.
It could work this way:
string.newtranslate(file_with_table, Drop=True, Dec=True)
So the parameters:
1. "file_with_table" : a text file with table in following format:
#[In][Ou
On Sat, Oct 22, 2016 at 4:09 AM, Paul Moore wrote:
> there are a lot of environments where smart quotes get
> accidentally inserted into code.
>
> * Tutorial/example material prepared by non-programmers, again using
> tools that are too "helpful" in auto-converting to smart quotes.
>
indeed --
my thought on this:
If you need translate() you probably can write the code to parse a text
file, and then you can use whatever format you want.
This seems a very special case to build into the stdlib.
-CHB
On Mon, Oct 24, 2016 at 10:39 AM, Mikhail V wrote:
> Hello all,
>
> I would be happ
On Sat, Oct 22, 2016 at 8:22 PM, Nick Coghlan wrote:
> 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
> This i
On Mon, Oct 24, 2016 at 8:21 AM, Michel Desmoulin wrote:
> This actually could be implemented directly in str.replace() without
> breaking the API by accepting:
>
> "stuff".replace('a', '')
> "stuff".replace(('a', 'b', 'c'), '')
> "stuff".replace(('a', 'b', 'c'), ('?', '*', ''))
>
+1 -- I have f
I also believe that using a text file would not be the best solution; using
a dictionary, other data structure, or anonomyous function would make more
sense than having a specially formatted file.
On Oct 24, 2016 13:45, "Chris Barker" wrote:
> my thought on this:
>
> If you need translate() you
On Mon, Oct 24, 2016 at 10:50 AM, Ryan Birmingham
wrote:
> I also believe that using a text file would not be the best solution;
> using a dictionary,
>
actually, now that you mention it -- .translate() already takes a dict, so
if youw ant to put your translation table in a text file, you can us
On 24 October 2016 at 18:39, Mikhail V wrote:
> I would be happy to see a somewhat more general and user friendly
> version of string.translate function.
> It could work this way:
> string.newtranslate(file_with_table, Drop=True, Dec=True)
Using a text file seems very odd. But regardless, this co
On 24 October 2016 at 20:02, Chris Barker wrote:
> On Mon, Oct 24, 2016 at 10:50 AM, Ryan Birmingham
> wrote:
>>
>> I also believe that using a text file would not be the best solution;
>> using a dictionary,
>
>
> actually, now that you mention it -- .translate() already takes a dict, so
> if yo
On Mon, Oct 24, 2016 at 1:30 PM, Mikhail V wrote:
> But how would you with current translate function drop all characters
> that are not in the table?
that is another question altogether, and one for a different list, actually.
I don't know a way to do "remove every character except these", bu
On 24 October 2016 at 21:54, Chris Barker wrote:
> I don't know a way to do "remove every character except these", but someone
> I expect there is a way to do that efficiently with Python strings.
It's easy enough with the re module:
>>> re.sub('[^0-9]', '', 'ab0c2m3g5')
'0235'
Possibly because
On 24 October 2016 at 22:54, Chris Barker wrote:
> On Mon, Oct 24, 2016 at 1:30 PM, Mikhail V wrote:
>>
>> But how would you with current translate function drop all characters
>> that are not in the table?
>
>
> that is another question altogether, and one for a different list, actually.
>
> I d
On Tue, Oct 25, 2016 at 4:48 AM, Chris Barker wrote:
> On Mon, Oct 24, 2016 at 8:21 AM, Michel Desmoulin
> wrote:
>>
>> This actually could be implemented directly in str.replace() without
>> breaking the API by accepting:
>>
>> "stuff".replace('a', '')
>> "stuff".replace(('a', 'b', 'c'), '')
>>
I personally find it kind of annoying when you have code like this:
x = A(1, B(2, 3))
and Python's error message looks like this:
TypeError: __init__() takes 1 positional argument but 2 were given
It doesn't give much of a clue to which `__init__` is being called. At all.
The idea: when sh
On Mon, Oct 24, 2016 at 5:56 PM, Chris Angelico wrote:
> On Tue, Oct 25, 2016 at 4:48 AM, Chris Barker
> wrote:
> > On Mon, Oct 24, 2016 at 8:21 AM, Michel Desmoulin
> > wrote:
> >>
> >> This actually could be implemented directly in str.replace() without
> >> breaking the API by accepting:
> >
On 24 October 2016 at 23:10, Paul Moore wrote:
> On 24 October 2016 at 21:54, Chris Barker wrote:
>> I don't know a way to do "remove every character except these", but someone
>> I expect there is a way to do that efficiently with Python strings.
>
> It's easy enough with the re module:
>
r
There was a discussion about this a while ago. From what
I remember, the conclusion reached was that there are too
many degrees of freedom to be able to express reduction
operations in a comprehension-like way that's any clearer
than just using reduce() or writing out the appropriate
loops.
--
Gr
On Tue, Oct 25, 2016 at 9:11 AM, Nathan Schneider wrote:
> What would be the expected behavior of "aabbccdd".replace(('a', 'aa'), ('x',
> 'y'))? It's not obvious to me whether longer replacement strings ('aa') or
> earlier replacement strings ('a') should take priority.
I'm actually not sure, so
>>
> re.sub('[^0-9]', '', 'ab0c2m3g5')
>> '0235'
>>
>> Possibly because there's a lot of good Python builtins that allow you
>> to avoid the re module when *not* needed, it's easy to forget it in
>> the cases where it does pretty much exactly what you want,
There is a LOT of overhead to figuri
> Just a pair of usage cases which I was facing in my practice:
> So I just define a table like:
> {
> 1072: 97
> 1073: 98
> 1074: 99
> ...
> [which localizes Cyrillic into ASCII]
> ...
> 97:97
> 98:98
> 99:99
> ...
> [those chars that are OK, leave them]
> }
>
> Then I use os.walk() and os.rename
> On Oct 24, 2016, at 3:54 PM, Chris Angelico wrote:
> . But in any case,
> this is a question you can't even ask until replace() accepts multiple
> arguments. Hence I'm +1 on the notion of simultaneous replacements
> being supported.
Agreed -- there are a lot of edge cases to work out, and ther
Chris Barker writes:
> I think the "better error message" option is the way to go,
> however. At least until we all have better Unicode support in all
> our tools
I don't think "better Unicode support" helps with confusables in
programming languages that value TOOWTDI. OK, we already have
Chris Barker wrote:
> Nick Coghlan wrote:
>> 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?
I'm with Chris, I think: this seems in
Nick Coghlan writes:
> P.S. Given the existence of the constraints discussed above, folks may
> then be curious as to why we have a brainstorming list at all, given
> that the default answer is almost always going to be "No",
Besides providing a place that encourages discussion of ideas from o
Danilo J. S. Bellini writes:
> >>> [prev * k for k in [5, 2, 4, 3] from prev = 1]
> [1, 5, 10, 40, 120]
> Among the examples I wrote on PyScanPrev, there are use cases on:
> - maths
> - physics
> - economics
As a practicing economist, I wonder what use cases you're referring
to. I can't t
On Mon, Oct 24, 2016 at 07:39:16PM +0200, Mikhail V wrote:
> Hello all,
>
> I would be happy to see a somewhat more general and user friendly
> version of string.translate function.
> It could work this way:
> string.newtranslate(file_with_table, Drop=True, Dec=True)
That's an interesting concept
30 matches
Mail list logo