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

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

Integers with leading zeroes

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

Contents

  Integers with leading zeroes Steven D'Aprano <steve@pearwood.info> - 2015-07-19 15:39 +1000
    Re: Integers with leading zeroes Ian Kelly <ian.g.kelly@gmail.com> - 2015-07-18 23:46 -0600
    Re: Integers with leading zeroes "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-07-19 10:19 +0200
      Re: Integers with leading zeroes Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-19 12:58 -0700
    Re: Integers with leading zeroes Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-07-21 19:21 +0200
      Re: Integers with leading zeroes sohcahtoa82@gmail.com - 2015-07-21 10:58 -0700
        Re: Integers with leading zeroes Emile van Sebille <emile@fenx.com> - 2015-07-21 11:06 -0700
          Re: Integers with leading zeroes sohcahtoa82@gmail.com - 2015-07-21 11:38 -0700
            Re: Integers with leading zeroes sohcahtoa82@gmail.com - 2015-07-21 11:41 -0700
      Re: Integers with leading zeroes Steven D'Aprano <steve@pearwood.info> - 2015-07-22 10:55 +1000
        Re: Integers with leading zeroes Chris Angelico <rosuav@gmail.com> - 2015-07-22 11:10 +1000
          Re: Integers with leading zeroes Steven D'Aprano <steve@pearwood.info> - 2015-07-22 12:14 +1000
            Re: Integers with leading zeroes Chris Angelico <rosuav@gmail.com> - 2015-07-22 14:16 +1000
            Re: Integers with leading zeroes Laura Creighton <lac@openend.se> - 2015-07-22 09:12 +0200
              Re: Integers with leading zeroes alister <alister.nospam.ware@ntlworld.com> - 2015-07-22 09:09 +0000
                Re: Integers with leading zeroes Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2015-07-22 17:27 +0200
                  Re: Integers with leading zeroes Grant Edwards <invalid@invalid.invalid> - 2015-07-22 15:47 +0000
                Re: Integers with leading zeroes MRAB <python@mrabarnett.plus.com> - 2015-07-22 16:38 +0100
                  Re: Integers with leading zeroes Grant Edwards <invalid@invalid.invalid> - 2015-07-22 15:50 +0000
                    Re: Integers with leading zeroes MRAB <python@mrabarnett.plus.com> - 2015-07-22 17:24 +0100
                Re: Integers with leading zeroes Chris Angelico <rosuav@gmail.com> - 2015-07-23 08:32 +1000
            Re: Integers with leading zeroes Laura Creighton <lac@openend.se> - 2015-07-22 09:31 +0200
            Re: Integers with leading zeroes Ben Finney <ben+python@benfinney.id.au> - 2015-07-22 18:40 +1000
              Re: Integers with leading zeroes Marko Rauhamaa <marko@pacujo.net> - 2015-07-22 12:10 +0300
                Re: Integers with leading zeroes Laura Creighton <lac@openend.se> - 2015-07-22 11:38 +0200
                  Re: Integers with leading zeroes Marko Rauhamaa <marko@pacujo.net> - 2015-07-22 13:26 +0300
              Re: Integers with leading zeroes Grant Edwards <invalid@invalid.invalid> - 2015-07-22 13:51 +0000
                Re: Integers with leading zeroes Rustom Mody <rustompmody@gmail.com> - 2015-07-22 07:03 -0700
                Re: Integers with leading zeroes Steven D'Aprano <steve@pearwood.info> - 2015-07-23 01:14 +1000
                  Re: Integers with leading zeroes Grant Edwards <invalid@invalid.invalid> - 2015-07-22 15:20 +0000
                Re: Integers with leading zeroes Michael Torrie <torriem@gmail.com> - 2015-07-22 20:11 -0600
                  Re: Integers with leading zeroes Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-07-24 18:23 +1200
                    Re: Integers with leading zeroes Chris Angelico <rosuav@gmail.com> - 2015-07-24 16:28 +1000
                  Re: Integers with leading zeroes alister <alister.nospam.ware@ntlworld.com> - 2015-07-24 13:16 +0000

