Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

[Michel Desmoulin]

+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 care of.


And remember that even when we do have something missing that we use 
often, it's not always enough to convince Guido to change the language 
for it.


E.G, we have an old and recurrent debate about adding a keyword to 
assign a temporary calculation in comprehension list so that:


[x[0].upper() for x in stuff() if x[0].upper()]

can become:


[x[0].upper() as word for x in stuff() if word]

(and many other variants)

All went to a dead end. So if you want to add the accumulate feature to 
the syntax, you better  have a VERY GOOD reason.



Le 23/10/2016 à 17:59, Steven D'Aprano a écrit :

On Sun, Oct 23, 2016 at 12:57:10PM -0200, Danilo J. S. Bellini wrote:

The idea is to let generator expressions and list/set comprehensions have a
clean syntax to access its last output. That would allow them to be an
alternative syntax to the scan higher-order function [1] (today implemented
in the itertools.accumulate function), which leads to an alternative way to
write a fold/reduce. It would be nice to have something like:


[cut suggested syntax]


instead of a reduce:


[cut four existing ways to solve the problem]

Why do we need a FIFTH way to solve this problem? What you are
describing is *exactly* the use case for a reduce or fold function. Why
add special magic syntax to make comprehensions do even more?

Not everything needs to be a one liner. It's okay to import reduce to do
a reduce. Its okay to write an actual for-loop.


Actually, I already wrote a solution for something similar to that:
PyScanPrev [2].


Ah, that makes SIX existing solutions. Do we need a seventh?




___
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] Easily remove characters from a string.

[Michel Desmoulin]

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 reasoning is that while it is currently possible to easily strip()
preceding and trailing characters, and even replace() individual
characters from a string, to replace more than one characters from
anywhere within the string requires (i believe) at its simplest a
command like this :

some_string.translate(str.maketrans('','','0123456789'))

In Python 2.* however we could say ...

some_string.translate(None, '0123456789')

My proposal is that if strip() and replace() are important enough to
receive modules, then the arguably more common operation (in terms of
programming tutorials, if not mainstream development) of just removing
all instances of specified numbers, punctuation, or even letters etc
from a list of characters should also.

I wholeheartedly admit that there are MANY other ways to do this
(including RegEx and List Comprehensions), as listed in the
StackOverflow answer below.   However the same could be said for
replace() and strip().


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'), ('?', '*', ''))

A pure Python implementation looks like this:

https://github.com/Tygs/ww/blob/dev/src/ww/wrappers/strings.py#L229

(this implementation also allow regexes, which is not what you want for 
the builtin replace(), however, as it would break the performances 
expectations)


I often had the use case of needing to strip many strings so I would +1 
for having a nice and easy way to do 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] Smart/Curly Quote Marks and cPython

[Michel Desmoulin]

+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 difficult to notice that your quotes are curved if you don't
know that's what you're looking for.

-Ryan Birmingham

On 22 October 2016 at 03:16, Steven D'Aprano mailto:st...@pearwood.info>> wrote:

On Sat, Oct 22, 2016 at 06:13:35AM +, Jonathan Goble wrote:
> Interesting idea. +1 from me; probably can be as simple as just having the
> tokenizer interpret curly quotes as the ASCII (straight) version of itself
> (in other words, " and the two curly versions of that would all produce 
the
> same token, and same for single quotes, eliminating any need for 
additional
> changes further down the chain).

There's a lot more than two. At least nineteen (including the ASCII
ones): 〝〞〟＂＇"'«»‘’‚‛“”„‟‹›


> This would help with copying and pasting
> code snippets from a source that may have auto-formatted the quotes 
without
> the original author realizing it.

Personally, I think that we should not encourage programmers to take a
lazy, slap-dash attitude to coding. Precision is important to
programmers, and there is no limit to how imprecise users can be. Should
we also guard against people accidentally using prime marks or ornaments
(dingbats):

′″‴‵‶‷ ❛❜❝❞❮❯

as well? If not, what makes them different from other accidents of
careless programmers?

