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

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

Tabs -vs- Spaces: Tabs should have won.

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

Contents

  Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-16 09:51 -0700
    Re: feeding the troll (was: Tabs -vs- Spaces: Tabs should have won.) Tim Chase <python.list@tim.thechases.com> - 2011-07-16 12:52 -0500
    Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-16 17:59 -0500
    Re: Tabs -vs- Spaces: Tabs should have won. Tim Roberts <timr@probo.com> - 2011-07-16 16:06 -0700
      Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 02:29 -0500
        Re: Tabs -vs- Spaces: Tabs should have won. Tim Roberts <timr@probo.com> - 2011-07-18 22:36 -0700
      Re: Tabs -vs- Spaces: Tabs should have won. Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-17 01:39 -0600
    Re: Tabs -vs- Spaces: Tabs should have won. Cameron Simpson <cs@zip.com.au> - 2011-07-17 09:52 +1000
      Re: Tabs -vs- Spaces: Tabs should have won. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-17 13:09 +1000
        Re: Tabs -vs- Spaces: Tabs should have won. anand jeyahar <anand.ibmgsi@gmail.com> - 2011-07-17 09:29 +0530
        Re: Tabs -vs- Spaces: Tabs should have won. Cameron Simpson <cs@zip.com.au> - 2011-07-17 14:12 +1000
        Re: Tabs -vs- Spaces: Tabs should have won. Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-17 01:32 -0600
          Re: Tabs -vs- Spaces: Tabs should have won. TheSaint <no@nowhere.net.no> - 2011-07-17 21:12 +0800
          Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 08:15 -0700
            Re: Tabs -vs- Spaces: Tabs should have won. Tim Chase <python.list@tim.thechases.com> - 2011-07-17 13:22 -0500
              Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 12:49 -0700
            Re: Tabs -vs- Spaces: Tabs should have won. Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-17 12:48 -0600
              Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 12:54 -0700
                Re: Tabs -vs- Spaces: Tabs should have won. Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-17 16:02 -0600
                  Re: Tabs -vs- Spaces: Tabs should have won. Roy Smith <roy@panix.com> - 2011-07-17 19:29 -0400
                    Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 18:55 -0500
                      Re: Tabs -vs- Spaces: Tabs should have won. Roy Smith <roy@panix.com> - 2011-07-17 20:28 -0400
                        Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 19:48 -0500
                        Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 19:50 -0500
                          Re: Tabs -vs- Spaces: Tabs should have won. Mel <mwilson@the-wire.com> - 2011-07-17 21:06 -0400
                          Re: Tabs -vs- Spaces: Tabs should have won. Mel <mwilson@the-wire.com> - 2011-07-17 21:06 -0400
                    Re: Tabs -vs- Spaces: Tabs should have won. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-18 11:01 +1000
                      Re: Tabs -vs- Spaces: Tabs should have won. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-18 11:12 +1000
                        Re: Tabs -vs- Spaces: Tabs should have won. Ben Finney <ben+python@benfinney.id.au> - 2011-07-18 11:42 +1000
                        Re: Tabs -vs- Spaces: Tabs should have won. Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-18 18:26 +1200
                      Re: Tabs -vs- Spaces: Tabs should have won. Tim Chase <python.list@tim.thechases.com> - 2011-07-18 05:52 -0500
                        Re: Tabs -vs- Spaces: Tabs should have won. Duncan Booth <duncan.booth@invalid.invalid> - 2011-07-18 13:52 +0000
                          Re: Tabs -vs- Spaces: Tabs should have won. MRAB <python@mrabarnett.plus.com> - 2011-07-18 17:59 +0100
                          Re: Tabs -vs- Spaces: Tabs should have won. Roy Smith <roy@panix.com> - 2011-07-18 19:07 -0400
                        Re: Tabs -vs- Spaces: Tabs should have won. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-19 00:59 +1000
                          Re: Tabs -vs- Spaces: Tabs should have won. Dave Angel <davea@ieee.org> - 2011-07-18 13:11 -0400
                      Re: Tabs -vs- Spaces: Tabs should have won. python@bdurham.com - 2011-07-18 08:33 -0400
                      Re: Tabs -vs- Spaces: Tabs should have won. gene heskett <gheskett@wdtv.com> - 2011-07-18 10:12 -0400
                    Re: Tabs -vs- Spaces: Tabs should have won. tinnews@isbd.co.uk - 2011-07-18 10:49 +0100
                    Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-18 21:51 +0300
                    Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-18 14:06 -0500
                    Re: Tabs -vs- Spaces: Tabs should have won. Chris Angelico <rosuav@gmail.com> - 2011-07-19 05:15 +1000
        Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 02:52 -0500
        Re: Tabs -vs- Spaces: Tabs should have won. "Anders J. Munch" <2011@jmunch.dk> - 2011-07-17 11:49 +0200
          Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 09:53 -0700
            Re: Tabs -vs- Spaces: Tabs should have won. Chris Angelico <rosuav@gmail.com> - 2011-07-18 03:11 +1000
              Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 10:57 -0700
                Re: Tabs -vs- Spaces: Tabs should have won. Chris Angelico <rosuav@gmail.com> - 2011-07-18 04:09 +1000
                Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 20:20 +0200
                  Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 12:22 -0700
                  Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-17 22:38 +0300
                Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-17 22:36 +0300
              Re: Tabs -vs- Spaces: Tabs should have won. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-18 10:54 +1000
                Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 20:26 -0500
                Re: Tabs -vs- Spaces: Tabs should have won. Teemu Likonen <tlikonen@iki.fi> - 2011-07-18 09:00 +0300
            Re: Tabs -vs- Spaces: Tabs should have won. Cameron Simpson <cs@zip.com.au> - 2011-07-18 08:14 +1000
          Re: Tabs -vs- Spaces: Tabs should have won. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-17 21:44 +0200
            Re: Tabs -vs- Spaces: Tabs should have won. "Anders J. Munch" <2011@jmunch.dk> - 2011-07-18 20:19 +0200
          Re: Tabs -vs- Spaces: Tabs should have won. Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-18 10:06 +1200
            Re: Tabs -vs- Spaces: Tabs should have won. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-18 18:58 +0200
    Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-16 19:29 -0500
      Re: Tabs -vs- Spaces: Tabs should have won. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-17 13:07 +1000
        Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-16 22:20 -0500
      Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 09:56 +0200
        Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 03:36 -0500
          Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 11:33 +0200
            Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 05:02 -0500
              Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 12:42 +0200
                Re: Tabs -vs- Spaces: Tabs should have won. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-17 14:35 +0200
                  Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 17:03 +0200
                    Re: Tabs -vs- Spaces: Tabs should have won. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-17 21:10 +0200
                Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 09:46 -0700
                  Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 18:21 -0500
    Re: Tabs -vs- Spaces: Tabs should have won. Chris Angelico <rosuav@gmail.com> - 2011-07-17 10:31 +1000
    Re: Tabs -vs- Spaces: Tabs should have won. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-07-16 19:27 -0700
    Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 09:35 +0200
      Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 09:29 -0700
        Re: Tabs -vs- Spaces: Tabs should have won. Chris Angelico <rosuav@gmail.com> - 2011-07-18 02:50 +1000
        Re: Tabs -vs- Spaces: Tabs should have won. Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-17 12:54 -0600
          Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 13:12 -0700
            Re: Tabs -vs- Spaces: Tabs should have won. Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-17 16:39 -0600
            Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 18:18 -0500
    Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-17 11:15 +0300
      Re: Tabs -vs- Spaces: Tabs should have won. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-17 14:53 +0200
        Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-17 22:26 +0300
          Re: Tabs -vs- Spaces: Tabs should have won. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-17 21:53 +0200
            Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-17 23:46 +0300
    Re: Tabs -vs- Spaces: Tabs should have won. Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-17 03:35 -0500
    Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-17 14:11 +0300
      Re: Tabs -vs- Spaces: Tabs should have won. rusi <rustompmody@gmail.com> - 2011-07-17 04:21 -0700
      Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 13:51 +0200
        Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-17 22:20 +0300
          Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 21:34 +0200
            Re: Tabs -vs- Spaces: Tabs should have won. rantingrick <rantingrick@gmail.com> - 2011-07-17 13:22 -0700
    Re: Tabs -vs- Spaces: Tabs should have won. gene heskett <gheskett@wdtv.com> - 2011-07-17 10:29 -0400
      Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-17 17:10 +0200
        Re: Tabs -vs- Spaces: Tabs should have won. Corey Richardson <kb1pkl@aim.com> - 2011-07-17 12:28 -0400
        Re: Tabs -vs- Spaces: Tabs should have won. Anssi Saari <as@sci.fi> - 2011-07-18 19:28 +0300
          Re: Tabs -vs- Spaces: Tabs should have won. Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-07-18 18:51 +0200
          Re: Tabs -vs- Spaces: Tabs should have won. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-18 19:07 +0200
      Re: Tabs -vs- Spaces: Tabs should have won. "Waldek M." <wm@localhost.localdomain> - 2011-07-17 21:39 +0200
    Re: Tabs -vs- Spaces: Tabs should have won. Dotan Cohen <dotancohen@gmail.com> - 2011-07-17 22:28 +0300
    Re: Tabs -vs- Spaces: Tabs should have won. gene heskett <gheskett@wdtv.com> - 2011-07-17 20:35 -0400

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