Page 1 of 2  [1] 2  Next page →

#94095 — Integers with leading zeroes

In Python 2, integer literals with leading zeroes are treated as octal, so
09 is a syntax error and 010 is 8.

This is confusing to those not raised on C-style octal literals, so in
Python 3 leading zeroes are prohibited in int literals. Octal is instead
written using the prefix 0o, similar to hex 0x and binary 0b.

Consequently Python 3 makes both 09 and 010 a syntax error.

However there is one exception: zero itself is allowed any number of leading
zeroes, so 00000 is a legal way to write zero as a base-10 int literal.

Does anyone use that (mis)feature?



-- 
Steven

[toc] | [next] | [standalone]

#94096

On Sat, Jul 18, 2015 at 11:39 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> In Python 2, integer literals with leading zeroes are treated as octal, so
> 09 is a syntax error and 010 is 8.
>
> This is confusing to those not raised on C-style octal literals, so in
> Python 3 leading zeroes are prohibited in int literals. Octal is instead
> written using the prefix 0o, similar to hex 0x and binary 0b.
>
> Consequently Python 3 makes both 09 and 010 a syntax error.
>
> However there is one exception: zero itself is allowed any number of leading
> zeroes, so 00000 is a legal way to write zero as a base-10 int literal.

It's obviously a base-8 literal, not a base-10 literal. :-P

> Does anyone use that (mis)feature?

I don't, but why should it matter?

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

#94105

Don't be noob ? ;)

Always remove leading zeroes ?

One case that comes to mind is ASCII art like code... where programmer may 
want to align numbers for clearity:

0014324
0234545
0000345
0534543

^ That could be a problem but possibly solveable with spaces instead:

  14324
234545
    345
534543

^ Looks less good though in non-fixed-sized font.

Bye,
  Skybuck.

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

#94157

On Sunday, July 19, 2015 at 3:19:01 AM UTC-5, Skybuck Flying wrote: 
>   14324
> 234545
>     345
> 534543
> 
> ^ Looks less good though in non-fixed-sized font.

The obvious solution is to use a fixed width font. If you're
inserting syntactical noise simply to maintain readability
in variable width fonts, then you may want to reconsider the
practicality of such a font. Readability counts. And errors 
(even mental errors) should never pass silently.

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

#94301

On 07/19/2015 07:39 AM, Steven D'Aprano wrote:
> In Python 2, integer literals with leading zeroes are treated as octal, so
> 09 is a syntax error and 010 is 8.
> 
> This is confusing to those not raised on C-style octal literals, so in
> Python 3 leading zeroes are prohibited in int literals. Octal is instead
> written using the prefix 0o, similar to hex 0x and binary 0b.
> 
> Consequently Python 3 makes both 09 and 010 a syntax error.
> 
> However there is one exception: zero itself is allowed any number of leading
> zeroes, so 00000 is a legal way to write zero as a base-10 int literal.
> 
> Does anyone use that (mis)feature?
> 

Yes. I like to sometime write numbers with leading zeros.
Sometimes these numbers represent codeblocks of a fixed
number of digits. Always writing those numbers with this
number of digits helps being aware of this. It is also
easier for when you need to know how many leading zero's
such a number has.

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

#94307

On Tuesday, July 21, 2015 at 10:22:44 AM UTC-7, Antoon Pardon wrote:
> On 07/19/2015 07:39 AM, Steven D'Aprano wrote:
> > In Python 2, integer literals with leading zeroes are treated as octal, so
> > 09 is a syntax error and 010 is 8.
> > 
> > This is confusing to those not raised on C-style octal literals, so in
> > Python 3 leading zeroes are prohibited in int literals. Octal is instead
> > written using the prefix 0o, similar to hex 0x and binary 0b.
> > 
> > Consequently Python 3 makes both 09 and 010 a syntax error.
> > 
> > However there is one exception: zero itself is allowed any number of leading
> > zeroes, so 00000 is a legal way to write zero as a base-10 int literal.
> > 
> > Does anyone use that (mis)feature?
> > 
> 
> Yes. I like to sometime write numbers with leading zeros.
> Sometimes these numbers represent codeblocks of a fixed
> number of digits. Always writing those numbers with this
> number of digits helps being aware of this. It is also
> easier for when you need to know how many leading zero's
> such a number has.