I don't think we should be trying to guess what programmers mean, nor do
I think that we should be encouraging programmers to use word processors
for coding. Use the right tool for the right job, and even Notepad is
better for the occasional programmer than Microsoft Office or
LibreOffice. Programming is hard, requiring precision and care, and we
don't do beginners any favours by making it easy for them to be
imprecise and careless.

I would be happy to see improved error messages for smart quotes:

py> s = ‘abcd’
  File "", line 1
s = ‘abcd’
 ^
SyntaxError: invalid character in identifier

(especially in IDLE), but I'm very dubious about the idea of using
typographical quote marks for strings. At the very least, Python should
not lead the way here. Let some other language experiment with this
first, and see what happens. Python is a mature, established language,
not an experimental language.

Of course, there's nothing wrong with doing an experimental branch of
Python supporting this feature, to see what happens. But that doesn't
mean we should impose it as an official language rule.



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





___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


___
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

[Chris Barker]

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 like this
up on one of these lists not too long ago -- "scripting" use cases really
are different that "systems programming"

However, that script/library distinction isn't well-defined in
> computing instruction in general,


no it's not -- except in the case of "scripting languages" vs. "systems
languages" -- you can go back to the classic  Ousterhout paper:

https://www.tcl.tk/doc/scripting.html

But Python really is suitable for both use cases, so tricky to know how to
teach.

And my classes, at least, have folks with a broad range of use-cases in
mind, so I can't choose one way or another. And, indeed, there is no small
amount of code (and coder) that starts out as a quicky script, but ends up
embedded in a larger system down the road.

And (another and?) one of the great things ABOUT Python is that is IS
suitable for such a broad range of use-cases.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(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/

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

[Mikhail V]

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][Out]

97{65}
98{66}
99{67}
100{}
...
110{110}


Notes:
All values are decimal or hex (to switch between parsing format use
Dec parameter)
As it turned out from my last discussion, majority prefers hex notation,
so I am not in mainstream with my decimal notation here, but both
should be supported.
Empty [Out] value {} means that the character will be deleted.

2. "Drop = True" this will set the default behavior for those values
which are NOT in the table.

For Drop = True: all values not defined in table set to [out] = {},
and be deleted.

For Drop=False: all values not defined in table set [out] = [in], so
those remain as is.

3. Dec= True : parsing format Decimal/hex. I use decimal everywhere.


Further thoughts: for 8-bit strings this should be simple to implement
I think. For 16-bit of course
there is issue of memory usage for lookup tables, but the gurus could
probably optimise it.
E.g. at the parsing stage it is not necessary to build the lookup
table  for whole 16-bit range of course,
but take only values till the largest ordinal present in the table file.

About the format of table file: I suppose many users would want also
to define characters directly, I am not sure
if it is really needed, but if so, additional brackets or escape char
could be used, like this for example:

a{A}
\98{\66}
\99{\67}

but as said I don't like very much the idea and would be OK for me to
use numeric values only.

So approximately I see it.
Feel free to share thoughts or criticise.


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] Smart/Curly Quote Marks and cPython

[Chris Barker]

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 -- I once id a whole set of python class slides in LaTeX -- really
nice format, etc

