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 4 of 4 — ← Prev page 1 2 3 [4]

#89689

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

When in Rome, do as the Romans do.

Besides: there probably is a reason for the Pythonic way.

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

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

#89690

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 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 :)
>
> When in Rome, do as the Romans do.
>
> Besides: there probably is a reason for the Pythonic way.
>

No probably about it, the threat of the Comfy Chair...

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

#89733

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 Pythonic way.

You maybe surprised, then, by how many people that stop by this list
wanting to program Java, C# or C++ in Python and get frustrated and
upset when the list tries to steer them in a Pythonic direction.  Most
of them leave upset and never return to the list or Python.

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

#89738

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 do.
>>
>> Besides: there probably is a reason for the Pythonic way.
>
> You maybe surprised, then, by how many people that stop by this list
> wanting to program Java, C# or C++ in Python and get frustrated and
> upset when the list tries to steer them in a Pythonic direction.
> Most of them leave upset and never return to the list or Python.

I am not really surprised. I know that this is how it often works. :-(
But I like to be different. :-D

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

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

#89655

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.

On what OS? If I try something similar on Win-8.1
and CPython 2.7.5 (32-bit):

  python -c "for i in range(int(1E9)): pass"
   Traceback (most recent call last):
     File "<string>", line 1, in <module>
   MemoryError


--gv

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

#89656

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 those programs more slowly. Is there a
>> way to circumvent Python claiming all the memory?
>>
>> By the way: this is CPython 2.7.8.
> 
> On what OS? If I try something similar on Win-8.1 and CPython 2.7.5
> (32-bit):
> 
>   python -c "for i in range(int(1E9)): pass"
>    Traceback (most recent call last):
>      File "<string>", line 1, in <module>
>    MemoryError
> 
> 
> --gv

also MemoryError on Fedora 21 32 bit




-- 
I am a traffic light, and Alan Ginzberg kidnapped my laundry in 1927!

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

#89658

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 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.
>>
>> On what OS? If I try something similar on Win-8.1 and CPython 2.7.5
>> (32-bit):
>>
>>    python -c "for i in range(int(1E9)): pass"
>>     Traceback (most recent call last):
>>       File "<string>", line 1, in <module>
>>     MemoryError
>>
>>
>> --gv
>
> also MemoryError on Fedora 21 32 bit
>

That's presumably because you end up running out of address space before 
you run out of swap space.  On a 64 bit system the reverse will be true, 
unless you have a really *really* large swap file

ulimit is your friend if you've got a program that wants to gobble up 
all of swap space.

-- 
DaveA

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

#89669

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 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.
>>>
>>> On what OS? If I try something similar on Win-8.1 and CPython
>>> 2.7.5 (32-bit):
>>>
>>> python -c "for i in range(int(1E9)): pass"
>>> Traceback (most recent call last):
>>> File "<string>", line 1, in <module>
>>> MemoryError
>>>
>>>
>>> --gv
>>
>> also MemoryError on Fedora 21 32 bit
>>
>
> That's presumably because you end up running out of address space
> before you run out of swap space. On a 64 bit system the reverse
> will be true, unless you have a really *really* large swap file
>
> 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:
    core file size          (blocks, -c) 0
    data seg size           (kbytes, -d) unlimited
    scheduling priority             (-e) 0
    file size               (blocks, -f) unlimited
    pending signals                 (-i) 63768
    max locked memory       (kbytes, -l) 64
    max memory size         (kbytes, -m) unlimited
    open files                      (-n) 1024
    pipe size            (512 bytes, -p) 8
    POSIX message queues     (bytes, -q) 819200
    real-time priority              (-r) 0
    stack size              (kbytes, -s) 8192
    cpu time               (seconds, -t) unlimited
    max user processes              (-u) 63768
    virtual memory          (kbytes, -v) unlimited
    file locks                      (-x) unlimited

That should be fine-tuned.

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

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

#89677

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 memory size         (kbytes, -m) unlimited

Note that AFAIK, "ulimit -m" doesn't work on Linux

http://unix.stackexchange.com/questions/129587/does-ulimit-m-not-work-on-modern-linux

Based on some quick testing[1], it doesn't appear to work on OpenBSD
or FreeBSD either.

-tkc


[1]
My test was to perform the following:

1) seq 20 > data.txt # to generate some random date