IMO, leading zeroes just looks like visual noise, and if I wanted to align numbers, I'd just use spaces.

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

#94308

On 7/21/2015 10:58 AM, sohcahtoa82@gmail.com wrote:
>
> IMO, leading zeroes just looks like visual noise, and if I wanted to align numbers, I'd just use spaces.
>

Aligning numbers using spaces doesn't always align -- using zeros does.

Emile

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

#94309

On Tuesday, July 21, 2015 at 11:07:43 AM UTC-7, Emile van Sebille wrote:
> On 7/21/2015 10:58 AM, sohcahtoa82@gmail.com wrote:
> >
> > IMO, leading zeroes just looks like visual noise, and if I wanted to align numbers, I'd just use spaces.
> >
> 
> Aligning numbers using spaces doesn't always align -- using zeros does.
> 
> Emile

You've got me confused.  They should align just fine if you're using a fixed-width font.

If you're not using a fixed-width font in your programming, then I don't know what to say to you.

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

#94310

On Tuesday, July 21, 2015 at 11:38:53 AM UTC-7, sohca...@gmail.com wrote:
> On Tuesday, July 21, 2015 at 11:07:43 AM UTC-7, Emile van Sebille wrote:
> > On 7/21/2015 10:58 AM, sohcahtoa82@gmail.com wrote:
> > >
> > > IMO, leading zeroes just looks like visual noise, and if I wanted to align numbers, I'd just use spaces.
> > >
> > 
> > Aligning numbers using spaces doesn't always align -- using zeros does.
> > 
> > Emile
> 
> You've got me confused.  They should align just fine if you're using a fixed-width font.
> 
> If you're not using a fixed-width font in your programming, then I don't know what to say to you.

I should probably state that I may use leading zeroes when using hexadecimal numbers.  For example, I might write 0x000ABCDE, rather than 0xABCDE, but that's only if I'm using a lot of 32-bit values.  If I only care about a single byte, I will use 0x01, for example.

But for base-10, I would never use leading zeroes.

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

#94332

On Wed, 22 Jul 2015 03:21 am, Antoon Pardon wrote:

> On 07/19/2015 07:39 AM, Steven D'Aprano wrote:
>> In Python 2, integer literals with leading zeroes are treated as octal,
>> so 09 is a syntax error and 010 is 8.
>> 
>> This is confusing to those not raised on C-style octal literals, so in
>> Python 3 leading zeroes are prohibited in int literals. Octal is instead
>> written using the prefix 0o, similar to hex 0x and binary 0b.
>> 
>> Consequently Python 3 makes both 09 and 010 a syntax error.
>> 
>> However there is one exception: zero itself is allowed any number of
>> leading zeroes, so 00000 is a legal way to write zero as a base-10 int
>> literal.
>> 
>> Does anyone use that (mis)feature?
>> 
> 
> Yes. I like to sometime write numbers with leading zeros.

In Python 2, those numbers will be in octal:

nums = [0000, 0001, 0002, 0003, 
        0004, 0005, 0006, 0007, 
        # 0008 and 0009 are syntax errors
        0010, ... ]


In Python 3, using leading zeroes is always a syntax error, unless all the
numbers are zero:

# Okay
nums = [0000, 0000, 0000, 0000, ... ]

# Fails
nums = [0000, 0001, 0002, 0003, ...]


I'm not interested in the Python 2 case with octal numbers. Can you show an
example of how you would use this in Python 3? Or at least explain what
benefit you get from typing out a block of all zeroes by hand, instead of
(say) this?

nums = [0]*10


> Sometimes these numbers represent codeblocks of a fixed
> number of digits. Always writing those numbers with this
> number of digits helps being aware of this. It is also
> easier for when you need to know how many leading zero's
> such a number has.

I'm not sure what you mean here. Python ints don't have a fixed number of
digits.



-- 
Steven

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

#94336

