Re: read Unicode characters one by one in python2
On 24 February 2018 at 17:17, Peng Yu wrote:
> Here shows some code for reading Unicode characters one by one in
> python2. Is it the best code for reading Unicode characters one by one
> in python2?
>
> https://rosettacode.org/wiki/Read_a_file_character_by_character/UTF8#Python
No, it’s terrible. So is the Python 3 version. All you need for both
Pythons is this:
import io
with io.open('input.txt', 'r', encoding='utf-8') as fh:
for character in fh:
print(character)
(and please make sure you need to read character-by-character first)
--
Chris Warrick
Re: read Unicode characters one by one in python2
On Mon, Feb 26, 2018 at 12:33 AM, Chris Warrick wrote:
> On 24 February 2018 at 17:17, Peng Yu wrote:
>> Here shows some code for reading Unicode characters one by one in
>> python2. Is it the best code for reading Unicode characters one by one
>> in python2?
>>
>> https://rosettacode.org/wiki/Read_a_file_character_by_character/UTF8#Python
>
> No, it’s terrible. So is the Python 3 version. All you need for both
> Pythons is this:
>
> import io
> with io.open('input.txt', 'r', encoding='utf-8') as fh:
> for character in fh:
> print(character)
If you actually need character-by-character, you'd need "for character
in fh.read()" rather than iterating over the file itself. Iterating
over a file yields lines.
(BTW, if you know for sure that you're running in Python 3, "io.open"
can be shorthanded to just "open". They're the same thing in Py3.)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: read Unicode characters one by one in python2
On Mon, 26 Feb 2018 01:50:16 +1100, Chris Angelico wrote: > If you actually need character-by-character, you'd need "for character > in fh.read()" rather than iterating over the file itself. Iterating over > a file yields lines. Indeed. But I wonder if there's a performance cost/gain to iterating over each line, rather than reading one char at a time? for line in file: for c in line: ... Too lazy to actually test it myself, but just tossing this idea out in case anyone else cares to give it a try. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
matrix multiplication
Hello, The following is an example of an Nx3 matrix (`uvw`) representing N vectors that need to be multiplied by a 3x3 matrix (generated by `randint_mat` function) and store the result in `uvw_rots`: ------ import numpy as np def randint_mat(x): return np.random.randint(x, size=(3, 3)) np.random.seed(123) uvw = np.random.randn(1000, 3) maxint = np.random.randint(1, 10, size=uvw.shape[0]) uvw_rots = np.empty_like(uvw) for i, v in enumerate(maxint): mati = randint_mat(v) uvw_roti = np.dot(uvw[i], mati) uvw_rots[i] = uvw_roti --- --- Is there a better (faster) approach than looping through the rows of uvw as shown? Thanks, -- Seb -- https://mail.python.org/mailman/listinfo/python-list
For Loop Dilema [python-list]
Why we don’t use: for _ in _ in _ Instead of for _ in _: for _ in _: Ex: Names = ["Arya","Pupun"] for name in Names: for c in name: print(c) instead use: for c in name in Names: print(c) -- https://mail.python.org/mailman/listinfo/python-list
Re: read Unicode characters one by one in python2
On Mon, Feb 26, 2018 at 3:57 AM, Steven D'Aprano wrote: > On Mon, 26 Feb 2018 01:50:16 +1100, Chris Angelico wrote: > >> If you actually need character-by-character, you'd need "for character >> in fh.read()" rather than iterating over the file itself. Iterating over >> a file yields lines. > > Indeed. But I wonder if there's a performance cost/gain to iterating over > each line, rather than reading one char at a time? > > for line in file: > for c in line: > ... > > Too lazy to actually test it myself, but just tossing this idea out in > case anyone else cares to give it a try. > Depends on the size of the file. For a small file, you could read the whole thing into memory in a single disk operation, and then splitting into lines is a waste of time; but for a gigantic file, reading everything into RAM means crazy-expensive transfer/copy, so it'd be HEAPS more efficient to work line by line - particularly if you don't need the whole file. But if you indeed want to cut the process off, having nested loops means a simple "break" won't work. So that's a different consideration. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: matrix multiplication
On 2/25/2018 12:45 PM, Seb wrote: Hello, The following is an example of an Nx3 matrix (`uvw`) representing N vectors that need to be multiplied by a 3x3 matrix (generated by `randint_mat` function) and store the result in `uvw_rots`: ------ import numpy as np def randint_mat(x): return np.random.randint(x, size=(3, 3)) np.random.seed(123) uvw = np.random.randn(1000, 3) maxint = np.random.randint(1, 10, size=uvw.shape[0]) uvw_rots = np.empty_like(uvw) for i, v in enumerate(maxint): mati = randint_mat(v) uvw_roti = np.dot(uvw[i], mati) uvw_rots[i] = uvw_roti --- --- Is there a better (faster) approach than looping through the rows of uvw as shown? numpy has a matrix multiply function and now the '@' matrix multiply operator. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: For Loop Dilema [python-list]
On Sun, Feb 25, 2018 at 11:19 AM, wrote: > Why we don’t use: > > for _ in _ in _ > > Instead of > > for _ in _: > for _ in _: > > Ex: > > Names = ["Arya","Pupun"] > > for name in Names: >for c in name: >print(c) > > instead use: > > for c in name in Names: > print(c) It doesn't seem very intuitive (doesn't follow proper English phrasing, for instance) and I don't think it's a common enough situation to warrant adding a special syntax for it. But if you really want it, you could use something like this: def double_for(iterable): for outer in iterable: yield from outer for c in double_for(Names): print(c) But I don't think this is any clearer than making the loops explicit. -- https://mail.python.org/mailman/listinfo/python-list
Re: For Loop Dilema [python-list]
On Sunday, February 25, 2018 at 12:19:56 PM UTC-6, [email protected] wrote: > Ex: > > Names = ["Arya","Pupun"] > > for name in Names: >for c in name: >print(c) > > instead use: > > for c in name in Names: > print(c) Hmm. Why stop there? bit = ["kibbles"] bits = [bit, bit] bitts = [bits, bits] for kibbles in bit in bits in bitts: do_something(kibbles) -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Friday, February 23, 2018 at 10:41:45 AM UTC-6, Steven D'Aprano wrote: [...] > There are dozens of languages that have made the design > choice to limit their default integers to 16- 32- or 64-bit > fixed size, and let the user worry about overflow. Bart, > why does it upset you so that Python made a different > choice? A default "integer-diversity-and-inclusivity-doctrine" is all fine and dandy by me, (Hey, even integers need safe spaces), but i do wish we pythonistas had a method to turn off this (and other) cycle burning "features" -- you know -- in the 99.9 percent of time that we don't need them. And BTW... Am i the *ONLY* person here who feels that Python optimizations should be more than merely the tossing of dead weight overboard? -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Mon, Feb 26, 2018 at 1:33 PM, Rick Johnson wrote: > On Friday, February 23, 2018 at 10:41:45 AM UTC-6, Steven D'Aprano wrote: > [...] >> There are dozens of languages that have made the design >> choice to limit their default integers to 16- 32- or 64-bit >> fixed size, and let the user worry about overflow. Bart, >> why does it upset you so that Python made a different >> choice? > > A default "integer-diversity-and-inclusivity-doctrine" is > all fine and dandy by me, (Hey, even integers need safe spaces), In Python 3.6+, integers have safe underscores instead. > but i do wish we pythonistas had a method to turn off this > (and other) cycle burning "features" -- you know -- in the > 99.9 percent of time that we don't need them. Definitely. We should also provide a way for people to manually allocate memory, for the times when that would be more efficient. And to switch out the syntax to include braces. And all those other things people like from other languages. Hey, here's an idea: maybe Python shouldn't stop people from using other languages, if those other languages are better suited to the job? > And BTW... Am i the *ONLY* person here who feels that Python > optimizations should be more than merely the tossing of dead > weight overboard? I dunno. We optimize this mailing list that way.. *ducking for cover* ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: For Loop Dilema [python-list]
https://docs.python.org/3.6/library/itertools.html#itertools.product On Mon, Feb 26, 2018 at 3:19 AM, wrote: > Why we don’t use: > > for _ in _ in _ > > Instead of > > for _ in _: > for _ in _: > > Ex: > > Names = ["Arya","Pupun"] > > for name in Names: >for c in name: >print(c) > > instead use: > > for c in name in Names: > print(c) > -- > https://mail.python.org/mailman/listinfo/python-list -- INADA Naoki -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Friday, February 23, 2018 at 8:48:55 PM UTC-6, Steven D'Aprano wrote: [...] > Take the Fibonacci double-recursion benchmark. Okay, it > tests how well your language does at making millions of > function calls. Why? Because making "millons of function calls" is what software *DOES*! Granted, and as others have testified in this thread, i myself have almost never implemented an algorithm like that monstrosity of recursion that is implemented in fib(), but whether we use recursive functions are not, a high number of functions calls is inevitable in our software. And if you don't believe me, then use sys.setrace(myFunc) to trace all function calls to stdout, and you shall be enlightened[1]. > How often do you make millions of function calls? All the time! Of course, if the extent of your code base is a single script containing the source `print 'Hello World'`, perhaps your experience may vary from others here. > For most application code, executing the function is far > more costly than the overhead of calling it, What? Your functions are only called _once_ during the lifetime of your code execution? Enough with the leg pulling. > and the call overhead is dwarfed by the rest of the > application. Of course, because it's calling _other_ functions. > For many, many applications, the *entire* program run could > take orders of magnitude fewer function calls than a single > call to fib(38). Hmm, let's see: def main(): print 'hello world' main() By golly, he's right! O_O -- [1] But, in the meantime, you may want to make yourself a taco; go play a round of golf; and possibly pay a visit to national monument (or three!), while all that crap is printing to stdout. -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Sunday, February 25, 2018 at 8:45:56 PM UTC-6, Chris Angelico wrote: > On Mon, Feb 26, 2018 at 1:33 PM, Rick Johnson [...] > > but i do wish we pythonistas had a method to turn off this > > (and other) cycle burning "features" -- you know -- in the > > 99.9 percent of time that we don't need them. > > Definitely. We should also provide a way for people to > manually allocate memory, for the times when that would be > more efficient. And to switch out the syntax to include > braces. Now you're throwing the baby out with the bath water. We needn't re-implement the C language simply to achieve reasonable and practical code-execution efficiency. Python was never intended to be the fastest language. Heck! Python was never intented to be the fastest _scripting_ language! So of course, speed is not and should not be the primary concern, but to say that execution speed is of _no_ concern is quite absurd indeed. As Steven mentioned, few people, even of they _could_ afford the absurd price, will ever purchase that high-end sports car. However, by using this example Steve is committing the argumentation sin of comparing apples to oranges because transportation is more a matter of practicality. Sure, you may arrive at your destination more quickly in the high-end sports car, however, the trade-off will be that you could be thrown in jail for speeding or be injured or killed in an accident. But such existential risks are not the case for software... Code that execute more quickly simply (wait for it...) yes, executes more quickly! And I can assure you: no one will die, be injured, or even become "Bubba's" cell mate should their code commit the unforgivable "sin" of executing more quickly[1]. -- [1] Quick! Someone please call a priest! We need to confess!!! -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Sunday, February 25, 2018 at 8:45:56 PM UTC-6, Chris Angelico wrote: > On Mon, Feb 26, 2018 at 1:33 PM, Rick Johnson > wrote: [...] > > A default "integer-diversity-and-inclusivity-doctrine" is > > all fine and dandy by me, (Hey, even integers need safe spaces), > > In Python 3.6+, integers have safe underscores instead. You spacist!!! -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Sun, 25 Feb 2018 18:33:47 -0800, Rick Johnson wrote: > On Friday, February 23, 2018 at 10:41:45 AM UTC-6, Steven D'Aprano > wrote: [...] >> There are dozens of languages that have made the design choice to limit >> their default integers to 16- 32- or 64-bit fixed size, and let the >> user worry about overflow. Bart, why does it upset you so that Python >> made a different choice? > > A default "integer-diversity-and-inclusivity-doctrine" is all fine and > dandy by me, (Hey, even integers need safe spaces), but i do wish we > pythonistas had a method to turn off this (and other) cycle burning > "features" -- you know -- in the 99.9 percent of time that we don't > need them. Ah, you mean just like the way things were in Python 1.0 through 2.1? Hands up anyone who has seen an integer OverflowError in the last 10 years? Anyone? [steve@ando ~]$ python1.5 -c "print 2**64" Traceback (innermost last): File "", line 1, in ? OverflowError: integer pow() I really miss having to either add, or delete, an "L" suffix from my long ints, and having to catch OverflowError to get any work done, and generally spending half my time worrying how my algorithms will behave when integer operations overflow. Good times. I miss those days. I also miss the days when everyone had scabies. As someone who wrote Python code when bignums where *not* the default, I can tell you that: - it was a real PITA for those who cared about their code working correctly and being bug-free; - and the speed up actually wasn't that meaningful. As is so often the case with these things, using fixed size ints looks good in benchmark games, but what's fast in a toy benchmark and what's fast in real code are not always the same. -- Steve -- https://mail.python.org/mailman/listinfo/python-list
Re: How to make Python run as fast (or faster) than Julia
On Sunday, February 25, 2018 at 10:35:29 PM UTC-6, Steven D'Aprano wrote: [...] > Ah, you mean just like the way things were in Python 1.0 > through 2.1? Hands up anyone who has seen an integer > OverflowError in the last 10 years? Anyone? I think Python2.1 is much older than 10 years, so yeah, of course almost no one (save a few old timers) have seen that error. :-) > [...] > I really miss having to either add, or delete, an "L" > suffix from my long ints, and having to catch OverflowError > to get any work done, and generally spending half my time > worrying how my algorithms will behave when integer > operations overflow. I agree with your sarcasm. And that's why these types of auto conversions should be optional. I agree that most times it's more practical to let python handle the dirty details. But in some cases, where you need to squeeze out a few more drops of speed juice, you won't mind the extra trouble. And perhaps you (meaning specifically you) will never need such a flexible feature. But hey. The Python community is diverse. So please do keep that in mind. -- https://mail.python.org/mailman/listinfo/python-list
Re: For Loop Dilema [python-list]
On Mon, Feb 26, 2018 at 5:19 AM, wrote: > Why we don’t use: > > for _ in _ in _ > > Instead of > > for _ in _: > for _ in _: > > Ex: > > Names = ["Arya","Pupun"] > > for name in Names: >for c in name: >print(c) > > instead use: > > for c in name in Names: > print(c) Because programming is all about building up a program from primitives. The number of times when we need this kind of nested loop (with absolutely nothing in between the loops) is way too small to justify dedicated syntax. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