but in teh process from LaTeX to PDF, I ended up with stuff that looked
like Code, but if you copy and pasted it the quotes were wrong -- but only
sometimes -- I got pretty used to fixing it, but still was symied once in a
while,a nd it was pretty painful for my students...

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

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(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]

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 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][Out]
>
> 97{65}
> 98{66}
> 99{67}
> 100{}
> ...
> 110{110}
>
>
> Notes:
> All values are decimal or hex (to switch between parsing format use
> Dec parameter)
> As it turned out from my last discussion, majority prefers hex notation,
> so I am not in mainstream with my decimal notation here, but both
> should be supported.
> Empty [Out] value {} means that the character will be deleted.
>
> 2. "Drop = True" this will set the default behavior for those values
> which are NOT in the table.
>
> For Drop = True: all values not defined in table set to [out] = {},
> and be deleted.
>
> For Drop=False: all values not defined in table set [out] = [in], so
> those remain as is.
>
> 3. Dec= True : parsing format Decimal/hex. I use decimal everywhere.
>
>
> Further thoughts: for 8-bit strings this should be simple to implement
> I think. For 16-bit of course
> there is issue of memory usage for lookup tables, but the gurus could
> probably optimise it.
> E.g. at the parsing stage it is not necessary to build the lookup
> table  for whole 16-bit range of course,
> but take only values till the largest ordinal present in the table file.
>
> About the format of table file: I suppose many users would want also
> to define characters directly, I am not sure
> if it is really needed, but if so, additional brackets or escape char
> could be used, like this for example:
>
> a{A}
> \98{\66}
> \99{\67}
>
> but as said I don't like very much the idea and would be OK for me to
> use numeric values only.
>
> So approximately I see it.
> Feel free to share thoughts or criticise.
>
>
> 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/
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(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] Deterministic iterator cleanup

[Chris Barker]

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 is likely mitigated in practice *today* by IPython users mostly
> being on CPython for access to the Scientific Python stack,


sure -- though there is no reason that Jupyter notebooks aren't really
useful to all sort of non-data-crunching tasks. It's just that that's the
community it was born in.

I can imagine they would be great for database exploration/management, for
instance.

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?


At first thought, talking about this seems like it would just confuse
newbies even MORE. Most of my students really want simple examples they can
copy and then change for their specific use case.

But I do have some pretty experienced developers (new to Python, but not
programming) in my classes, too, that I might be able to bring this up with.

 # Cleaned up whenever the interpreter gets around to cleaning up

> the function locals
> def readlines_with_default_resource_management(fname):
> return open(fname).readlines()
>
> # Cleaned up on function exit, even if the locals are still
> referenced from an exception traceback
> # or the interpreter implementation doesn't use a reference counting GC
> from local_resources import function_resource
>
> def readlines_with_declarative_cleanup(fname):
>return function_resource(open(fname)).readlines()
>
> # Cleaned up at the end of the with statement
> def readlines_with_imperative_cleanup(fname):
> with open(fname) as f:
> return f.readlines()
>
> The idea here is to change the requirement for new developers from
> "telling the interpreter what to *do*" (which is the situation we have
> for context managers) to "telling the interpreter what we *want*"
> (which is for it to link a managed resource with the lifecycle of the
> currently running function call, regardless of interpreter
> implementation details)
>

I can see that, but I'm not sure newbies will -- it either case, you have
to think about what you want -- which is the complexity I'm trying to avoid
at this stage. Until much later, when I get into weak references, I can
pretty much tell people that python will take care of itself with regards
to resource management.

That's what context mangers are for, in fact. YOU can use:

with open(...) as infile:
.

Without needing to know what actually has to be "cleaned up" about a file.
In the case of files, it's a close() call, simple enough (in the absence of
Exceptions...), but with a database connection or something, it could be a
lot more complex, and it's nice to know that it will simply be taken care
of for you by the context manager.

The big refactoring benefit that this feature would offer over with
> statements is that it doesn't require a structural change to the code
> - it's just wrapping an existing expression in a new function call
> that says "clean this up promptly when the function terminates, even
> if it's still part of a reference cycle, or we're not using a
> reference counting GC".


hmm -- that would be simpler in one sense, but wouldn't it require a new
function to be defined for everything you might want to do this with?
rather than the same "with" syntax for everything?

-CHB




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(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] Easily remove characters from a string.

[Chris Barker]

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 found I Need to do this often enough that I've wondered why
it's not there.

