Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #89638 > unrolled thread

l = range(int(1E9))

Back to article view | Back to comp.lang.python

Contents

  l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 18:06 +0200
    Re: l = range(int(1E9)) Grant Edwards <invalid@invalid.invalid> - 2015-04-30 16:33 +0000
      Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 19:26 +0200
        Re: l = range(int(1E9)) Ben Finney <ben+python@benfinney.id.au> - 2015-05-01 03:41 +1000
          Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 20:44 +0200
      Re: l = range(int(1E9)) Roel Schroeven <roel@roelschroeven.net> - 2015-04-30 21:40 +0200
    Re: l = range(int(1E9)) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-04-30 16:55 +0000
      Re: l = range(int(1E9)) Ben Finney <ben+python@benfinney.id.au> - 2015-05-01 03:20 +1000
        Re: l = range(int(1E9)) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-01 15:20 +1000
          Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-05-01 08:08 +0200
        Re: l = range(int(1E9)) BartC <bc@freeuk.com> - 2015-05-02 16:26 +0100
          Re: l = range(int(1E9)) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-02 16:40 +0100
            Re: l = range(int(1E9)) BartC <bc@freeuk.com> - 2015-05-02 17:17 +0100
              Re: l = range(int(1E9)) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-02 17:39 +0100
                Re: l = range(int(1E9)) BartC <bc@freeuk.com> - 2015-05-02 19:34 +0100
                  Re: l = range(int(1E9)) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-02 20:15 +0100
                    Re: l = range(int(1E9)) Marko Rauhamaa <marko@pacujo.net> - 2015-05-02 22:26 +0300
                    Re: l = range(int(1E9)) BartC <bc@freeuk.com> - 2015-05-02 20:51 +0100
                      Re: l = range(int(1E9)) Joel Goldstick <joel.goldstick@gmail.com> - 2015-05-02 17:21 -0400
                      Re: l = range(int(1E9)) Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-02 15:31 -0600
                      Re: l = range(int(1E9)) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-05-02 21:40 +0000
                        Re: l = range(int(1E9)) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-02 23:26 +0100
                        Re: l = range(int(1E9)) BartC <bc@freeuk.com> - 2015-05-02 23:33 +0100
                          Re: l = range(int(1E9)) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-05-03 00:13 +0000
                          Re: l = range(int(1E9)) Michael Torrie <torriem@gmail.com> - 2015-05-02 20:07 -0600
                          Re: l = range(int(1E9)) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-03 03:16 +0100
                            Re: l = range(int(1E9)) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-03 21:16 +1000
                              Re: l = range(int(1E9)) Chris Angelico <rosuav@gmail.com> - 2015-05-03 21:30 +1000
                              Re: l = range(int(1E9)) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-03 19:36 +0100
                          Re: l = range(int(1E9)) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-03 21:15 +1000
                            Re: l = range(int(1E9)) Chris Angelico <rosuav@gmail.com> - 2015-05-03 21:29 +1000
                        Re: l = range(int(1E9)) Terry Reedy <tjreedy@udel.edu> - 2015-05-02 19:26 -0400
                          Re: l = range(int(1E9)) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-05-03 00:01 +0000
                            Re: l = range(int(1E9)) Terry Reedy <tjreedy@udel.edu> - 2015-05-02 23:18 -0400
                              Re: l = range(int(1E9)) Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-05-03 03:40 +0000
                        Re: l = range(int(1E9)) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-03 21:05 +1000
                      Re: l = range(int(1E9)) Terry Reedy <tjreedy@udel.edu> - 2015-05-02 19:51 -0400
                      Re: l = range(int(1E9)) Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-02 22:51 -0600
                        Re: l = range(int(1E9)) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-03 21:21 +1000
                  Re: l = range(int(1E9)) Marko Rauhamaa <marko@pacujo.net> - 2015-05-02 22:15 +0300
              Re: l = range(int(1E9)) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-03 20:32 +1000
                Re: l = range(int(1E9)) Chris Angelico <rosuav@gmail.com> - 2015-05-03 20:59 +1000
          Re: l = range(int(1E9)) Terry Reedy <tjreedy@udel.edu> - 2015-05-02 18:41 -0400
      Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 19:28 +0200
    Re: l = range(int(1E9)) Terry Reedy <tjreedy@udel.edu> - 2015-04-30 13:02 -0400
    Re: l = range(int(1E9)) Gary Herron <gherron@digipen.edu> - 2015-04-30 10:05 -0700
      Re: l = range(int(1E9)) Rob Gaddi <rgaddi@technologyhighland.invalid> - 2015-04-30 17:12 +0000
        Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 20:50 +0200
          Re: l = range(int(1E9)) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-04-30 21:53 +0100
            Re: l = range(int(1E9)) ElChino <elchino@cnn.cn> - 2015-04-30 23:23 +0200
              Re: l = range(int(1E9)) Chris Angelico <rosuav@gmail.com> - 2015-05-01 08:45 +1000
                Re: l = range(int(1E9)) ElChino <elchino@cnn.cn> - 2015-05-01 01:03 +0200
              Re: l = range(int(1E9)) Ben Finney <ben+python@benfinney.id.au> - 2015-05-01 09:12 +1000
                Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-05-01 07:04 +0200
                  Re: l = range(int(1E9)) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-01 13:15 +0200
                    Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-05-01 14:22 +0200
                  Re: l = range(int(1E9)) Terry Reedy <tjreedy@udel.edu> - 2015-05-01 22:00 -0400
              Use ‘python2’ or ‘python3’, explicit is better than implicit  (was: l = range(int(1E9))) Ben Finney <ben+python@benfinney.id.au> - 2015-05-01 09:19 +1000
                Re: Use 'python2' or 'python3', explicit is better than implicit  (was: l = range(int(1E9))) Rustom Mody <rustompmody@gmail.com> - 2015-04-30 19:24 -0700
              Re: l = range(int(1E9)) Chris Angelico <rosuav@gmail.com> - 2015-05-01 09:23 +1000
            Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-05-01 06:19 +0200
              Re: l = range(int(1E9)) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-01 05:41 +0100
              Re: l = range(int(1E9)) Michael Torrie <torriem@gmail.com> - 2015-05-01 07:25 -0600
                Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-05-01 16:12 +0200
    Re: l = range(int(1E9)) Gisle Vanem <gvanem@yahoo.no> - 2015-04-30 20:23 +0200
      Re: l = range(int(1E9)) alister <alister.nospam.ware@ntlworld.com> - 2015-04-30 18:48 +0000
        Re: l = range(int(1E9)) Dave Angel <davea@davea.name> - 2015-04-30 14:59 -0400
          Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-04-30 22:18 +0200
            Re: l = range(int(1E9)) Tim Chase <python.list@tim.thechases.com> - 2015-04-30 16:41 -0500
              Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-05-01 07:19 +0200
    Re: l = range(int(1E9)) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-01 14:42 +1000
      Re: l = range(int(1E9)) Cecil Westerhof <Cecil@decebal.nl> - 2015-05-01 07:13 +0200
      Re: l = range(int(1E9)) Tony the Tiger <tony@tiger.invalid> - 2015-05-02 21:28 +0000
        Re: l = range(int(1E9)) Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-02 15:32 -0600
        Re: l = range(int(1E9)) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-03 20:56 +1000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#89850

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 to b' loop suddenly
> acquired a substantial overhead it didn't have before!