#9662

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On 2011.07.16 06:52 PM, Cameron Simpson wrote:
> Only for leading indentation, not following indentation. Consider 
> docstrings and other stuff with embedded fixed witdh layout.
I try to avoid aligning things unless not doing it really hurts
readability for that reason. For example, in most of my source files, I
use tabs to indent. Since Python won't allow a mix of tabs and spaces
(for whitespace) on one line, I don't try to align things:

		else:
			self.x264_cmd = [
				self.x264_exe, self.avs_file,
				'--fps', self.fpsr,
				'--sar', self.sar,
				'--crf', self.crf,
				'--level', self.level,
				'--keyint', self.ki,
				'--min-keyint', self.minki,
				'--ref', self.ref,
				'--weightp', self.weightp,
				'--bframes', self.bframes,
				'--b-adapt', self.badapt,
				'--me', self.me,
				'--merange', self.merange,
				'--direct', self.direct,
				'--trellis', self.trellis,
				'--subme', self.subme,
				'--deblock', self.deblock,
				'--output', self.video_output
				]

But it's still very readable.

However, when alignment really matters, such as in a module's setup.py,
spaces are the way to go:

from distutils.core import setup

setup(
    name         = 'Elucidation',
    version      = '0.0.1-WIP',
    py_modules   = ['elucidation'],
    author       = 'Andrew Berg',
    author_email = 'bahamut@digital-signal.net',
    url          = '',
    platforms    = 'Windows',
    description  = 'Provides a class for storing information on
multimedia files that are to be converted or remuxed and methods to
convert and remux using popular tools.'
    )