making three calls to replace() isn't too bad, but is klunky and has
performance issues.

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(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()

[Ryan Birmingham]

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 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 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][Out]
>>
>> 97{65}
>> 98{66}
>> 99{67}
>> 100{}
>> ...
>> 110{110}
>>
>>
>> Notes:
>> All values are decimal or hex (to switch between parsing format use
>> Dec parameter)
>> As it turned out from my last discussion, majority prefers hex notation,
>> so I am not in mainstream with my decimal notation here, but both
>> should be supported.
>> Empty [Out] value {} means that the character will be deleted.
>>
>> 2. "Drop = True" this will set the default behavior for those values
>> which are NOT in the table.
>>
>> For Drop = True: all values not defined in table set to [out] = {},
>> and be deleted.
>>
>> For Drop=False: all values not defined in table set [out] = [in], so
>> those remain as is.
>>
>> 3. Dec= True : parsing format Decimal/hex. I use decimal everywhere.
>>
>>
>> Further thoughts: for 8-bit strings this should be simple to implement
>> I think. For 16-bit of course
>> there is issue of memory usage for lookup tables, but the gurus could
>> probably optimise it.
>> E.g. at the parsing stage it is not necessary to build the lookup
>> table  for whole 16-bit range of course,
>> but take only values till the largest ordinal present in the table file.
>>
>> About the format of table file: I suppose many users would want also
>> to define characters directly, I am not sure
>> if it is really needed, but if so, additional brackets or escape char
>> could be used, like this for example:
>>
>> a{A}
>> \98{\66}
>> \99{\67}
>>
>> but as said I don't like very much the idea and would be OK for me to
>> use numeric values only.
>>
>> So approximately I see it.
>> Feel free to share thoughts or criticise.
>>
>>
>> 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/
>>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(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/
>
___
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 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 use a
dict literal to do it:

# contents of file:

>
{
32: 95,

> 105: 64,
115: 36,
}

then use it:

s.translate(ast.literal_eval(open("trans_table.txt").read()))
now all you need is a tiny little utility function:

def translate_from_file(s, filename):
return s.translate(ast.literal_eval(open(filename).read()))


:-)

-Chris


>
>
>
> 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 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 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][Out]
>>>
>>> 97{65}
>>> 98{66}
>>> 99{67}
>>> 100{}
>>> ...
>>> 110{110}
>>>
>>>
>>> Notes:
>>> All values are decimal or hex (to switch between parsing format use
>>> Dec parameter)
>>> As it turned out from my last discussion, majority prefers hex notation,
>>> so I am not in mainstream with my decimal notation here, but both
>>> should be supported.
>>> Empty [Out] value {} means that the character will be deleted.
>>>
>>> 2. "Drop = True" this will set the default behavior for those values
>>> which are NOT in the table.
>>>
>>> For Drop = True: all values not defined in table set to [out] = {},
>>> and be deleted.
>>>
>>> For Drop=False: all values not defined in table set [out] = [in], so
>>> those remain as is.
>>>
>>> 3. Dec= True : parsing format Decimal/hex. I use decimal everywhere.
>>>
>>>
>>> Further thoughts: for 8-bit strings this should be simple to implement
>>> I think. For 16-bit of course
>>> there is issue of memory usage for lookup tables, but the gurus could
>>> probably optimise it.
>>> E.g. at the parsing stage it is not necessary to build the lookup
>>> table  for whole 16-bit range of course,
>>> but take only values till the largest ordinal present in the table file.
>>>
>>> About the format of table file: I suppose many users would want also
>>> to define characters directly, I am not sure
>>> if it is really needed, but if so, additional brackets or escape char
>>> could be used, like this for example:
>>>
>>> a{A}
>>> \98{\66}
>>> \99{\67}
>>>
>>> but as said I don't like very much the idea and would be OK for me to
>>> use numeric values only.
>>>
>>> So approximately I see it.
>>> Feel free to share thoughts or criticise.
>>>
>>>
>>> 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/
>>>
>>
>>
>>
>> --
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR&R(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/
>>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(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()

[Paul Moore]

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 could *easily*
be published on PyPI, and then if it gained enough users be proposed
for the stdlib. I don't think there's anything like sufficient value
to warrant "fast-tracking" something like this direct to the stdlib.
And real-world use via PyPI would very quickly establish whether the
unusual "pass a file with a translation table in it" design was
acceptable to users.

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

[Mikhail V]

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 youw ant to put your translation table in a text file, you can use a dict
> literal to do it:
>
> # contents of file:
>
>
> {
> 32: 95,
>
> 105: 64,
> 115: 36,
> }
>
> then use it:
>
> s.translate(ast.literal_eval(open("trans_table.txt").read()))
>
> now all you need is a tiny little utility function:
>
> def translate_from_file(s, filename):
> return s.translate(ast.literal_eval(open(filename).read()))
>
>
> :-)
>
> -Chris
>

Yes making special file format is not a good option I agree.
Also of course it does not have sence to read it everytime if translate
is called in a loop with the same table. So it was merely a sketch of
behaviour.

But how would you with current translate function drop all characters
that are not in the table? so I can pass [deletechars] to the function but
this seems not very convenient to me -- very often I want to
drop them *all*, excluding some particular values.  This for example
is needed for filtering out all non-standard characters from paths, etc.
So in other words, there should be an option to control this behavior.
Probably I am missing something here, but I didn't find such solution
for translate() and that is main point of proposal actually.
It is all the same as translate() but with this extension it can cover
much more usage cases.


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

[Chris Barker]

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", but someone
I expect there is a way to do that efficiently with Python strings.

you could probably (ab)use the codecs module, though.

If there really is no way to do it, then you might have feature worth
pursuing, but be prepared with use-cases!

The only use-case I've had for that sort of this is when I want only ASCII
-- but I can uses the ascii codec for that :-)