The oldest version of Python that is documented on the python.org site is
1.4, and it had xrange:

https://docs.python.org/release/1.4/lib/node26.html

The oldest version of Python I have is Python 0.9.1, which has range but not
xrange:

steve@runes:~/personal/python/Interpreters/python-0.9.1$ ./python0.9.1
>>> range
<built-in function 'builtin.range'>
>>> xrange
Unhandled exception: undefined name: xrange
Stack backtrace (innermost last):
  File "<stdin>", line 1


but then Python 0.9 was missing a lot of features, such as double quoted
strings, and various operators:

>>> "a"
Parsing error: file <stdin>, line 1:
"a"
 ^
Unhandled exception: run-time error: syntax error
>>> 2**3
Parsing error: file <stdin>, line 1:
2**3
   ^
Unhandled exception: run-time error: syntax error


It's unfair to consider anything before version 1.0: it is obvious that
pre-1.0 Python was still incomplete and a work in progress.

If you check the versions here:

http://legacy.python.org/download/releases/src/

you will see that xrange was available in 1.1, but (probably) not in 1.0. So
xrange has been available since almost the start. By version 1.4, or
possibly 1.5, the general advice given as I remember it was that if the
number of loops was small, range was faster than xrange, but if it was
large, xrange used less memory.

On the basis of two software development principles:

(1) release early, release often;

(2) avoid premature optimization;

I don't think there is any problem with range being released before the need
for xrange was proven. Python, especially in the early days, was considered
more of a scripting language than a general purpose language, and 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).