Of everything I've read on tabs vs. spaces, this is what makes the most
sense to me:
http://www.iovene.com/61/

- -- 
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAwAGBQJOIizqAAoJEPiOA0Bgp4/Lz3MH/2intDlRrMNNtfnyJF384/yS
+dDptVATyTfFYlEGYhVAc1DZHWC2574ZPlB+rPQd8EnDuawGgFtq0h+5m2oMrWTV
dG+53im/TD3t9vU8ElsQ4gdINV99bw2jASJA2zrFwUS7QWAadqHWfZji1JgJkp+k
BupqXbBWaKZn9tREDbWNeTp3byHD0WFs6ZZp5ZxRxYCMNl4I4YMWgkSQuRmQJRy+
3FuFokUz9uyCQk/pHD9JSQqiB2mkXBLZbXU0V71rTBqGIWe+u0n+DggWAAYNAK5R
U+neKJAfwHfwNcgCI0r56gNl1fWc5cOXzT7HcPW4cErvgsBXOOGicPoxZTZZ05I=
=6w/9
-----END PGP SIGNATURE-----

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

#9669

Andrew Berg wrote:

> I try to avoid aligning things unless not doing it really hurts
> readability for that reason. For example, in most of my source files, I
> use tabs to indent. Since Python won't allow a mix of tabs and spaces
> (for whitespace) on one line, I don't try to align things:
> 
> else:
> self.x264_cmd = [
> self.x264_exe, self.avs_file,
> '--fps', self.fpsr,
> '--sar', self.sar,
[snip rest of code]
> However, when alignment really matters, such as in a module's setup.py,
> spaces are the way to go:
> 
> from distutils.core import setup
> 
> setup(
>     name         = 'Elucidation',
>     version      = '0.0.1-WIP',
[snip]


Hilariously, in my newsreader, the first example (allegedly unaligned) was
lined up as straight as an arrow, while the allegedly aligned second
example was completely jagged and all over the place :)

The perils of proportional fonts.


-- 
Steven

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

#9672

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On 2011.07.16 10:07 PM, Steven D'Aprano wrote:
> Hilariously, in my newsreader, the first example (allegedly
> unaligned) was lined up as straight as an arrow,
It has consistent indentation, but the self.whatever references aren't
aligned.

> The perils of proportional fonts.
Indeed. I have my MUA set up to always send plain text, so I don't think
there's a way I can suggest a font to the recipient (like my favorite
fixed-width font, Courier New).

- -- 
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAwAGBQJOIlToAAoJEPiOA0Bgp4/Lb1MH/R/0RCHYSNpP2cbYG10oPEVI
JTx+u2vnRDJzjlJ2B85mKz3BV/cIO67rV+3tX3C4J272bS5SfmET3QUzprSTLerb
WIAKWL3zJF+VNSPuPI2HMnHepOV61Cjlom0GGf/dOTY/zaQCGdqx3gVy0RljUsV+
xj/ywxsHbV3vbT34b1EtNaSIz+EnzZknd0mTBApNClv9Y+VF5g8pQmPyQ6mJTXuu
8uVS5yxXyH4h5sYpONFzMdPSQdZHFUggmEfUZ3xkJ2OWwJBDtrUrIQIgs2qopIxG
Cx8sM1hg9mkcILN95e9qVkohXAzHl4R6tXSVC+vYj0k4TMM6sj5CowzgorbfpgA=
=YvS2
-----END PGP SIGNATURE-----

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

#9682

* Andrew Berg (Sat, 16 Jul 2011 19:29:30 -0500)
> Of everything I've read on tabs vs. spaces, this is what makes the
> most sense to me:
> http://www.iovene.com/61/

Interesting one, especially the - from the coder's point of view - 
artificial distinction between indentation and alignment.

What is the difference between indentation and alignment? Well, 
indentation works with tabs, alignment not.

The author's conclusion "simply just use what ever you want for 
indenting, but use spaces for aligning" leaves only two choices for 
Python programmers: use spaces for indenting or don't align.

Thorsten

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