This for example
> is needed for filtering out all non-standard characters from paths, etc.
>

You'd usually want to replace those with something, rather than remove them
entirely, yes?

-CHB



> So in other words, there should be an option to control this behavior.
> Probably I am missing something here, but I didn't find such solution
> for translate() and that is main point of proposal actually.
> It is all the same as translate() but with this extension it can cover
> much more usage cases.
>
>
> Mikhail
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(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()

[Paul Moore]

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 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, or can be
persuaded to do so with much less difficulty than rolling your own
solution (I know I'm guilty of that...).

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

[Mikhail V]

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 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.
>
> you could probably (ab)use the codecs module, though.
>
> If there really is no way to do it, then you might have feature worth
> pursuing, but be prepared with use-cases!
>
> The only use-case I've had for that sort of this is when I want only ASCII
> -- but I can uses the ascii codec for that :-)
>
>> This for example
>> is needed for filtering out all non-standard characters from paths, etc.
>
>
> You'd usually want to replace those with something, rather than remove them
> entirely, yes?

Just a pair of usage cases which I was facing in my practice:
1. Imagine I perform some admin tasks in a company with very different users
who also tend to name the files as they wish. So only God knows what can
be there in filenames. And I know foe example that there can be Cyrillic besides
ASCII their. 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() and voila! the file system
regains it virginity
in one simple script.

2. Say I have a multi-lingual file or whatever, I want to filter out
some unwanted
characters so I can do it similarly.


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] Easily remove characters from a string.

[Chris Angelico]

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'), '')
>> "stuff".replace(('a', 'b', 'c'), ('?', '*', ''))
>
>
> +1 -- I have found I Need to do this often enough that I've wondered why
> it's not there.
>
> making three calls to replace() isn't too bad, but is klunky and has
> performance issues.

And it may not be semantically identical. In the examples above, three
separate replace calls would work, but a syntax like this ought to be
capable of an exchange - "aabbccdd".replace(('b', 'd'), ('d', 'b')) ==
"aaddccbb".

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/

[Python-ideas] Showing qualified names when a function call fails

[Ryan Gonzalez]

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 showing the function name in an error like this, show the
fully qualified name, like:


TypeError: A.__init__() takes 1 positional argument but 2 were given


This would be MUCH more helpful!


Another related change would be to do the same thing in tracebacks:


Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in __init__
AssertionError


to:


Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in MyClass.__init__
AssertionError


which could make it easier to find where exactly an error originated.

-- 
Ryan (ライアン)
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
___
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] Easily remove characters from a string.