On Wed, Jul 22, 2015 at 10:55 AM, Steven D'Aprano <steve@pearwood.info> wrote:
>> Sometimes these numbers represent codeblocks of a fixed
>> number of digits. Always writing those numbers with this
>> number of digits helps being aware of this. It is also
>> easier for when you need to know how many leading zero's
>> such a number has.
>
> I'm not sure what you mean here. Python ints don't have a fixed number of
> digits.

Sometimes your numbers carry specific payloads or structures. A few examples:

Date: 20150722 [decimal]
Unix permissions: 10777 [octal]
MAC address: 0014a466fba9 [hex]

In the MAC address example, it doesn't make sense to elide the leading
zeroes. I can't currently think of a common, real-world example that
uses decimal and isn't gong to push itself to the full eight digits,
apart from Northern Territory postcodes with their silly 08nn pattern,
but I'm sure they exist.

ChrisA

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

#94340

On Wed, 22 Jul 2015 11:10 am, Chris Angelico wrote:

> On Wed, Jul 22, 2015 at 10:55 AM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>>> Sometimes these numbers represent codeblocks of a fixed
>>> number of digits. Always writing those numbers with this
>>> number of digits helps being aware of this. It is also
>>> easier for when you need to know how many leading zero's
>>> such a number has.
>>
>> I'm not sure what you mean here. Python ints don't have a fixed number of
>> digits.
> 
> Sometimes your numbers carry specific payloads or structures. A few
> examples:
> 
> Date: 20150722 [decimal]
> Unix permissions: 10777 [octal]
> MAC address: 0014a466fba9 [hex]

I don't see the relevance of any of those examples. Only the date is
kinda-sort in decimal, the others are in octal and hex and so need to be
written as octal or hex numbers:

perm = 0o10777  # not 25031 as the above will give
addr = 0x0014a466fba9  # the above will give a syntax error


The date example should be a string, not an integer.

today = 20151231
tomorrow = today + 1
assert tomorrow == 20160101  # fails

I guess you can have 0 as Unix permissions, there might even be a 0 MAC
address, but would you write them in decimal as 0000 (etc.) when all the
other perms and addresses are written in oct or hex?

addresses = [
    0x0014a466fba9, 
    0x0014a00b3fb1, 
    000000000000, 
    0x003744a9012a, 
    ]


> In the MAC address example, it doesn't make sense to elide the leading
> zeroes. I can't currently think of a common, real-world example that
> uses decimal and isn't gong to push itself to the full eight digits,
> apart from Northern Territory postcodes with their silly 08nn pattern,
> but I'm sure they exist.

Postcodes, or zip codes, also should be written as strings, even if they
happen to be all digits.

I'm still looking for an example of where somebody would write the int zero
in decimal using more than one 0-digit. While I'm sure they are fascinating
in and of themselves, examples of numbers written as strings, in hex or
octal, non-zero numbers written without leading zeroes, or zero written
with only a single digit don't interest me :-)



-- 
Steven

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

#94343

On Wed, Jul 22, 2015 at 12:14 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Wed, 22 Jul 2015 11:10 am, Chris Angelico wrote:
>
>> On Wed, Jul 22, 2015 at 10:55 AM, Steven D'Aprano <steve@pearwood.info>
>> wrote:
>>>> Sometimes these numbers represent codeblocks of a fixed
>>>> number of digits. Always writing those numbers with this
>>>> number of digits helps being aware of this. It is also
>>>> easier for when you need to know how many leading zero's
>>>> such a number has.
>>>
>>> I'm not sure what you mean here. Python ints don't have a fixed number of
>>> digits.
>>
>> Sometimes your numbers carry specific payloads or structures. A few
>> examples:
>>
>> Date: 20150722 [decimal]
>> Unix permissions: 10777 [octal]
>> MAC address: 0014a466fba9 [hex]
>
> I don't see the relevance of any of those examples. Only the date is
> kinda-sort in decimal, the others are in octal and hex and so need to be
> written as octal or hex numbers:
>
> perm = 0o10777  # not 25031 as the above will give
> addr = 0x0014a466fba9  # the above will give a syntax error