#9685

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On 2011.07.17 02:56 AM, Thorsten Kampe wrote:
> What is the difference between indentation and alignment? Well, 
> indentation works with tabs, alignment not.
The use of spaces for indentation is as much of a hack as the use of
tabs for alignment is. Not everyone agrees on how many spaces an indent
should be (whether an indent is a tab or a space-tab), which is a good
reason to use tabs. In fact, spaces have absolutely /no/ advantage over
tabs when it comes to pure indentation. It may be possible to configure
an editor to compensate using space-tabs (and perhaps even detect the
length of indents, changing the number of spaces to conform to what the
reader thinks is the right number of spaces per indent), but this is all
to make a pretty delicate environment just to be even with tabs.
On the flip side, tabs can't maintain alignment because again, not
everyone agrees on how big a tab should be. This is a good reason to use
spaces. Using tabs for indentation and spaces for alignment solves the
problem. I really can't think of any problems this would cause that
aren't superficial.
> The author's conclusion "simply just use what ever you want for 
> indenting, but use spaces for aligning" leaves only two choices for 
> Python programmers: use spaces for indenting or don't align.
It's possible to indent with tabs and align with spaces in Python; see
my earlier post.

- -- 
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAwAGBQJOIp8PAAoJEPiOA0Bgp4/LpjYIAIa+Qpw+1Uhsdv8R3NkH4yat
h7axOgwpq2SqbU9KsJpmJbC737C2JWj3GrCzkSfExjlrG2Wv5qB7U5hgFbJVeTU/
1paBZtXP0BZgXLEeZwlIKJDT3HF28sj7GCMFoP6KhX0v7oe7BsaRyriIBAQWX4Hh
p8NrMfr16tkGQXFmTPyu5UHdiCX35/9ywR1hw96h4H1J6sht1Q6N47Xx4EI4DN/X
eU5wY7qrJPjinYD7N3uQGpRhHKjTIAWRSPxFtN6voP9Y+6KGPH+e2eDFV06h8Hi1
/tPQtbfWROdN1c10TL57FDBqW+Q32gMB3z60/XMPWhB5Mz0a/dFLou5bdDhvtvc=
=w8GN
-----END PGP SIGNATURE-----

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

#9686

* Andrew Berg (Sun, 17 Jul 2011 03:36:31 -0500)
> Not everyone agrees on how many spaces an indent should be (whether an
> indent is a tab or a space-tab), which is a good reason to use tabs.

Not everyone who doesn't agree on indent size actually cares enough 
about indent size - especially in someone else's code. I'd say it's 
probably rather the majority making this whole debate artificial.

I like my indent four spaces. If you like eight, wonderful, I don't 
care, it's your code. If I want to use your code in my own, I completely 
have to reformat your code anyway. And if we work on a project together, 
we have to agree on formatting anyway, the indent size being the least 
important one.

This whole debate is artificial.

> Using tabs for indentation and spaces for alignment solves the
> problem. I really can't think of any problems this would cause that
> aren't superficial.

Sorry, you didn't understand my point. My point is: the distinction 
between indentation and alignment is superficial. Indentation /is/ 
exactly the same as alignment.

Thorsten

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

#9689

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On 2011.07.17 04:33 AM, Thorsten Kampe wrote:
> Not everyone who doesn't agree on indent size actually cares enough 
> about indent size - especially in someone else's code. I'd say it's 
> probably rather the majority making this whole debate artificial.
It's more of a debate on what's good practice when sharing with others
(especially when many developers work together and there are no strict
guidelines enforced, which is not uncommon with large open-source
projects). Obviously, one can completely disregard all guidelines for
writing readable and maintainable code, and no one will care if no one
sees it.

> And if we work on a project together, we have to agree on formatting
> anyway, the indent size being the least important one.
How is indent size unimportant with regard to formatting? Or are you
talking about design as part of formatting?

> This whole debate is artificial.
Only if no one cares about your code. Sometimes that's more or less the
case, and sometimes it isn't. It's also worth mentioning that some
people have an almost religious fervor when it comes to spaces and tabs.
That can make the issue much more relevant than other things that are
more important. Many editors can work around either style (at least in
some sense), so in many circumstances, it is indeed artificial, but
there are other circumstances where it matters a lot (often more than it
should).

> Sorry, you didn't understand my point. My point is: the distinction 
> between indentation and alignment is superficial. Indentation /is/ 
> exactly the same as alignment.
I still don't understand. Whitespace to the left of an assignment to
signify an indent and whitespace around operators to align values (in a
multi-line assignment) are not the same.

- -- 
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAwAGBQJOIrMtAAoJEPiOA0Bgp4/LlHIH/j42a2rms3GDPzAkl8iLZvCq
okJULVeqxAeW4gKFDnPHaagyqqj+d+jbeuEArPU0i3PPEaajCFk/0h53D6tP3lpf
Gt8Iyg5cPjmnUchIuwdI1evSISIJoKU44m2x6W3joDzy+fqHfy14K8wdVV69oTKk
YzUb/5mU2/xyW0ULpOMCQwTSBsbE+bQxPEoULNPoUHR0bglPqgrDkHlFkD6iOVRt
IpL4exPXM8OxKknir7omN7mHNXD2InJqV2QE6nHwirywMxVrWtuIpM4YQ2RhRdES
zfjelskyvp2KOG+VwLxaYmHHbonzRyMJY51w4kw2C7y4nAYzjiN5z4rgLrPyo2w=
=FKP/
-----END PGP SIGNATURE-----

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

