On Sun, 3 May 2015 02:51 pm, Ian Kelly wrote:
On Sat, May 2, 2015 at 5:51 PM, Terry Reedy tjre...@udel.edu wrote:
On 5/2/2015 5:31 PM, Ian Kelly wrote:
Would it have been better if range() had been implemented as xrange()
from the beginning? Sure, that would have been great. Except for one
On Sun, 3 May 2015 07:40 am, Jon Ribbens wrote:
On 2015-05-02, BartC b...@freeuk.com wrote:
So do I, I think, if no-one is willing to admit that the original way of
implementing range() was a glaring mistake.
I think the issue is that nobody else here thinks the original way
of iterating
On Sun, 3 May 2015 08:33 am, BartC wrote:
OK, so it's just an irritation then, as a workaround has been available
for a long time. (For example, if you use xrange, it won't work on 3.x.
If you use range, then it might be inefficient on 2.x.)
That is trivially easy to deal with. Put this at
On Sun, 3 May 2015 12:16 pm, Mark Lawrence wrote:
I doubt that six will ever make the standard library as 2.7 only has
another five years in official support. By that time I suppose we'll to
going through the porting pain all over again with the transition from
Python 3 to Python 4.
On Sun, 3 May 2015 02:17 am, BartC wrote:
But for looping over a simple integer range, then using 'range' to
denote the range (and build a list as it used to do), was how it was
done. And earlier on people would have been porting coding code to
Python at which point a straightforward 'for i=a
On Sun, May 3, 2015 at 8:32 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
scripting
languages often lack a C-style for-loop, using a foreach loop instead. E.g.
I believe the canonical way to loop in bash is something like:
for $i in `seq start stop` do ...
(by memory).
On Sun, 3 May 2015 07:28 am, Tony the Tiger wrote:
On Fri, 01 May 2015 14:42:04 +1000, Steven D'Aprano wrote:
use l as a variable name, as it looks too much like 1
If you use a better font, they are very different. Besides, a variable
name cannot start with a digit (nor can it be a single
On Sun, May 3, 2015 at 9:15 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
Or if you prefer:
try:
range = xrange
except NameError:
pass
and just use range.
I prefer this idiom, on the basis that code should be written for the
more recent version, and have minimal
On Sun, May 3, 2015 at 9:16 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Sun, 3 May 2015 12:16 pm, Mark Lawrence wrote:
I doubt that six will ever make the standard library as 2.7 only has
another five years in official support. By that time I suppose we'll to
going
On 03/05/2015 12:30, Chris Angelico wrote:
On Sun, May 3, 2015 at 9:16 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Sun, 3 May 2015 12:16 pm, Mark Lawrence wrote:
I doubt that six will ever make the standard library as 2.7 only has
another five years in official support.
On 30/04/2015 18:20, Ben Finney wrote:
Jon Ribbens jon+use...@unequivocal.co.uk writes:
If you use xrange() instead of range() then you will get an iterator
which will return each of the numbers in turn without any need to
create an enormous list of all of them.
If you use Python 3 instead
On 02/05/2015 16:26, BartC wrote:
On 30/04/2015 18:20, Ben Finney wrote:
Jon Ribbens jon+use...@unequivocal.co.uk writes:
If you use xrange() instead of range() then you will get an iterator
which will return each of the numbers in turn without any need to
create an enormous list of all of
On 02/05/2015 16:40, Mark Lawrence wrote:
On 02/05/2015 16:26, BartC wrote:
On 30/04/2015 18:20, Ben Finney wrote:
Jon Ribbens jon+use...@unequivocal.co.uk writes:
If you use xrange() instead of range() then you will get an iterator
which will return each of the numbers in turn without any
On 02/05/2015 17:17, BartC wrote:
On 02/05/2015 16:40, Mark Lawrence wrote:
On 02/05/2015 16:26, BartC wrote:
On 30/04/2015 18:20, Ben Finney wrote:
Jon Ribbens jon+use...@unequivocal.co.uk writes:
If you use xrange() instead of range() then you will get an iterator
which will return each
Mark Lawrence breamore...@yahoo.co.uk:
On 02/05/2015 19:34, BartC wrote:
[...]
[...]
[...]
[...]
[...]
[...]
[...]
[...]
[...]
[...]
[...]
[...]
[...]
[...]
[etc etc etc]
I give up.
Mark, you do a commendable job admonishing the forum participants
against top-posting. Let me
On 02/05/2015 17:39, Mark Lawrence wrote:
On 02/05/2015 17:17, BartC wrote:
On 02/05/2015 16:40, Mark Lawrence wrote:
for item in items:
When did this change, or has it always been this way and you were simply
using an idiom from other languages?
Your example is the equivalent of
On 02/05/2015 19:34, BartC wrote:
On 02/05/2015 17:39, Mark Lawrence wrote:
On 02/05/2015 17:17, BartC wrote:
On 02/05/2015 16:40, Mark Lawrence wrote:
for item in items:
When did this change, or has it always been this way and you were
simply
using an idiom from other languages?
Your
BartC b...@freeuk.com:
(I tried an empty loop counting to 1 billion in Python 2.x, using 'for
i in range'. It ran out of memory. Counting to 100 million instead, it
worked, but still used a massive 1.5GB RAM while doing so (and took 6
seconds to count to 100M, not too bad for Python)
On 02/05/2015 20:15, Mark Lawrence wrote:
On 02/05/2015 19:34, BartC wrote:
OK, so it's the programmer's fault if as fundamental a concept as a
for-loop ranging over integers is implemented inefficiently. He has to
transform it into high-level terms, or has to reconstruct it somehow
using a
On 5/2/2015 5:40 PM, Jon Ribbens wrote:
For information, it looks like xrange() was added on 26 Oct 1993,
which pre-dates Python 1.0.
1.0 was released Feb 1991. 3.2 exactly 20 years later.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
I give up.
So do I, I think, if no-one is willing to admit that the original way of
implementing range() was a glaring mistake.
--
Bartc
It doesn't matter for small ranges. Anyway it was fixed.
--
https://mail.python.org/mailman/listinfo/python-list
--
Joel Goldstick
On Sat, May 2, 2015 at 1:51 PM, BartC b...@freeuk.com wrote:
On 02/05/2015 20:15, Mark Lawrence wrote:
On 02/05/2015 19:34, BartC wrote:
OK, so it's the programmer's fault if as fundamental a concept as a
for-loop ranging over integers is implemented inefficiently. He has to
transform it
On 02/05/2015 22:40, Jon Ribbens wrote:
On 2015-05-02, BartC b...@freeuk.com wrote:
So do I, I think, if no-one is willing to admit that the original way of
implementing range() was a glaring mistake.
I think the issue is that nobody else here thinks the original way
of iterating was to use
On 5/2/2015 11:26 AM, BartC wrote:
When I first looked at Python 20 or so years ago this seemed to be the
standard way of writing a for-loop:
for i in range(N):
As Mark said, the actual syntax was originally
for item in sequence: ...
where sequence technically meant an object with
On 5/2/2015 5:31 PM, Ian Kelly wrote:
Would it have been better if range() had been implemented as xrange()
from the beginning? Sure, that would have been great. Except for one
small detail: the iterator protocol didn't exist back then.
For loops originally used the getitem iterator protocol.
On Sat, May 2, 2015 at 3:28 PM, Tony the Tiger tony@tiger.invalid wrote:
On Fri, 01 May 2015 14:42:04 +1000, Steven D'Aprano wrote:
use l as a variable name, as it looks too much like 1
If you use a better font, they are very different. Besides, a variable
name cannot start with a digit (nor
On 2015-05-02, BartC b...@freeuk.com wrote:
So do I, I think, if no-one is willing to admit that the original way of
implementing range() was a glaring mistake.
I think the issue is that nobody else here thinks the original way
of iterating was to use range(), for anything other than extremely
On 02/05/2015 22:40, Jon Ribbens wrote:
On 2015-05-02, BartC b...@freeuk.com wrote:
So do I, I think, if no-one is willing to admit that the original way of
implementing range() was a glaring mistake.
I think the issue is that nobody else here thinks the original way
of iterating was to use
On Sat, May 2, 2015 at 5:51 PM, Terry Reedy tjre...@udel.edu wrote:
On 5/2/2015 5:31 PM, Ian Kelly wrote:
Would it have been better if range() had been implemented as xrange()
from the beginning? Sure, that would have been great. Except for one
small detail: the iterator protocol didn't exist
On 2015-05-02, Terry Reedy tjre...@udel.edu wrote:
On 5/2/2015 5:40 PM, Jon Ribbens wrote:
For information, it looks like xrange() was added on 26 Oct 1993,
which pre-dates Python 1.0.
1.0 was released Feb 1991. 3.2 exactly 20 years later.
No, you are thinking of 0.9, which was indeed
On 05/02/2015 04:33 PM, BartC wrote:
OK, so it's just an irritation then, as a workaround has been available
for a long time. (For example, if you use xrange, it won't work on 3.x.
If you use range, then it might be inefficient on 2.x.)
In both Python 2.7 and 3.3+, you can use the 3rd-party
On 03/05/2015 03:07, Michael Torrie wrote:
On 05/02/2015 04:33 PM, BartC wrote:
OK, so it's just an irritation then, as a workaround has been available
for a long time. (For example, if you use xrange, it won't work on 3.x.
If you use range, then it might be inefficient on 2.x.)
In both
On 5/2/2015 8:01 PM, Jon Ribbens wrote:
On 2015-05-02, Terry Reedy tjre...@udel.edu wrote:
On 5/2/2015 5:40 PM, Jon Ribbens wrote:
For information, it looks like xrange() was added on 26 Oct 1993,
which pre-dates Python 1.0.
1.0 was released Feb 1991. 3.2 exactly 20 years later.
No, you
On 2015-05-03, Terry Reedy tjre...@udel.edu wrote:
On 5/2/2015 8:01 PM, Jon Ribbens wrote:
On 2015-05-02, Terry Reedy tjre...@udel.edu wrote:
On 5/2/2015 5:40 PM, Jon Ribbens wrote:
For information, it looks like xrange() was added on 26 Oct 1993,
which pre-dates Python 1.0.
1.0 was
On 2015-05-02, BartC b...@freeuk.com wrote:
On 02/05/2015 22:40, Jon Ribbens wrote:
I think the issue is that nobody else here thinks the original way
of iterating was to use range(), for anything other than extremely
small ranges.
What /is/ the way to iterate then?
Other people have
On 5/1/2015 1:04 AM, Cecil Westerhof wrote:
By the way: I also see python3.4 and python3.4m. Any idea where the m
stands for?
I never heard of that in 18 years of Python, and thought it must be an
error, but putting 'python3.4b' into google search return this.
Op Friday 1 May 2015 15:25 CEST schreef Michael Torrie:
On 04/30/2015 10:19 PM, Cecil Westerhof wrote:
I must also confess to being highly impressed, it's a breath of
fresh air having an apprentice Pythonista who is looking at doing
things the Pythonic way :)
When in Rome, do as the Romans
Op Friday 1 May 2015 07:20 CEST schreef Steven D'Aprano:
Some programming language virtual machines limit how much memory
they will use. The CPython VM isn't one of those, although I
understand that both Jython and IronPython are. (I may be wrong --
Jython runs in the JVM, so Jython is.
--
Cecil Westerhof wrote:
By the way: I also see python3.4 and python3.4m. Any idea where the m
stands for?
I googled for “python3.4m” and found as second result
http://stackoverflow.com/questions/16675865/difference-between-python3-and-python3m-executibles
In a nutshell: python3.4m was built
Op Friday 1 May 2015 13:15 CEST schreef Thomas Lahn:
Cecil Westerhof wrote:
By the way: I also see python3.4 and python3.4m. Any idea where the
m stands for?
I googled for “python3.4m” and found as second result
Eh, I could/should have done that myself. :-(
Nice that you do not burn me.
On 04/30/2015 10:19 PM, Cecil Westerhof wrote:
I must also confess to being highly impressed, it's a breath of
fresh air having an apprentice Pythonista who is looking at doing
things the Pythonic way :)
When in Rome, do as the Romans do.
Besides: there probably is a reason for the
Jon Ribbens jon+use...@unequivocal.co.uk writes:
On 2015-04-30, Cecil Westerhof ce...@decebal.nl wrote:
If I execute:
l = range(int(1E9)
The python process gobbles up all the memory and is killed. […] Is
there a way to circumvent Python claiming all the memory?
You seem
On 2015-04-30, Cecil Westerhof ce...@decebal.nl wrote:
If I execute:
l = range(int(1E9)
The python process gobbles up all the memory and is killed. The
problem is that after this my swap is completely used, because other
processes have swapped to it. This make those programs more slowly
On 4/30/2015 12:06 PM, Cecil Westerhof wrote:
If I execute:
l = range(int(1E9)
you get a SyntaxError
The python process gobbles up all the memory and is killed. The
problem is that after this my swap is completely used, because other
processes have swapped to it. This make those
Cecil Westerhof wrote:
If I execute:
l = range(int(1E9)
The python process gobbles up all the memory and is killed. The
problem is that after this my swap is completely used, because other
processes have swapped to it. This make those programs more slowly. Is
there a way to circumvent
If I execute:
l = range(int(1E9)
The python process gobbles up all the memory and is killed. The
problem is that after this my swap is completely used, because other
processes have swapped to it. This make those programs more slowly. Is
there a way to circumvent Python claiming all the memory
On 04/30/2015 09:06 AM, Cecil Westerhof wrote:
If I execute:
l = range(int(1E9)
The python process gobbles up all the memory and is killed. The
problem is that after this my swap is completely used, because other
processes have swapped to it. This make those programs more slowly
Op Thursday 30 Apr 2015 18:33 CEST schreef Grant Edwards:
On 2015-04-30, Cecil Westerhof ce...@decebal.nl wrote:
If I execute:
l = range(int(1E9)
The python process gobbles up all the memory and is killed. The
problem is that after this my swap is completely used, because
other processes
Cecil Westerhof ce...@decebal.nl writes:
That works, yes. Now I get a MemoryError and the other processes are
left alone. Now determining what are the best values.
I would strongly recommend that “best values” includes “run Python
version = 3”.
One of the many problems you avoid by leaving
Op Thursday 30 Apr 2015 18:55 CEST schreef Jon Ribbens:
On 2015-04-30, Cecil Westerhof ce...@decebal.nl wrote:
If I execute:
l = range(int(1E9)
The python process gobbles up all the memory and is killed. The
problem is that after this my swap is completely used, because
other processes
On Thu, 30 Apr 2015 10:05:44 -0700, Gary Herron wrote:
On 04/30/2015 09:06 AM, Cecil Westerhof wrote:
If I execute:
l = range(int(1E9)
The python process gobbles up all the memory and is killed. The problem
is that after this my swap is completely used, because other processes
have
On 2015-04-30, Cecil Westerhof ce...@decebal.nl wrote:
If I execute:
l = range(int(1E9)
The python process gobbles up all the memory and is killed. The
problem is that after this my swap is completely used, because other
processes have swapped to it. This make those programs more slowly
Op Thursday 30 Apr 2015 19:12 CEST schreef Rob Gaddi:
This also leads to a unrelated question, Cecil. Given that you
really are just starting to get your Python feet under you, why are
you using Python2? Python3 is the standard now, Python2 is really
just given legacy support. I'd understand
On 04/30/2015 02:48 PM, alister wrote:
On Thu, 30 Apr 2015 20:23:31 +0200, Gisle Vanem wrote:
Cecil Westerhof wrote:
If I execute:
l = range(int(1E9)
The python process gobbles up all the memory and is killed. The problem
is that after this my swap is completely used, because other
On 30/04/2015 19:50, Cecil Westerhof wrote:
Op Thursday 30 Apr 2015 19:12 CEST schreef Rob Gaddi:
This also leads to a unrelated question, Cecil. Given that you
really are just starting to get your Python feet under you, why are
you using Python2? Python3 is the standard now, Python2 is really
Op Thursday 30 Apr 2015 20:59 CEST schreef Dave Angel:
On 04/30/2015 02:48 PM, alister wrote:
On Thu, 30 Apr 2015 20:23:31 +0200, Gisle Vanem wrote:
Cecil Westerhof wrote:
If I execute:
l = range(int(1E9)
The python process gobbles up all the memory and is killed. The
problem
Grant Edwards schreef op 2015-04-30 18:33:
On 2015-04-30, Cecil Westerhof ce...@decebal.nl wrote:
If I execute:
l = range(int(1E9)
The python process gobbles up all the memory and is killed. The
problem is that after this my swap is completely used, because other
processes have swapped
On Thu, 30 Apr 2015 20:23:31 +0200, Gisle Vanem wrote:
Cecil Westerhof wrote:
If I execute:
l = range(int(1E9)
The python process gobbles up all the memory and is killed. The problem
is that after this my swap is completely used, because other processes
have swapped to it. This make
Op Thursday 30 Apr 2015 19:41 CEST schreef Ben Finney:
Cecil Westerhof ce...@decebal.nl writes:
That works, yes. Now I get a MemoryError and the other processes
are left alone. Now determining what are the best values.
I would strongly recommend that “best values” includes “run Python
Op Thursday 30 Apr 2015 22:53 CEST schreef Mark Lawrence:
On 30/04/2015 19:50, Cecil Westerhof wrote:
Op Thursday 30 Apr 2015 19:12 CEST schreef Rob Gaddi:
This also leads to a unrelated question, Cecil. Given that you
really are just starting to get your Python feet under you, why
are you
On Fri, 1 May 2015 02:06 am, Cecil Westerhof wrote:
If I execute:
l = range(int(1E9)
Others have already answered your questions about memory. Let me answer the
question you didn't ask about style :-)
Don't use l as a variable name, as it looks too much like 1. Better to use
L, or even
Op Friday 1 May 2015 01:12 CEST schreef Ben Finney:
Chris Angelico ros...@gmail.com writes:
Very easily and simply: Python 3 and Python 2 will always install
separately, and the only possible conflicts are over the python
command in PATH and which program is associated with .py files.
Op Friday 1 May 2015 06:42 CEST schreef Steven D'Aprano:
On Fri, 1 May 2015 02:06 am, Cecil Westerhof wrote:
If I execute:
l = range(int(1E9)
Others have already answered your questions about memory. Let me
answer the question you didn't ask about style :-)
That can be very useful
On 01/05/2015 05:19, Cecil Westerhof wrote:
Op Thursday 30 Apr 2015 22:53 CEST schreef Mark Lawrence:
On 30/04/2015 19:50, Cecil Westerhof wrote:
Op Thursday 30 Apr 2015 19:12 CEST schreef Rob Gaddi:
This also leads to a unrelated question, Cecil. Given that you
really are just starting to
On Fri, 1 May 2015 03:20 am, Ben Finney wrote:
Jon Ribbens jon+use...@unequivocal.co.uk writes:
On 2015-04-30, Cecil Westerhof ce...@decebal.nl wrote:
If I execute:
l = range(int(1E9)
The python process gobbles up all the memory and is killed. […] Is
there a way to circumvent Python
= range(int(1E9))
gives MemoryError.
And if I can also do (from another thread):
happy_number_list(int(1E8))
if I did not something memory consuming.
And if a (Python) process should use significantly less, it could be a
good idea to tweak the ulimit call.
--
Cecil Westerhof
Senior Software
On Fri, May 1, 2015 at 7:23 AM, ElChino elch...@cnn.cn wrote:
Mark Lawrence wrote:
You might find this useful then in you haven't already seen it
https://docs.python.org/3/howto/pyporting.html
The main reason I haven't switched to Python3 (from 2.7.4/MSVC),
is fear of a major breakage. How
On Friday, May 1, 2015 at 4:50:45 AM UTC+5:30, Ben Finney wrote:
Chris Angelico writes:
Very easily and simply: Python 3 and Python 2 will always install
separately, and the only possible conflicts are over the python
command in PATH and which program is associated with .py files.
Mark Lawrence wrote:
You might find this useful then in you haven't already seen it
https://docs.python.org/3/howto/pyporting.html
The main reason I haven't switched to Python3 (from 2.7.4/MSVC),
is fear of a major breakage. How can I be certain that even if
I install to different
Chris Angelico wrote:
Very easily and simply: Python 3 and Python 2 will always install
separately, and the only possible conflicts are over the python
command in PATH and which program is associated with .py files. You
can fix both of them by installing a recent version of Python and
using
Chris Angelico ros...@gmail.com writes:
Very easily and simply: Python 3 and Python 2 will always install
separately, and the only possible conflicts are over the python
command in PATH and which program is associated with .py files.
Calling ‘python’ is now ambiguous, and with Python 2
On 2015-04-30 22:18, Cecil Westerhof wrote:
Op Thursday 30 Apr 2015 20:59 CEST schreef Dave Angel:
ulimit is your friend if you've got a program that wants to gobble
up all of swap space.
Yes, my system is openSUSE 64 bit. I really should look into ulimit.
The default is:
[snip]
max
Chris Angelico ros...@gmail.com writes:
Very easily and simply: Python 3 and Python 2 will always install
separately, and the only possible conflicts are over the python
command in PATH and which program is associated with .py files.
Using the ‘python’ command is now ambiguous, and with
On Fri, May 1, 2015 at 9:12 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Chris Angelico ros...@gmail.com writes:
Very easily and simply: Python 3 and Python 2 will always install
separately, and the only possible conflicts are over the python
command in PATH and which program is
74 matches
Mail list logo