Right, I'm just giving examples of structured numbers. I don't have a
good example of a decimal structured number, but there are good
examples in other bases, and the possibility is there for someone to
have one that makes sense in decimal.

> The date example should be a string, not an integer.
>
> today = 20151231
> tomorrow = today + 1
> assert tomorrow == 20160101  # fails

All that proves is that there are certain operations that don't work
on date-stored-as-integer. The same operations equally won't work on
date-stored-as-string. If you want date arithmetic, you MUST use a
proper date/time library; but if all you want is simple and efficient
comparisons, integers work fine. So do strings, but integers are
right-justified. If you imagine a situation in which it's not dates
with four digit years, but some other starting figure - maybe it's the
year in some arbitrary calendar on which today is the 6th of Cuspis in
the year 411 of the Common Reckoning. Those dates can go back before
year 100, so the date numbers would lose a digit compared to today's
4110206. Hence it's useful to be able to right-justify them.

Dates aren't a great example (because good date/time libraries do
exist), but they're more universally understood than domain-specific
examples.

> I guess you can have 0 as Unix permissions, there might even be a 0 MAC
> address, but would you write them in decimal as 0000 (etc.) when all the
> other perms and addresses are written in oct or hex?
>
> addresses = [
>     0x0014a466fba9,
>     0x0014a00b3fb1,
>     000000000000,
>     0x003744a9012a,
>     ]

Right, so those aren't ideal examples either, because they're not decimal.

> Postcodes, or zip codes, also should be written as strings, even if they
> happen to be all digits.

Hmm, maybe. I'm on the fence about that one. Of course, most of the
time, I advocate a single multi-line text field "Address", and let
people key them in free-form. No postcode field whatsoever.

> I'm still looking for an example of where somebody would write the int zero
> in decimal using more than one 0-digit. While I'm sure they are fascinating
> in and of themselves, examples of numbers written as strings, in hex or
> octal, non-zero numbers written without leading zeroes, or zero written
> with only a single digit don't interest me :-)

Frankly, I'm in broad agreement: using 00000000000 to represent 0
isn't particularly useful, given that 0001 is an error. But since
C-like languages (and Py2) use the leading zero to mean octal, and
mathematics ignores the leading zero, there's no way to avoid
confusing people other than by having an instant error. There's
probably code out there that uses 000 to mean 0, but personally, I
wouldn't be against deprecating it.

One thing that's really REALLY annoying is running into something that
uses virtually the same syntax to mean something almost, but not
entirely, identical... and completely incompatible. If Py3 allowed
0009 to mean 9, we would have nightmares all over the place, even
without Py2/Py3 conversion. Unadorned octal still shows up in one
place in Py3, and that's string escapes:

>>> "\33"
'\x1b'
>>> b"\33"
b'\x1b'

I hope this *never* gets changed to decimal or hex. If it's considered
a problem, the only solution is to excise it altogether. Please do NOT
do what BIND9 did, and have "\033" mean 33 decimal... it bugged me no
end when I tried to move some binary around between DNS and other
systems...

ChrisA

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

#94349

The biggest use I have for decimal numbers that begin with 0 is in
credit card numbers, account numbers and the like where the first
check you do is 'does this thing have the correct number of digits'.
So far, all the examples I've been able to find in my code -- which
does this sort of stuff a lot -- is looking at string versions of
decimal numbers, but I suspect there is old code out there in the
wild which just used integers.

Laura

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

#94356

On Wed, 22 Jul 2015 09:12:59 +0200, Laura Creighton wrote:

> The biggest use I have for decimal numbers that begin with 0 is in
> credit card numbers, account numbers and the like where the first check
> you do is 'does this thing have the correct number of digits'.
> So far, all the examples I've been able to find in my code -- which does
> this sort of stuff a lot -- is looking at string versions of decimal
> numbers, but I suspect there is old code out there in the wild which
> just used integers.
> 
> Laura

This type of information should be stored as a string not any type of 
numeric format, if you are not performing maths on it then it is a string 
& not a number.

anyone doing anything else is heading or the front page on 
www.thedailywtf.com :-)