#9692

* Andrew Berg (Sun, 17 Jul 2011 05:02:22 -0500)
> > And if we work on a project together, we have to agree on formatting
> > anyway, the indent size being the least important one.
> How is indent size unimportant with regard to formatting?

Take some code or yours and format it with three and with six spaces. 
Then you will see how unimportant it is: it looks virtually the same.

Or as I've written in another posting:
"There is for instance maximum line length, the number of empty lines, 
the author's method of alignment, spaces between the equals sign and so 
on. These are all much more "dominant" in the source code and none of 
this is left for the reader's disposition.

Compare for instance

variable        = 11
anothervariable = 22

def whatever (prettylong     = 1,
              alsoprettylong = 22,
              anotherone     = 33):
    pass

to

variable=11
anothervariable=22
def whatever (prettylong=1, alsoprettylong=22, anotherone=33):
    pass"


> > This whole debate is artificial.
> Only if no one cares about your code.

Only if you don't care about indent length - which I again state, most 
people (probably) don't.

> It's also worth mentioning that some people have an almost religious
> fervor when it comes to spaces and tabs.

I know. These are people like rantingrick who start artificial threads 
like this with artificial problems like tabs versus spaces to liberate 
the common coder.

> > Sorry, you didn't understand my point. My point is: the distinction
> > between indentation and alignment is superficial. Indentation /is/
> > exactly the same as alignment.

> I still don't understand. Whitespace to the left of an assignment to
> signify an indent and whitespace around operators to align values (in
> a multi-line assignment) are not the same.

When I'm (consistently, of course) indenting code, I'm aligning it. When 
I'm aligning code, I do this by indenting it, see for instance...

firstvariable = 11
variable      = 111

firstvariable = 22
variable =      222

The second "=" and the "222" is indented.

Or your example:
setup(
    name         = 'Elucidation',
    version      = '0.0.1-WIP',
    py_modules   = ['elucidation'],
    author       = 'Andrew Berg',
    author_email = 'bahamut@digital-signal.net',
    url          = '',
    platforms    = 'Windows',
    description  = 'Provides a class for storing information on
multimedia files that are to be converted or remuxed and methods to
convert and remux using popular tools.'
    )

The keywords are aligned by indenting. In the "left of an assignment" 
case it makes a difference for the Python compiler, in the alignment 
case it doesn't. In both cases, it makes a difference to the human who 
indents/aligns to group similar things and blocks.

Thorsten

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

#9700

Thorsten Kampe wrote:

> * Andrew Berg (Sun, 17 Jul 2011 05:02:22 -0500)
>> I still don't understand. Whitespace to the left of an assignment to
>> signify an indent and whitespace around operators to align values (in
>> a multi-line assignment) are not the same.
> 
> When I'm (consistently, of course) indenting code, I'm aligning it. When
> I'm aligning code, I do this by indenting it, see for instance...
> 
> firstvariable = 11
> variable      = 111
> 
> firstvariable = 22
> variable =      222
> 
> The second "=" and the "222" is indented.

You might want to check your English dictionary.  Indenting is commonly 
understood in typography as "To begin (a line or lines) at a greater or less 
distance from the margin"¹.  In particular, in computer programming it 
usually means that there is, at most, whitespace on the left of the text.²  
In that sense, the above is _not_ indentation (or indenting), as neither 
"variable" nor "variable =" consist only of whitespace.  It is only 
aligning.³

HTH

_______
¹ <http://en.wiktionary.org/wiki/indenting>
² <http://en.wikipedia.org/wiki/Indent_style>
³ <http://en.wiktionary.org/wiki/aligning>
-- 
PointedEars

Bitte keine Kopien per E-Mail. / Please do not Cc: me.

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

#9708

* Thomas 'PointedEars' Lahn (Sun, 17 Jul 2011 14:35:15 +0200)
> Thorsten Kampe wrote:
> > * Andrew Berg (Sun, 17 Jul 2011 05:02:22 -0500)
> >> I still don't understand. Whitespace to the left of an assignment
> >> to signify an indent and whitespace around operators to align
> >> values (in a multi-line assignment) are not the same.
> > 
> > When I'm (consistently, of course) indenting code, I'm aligning it. When
> > I'm aligning code, I do this by indenting it, see for instance...
> > 
> > firstvariable = 11
> > variable      = 111
> > 
> > firstvariable = 22
> > variable =      222
> > 
> > The second "=" and the "222" is indented.
> 
> You might want to check your English dictionary.  Indenting is commonly 
> understood in typography as "To begin (a line or lines) at a greater or less 
> distance from the margin"¹.  In particular, in computer programming it 
> usually means that there is, at most, whitespace on the left of the text.²  
> In that sense, the above is _not_ indentation (or indenting), as neither 
> "variable" nor "variable =" consist only of whitespace.  It is only 
> aligning.³

*doublesigh* that is actually the point I was trying to make. From a 
programmer's point of view the distinction is artificial because he does 
essentially the same: press the tab key or the indent button to move the 
stuff right from the cursor to the right so it gets aligned with the 
stuff above.