2) ed data.txt

3) find the PID of the "ed" process from another window using "ps ax
| grep ed"

4) make note of the current memory used for that PID using "top -p
$PID"

5) issue ",t$" in ed until the memory-used jumps up in the "top"
window (this copies the entire file to the bottom of the file,
doubling the size each time)

6) quit ed without saving ("Q")

7) issue "ulimit -m", specifying a threshold between the
before-the-memory-jump and after-the-memory-jump values

8) repeat steps 2-5 until the memory jumps up in top.  Notice that
it's possible to do this multiple times and exceed the "ulimit -m"
threshold, something the ulimit should prevent.




.

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

#89697

Op Thursday 30 Apr 2015 23:41 CEST schreef Tim Chase:

> 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 memory size         (kbytes, -m) unlimited
>
> Note that AFAIK, "ulimit -m" doesn't work on Linux
>
> http://unix.stackexchange.com/questions/129587/does-ulimit-m-not-work-on-modern-linux
>
> Based on some quick testing[1], it doesn't appear to work on OpenBSD
> or FreeBSD either.

Yes, as I already found out you need to use -v. But it would be nice
that there was an indication that -m is obsolete.

Depending on the available memory you could use something like:
    ulimit -v $((4 * 1024 * 1024))

I can then do:
    l = range(int(1E8))
but:
    l = 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 Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

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

#89691

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 better, a meaningful name.

Rather than convert a float 1E9 to an int at runtime, better to use an int:

range(10**9)


With recent versions of CPython, the compiler has a keyhole optimiser which
does constant folding. For implementations of Python which don't do
constant folding, 10**9 is likely to be faster than int(1E9) -- but even if
it isn't, does it matter? It will be very fast one way of the other. The
important thing is that 10**9 expresses the intention to use an integer in
a more direct fashion than using 1E9.



-- 
Steven

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

#89694

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.


> Don't use "l" as a variable name, as it looks too much like 1.
> Better to use L, or even better, a meaningful name.
>
> Rather than convert a float 1E9 to an int at runtime, better to use
> an int:
>
> range(10**9)
>
>
> With recent versions of CPython, the compiler has a keyhole
> optimiser which does constant folding. For implementations of Python
> which don't do constant folding, 10**9 is likely to be faster than
> int(1E9) -- but even if it isn't, does it matter? It will be very
> fast one way of the other. The important thing is that 10**9
> expresses the intention to use an integer in a more direct fashion
> than using 1E9.

It was just a short hack to show the problem. In real code I would
never use l. But I'll remember to use 10**9 instead of 1E9.

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

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

#89801

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 digit), so it's a 
given that it's an 'l'.

http://fontsgeek.com/fonts/DejaVu-Sans-Mono-Book
Type (or copy, paste) "ll111l" into the little box below the preview 
image.


 /Grrr
-- 
          ___                  ___
 (\_--_/)  | _ ._    _|_|_  _   |o _  _ ._
 ( 9  9 )  |(_)| |\/  |_| |(/_  ||(_|(/_|
 stripes are forever - as overripe ferrets

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

#89803

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 can it be a single digit), so it's a
> given that it's an 'l'.

Of course it can be a single digit. You're assuming that the person
reading the code already somehow knows that this is a variable name
and not an integer literal.

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

#89852

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 digit), so it's a
> given that it's an 'l'.

How do you know its a variable?

x+1

Is that 1 the constant or l the variable?

Yes, "use a better font" is good advice, if you can -- you don't always have
control over the machine you are working on, and the fonts which you have
access to -- but even with a better font, they still look two similar for
comfort. It's just common sense[1] to avoid easily confusable names
whenever possible:

advice = 23
advise = 23
makenewhttpfactorywidgetcreator = True
makenewhttpfactoryuidgetcreator = False

regardless of how awesome your font is. Unless you're spelling out each word
letter by letter, sometimes you will misread words.

Another one is rn versus m, especially at small text sizes, or if you're
silly or unlucky enough to be using Arial.




[1] So rare it's a superpower:

http://i0.wp.com/lolzombie.com/wp-content/uploads/2010/10/8eqf.jpeg




-- 
Steven

[toc] | [prev] | [standalone]

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

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

csiph-web