-- 
Everybody likes a kidder, but nobody lends him money.
		-- Arthur Miller

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

#94374

On 07/22/2015 11:09 AM, alister wrote:
> On Wed, 22 Jul 2015 09:12:59 +0200, Laura Creighton wrote:
> 
>> The biggest use I have for decimal numbers that begin with 0 is in
>> credit card numbers, account numbers and the like where the first check
>> you do is 'does this thing have the correct number of digits'.
>> So far, all the examples I've been able to find in my code -- which does
>> this sort of stuff a lot -- is looking at string versions of decimal
>> numbers, but I suspect there is old code out there in the wild which
>> just used integers.
>>
>> Laura
> 
> This type of information should be stored as a string not any type of 
> numeric format, if you are not performing maths on it then it is a string 
> & not a number.

Does the same condition hold for strings? If you are not performing string
operations on something, it is not a string?

-- 
Antoon Pardon.

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

#94376

On 2015-07-22, Antoon Pardon <antoon.pardon@rece.vub.ac.be> wrote:

> Does the same condition hold for strings? If you are not performing string
> operations on something, it is not a string?

If you never need to do any string operations on it then you should
not be using a string.

-- 
Grant Edwards               grant.b.edwards        Yow! The PINK SOCKS were
                                  at               ORIGINALLY from 1952!!
                              gmail.com            But they went to MARS
                                                   around 1953!!

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

#94375

On 2015-07-22 16:27, Antoon Pardon wrote:
> On 07/22/2015 11:09 AM, alister wrote:
>> On Wed, 22 Jul 2015 09:12:59 +0200, Laura Creighton wrote:
>>
>>> The biggest use I have for decimal numbers that begin with 0 is in
>>> credit card numbers, account numbers and the like where the first check
>>> you do is 'does this thing have the correct number of digits'.
>>> So far, all the examples I've been able to find in my code -- which does
>>> this sort of stuff a lot -- is looking at string versions of decimal
>>> numbers, but I suspect there is old code out there in the wild which
>>> just used integers.
>>>
>>> Laura
>>
>> This type of information should be stored as a string not any type of
>> numeric format, if you are not performing maths on it then it is a string
>> & not a number.
>
> Does the same condition hold for strings? If you are not performing string
> operations on something, it is not a string?
>
Tkinter comes to mind. You specify how widgets are laid out strings
that are basically flags:

     text_widget.pack(side=LEFT, fill=BOTH, expand=YES)

where LEFT, BOTH and YES are strings.

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

#94377

On 2015-07-22, MRAB <python@mrabarnett.plus.com> wrote:
> On 2015-07-22 16:27, Antoon Pardon wrote:
>
>> Does the same condition hold for strings? If you are not performing string
>> operations on something, it is not a string?
>
> Tkinter comes to mind. You specify how widgets are laid out strings
> that are basically flags:
>
>      text_widget.pack(side=LEFT, fill=BOTH, expand=YES)
>
> where LEFT, BOTH and YES are strings.

That's Tcl's fault.  They have to be passed to Tcl, and Tcl only has
one data type: strings.

-- 
Grant Edwards               grant.b.edwards        Yow! An INK-LING?  Sure --
                                  at               TAKE one!!  Did you BUY any
                              gmail.com            COMMUNIST UNIFORMS??

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

#94379

On 2015-07-22 16:50, Grant Edwards wrote:
> On 2015-07-22, MRAB <python@mrabarnett.plus.com> wrote:
>> On 2015-07-22 16:27, Antoon Pardon wrote:
>>
>>> Does the same condition hold for strings? If you are not performing string
>>> operations on something, it is not a string?
>>
>> Tkinter comes to mind. You specify how widgets are laid out strings
>> that are basically flags:
>>
>>      text_widget.pack(side=LEFT, fill=BOTH, expand=YES)
>>
>> where LEFT, BOTH and YES are strings.
>
> That's Tcl's fault.  They have to be passed to Tcl, and Tcl only has
> one data type: strings.
>
But _I'm_ writing in Python. Do I have to know how Tcl works underneath?

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web