If we were creating Python from scratch now, we would never have had an
eager range() that returns a list. But back in the early 1990s, that wasn't
as obvious as it is in hindsight.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#89856

On Sun, May 3, 2015 at 8:32 PM, Steven D'Aprano
<steve+comp.lang.python@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).

Newer versions of bash have grown an alternative syntax for that
common case, but if you need to support older forms, or other shells,
then yes, it's something like that. Maybe without the dollar sign. (I
can never remember the exact syntax, and I know bash is really finicky
about where you put newlines and where you don't, but it looks
something like what you had.)

ChrisA

[toc] | [prev] | [next] | [standalone]

#89810

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 a .__getitem__(x) method 
that either returned an item or raised IndexError.  In 2.2, 'sequence' 
was replaced by the more general concept 'iterable'.

In python, 'for' is and has always been an abbreviation of 'for each' or 
'foreach', as used in other languages. C for loops are not 'for each' 
loops but are initialized while loops, and are so explained in K&R's 
book, page 56.

'''
for (initializer; condition; update;) body

is equivalent to

initializer
while (condition) {
     body
     update;
}
...
Whether to use while or for is largely a matter of taste.
'''

(I substituted 'initializer', 'condition', 'update' for 'expr1', 
'expr2', and 'expr3' as more meaningful.)  The proper translation of a C 
for loop to Python is the translation of the equivalent C while loop. 
Translating to a Python 'for range' loop is a bit of a mis-translation. 
  One should not be surprised if non-equivalent code behaves differently.

> I remember being completely astonished at the time that 'range' actually
> created a list of values from 0 to N-1.

The purpose and *documented* behavior of range was to produce an 
arithmetic sequence.  Map, filter, dict.keys, dict.values, dict.items, 
many others functions also returned lists.  In Python3, the ones I named 
above and some others now return 'less spacious' iterables.

> Python was already known to be slow yet it deliberately crippled itself
> by using just about the slowest method imaginable of executing a simple
> iterative loop? By first creating a list of a million objects!

No, you were also free to do the sensible thing when you did not need a 
concrete arithmetic sequence (list).

n = 0
while n < 1000000:
     pass
     n = n+1

> And sometimes you weren't even interested in the values but just wanted
> to execute something N times so it was a wasted effort.

# even simpler
n = 1000000
while n:
     pass
     n -= 1

Using for ... range() is a convenient abbreviation of either pattern. 
It works for small values of n, it did not work for large values.  When 
Python 1.0 was released in Feb 1992, memory for many system was limited 
to a megabyte or less. At that time, range(1000000) was an impossible 
object, so no one aware of memory constraints would try to create it.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#89653

Op Thursday 30 Apr 2015 18:55 CEST schreef Jon Ribbens:

> On 2015-04-30, Cecil Westerhof <Cecil@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. Is there a way to circumvent Python claiming all the
>> memory?
>>
>> By the way: this is CPython 2.7.8.
>
> It's your operating system's job to handle processes.
>
> 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.

I did it on purpose. Wanted to now the limits. Just need to use ulimit
to get a MemoryError.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#89643

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 programs more slowly. Is
> there a way to circumvent Python claiming all the memory?

For this specific case, use xrange or 3.x range

> By the way: this is CPython 2.7.8.



-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#89646

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. Is
> there a way to circumvent Python claiming all the memory?
>
> By the way: this is CPython 2.7.8.

Well, that could be considered the problem.   In Python3, the range 
function returns a range object which takes up almost no resources, 
while in Python2 it produces a list.  Both can be iterated over, so they 
produce the same result in the most common use case (i.e., iteration), 
but the Python3 version generates the elements only as needed.

If you really *wanted* the list (but WHY?) in Python3, do 
list(range(...)), but then you get what you deserve. :-)

Python3:

 >>> l = range(int(1E9))
 >>> l
range(0, 1000000000)


-- 
Dr. Gary Herron
Department of Computer Science
DigiPen Institute of Technology
(425) 895-4418

[toc] | [prev] | [next] | [standalone]

#89647

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 swapped to it. This make those programs more slowly. Is there a
>> way to circumvent Python claiming all the memory?
>>
>> By the way: this is CPython 2.7.8.
> 
> Well, that could be considered the problem.   In Python3, the range
> function returns a range object which takes up almost no resources,
> while in Python2 it produces a list.  Both can be iterated over, so they
> produce the same result in the most common use case (i.e., iteration),
> but the Python3 version generates the elements only as needed.
> 
> If you really *wanted* the list (but WHY?) in Python3, do
> list(range(...)), but then you get what you deserve. :-)
> 
> Python3:
> 
>  >>> l = range(int(1E9))
>  >>> l
> range(0, 1000000000)

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 if you were trying to maintain an old 
codebase with lots of legacy code that was having "problematic" 
migrations, but with the opportunity to start fresh?  Start fresh.  
You'll be happier for it.