[Nathan Schneider]

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:
> >>
> >> "stuff".replace('a', '')
> >> "stuff".replace(('a', 'b', 'c'), '')
> >> "stuff".replace(('a', 'b', 'c'), ('?', '*', ''))
> >
> >
> > +1 -- I have found I Need to do this often enough that I've wondered why
> > it's not there.
> >
> > making three calls to replace() isn't too bad, but is klunky and has
> > performance issues.
>
> And it may not be semantically identical. In the examples above, three
> separate replace calls would work, but a syntax like this ought to be
> capable of an exchange - "aabbccdd".replace(('b', 'd'), ('d', 'b')) ==
> "aaddccbb".
>

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.

Or is the proposal to only support this for replacements of single
characters?

Nathan


>
> 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/
>
___
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 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:
>
 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, or can be
> persuaded to do so with much less difficulty than rolling your own
> solution (I know I'm guilty of that...).
>
> Paul

Thanks, this would solve the task of course.
However for example in the case in my last example (filenames)
this would require:

- Write a function to construct the expression for "all except given"
characters from my table. This could be easy I believe, but still another task.

Then:
1. Apply translate() with my table to the string.
2. Apply re.sub() to the string.

I usually start using RE when I want to find/replace words or patterns,
but not translate/filter the characters directly. So since there is
already an "inclusive"
translate() then probably having an "exclusive" one is not a bad idea.
I believe it is something very similar in implementation, so instead
of appending next character which is not in the table, it simply does nothing.

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] Reduce/fold and scan with generator expressions and comprehensions

[Greg Ewing]

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.

--
Greg

___
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] Easily remove characters from a string.

[Chris Angelico]

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 I would look at prior art. 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.

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 - NOAA Federal]

>>
> 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 figuring out how to use the re module.
I've always though t it had it's place, but it sure seems like
overkill for something this seemingly simple.

If (a big if) removing "all but these" was a common use case, it would
be nice to have a way to do it with string methods.

This is a classic case of:

Put it on PyPi, and see how much interest it garners.

-CHB
___
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 - NOAA Federal]

> 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() and voila! the file system
> regains it virginity
> in one simple script.

This sounds like a perfect use case for str.translate() as it is.

> 2. Say I have a multi-lingual file or whatever, I want to filter out
> some unwanted
> characters so I can do it similarly.

Filtering out is different-- but I would think that you would want
replace, rather than remove.

If you wanted names to all comply with a given encoding (ascii or
Latin-1, or...), then encoding/decoding (with error set to replace)
would do nicely.

-CHB


>
>
> 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] Easily remove characters from a string.

[Chris Barker - NOAA Federal]

> 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 there is not
one way to define the API, but if folks think it's a good idea, we can
hash those out.

If anyone decides to take this on, be prepared for a lot of bike shedding!

-CHB


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

[Stephen J. Turnbull]

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 4 kinds
of quoting in Python which suggests that TOOWTDI doesn't apply to
quoting, but I think that's a bit naive.  Given the frequency with
which quotes appear in strings, and the fact that English quotation
marks can't nest but rarely need to nest more than once, use of both
"" and '' with identical semantics to make one level of nesting
convenient and readable was plausible.  The use of triple quotes for
block quoting again has arguments for it.  You can think that these
were experiments with "meh" results[1], but I don't think it's
appropriate to say that therefore TOOWTDI doesn't apply to quote
marks.

As a general rule, I think use of confusables in new syntax (eg,
double curly quotes = f"") runs into "Syntax shall not look like grit
on Tim's screen".  OTOH, better Unicode support should (cautiously)
be used to support new operators and syntax subject to TOOWDTI and
other considerations of Pythonicity.

Footnotes: 
[1]  Personally, I immediately liked the triple quotes, because the
(Emacs) Lisp convention of allowing literal newline characters in all
strings caused a number of small annoyances.  I also quickly evolved a
personal convention where single quotes indicate "string as protocol
constant" (eg, where today we'd use enums), while double quotes
indicate "arbitrary text content".  But those are both obviously YMMV
evaluations.


___
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