Thorsten

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

#9732

Thorsten Kampe wrote:

> * Thomas 'PointedEars' Lahn (Sun, 17 Jul 2011 14:35:15 +0200)
>> Thorsten Kampe wrote:
>> > * Andrew Berg (Sun, 17 Jul 2011 05:02:22 -0500)
>> >> I still don't understand. Whitespace to the left of an assignment
>> >> to signify an indent and whitespace around operators to align
>> >> values (in a multi-line assignment) are not the same.
>> > 
>> > When I'm (consistently, of course) indenting code, I'm aligning it.
>> > When I'm aligning code, I do this by indenting it, see for instance...
>> > 
>> > firstvariable = 11
>> > variable      = 111
>> > 
>> > firstvariable = 22
>> > variable =      222
>> > 
>> > The second "=" and the "222" is indented.
>> 
>> You might want to check your English dictionary.  Indenting is commonly
>> understood in typography as "To begin (a line or lines) at a greater or
>> less distance from the margin"¹.  In particular, in computer programming
>> it usually means that there is, at most, whitespace on the left of the
>> text.² In that sense, the above is _not_ indentation (or indenting), as
>> neither "variable" nor "variable =" consist only of whitespace.  It is
>> only aligning.³
> 
> *doublesigh* that is actually the point I was trying to make.

Well, you said you would "align code *by indenting*", which is either 
nonsense following the not-so-uncommon definition of "indenting" that I 
presented, or you chose a particularly bad example to make your point
(as it does not feature indentation at all).

> From a programmer's point of view the distinction is artificial because he
> does essentially the same: press the tab key

But he should not, unless he uses the Tab key to insert spaces, because the 
*display width* of the Tab *character* is variable.  *That* is the point!

> or the indent button to move the stuff right from the cursor to the right
> so it gets aligned with the stuff above.

"Indent button"?

-- 
PointedEars

Bitte keine Kopien per E-Mail. / Please do not Cc: me.

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

#9718

On Jul 17, 5:42 am, Thorsten Kampe <thors...@thorstenkampe.de> wrote:

> When I'm (consistently, of course) indenting code, I'm aligning it. When
> I'm aligning code, I do this by indenting it, see for instance...
>
> firstvariable = 11
> variable      = 111
>
> firstvariable = 22
> variable =      222
>
> The second "=" and the "222" is indented.
>
> Or your example:
> setup(
>     name         = 'Elucidation',
>     version      = '0.0.1-WIP',
>     py_modules   = ['elucidation'],
>     author       = 'Andrew Berg',
>     author_email = 'baha...@digital-signal.net',
>     url          = '',
>     platforms    = 'Windows',
>     description  = 'Provides a class for storing information on
> multimedia files that are to be converted or remuxed and methods to
> convert and remux using popular tools.'

Why do you feel the need to layout your code in a "GUI-listview"
manner. Next you'll want column titles and column sorting... Jeez!
This is what you should have done...

DESC = """
Provides a class for storing information on
multimedia files that are to be converted
or remuxed and methods to convert and remux
using popular tools.
"""

setup(
    name='Elucidation',
    version='0.0.1-WIP',
    py_modules=['elucidation'],
    author='Andrew Berg',
    author_email='baha...@digital-signal.net',
    url='',
    platforms='Windows',
    description=DESC,
    )

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

#9760

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On 2011.07.17 11:46 AM, rantingrick wrote:
> Why do you feel the need to layout your code in a "GUI-listview" 
> manner. Next you'll want column titles and column sorting... Jeez! 
> This is what you should have done...
I was testing my psychic abilities. I had the feeling that such a layout
would irritate you, so I had to try it. Before, I thought this psychic
stuff was all hokey, but now...

- -- 
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAwAGBQJOI25rAAoJEPiOA0Bgp4/L5lwIAIxwvAz7QBEOaQ9Hn/Er7esE
t4A76iJMOzVajFD61Wf8HkCyBrkQPk2i7koUqByUbQMRjAD3ukBorH+RNlfYwdJQ
w2HGjxCG36fA9yYZe5N+ySX1UlxH4pbZJLDxJMvo4brF8XVVOknsQyIW3rPM2ma9
CtdP4pWRpuE+4mz+wu4uxZW0xFarFV64TbcsXs1aZZAUSSJ4HUEbSuk/gw4IGBc5
HrOCBKt9hlgB7oh6KyITikFHCWV63iDzqfkVxP7Cr7ON3KaMPcfEVe2JowZv8NeV
cZmr4pbxWQ+ya0i8ukGjizrUa+Jdjp0p3I1OsVlZ0NCLyp4v5zDVS6R+97zjVc4=
=lBEF
-----END PGP SIGNATURE-----

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

#9663

On Sun, Jul 17, 2011 at 9:52 AM, Cameron Simpson <cs@zip.com.au> wrote:
> | Programming languages MUST have rules or
> | ambiguities will run a muck and bring the entire system crashing down.
>
> "Amuck" is one word you know...

Yes, but maybe he's wanting to run a MUCK. It's quite possible; I run
a MUD. Now, I'm not sure how ambiguities alone could run the MUCK
without human intervention, but as we know, Rick has the solution to
everything - it always involves other people doing work.

> | We should never create languages that cater to the selfish. Our rules
> | must take in consideration the "good of the many", and NEVER "the good
> | of the few". We should ALWAYS give our community freedoms; but only
> | the freedoms that foster unity! Tabs meet both criteria and as such
> | should be Pythons only token for indention formatting.
>
> It must be nice to always be right.
>
> In fact, I know it is, being so myself. You haven't yet reached that
> happy state.

I was born here. It's a good place to be. (Wait, were we talking about
Australia or Right?)