-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

[toc] | [prev] | [next] | [standalone]

#89659

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 if you were trying to
> maintain an old codebase with lots of legacy code that was having
> "problematic" migrations, but with the opportunity to start fresh?
> Start fresh. You'll be happier for it.

I try to write code that works with both. Wen looking around in the
Netherlands there are more job opportunities with Python 2 as with
Python 3. So at the moment I find Python 2 more important, without
forgetting Python 3.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#89671

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
>> just given legacy support. I'd understand if you were trying to
>> maintain an old codebase with lots of legacy code that was having
>> "problematic" migrations, but with the opportunity to start fresh?
>> Start fresh. You'll be happier for it.
>
> I try to write code that works with both. Wen looking around in the
> Netherlands there are more job opportunities with Python 2 as with
> Python 3. So at the moment I find Python 2 more important, without
> forgetting Python 3.
>

You might find this useful then in you haven't already seen it 
https://docs.python.org/3/howto/pyporting.html

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

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#89674

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 directories, the Python2 and Python3 won't
step on each other toes. And what about all the .pyd I have around?
Do they need an update?

I'm barely familiar with virtualenv BTW; not sure another
confusing factor in the equation would be a good idea. Or
lessen my fear.

[toc] | [prev] | [next] | [standalone]

#89679

On Fri, May 1, 2015 at 7:23 AM, ElChino <elchino@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 can I be certain that even if
> I install to different directories, the Python2 and Python3 won't
> step on each other toes. And what about all the .pyd I have around?
> Do they need an update?
>
> I'm barely familiar with virtualenv BTW; not sure another
> confusing factor in the equation would be a good idea. Or
> lessen my fear.

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 the py.exe launcher:

https://www.python.org/dev/peps/pep-0397/
https://docs.python.org/3/using/windows.html#python-launcher-for-windows

As to your .pyd files... they'll continue to work with Python 2.7
(and, incidentally, I would suggest upgrading to 2.7.9 or 2.7.10), but
you'll need to update them for Python 3. If you got them from a third
party, chances are good that there'll be a Py3 build available; if you
built them from source, you could try just recompiling the latest
source. But if you wrote them yourself, you may well have to make some
changes to get them to compile against Python 3.

If you have issues, start a new thread; people will be happy to help.

ChrisA

[toc] | [prev] | [next] | [standalone]

#89681

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 the py.exe launcher:

Thanks for the info. I'll give it a try.

[toc] | [prev] | [next] | [standalone]

#89682

Chris Angelico <rosuav@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 slipping inexorably
into the past, increasingly the ‘python’ command is the wrong choice for
code that we want to survive in the future.

I am seeing a growing call, with which I agree, to recommend explicitly
calling ‘python2’ or ‘python3’ as commands.

That includes when we type it for direct invocation, or when we set it
as the command for automatic execution of a program (e.g. in the
“shebang” line of a program).

Use the command ‘python2’ or ‘python3’ to be explicit about which Python
version you intend to run.