[Stephen J. Turnbull]

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 inappropriate to me.  A student
has to be rather sophisticated to understand resource management at
all in Python.  Eg, generators and closures can hang on to resources
between calls, yet there's no syntactic marker at the call site.

 >> The idea here is to change the requirement for new developers from
 >> "telling the interpreter what to *do*" (which is the situation we have
 >> for context managers) to "telling the interpreter what we *want*"
 >> (which is for it to link a managed resource with the lifecycle of the
 >> currently running function call, regardless of interpreter
 >> implementation details)

I think this attempt at a distinction is spurious.  On the syntactic
side,

with open("file") as f:
results = read_and_process_lines(f)

the with statement effectively links management of the file resource
to the lifecycle of read_and_process_lines.  (Yes, I know what you
mean by "link" -- will "new developers"?)  On the semantic side,
constructs like closures and generators (which they may be cargo-
culting!) mean that it's harder to link resource management to
(syntactic) function calls than a new developer might think.  (Isn't
that Nathaniel's motivation for the OP?)  And then there's the loop
that may not fully consume an iterator problem: that must be
explicitly decided -- the question for language designers is which of
"close generators on loop exit" or "leave generators open on loop
exit" should be marked with explicit syntax -- and what if you've got
two generators involved, and want different decisions for both?

Chris:

 > I can see that, but I'm not sure newbies will -- it either case,
 > you have to think about what you want -- which is the complexity
 > I'm trying to avoid at this stage.

Indeed.

 > Until much later, when I get into weak references, I can pretty
 > much tell people that python will take care of itself with regards
 > to resource management.

I hope you phrase that very carefully.  Python takes care of itself,
but does not take care of the use case.  That's the programmer's
responsibility.  In a very large number of use cases, including the
novice developer's role in a large project, that is a distinction that
makes no difference.  But the "close generators on loop exit" (or
maybe not!) use case makes it clear that in general the developer must
explicitly manage resources.

 > That's what context mangers are for, in fact. YOU can use:
 > 
 > with open(...) as infile:
 > .
 > 
 > Without needing to know what actually has to be "cleaned up" about
 > a file.  In the case of files, it's a close() call, simple enough
 > (in the absence of Exceptions...), but with a database connection
 > or something, it could be a lot more complex, and it's nice to know
 > that it will simply be taken care of for you by the context
 > manager.

But somebody has to write that context manager.  I suppose in the
organizational context imagined here, it was written for the project
by the resource management wonk in the group, and the new developer
just cargo-cults it at first.

 > > The big refactoring benefit that this feature would offer over
 > > with statements is that it doesn't require a structural change to
 > > the code - it's just wrapping an existing expression in a new
 > > function call that says "clean this up promptly when the function
 > > terminates, even if it's still part of a reference cycle, or
 > > we're not using a reference counting GC".
 > 
 > hmm -- that would be simpler in one sense, but wouldn't it require
 > a new function to be defined for everything you might want to do
 > this with?  rather than the same "with" syntax for everything?

Even if it can be done with a single "ensure_cleanup" function, Python
isn't Haskell.  I think context management deserves syntax to mark it.

After all, from the "open and read one file" scripting standpoint,
there's really not a difference between

f = open("file")
process(f)

and

with open("file") as f:
process(f)

(see "taking care of Python ~= taking care of use case" above).  But
the with statement and indentation clearly mark the call to process as
receiving special treatment.  As Chris says, the developer doesn't
need to know anything but that the object returned by the with
expression participates "appropriately" in the context manager
protocol (which she may think of as the "with protocol"!, ie, *magic*)
and gets the "special treatment" it needs.

So (for me) this is full circle: "with" context management is what we
need, but it interacts poorly with stateful "function" calls -- and
that's what Nathaniel proposes to deal with.

___
Python-ideas mailin

Re: [Python-ideas] Civility on this mailing list

[Stephen J. Turnbull]

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 out
of the blue that just might be evolutionary steps forward, it also
provides a place where language design principles can be discussed and
illustrated in the context of concrete proposals, and an archive of
those discussions.

I realize that it's a significant amount of effort to find the
discussions where principles are enunciated and elaborated, and don't
have a good solution to propose to those who prefer not to spend the
effort.  But the resource is there.

___
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] Reduce/fold and scan with generator expressions and comprehensions