ChrisA

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

#9668

On Sun, 17 Jul 2011 09:52:45 +1000, Cameron Simpson <cs@zip.com.au>
declaimed the following in gmane.comp.python.general:

> On 16Jul2011 09:51, rantingrick <rantingrick@gmail.com> trolled:
> | a complete nut job. Programming languages MUST have rules or
> | ambiguities will run a muck and bring the entire system crashing down.
> 
> "Amuck" is one word you know...
>
	Or the code took on a life of its own, and the ambiguities created a
MUCK server in the background <G>
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#9678

* rantingrick (Sat, 16 Jul 2011 09:51:02 -0700 (PDT))
> 3) Tabs create freedom in the form of user controlled indention.
> 
> Indention width should be a choice of the reader NOT the author. We
> should never "code in" indention width; but that is EXACTLY what we
> are doing with spaces! No, the reader should be able to choose the
> indention width without ANY formatting required or without any
> collateral damage to the source code. Tabs offer freedom, spaces offer
> oppression.

Why are you so obsessed with indentation length? Indentation length is 
just /one/ of the formatting choices that the author makes for the 
reader - and probably the /least/ significant one.

There is for instance maximum line length, the number of empty lines, 
the author's method of alignment, spaces between the equals sign and so 
on. These are all much more "dominant" in the source code and none of 
this is left for the reader's disposition.

Compare for instance

variable        = 11
anothervariable = 22

def whatever (prettylong     = 1,
              alsoprettylong = 22,
              anotherone     = 33):
    pass

to

variable=11
anothervariable=22
def whatever (prettylong=1, alsoprettylong=22, anotherone=33):
    pass

Thorsten

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

#9717

On Jul 17, 2:35 am, Thorsten Kampe <thors...@thorstenkampe.de> wrote:
> * rantingrick (Sat, 16 Jul 2011 09:51:02 -0700 (PDT))
>
> > 3) Tabs create freedom in the form of user controlled indention.
>
> > Indention width should be a choice of the reader NOT the author. We
> > should never "code in" indention width; but that is EXACTLY what we
> > are doing with spaces! No, the reader should be able to choose the
> > indention width without ANY formatting required or without any
> > collateral damage to the source code. Tabs offer freedom, spaces offer
> > oppression.
>
> Why are you so obsessed with indentation length? Indentation length is
> just /one/ of the formatting choices that the author makes for the
> reader - and probably the /least/ significant one.

I am not OBSESSED with it, i am just PERTURBED that we are not using
tabs; since tabs offer freedom to view the source at ANY indentation
level you choose REGARDLESS of what the author "thought" was
appropriate. It is a wise choice to only allow tabs in a language that
has FORCED indention. This is one way we can actually promote freedom
whist maintaining unity.

> There is for instance maximum line length,

I like to keep lines at 80. Sometimes i go over if the code is not
something you would need to read often. If the code was to go into the
stdlib i would make sure it was 110% style guide compliant.

>  the number of empty lines,

I hate  vertical white-space. I follow Python style guide suggestions,
and then some! I hate when people insert spaces into code blocks and
function/method bodies. If you feel a space must be inserted then that
is a good clue you should be using a comment there instead. Vertical
breaks should only happen before and after classes, methods,
functions, groups of GLOBALS, groups of import statements. Think of
func/method bodies as paragraphs and classes as sections of a book.
Two vertical spaces between classes and one vertical space between
func/methods.

> the author's method of alignment, spaces between the equals sign and so
> on.

I believe non-compliant spacing in args should throw an syntax error.
I hate this:

>>> func( arg1 = 1, arg2 = 3 )

It should be...

>>> func(arg1=1, arg2=3)

Much easier to read when formatted into logical groups.

>  These are all much more "dominant" in the source code and none of
> this is left for the reader's disposition.

It should be MANDATED. And these @holes who refuse to format their
code in a community standard will suffer the plague of syntax errors.
Who do these people think they are? Do they believe the rules do not
apply to them? I'll tell you who they are, they are F'ING format
criminals.

> Compare for instance
>
> variable        = 11
> anothervariable = 22
>
> def whatever (prettylong     = 1,
>               alsoprettylong = 22,
>               anotherone     = 33):
>     pass
>
> to
>
> variable=11
> anothervariable=22
> def whatever (prettylong=1, alsoprettylong=22, anotherone=33):
>     pass

Both examples show non-compliance to the Python style guide.Except for
this...

------------------
FUNCTIONS/METHODS
------------------
def whatever(
    prettylong=1,
    alsoprettylong=22,
    anotherone=33):