-- 
 \      “I don't want to live peacefully with difficult realities, and |
  `\     I see no virtue in savoring excuses for avoiding a search for |
_o__)                        real answers.” —Paul Z. Myers, 2009-09-12 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#89695

Op Friday 1 May 2015 01:12 CEST schreef Ben Finney:

> Chris Angelico <rosuav@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 slipping
> inexorably into the past, increasingly the ‘python’ command is the
> wrong choice for code that we want to survive in the future.
>
> I am seeing a growing call, with which I agree, to recommend
> explicitly calling ‘python2’ or ‘python3’ as commands.
>
> That includes when we type it for direct invocation, or when we set
> it as the command for automatic execution of a program (e.g. in the
> “shebang” line of a program).
>
> Use the command ‘python2’ or ‘python3’ to be explicit about which
> Python version you intend to run.

Good tip. I used python and python3, but there is also a python2. I
learn myself to use that instead of python.

By the way: I also see python3.4 and python3.4m. Any idea where the m
stands for?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#89723

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 with configure option “--with-pymalloc” 
which causes the resulting implementation to use “Pymalloc, a specialized 
object allocator written by Vladimir Marangozov, […] a feature added to 
Python 2.1. Pymalloc is intended to be faster than the system malloc() and 
to have less memory overhead for allocation patterns typical of Python 
programs. The allocator uses C's malloc() function to get large pools of 
memory and then fulfills smaller memory requests from these pools.”

See also: <https://github.com/Homebrew/homebrew/issues/32402> (first result)

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#89730

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. :-D


> <http://stackoverflow.com/questions/16675865/difference-between-python3-and-python3m-executibles>
>
> In a nutshell: python3.4m was built with configure option
> “--with-pymalloc” which causes the resulting implementation to use
> “Pymalloc, a specialized object allocator written by Vladimir
> Marangozov, […] a feature added to Python 2.1. Pymalloc is intended
> to be faster than the system malloc() and to have less memory
> overhead for allocation patterns typical of Python programs. The
> allocator uses C's malloc() function to get large pools of memory
> and then fulfills smaller memory requests from these pools.”
>
> See also: <https://github.com/Homebrew/homebrew/issues/32402> (first
> result)

Something to look in later. Looks interesting, but have a ‘few’ things
that are more important.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#89745

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.

https://stackoverflow.com/questions/16675865/difference-between-python3-and-python3m-executibles

See first answer.
-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#89683 — Use ‘python2’ or ‘python3’, explicit is better than implicit (was: l = range(int(1E9)))

Chris Angelico <rosuav@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 Python 2 slipping
inexorably into the past, increasingly the ‘python’ command is the wrong
choice for Python programs that we want to survive in the future.

I am seeing a growing call, with which I agree, to recommend explicitly
calling ‘python2’ or ‘python3’ as commands.

That includes when we type it for direct one-time invocation, or when we
set it as the command for automatic execution of a program (e.g. in the
“shebang” line of a program).

Use the command ‘python2’ or ‘python3’ to be explicit about which Python
version you intend to run. Legacy programs will continue to work, and
code targeting Python 3 will not accidentally get an incompatible Python
2 interpreter.

-- 
 \      “I don't want to live peacefully with difficult realities, and |
  `\     I see no virtue in savoring excuses for avoiding a search for |
_o__)                        real answers.” —Paul Z. Myers, 2009-09-12 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#89687 — Re: Use 'python2' or 'python3', explicit is better than implicit (was: l = range(int(1E9)))

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.
> 
> Using the 'python' command is now ambiguous, and with Python 2 slipping
> inexorably into the past, increasingly the 'python' command is the wrong
> choice for Python programs that we want to survive in the future.
> 
> I am seeing a growing call, with which I agree, to recommend explicitly
> calling 'python2' or 'python3' as commands.

There was this recent exchange on the debian user list.
The OP asked a somewhat vague/generic question about recommendations for
programming books[0]

After some point when I put in
| 20 years ago I had written that C fries students' brains.
| If python had existed then I would have recommended it.[1]


Someone responded with:

| And yes, about the only *reasonable* way to understand Linux is to do
| write something which (ab)using syscalls. And that's something best done
| in C (maybe Perl).

| And please think of the children :) Teaching young ones something as
| volatile and ever-changing as Python (or, $DEITY forbid, Ruby) can be
| considered cruel and abusive :)  [2] [3]

From which I conclude that in the short term distinguishing python 2 from 3
may be convenient.
In the long term and in circles further away from those directly interested
in python... not clear (to me at least)

Coming to this question you rightly said:
> You seem to be asking for a way to stop a program doing exactly what
> it's written to do. I don't know what kind of answer you expect. 

which is to say if you explore pathology you will get pathological behavior.
What of it?

------------------------------------------
[0] https://lists.debian.org/debian-user/2015/04/msg00497.html
[1] https://lists.debian.org/debian-user/2015/04/msg00650.html
[2] https://lists.debian.org/debian-user/2015/04/msg00660.html
[3] https://lists.debian.org/debian-user/2015/04/msg00682.html

[toc] | [prev] | [next] | [standalone]

#89684

On Fri, May 1, 2015 at 9:12 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Chris Angelico <rosuav@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 slipping inexorably
> into the past, increasingly the ‘python’ command is the wrong choice for
> code that we want to survive in the future.
>
> I am seeing a growing call, with which I agree, to recommend explicitly
> calling ‘python2’ or ‘python3’ as commands.
>

Agreed. And on Windows, the "py -3" or "py -2" options are also available.

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web