[Stephen J. Turnbull]

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 think of any use cases where if one previous value is
useful, having all previous values available (ie, an arbitrary
temporal structure, at the modeler's option) isn't vastly more useful.

This means that in modern econometrics, for example, simple procedures
like Cochrane-Orcutt (which handles one previous value of the
dependent variable in a single-equation regression) are subsumed in
ARIMA and VAR estimation, which generalize the number of equations
and/or the number of lags to greater than one.  BTW, numerical
accuracy considerations often mean you don't want to use the compact
"for ... in ... if ..." expression syntax anyway, as accuracy can
often be greatly improved with appropriate reordering of values in the
series.

Even "online" regression algorithms, where you might think to write

( updated_model(datum, prev)
  for datum in sensor_data()
  from prev = something )

'prev' need to refer not to the previous value of 'datum', but to the
previous value of 'updated_model()' (since you need a sufficient
statistic for all previous data).  And 'prev' as currently conceived
is just plain useless for any long period moving average, etc.

So in the end, even if there are plausible use cases for quick and
dirty code, an experienced implementer wouldn't use them anyway as
more powerful tools are likely to be immediately to hand.
___
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 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 for "user friendly". Apart from functions 
that are actually designed to read files of a particular format, can 
you think of any built-in functions that take a file as argument?

This is how you would use this "user friendly version of translate":

path = '/tmp/table'  # hope no other program is using it...
with open(path, 'w') as f:
f.write('97{65}\n')
f.write('98{66}\n')
f.write('99{67}\n')

with open(path, 'r') as f:
new_string = old_string.newtranslate(f, False, True)


Compared to the existing solution:

new_string = old_string.translate(str.maketrans('abc', 'ABC'))


Mikhail, I appreciate that you have many ideas and want to share them, 
but try to think about how those ideas would work. The Python standard 
library is full of really well-designed programming interfaces. You can 
learn a lot by thinking "what existing function is this like? how does 
that existing function work?".

str.translate and str.maketrans already exist. Look at how maketrans 
builds a translation table: it can take either two equal length strings, 
and maps characters in one to the equivalent character in the other:

str.maketrans('abc', 'ABC')

Or it can take a mapping (usually a dict) that maps either characters or 
ordinal numbers to a new string (not just a single character, but an 
arbitrary string) or ordinal numbers. 

str.maketrans({'a': 'A', 98: 66, 0x63: 0x:43})

(or None, to delete them). Note the flexibility: you don't need to 
specify ahead of time whether you are specifying the ordinal 
value as a decimal, hex, octal or binary value. Any expression that 
evaluates to a string or a int within the legal range is valid.

That's a good programming interface.

Could it be better? Perhaps. I've suggested that maybe translate could 
automatically call maketrans if given more than one argument. Maybe 
there's an easier way to just delete unwanted characters. Perhaps there 
could be a way to say "any character not in the translation table should 
be dropped". These are interesting questions.


> Further thoughts: for 8-bit strings this should be simple to implement
> I think.

I doubt that these new features will be added to bytes as well as 
strings. For 8-bits byte strings, it is easy enough to generate your own 
translation and deletion tables -- there are only 256 values to 
consider.


> For 16-bit of course
> there is issue of memory usage for lookup tables, but the gurus could
> probably optimise it.

There are no 16-bit strings.

Unicode is a 21-bit encoding, usually encoded as either fixed-width 
sequence of 4-byte code units (UTF-32) or a variable-width sequence of 
2-byte (UTF-16) or 1-byte (UTF-8) code units. But it absolutely is not a 
"16-bit string".


[...]
> but as said I don't like very much the idea and would be OK for me to
> use numeric values only.

I think you are very possibly the only Python programmer in the world 
who thinks that writing decimal ordinal values is more user-friendly 
than writing the actual character itself. I know I would much rather 
see $, π or ╔ than 36, 960 or 9556.



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