OR

def whatever(prettylong=1, alsoprettylong=22,
             anotherone=33):

I think the second is more readable for block openers. Note the
closing bracket and colon on last line!

------------------
 CONTAINER TYPES
------------------

d = {
    1:1,
    2:2,
    3:3,
    4:4,
    }

Note closing bracket on newline; and all alone! For hand stitching
containers you should put the "closer" on a newline that matches the
"opener's" indention level.

------------------
 VARIABLES
------------------

variable = 11
anothervariable = 22

Stop trying to be an individual in a community. When you write code
for just you then write it any way you like. Go ahead and use that
Joker font and 10 space indention. Go ahead an use foolish spacing and
whatever. However when you are writing code in public or for the
stdlib you should always be Style Guide compliant.

You guys should feel lucky i am not the BDFL, because i would cast
plagues of exceptions on your lazy butts!

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

#9720

On Mon, Jul 18, 2011 at 2:29 AM, rantingrick <rantingrick@gmail.com> wrote:
> You guys should feel lucky i am not the BDFL, because i would cast
> plagues of exceptions on your lazy butts!
>

BDFL = Benevolent Dictator For Life. Note that first word.

ChrisA

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

#9730

On Sun, Jul 17, 2011 at 10:29 AM, rantingrick <rantingrick@gmail.com> wrote:
> I hate  vertical white-space. I follow Python style guide suggestions,
> and then some! I hate when people insert spaces into code blocks and
> function/method bodies. If you feel a space must be inserted then that
> is a good clue you should be using a comment there instead. Vertical
> breaks should only happen before and after classes, methods,
> functions, groups of GLOBALS, groups of import statements. Think of
> func/method bodies as paragraphs and classes as sections of a book.
> Two vertical spaces between classes and one vertical space between
> func/methods.

You know, there is such a thing as a vertical tab.  If we're going to
take your suggestion of mandating tabs (for greater freedom!), should
we not follow it to its logical conclusion and mandate the usage of
vertical tabs instead of multiple newlines?  Then everybody could
choose for themselves how many lines they want a vertical tab to
represent

> It should be MANDATED. And these @holes who refuse to format their
> code in a community standard will suffer the plague of syntax errors.
> Who do these people think they are? Do they believe the rules do not
> apply to them? I'll tell you who they are, they are F'ING format
> criminals.

I think I get it now.  Your idea of "freedom" is that anybody can do
whatever they want as long as it's not illegal, and the ruling party
just makes anything it doesn't like illegal.  In other words, a
monarchy.

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

#9747

On Jul 17, 1:54 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Sun, Jul 17, 2011 at 10:29 AM, rantingrick <rantingr...@gmail.com> wrote:
> > I hate  vertical white-space. I follow Python style guide suggestions,
> > and then some! I hate when people insert spaces into code blocks and
> > function/method bodies. If you feel a space must be inserted then that
> > is a good clue you should be using a comment there instead. Vertical
> > breaks should only happen before and after classes, methods,
> > functions, groups of GLOBALS, groups of import statements. Think of
> > func/method bodies as paragraphs and classes as sections of a book.
> > Two vertical spaces between classes and one vertical space between
> > func/methods.
>
> You know, there is such a thing as a vertical tab.  If we're going to
> take your suggestion of mandating tabs (for greater freedom!), should
> we not follow it to its logical conclusion and mandate the usage of
> vertical tabs instead of multiple newlines?  Then everybody could
> choose for themselves how many lines they want a vertical tab to
> represent

On the face of it one might think vertical tabs are a good idea
however newlines work just fine. There is no reason for expanding
vertical whitespace to create readble code. If you can offer a good
reason i'm listening. Also be sure to post links where others have
requested the same.

Besides, horizontal tabs are tied closely to distinguishing code
blocks. Vertical tabs do not have such a benefit. Instead of vertical
tabs we need strict rules on vertical code formatting. I intend to
draft AND implement such rules very shortly.

> > It should be MANDATED. And these @holes who refuse to format their
> > code in a community standard will suffer the plague of syntax errors.
> > Who do these people think they are? Do they believe the rules do not
> > apply to them? I'll tell you who they are, they are F'ING format
> > criminals.
>
> I think I get it now.  Your idea of "freedom" is that anybody can do
> whatever they want as long as it's not illegal,

In a programming language yes. You're trying to draw correlations
between morality and law. In the arena of programming there is no such
thing as morality, only the law.

> and the ruling party
> just makes anything it doesn't like illegal.  In other words, a
> monarchy.

What do you think we have now, a democracy? Does "Benevolent?-Dictator-
For-Life" ring a bell?

I can tell you one thing for sure. In MY version of Python everyone
will have a voice. That does not mean that EVERYONE will make the
final decision but EVERYONE's voice will be equally important. I can
also tell you this. I will not hide under the coat tails of my dev
team , NO, i will mingle with the people on my comp.lang.rickpy list.
Mats (Ruby's creator) will answer questions on comp.lang.ruby so why
does Guido refuse to acknowledge us here on comp.lang.python?

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

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

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

csiph-web