Re: Tabs -vs- Spaces: Tabs should have won.

[Gregory Ewing]

Steven D'Aprano wrote:


Why 78? Because it's one less than 79, as mandated by PEP 8, and two less
than 80, the hoary old standard.


There's another possible reason for the number 78, although
hopefully it doesn't still apply today.

There's an application I work with that stores free text
in database records of 78 chars each. I suspect it's
because early versions go back to the MS-DOS era, when
it was common to make windows out of box-drawing characters.
80 columns minus two border chars equals 78!

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Teemu Likonen]

* 2011-07-18T10:54:40+10:00 * Steven D'Aprano wrote:

> Back in 2007, a n00b calling himself "TheFlyingDutchman" who I am
> *reasonably* sure was Rick decided to fork Python:
>
> http://mail.python.org/pipermail/python-list/2007-September/1127123.html

I don't know if they are the same person but quite recently
"TheFlyingDutchman" tried to understand symbols, variables' scope,
bindings as well as function and variable namespaces in Common Lisp. It
resulted in a long thread, some of it was quite interesting.

http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/36000a1f37ebb052/5683597dd587fa87
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Crazy what-if idea for function/method calling syntax

[Steven D'Aprano]

On Mon, 18 Jul 2011 08:54 am ΤΖΩΤΖΙΟΥ wrote:

> Jumping in:
> 
> What if a construct
> 
>xx(*args1, **kwargs1)yy(*args2, **kwargs2)
> 
> was interpreted as
> 
>   xxyy(*(args1+args2), **(kwargs1+kwargs2))
> 
> (Note: with **(kwargs1+kwargs2) I mean “put keyword arguments in the
> order given”, since dicts can't be added)
> 
> This construct is currently a syntax error. The intent of this idea is
> to help improve legibility.

I don't think it does that. I think it is misleading, as it looks like two
independent function calls. It also makes it hard to search for a function
call -- instead of searching for

do_something\(.*\)

you have to now search for 

do_something\(.*\)
do\(.*\)_something\(.*\)
do_\(.*\)something\(.*\)
do_some\(.*\)thing\(.*\)

and so on.



> Example:
>   def place_at(item, x, y): blah blah
> could be called as
>   place(item)_at(x, y)

You would probably like the Xtalk family of languages, starting with
Hypertalk from Apple in the late 80s or early 90s.

There's a neat implementation here: http://code.google.com/p/openxion/


Xtalk includes syntax like this:

put newStr into character 23 to 42 of theStr
put suffix after theStr
delete first char of theStr

although this only applied to built-in functions, not user-functions.


-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ordered list question

[jyoung79]

Thank you Chris, Dan and Thomas for your replies.  I really appreciate your 
insight, and I will look into the information you have given me.  

Dan,
I've never heard of a "treap" or "red-black tree", so I'll be interested to 
research these.

Thomas,
Thanks very much for giving me further knowledge on xml and ECMAScript (I 
continually get this confused with javascript!).  In this project, I'm 
using Adobe InDesign with javascript (which is probably ECMAScript).  For 
xml parsing, it looks like Adobe uses the E4X XML Object, so I'm trying 
to go by those rules.  I'm new to xml, so I might be doing this all the 
wrong way.  Currently I'm looping through each element (in the XML Object), 
knowing what to do by the element type name and attributes given me.  In 
certain circumstances I'm needing things ordered by the id attribute, and 
as mentioned the elements will always be a different set of data.  I'm 
looking for a quick way to do this instead of a bubble sort.  Further 
down the line I'm hoping to incorporate Python and will probably use the 
ElementTree module.

I did have a couple of questions from your reply though:

> var o = {};
>   o[5] = "price";
>   o[1] = "copyright";
>   o[3] = "address";

> Then:

>   for (var prop in o)
>   {
> /* get prop or o[prop] */
>   }

If using this object instance, how were you thinking of putting this in 
index order?  Remember, I'm needing the original items "price", 
"copyright" and "address" in numerical order by what the id attributes 
are.  So I'd need it to end up being in this order - ["copyright", 
"address", "price"].

> The variable name `x' should also be reserved for non-counters, e. g. object 
> references.  Use i, j, k, and so forth in good programming tradition here 
> instead.

Can you share a website that goes into more detail on this good variable 
naming?  By the way, thanks for all the links you shared… I have bookmarked 
all of these - they look incredibly useful!


Thanks again for the help!

Jay

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Looking for general advice on complex program

[Josh English]

Chris,

I got my solution working, at least on my local machine. I'm trying to bundle 
it for testing on location.

I've thought about the server-client model and one day I may have the guts to 
tackle that, but I don't think it's this project. 

Sadly, I'm the type of guy who almost has to re-invent the wheel. When I 
started XML processing, it was on an old computer and I couldn't get things 
like lxml to work, or understand the ones I did manage to install. To fully 
understand XML processing and validating, I had to write my own XML validation 
utility.

Josh
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Crazy what-if idea for function/method calling syntax

[Ian Kelly]

2011/7/17 ΤΖΩΤΖΙΟΥ :
> Jumping in:
>
> What if a construct
>
>   xx(*args1, **kwargs1)yy(*args2, **kwargs2)
>
> was interpreted as
>
>  xxyy(*(args1+args2), **(kwargs1+kwargs2))
>
> (Note: with **(kwargs1+kwargs2) I mean "put keyword arguments in the
> order given", since dicts can't be added)
>
> This construct is currently a syntax error. The intent of this idea is
> to help improve legibility.
>
> Example:
>  def place_at(item, x, y): blah blah
> could be called as
>  place(item)_at(x, y)


class place(object):
def __init__(self, item):
self.__item = item
def at(self, x, y):
# place self.__item at (x, y)
pass

Then you can do:

place(item).at(x, y)

No syntax changes required. :-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Using argparse to call method in various Classes?

[Victor Hooi]

Hi,

I'm attempting to use argparse to write a simple script to perform operations 
on various types of servers:

manage_servers.py   

Operations are things like check, build, deploy, configure, verify etc.

Types of server are just different types of inhouse servers we use.

We have a generic server class, and specific types that inherit from that:

class Server
def configure_logging(self, loggin_file):
...
def check(self):
...
def deploy(self):
...
def configure(self):
...
def __init__(self, hostname):
self.hostname = hostname
logging = self.configure_logging(LOG_FILENAME)
class SpamServer(Server):
def check(self):
...
class HamServer(Server):
def deploy(self):
...

My question is how to link that all up to argparse?

Originally, I was using argparse subparses for the operations (check, build, 
deploy) and another argument for the type.

subparsers = parser.add_subparsers(help='The operation that you want to run on 
the server.')
parser_check = subparsers.add_parser('check', help='Check that the server has 
been setup correctly.')
parser_build = subparsers.add_parser('build', help='Download and build a copy 
of the execution stack.')
parser_build.add_argument('-r', '--revision', help='SVN revision to build 
from.')
...
parser.add_argument('type_of_server', action='store', choices=types_of_servers,
help='The type of server you wish to create.')

Normally, you'd link each subparse to a method - and then pass in the 
type_of_server as an argument. However, that's slightly backwards due to the 
classes- I need to create an instance of the appropriate Server class, then 
call the operation method inside of that - not a generic check/build/configure 
module

Any ideas of how I could achieve the above? Perhaps a different design pattern 
for Servers? Or any way to mould argparse to work with this?

Thanks,
Victor
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Crazy what-if idea for function/method calling syntax

[Cameron Simpson]

On 17Jul2011 15:54, ΤΖΩΤΖΙΟΥ  wrote:
| What if a construct
| 
|xx(*args1, **kwargs1)yy(*args2, **kwargs2)
| 
| was interpreted as
| 
|   xxyy(*(args1+args2), **(kwargs1+kwargs2))
| 
| (Note: with **(kwargs1+kwargs2) I mean “put keyword arguments in the
| order given”, since dicts can't be added)
| 
| This construct is currently a syntax error. The intent of this idea is
| to help improve legibility.
| 
| Example:
|   def place_at(item, x, y): blah blah
| could be called as
|   place(item)_at(x, y)
[...]
| There is also a big window for misuse (i.e. break the function/method
| name in illogical places), but I would classify this under “consenting
| adults”. It might be suggested as good form that function names break
| at underscores, like my examples.

Another problem is the scope for error. I can easily imagine typing:

  x=foo(x)bah(y)

when I intended to type:

  x=foo(x)+bah(y)

Adding your syntax causes silent breakage later instead of immediate
syntax error now.

Cheers,
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

hybrid rather than pure; compromising rather than clean;
distorted rather than straightforward; ambiguous rather than
articulated; both-and rather than either-or; the difficult
unity of inclusion rather than the easy unity of exclusion.
- Paul Barton-Davis 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[rantingrick]

On Jul 17, 2:47 am, Xah Lee  wrote:
> 2011-07-16
>
> folks, this one will be interesting one.
>
> the problem is to write a script that can check a dir of text files
> (and all subdirs) and reports if a file has any mismatched matching
> brackets.
>
>[...]
>
> • You script must be standalone. Must not be using some parser tools.
> But can call lib that's part of standard distribution in your lang.

I stopped reading here and did...

>>> from HyperParser import HyperParser # python2.x

...and called it a day. ;-) This module is part of the stdlib (idlelib
\HyperParser) so as per your statement it is legal (may not be the
fastest solution).

-- 
http://mail.python.org/mailman/listinfo/python-list

Argparse, and linking to methods in Subclasses

[Victor Hooi]

Hi,

I have a simple Python script to perform operations on various types on 
in-house servers:

manage_servers.py   

Operations are things like check, build, deploy, configure, verify etc.

Types of server are just different types of inhouse servers we use.

We have a generic server class, then specific types that inherit from that:

class Server
def configure_logging(self, loggin_file):
...
def check(self):
...
def deploy(self):
...
def configure(self):
...
def __init__(self, hostname):
self.hostname = hostname
logging = self.configure_logging(LOG_FILENAME)
class SpamServer(Server):
def check(self):
...
class HamServer(Server):
def deploy(self):
...

My question is how to link that all up to argparse?

Originally, I was using argparse subparses for the operations (check, build, 
deploy) and another argument for the type.

subparsers = parser.add_subparsers(help='The operation that you want to run on 
the server.')
parser_check = subparsers.add_parser('check', help='Check that the server has 
been setup correctly.')
parser_build = subparsers.add_parser('build', help='Download and build a copy 
of the execution stack.')
parser_build.add_argument('-r', '--revision', help='SVN revision to build 
from.')
...
parser.add_argument('type_of_server', action='store', choices=types_of_servers,
help='The type of server you wish to create.')

Normally, you'd link each subparse to a method - and then pass in the 
type_of_server as an argument. However, that's slightly backwards due to the 
classes- I need to create an instance of the appropriate Server class, then 
call the operation method inside of that.

Any ideas of how I could achieve the above? Perhaps a different design pattern 
for Servers? Or a way to use argparse in this situation?

Thanks,
Victor
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Ben Finney]

Steven D'Aprano  writes:

> The exception is, you have an indented block of code, perhaps three or four
> indents deep (surely you never allow anything to get beyond five or six
> indents?), and you want to raise an exception:
>
> raise SomeExceptionType("and here's a rather long error"
> "message blah blah blah")

Give yourself plenty more room, stay within PEP 8, *and* make the
alignment robust in the face of changes::

raise SomeExceptionType(
"and here's a rather long error"
"message blah blah blah")

-- 
 \   “I have one rule to live by: Don't make it worse.” —Hazel |
  `\  Woodcock |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Andrew Berg]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On 2011.07.17 07:54 PM, Steven D'Aprano wrote:
> Then in 2010, Rick promised that if the Python developers didn't bow
> to his demands, he would folk Python, and the silent majority who
> agreed with him but were too terrified to say so publicly would drop
> CPython in a flash and follow him.
> 
> Thread starts here: read and weep.
> 
> http://www.gossamer-threads.com/lists/python/python/835227?do=post_view_threaded#835227
>
>  How's that fork going Rick? Written a single line of code yet?
I skimmed through the first post a bit and it's hilarious. TL;DR for
now, but I'll read the whole thread later. I'm still surprised how much
entertainment I get from a programming language newsgroup.

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

iQEcBAEBAwAGBQJOI4vQAAoJEPiOA0Bgp4/LiN4IAMFXmBUxLOr1lYRIVY7kSwWj
Ln+pTvOR6S0og6S1v1fljTeFy8NWsbeLHjF48TahJf5VlEqiuCd7zUQ8r0gDn6ut
+ibDz+rtJJAE2XOG5myBylwcuG31TuaoXcSsNMCTnIMi6ZsoOWeBmkD0rvG66eFM
tPaceBdv7qe/0oNcy/DalEZ8gE2NSfrm6u4g5RQge8E4o4IwCWwMdSOkKRjkJdix
mbCfcCytQtc+X7IFwuUcFMAtFq9f8rzp8Jl45/wCBlxBPvZbLfqJvit9J8hgF81v
KgSeyV9BLKgzRamBOZQdG2/mUwJV8aQwxdSJrtRwZ0YWpQaOPnTZlQsRyAzf4nw=
=9zSp
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Steven D'Aprano]

Steven D'Aprano wrote:

> Roy Smith wrote:
> 
>> We don't have that problem any more.  It truly boggles my mind that
>> we're still churning out people with 80 column minds.  I'm willing to
>> entertain arguments about readability of long lines, but the idea that
>> there's something magic about 80 columns is hogwash.
> 
> I agree! Which is why I set my line width to 78 columns.

Sorry, that looks like a troll, but isn't.

I seriously do set my editor to a soft limit of 78 characters. That is, I
can exceed it if I want, but almost never do.

Why 78? Because it's one less than 79, as mandated by PEP 8, and two less
than 80, the hoary old standard. The reasons given in PEP 8 for 79 make
sense to me, and I don't like reading really long lines of code. With one
exception, if your line of code needs more than 79 plus or minus 1
characters, chances are it is doing too much.

The exception is, you have an indented block of code, perhaps three or four
indents deep (surely you never allow anything to get beyond five or six
indents?), and you want to raise an exception:

raise SomeExceptionType("and here's a rather long error"
"message blah blah blah")

If I only go a character or two over, I might be tempted to just go over.
But normally I split the line, as above, and use implicit line
concatenation.


http://www.python.org/dev/peps/pep-0008/


-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Mel]

Andrew Berg wrote:
> I should also mention that this mostly speculation on my part, and that
> I would love to hear from someone who develops for these devices.

There's a mailing list for Python scripting on Android -- 
List-Subscribe: ,  
. Tends to be pretty detail-oriented.

Mel.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Steven D'Aprano]

Roy Smith wrote:

> We don't have that problem any more.  It truly boggles my mind that
> we're still churning out people with 80 column minds.  I'm willing to
> entertain arguments about readability of long lines, but the idea that
> there's something magic about 80 columns is hogwash.

I agree! Which is why I set my line width to 78 columns. 


-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Mel]

Andrew Berg wrote:
> I should also mention that this mostly speculation on my part, and that
> I would love to hear from someone who develops for these devices.

There's a mailing list for Python scripting on Android -- 
List-Subscribe: ,  
. Tends to be pretty detail-oriented.

Mel.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Steven D'Aprano]

Chris Angelico wrote:

> On Mon, Jul 18, 2011 at 2:53 AM, rantingrick 
> wrote:
>> [a whole lot of guff]
> 
> Rick, you need to:
> 
> 1) Grab the Python source code
> 2) Make your own version of Python that works the way you want it
> 3) Call it something different
> 4) Start your own mailing list.
> 
> Put your money - or, in this case, development time - where your big
> ranting mouth is. Prove that your ideas are worth something by acting
> on them.

Ha ha, oh that's hilarious!!!

Back in 2007, a n00b calling himself "TheFlyingDutchman" who I am
*reasonably* sure was Rick decided to fork Python:

http://mail.python.org/pipermail/python-list/2007-September/1127123.html

Then in 2010, Rick promised that if the Python developers didn't bow to his
demands, he would folk Python, and the silent majority who agreed with him
but were too terrified to say so publicly would drop CPython in a flash and
follow him.

Thread starts here: read and weep.

http://www.gossamer-threads.com/lists/python/python/835227?do=post_view_threaded#835227

How's that fork going Rick? Written a single line of code yet?



-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Andrew Berg]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

I should also mention that this mostly speculation on my part, and that
I would love to hear from someone who develops for these devices.

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

iQEcBAEBAwAGBQJOI4NvAAoJEPiOA0Bgp4/LI8UH/3s+YyOsRGfHmcfX17glGUPT
bMAHq7vkmyWp5/zdcTWiRSxySrmTdcBJlquQOzUXhzGjRJlDoRQJrVypNr5zEO/r
FQkqwSnd0MmAg7wQX5I8xnM+muqeqOMvSqPs6HzBUiUqgwNoMlDn1v0Cc0h72mxx
Nf5r67/0Sptg7sR15aZnLtDodfql6qDxbIbDBdsp6SVnL6XE3l2NfFnB8DcOXRXk
2ooiV5/HlV0S2lr5TiKshyWuumQCnOPg6+ZDc//vev4L3aeM6EAXtYTWTWJEERl+
6PMP6u1SmA7P43jjzunxTiyXRkLLp7lJDaoWVzb3o+FDLOwNhgVEUH28TiXuNgQ=
=0HaP
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Andrew Berg]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On 2011.07.17 07:28 PM, Roy Smith wrote:
> Can you give me a more specific example?  I assume there's nobody (at
>  least nobody sane) editing Python source code on iPhones.
I haven't done it myself, but there are plenty of Python projects out
there made for mobile devices, and I would imagine the convenience of
editing on the platform itself to test things immediately outweighs the
inconvenience of a small display and tiny keyboard.

> Are there really devices which impose exactly an 80-column width?
Font size can be changed, so it's not a matter of a fixed number of
characters, but rather how many characters can fit on such a small
display at a reasonable size. My guess is that 80 is pretty arbitrary
nowadays, but it's much easier to stick with 80 than debate over it,
especially when display sizes vary so greatly among these devices.

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

iQEcBAEBAwAGBQJOI4LnAAoJEPiOA0Bgp4/L9s4H/1hZUtzSUEK3ZCs/+5SQk4dE
W7Au9Gv4rpNK6zmIRTmWkBeqUZdJHVXftQslnkvVr+pUMjz395YZbT3a2rAiaMje
IYq2HqKk8kZAeVo1sQLlKAl5PcCP8yJKGW1UJBLcLarXC33e/3pB1M7MY3QIVEta
S68IsBR5RJdtNIOJcmNtYEglPe1CSXt0LeEGYoseBhz9UyUDnnJlelu6WRAatKxR
jB8sbaWN4wLdT1iFkNFePSA1hJQSGmot0D5UaYTTG5HuG4JNlSeTZ23ctFLph/XG
96vndHBjxkDEdzCBkxSRaM5i5W/vSa/t25c5uDvXibldrxBWqm2QYJTeMhJ9JsY=
=6RXz
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Roy Smith]

In article ,
 Andrew Berg  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
> 
> On 2011.07.17 06:29 PM, Roy Smith wrote:
> > We don't have that problem any more.  It truly boggles my mind that 
> > we're still churning out people with 80 column minds.  I'm willing
> > to entertain arguments about readability of long lines, but the idea 
> > that there's something magic about 80 columns is hogwash.
> I think the reason the idea isn't dead is because of the emergence of
> new devices with small displays (tablets/smartphones/etc.) and their
> increasing popularity. When writing code that is meant to be run on
> desktops or servers, the 80-column limit is mostly irrelevant, but
> Python running on these small devices, especially with Python code being
> interpreted rather than compiled, it's convenient to edit code on those
> platforms, where there is a significant column limit.

Can you give me a more specific example?  I assume there's nobody (at 
least nobody sane) editing Python source code on iPhones.  I'll admit 
I'm not that familiar with the plethora of tablets and handheld devices 
out there.  Are there really devices which impose exactly an 80-column 
width?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Andrew Berg]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On 2011.07.17 06:29 PM, Roy Smith wrote:
> We don't have that problem any more.  It truly boggles my mind that 
> we're still churning out people with 80 column minds.  I'm willing
> to entertain arguments about readability of long lines, but the idea 
> that there's something magic about 80 columns is hogwash.
I think the reason the idea isn't dead is because of the emergence of
new devices with small displays (tablets/smartphones/etc.) and their
increasing popularity. When writing code that is meant to be run on
desktops or servers, the 80-column limit is mostly irrelevant, but
Python running on these small devices, especially with Python code being
interpreted rather than compiled, it's convenient to edit code on those
platforms, where there is a significant column limit.

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

iQEcBAEBAwAGBQJOI3aPAAoJEPiOA0Bgp4/LRMQH/irglKlq7+Nk67dvGuQt39ZH
nHqEE4HG5J7y/JfW+3g4UbhISHFwsJO0yvvcUN8cfLQ9O4KxzR65PS6Jqs8KEWS+
04hAZl0AbEKHZv3nOxWhxvAF5saJnq0xWHAtE9tFwS31I7Oh65rCBZD4g9BFiCql
YeTAklPB64Ik6F+7kcLDx3xDn6CPb/03Nj2assGatSUEY5p0OqzZ9nPnBxifLDFC
piOkZOgPW39s/zEzr+0LiD3ayFmtPoYldBFR0c7qkzyN6aS+Fur4kqbxlGl4jbI/
Xkms/5yrie/jAf4HgcaMHX2l4Or/dY7jyb6cK+How+yNa76xh6CZdxIZ68oR6Fs=
=K9SY
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Andrew Berg]

-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-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Crazy what-if idea for function/method calling syntax

[Thomas Jollans]

On 07/18/2011 12:54 AM, ΤΖΩΤΖΙΟΥ wrote:
> Jumping in:
> 
> What if a construct
> 
>xx(*args1, **kwargs1)yy(*args2, **kwargs2)
> 
> was interpreted as
> 
>   xxyy(*(args1+args2), **(kwargs1+kwargs2))
> 
> (Note: with **(kwargs1+kwargs2) I mean “put keyword arguments in the
> order given”, since dicts can't be added)
> 
> This construct is currently a syntax error. The intent of this idea is
> to help improve legibility.
> 
> Example:
>   def place_at(item, x, y): blah blah
> could be called as
>   place(item)_at(x, y)

Objective C does something similar. I don't actually know Objective C,
but from what I remember from when I briefly read up on in (somebody
please correct me), that call could, in Objective C, look something like:

[ place:item atPositionX:x Y:y ]

The idiomatic Python way for this is the following:

def place(item, at): pass
place(item, at=(x,y))

Your suggestion would open up an infinite number of different, mostly
unreadable, ways to call a single method. This completely goes against
the principle of encouraging there being only one way to do things.

Multi-part method names (with fixed, non-optional, "split" points, if
you know what I mean) are slightly interesting, but don't fit in, and,
more importantly, don't add anything to the language: all the possible
readability benefits are already provided (and trumped) by keyword
arguments.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Andrew Berg]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On 2011.07.17 03:12 PM, rantingrick wrote:
> 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.
That reminds me of Full Metal Jacket.
"Here you are all equally worthless."

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

iQEcBAEBAwAGBQJOI22xAAoJEPiOA0Bgp4/LIwsIANrgRO1m4f2w4M6HQ0I2Ysjl
SqSCQ4r4p7ZG4O6t/ms6r3uVQXh7FrV1atkWLkUprwd+DfPTl2Lpp5xF7RB2lJ4/
pvcIWQ47kC2F4BgbcW2UN8E1vu6K1G+q/s81HzXsTfdnFqYBrhli+Hd3XvgFH9Zr
nt8dKJuX1lVowYeg22iZyUiMaubpZl35Xyw4xFTPJ7eW8ynHriYG3JfJtUVjDYz0
Hs4oXrdcllugOwYcGUN4tddJ1uls/Xat16HUtxOIYIJUQr1kZVa/l0kmsoi1AT1/
SBCnLzyiuBLA8fHcvE675+/834FZi9sgAPOM4HY/dx3YDa8musSjbPtfSUFAQKQ=
=NEuJ
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

Crazy what-if idea for function/method calling syntax

[ΤΖΩΤΖΙΟΥ]

Jumping in:

What if a construct

   xx(*args1, **kwargs1)yy(*args2, **kwargs2)

was interpreted as

  xxyy(*(args1+args2), **(kwargs1+kwargs2))

(Note: with **(kwargs1+kwargs2) I mean “put keyword arguments in the
order given”, since dicts can't be added)

This construct is currently a syntax error. The intent of this idea is
to help improve legibility.

Example:
  def place_at(item, x, y): blah blah
could be called as
  place(item)_at(x, y)

I believe it makes code more readable; it's also a more terse
alternate to a call like:
  place_at(item=item, x=x, y=y)

Another example:
  group(iterable)_by(callable)

I can think of some objections myself; the most important is whether
the current parser (with a complexity defined by the wishes of Guido,
which I faintly recall reading about a long time ago) can do that or
not. I also don't know if any other language exists supporting this
construct.

There is also a big window for misuse (i.e. break the function/method
name in illogical places), but I would classify this under “consenting
adults”. It might be suggested as good form that function names break
at underscores, like my examples.

I know it seems extreme. I only posted this idea here because I would
like some input about how feasible it can be and whether people like
it or not. Any input is welcome; however, I kindly request that
negative replies include counter-arguments (an abrupt “no” or “yuck!”
does not help others improve their knowledge of Python or Pythonic-
ness :).

Thanks in advance.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Ian Kelly]

On Sun, Jul 17, 2011 at 2:12 PM, rantingrick  wrote:
> 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.

Okay:

1) Vertical tabs create freedom in the form of user controlled vertical spacing.

Vertical spacing height should be a choice of the reader NOT the author. We
should never "code in" vertical spacing height; but that is EXACTLY what we
are doing with newlines! No, the reader should be able to choose the
vertical spacing height without ANY formatting required or without any
collateral damage to the source code. Vertical tabs offer freedom,
newlines offer
oppression.

2) Vertical tabs remove the need for complicated newline-formatting tools.

With "vertical tabs only" you no longer need those fancy tools to add
the correct number of newlines between classes or methods.. THAT IS
EXACTLY WHY VERTICAL TABS
WHERE INVENTED! Why are we not using this technology? Why are we
continuing to promote newlines when vertical tabs are obviously more superior?

And as to why we should remove newlines:

3) Using only one vertical space token removes any chance of user error.

Unlike many syntactical errors, vertical space is invisible in a text/
source editor. Sure there are tools that can make vertical space visible,
however why do we constantly create asinine rules that force us to use
complicated tools when we could have choose vertical tabs and none of this
would have been a problem?

4) Vertical tabs maintain unity in the source code base.

When we replace "newlines only" with "vertical tabs only" we maintain
a code base that promotes unity and
not conformity. There shall not be any "inconsistent vertical spacing
errors" due to mixing vertical tabs and newlines. Also we can avoid
adding multiplicity
to the compiler. The compiler will not have to consider BOTH vertical tabs AND
newlines as valid vertical spacing tokens, only vertical tabs. The
logic would be much
simpler.

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

Vertical spacing helps to visually separate classes from other
classes, and methods from other methods.

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

You have been drawing the same correlation from your very first post
where you stated, "Tabs offer freedom, spaces offer oppression."

>> 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 don't see Guido going around making ridiculous pronouncements about
what forms of indentation are acceptable (beyond the standards that
are set and expected for the standard library, that is).  He could
have made the language space-only from the very beginning.  He didn't;
that should tell you something.  He also could have insisted that the
parser only accept source written in the ISO-8859-1 encoding "for
unity and freedom", but he didn't.  Or he could have stated "absolute
imports only" from the very beginning, and yet even in Python 3 where
the old-style relative imports have been removed, relative imports are
still available to be used.

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

Thanks, but I won't be needing a voice, because your version of Python
will clearly be too limiting from the ground up for me to have any
interest in using it in the first place.

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

Probably for the same reason that (I presume) he doesn't spend all day
answering Python questions on stackoverflow or responding to comments
about Python on slashdot: he can get more done in his actual job by
unsubscribing.

If you want to have input on Python, all you have to do is subscribe
to python-dev.  Of course, it *is* a moderated list, so if you make as
much of a nuisance of yourself over there as you do here, they might
kick you out.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Cameron Simpson]

On 17Jul2011 09:53, rantingrick  wrote:
| On Jul 17, 4:49 am, "Anders J. Munch" <2...@jmunch.dk> wrote:
| > Originally, tabs were a navigation device: When you press the tab key, you 
skip
| > ahead to the next tab column.  The notion that whitespace characters are
| > inserted into the text would have been very alien to someone using text
| > processing software anno 1970.  Same thing with space and enter; on 
typewriters
| > the space bar doesn't "type" anything onto the paper, it moves to the next
| > column, and that thinking carried over to computers.
| 
| And how much longer are we going to live in the past? Who cares about
| backward compatible tabs.

Anders was explaining, not supporting-for-the-future.

| Mandate the four space tab now! Mandate that
| Python takes four space and four space only! We shall lead the charge
| for universal tab unity in all programming languages.

You really don't know what you're talking about, do you? If Python
mandates this (hahaha!) the Perl crowd will immediately move to a more
advanced standard, likely 5 space indents (nicely decimalisable) while
indenting by two tabs (to flexibly leave room for more intermediate
logic to be inserted later with less diff noise, which they will find
hard to distinguish from program code).

| > The reason the tab stop is a full 8 positions: for faster navigation.  If it
| > were 3 positions, it would take forever to skip from the start of line to 
column
| > 60.  You'd appreciate that, if you were e.g. writing a fiduciary report with
| > some text to the left and two number columns to the right, back in the day
| > before spreadsheets and word processor tables.
| 
| Just in case you were not aware this the year 2011. Spreadsheets have
| been around for a LONG time. Stop living the past.

The past was better. Always was and will be increasingly so in the
future. Stop fighting the tide!
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

Pardon my driving, I'm trying to reload.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Gregory Ewing]

Anders J. Munch wrote:


 > Cameron Simpson wrote:
 >> Personally, I like to use the tab _key_ as an input device, but to have
 >> my editor write real spaces to the file in consequence.

Just like in the old days:)


Most editors can be configured to do that.

Where they fall down, in my experience, is that having inserted
those spaces, if you want to delete them you typically have to
backspace over them one at a time.

I don't enjoy that experience, which is why I have BBEdit Lite
set up to use tab-only indentation. If I'm feeling conscientious,
I convert to spaces before sharing the code with others. But tabs
work better for me given the tools I use and the way I like to
work.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Ian Kelly]

On Sun, Jul 17, 2011 at 1:54 PM, rantingrick  wrote:
> On Jul 17, 1:48 pm, Ian Kelly  wrote:
>
>> Let me get this straight.  You want us to use tabs so that individuals
>> can set their tab width to however many spaces they want, but then you
>> want everybody to set their tab widths to 4 spaces.  You're
>> contradicting yourself here.
>
> In my mind people are free to use whatever width they like. A tab is a
> tab is a tab. However for judging line widths we must pick one size
> tab (since 8 space tabs will create longer lines than four space tabs.
> This four space mandate is ONLY for determining line width. Let me
> repeat. ONLY FOR DETERMINING LINE WIDTH.
>
> How else could we decide what is truly 80 chars and what is not?

You're so focused on declaring code as compliant or not that you're
missing the whole point of having the line width mandate in the first
place.  It exists so that people using 80-column editors can open up
code without having line-wrapping problems.  You can arbitrarily
declare that line width is to be measured using 4-space tabs, and you
can stamp code as being correctly formatted by that metric all you
want, but it doesn't change the fact that if somebody with 8-space
tabs opens up a file and has to deal with line-wrapping problems, the
system has failed them.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

> It is possible [to parse the parentheses language], with Perl-compatible
> Regular Expressions (PCRE), provided that you have enough memory, to use
> such an extended Regular Expression (not to be confused with EREs³)⁴:
> 
>   \((([^()]*|(?R))*)\)
> 
> However, even Python 3.2 does not support those expressions (although it
> supports some other PCRE patterns, like named subexpressions)⁵, neither do
> standard and forked versions of sed(1) (BREs, EREs, using an NFA) nor awk
> (EREs, using a DFA or NFA).  [That is not to say it would not be possible
> with Python, or sed or awk (both of which are off-topic here), but that
> more than a Regular Expression would be required.]

Supplemental: Further research shows that the Python `re' module is not 
going to implement (PCRE) recursive Regular Expressions.  The maintainer's, 
Matthew Barnett's, argument (of 2009-03-24) is that such things are better 
left to modules such as `pyparsing' [1][2].

However, FWIW, here is the Python port of the start of a language parser 
originally written in (and for) ECMAScript:

import re

def matchingBraces(s):
level = 0

for match in re.finditer(r'[{}]', s):
paren = match.group(0)

if paren == "{":
level += 1
else:
if level == 0: return False
level -= 1

return level == 0

As you can see, the theoretically necessary PDA¹ implementation can be 
simplified to a braces counter with range checks by iterative use of a 
Regular Expression.  Extensions to meet the "challenge" are left as an 
exercise to the reader.

It has also occurred to me that because parentheses (`(', `)') and brackets 
(`[', `]') have special meaning in Regular Expressions (grouping and 
character classes, respectively), you could escape all other special 
characters in a text and use the RE evaluator itself to find out whether 
they are properly nested, having it evaluate one large RE.  But I have not 
tested this idea yet.  (Obviously it cannot be used to satisfy the 
"challenge"'s condition that braces – `{', `}' – and other parenthesis-like 
characters are to be considered as well, and that the parenthesis-like 
characters are to be printed.)

__
¹ Pushdown automaton

References:
[1] 
[2] 
-- 
PointedEars

Bitte keine Kopien per E-Mail. / Please do not Cc: me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[Thomas Jollans]

On 07/17/2011 10:16 PM, Thomas 'PointedEars' Lahn wrote:
> Raymond Hettinger wrote:
> 
>> Thomas 'PointedEars' Lahn wrote:
>>> Did you notice the excessive crosspost?  Please do not feed the troll.
>>
>> IMO, this was a legitimate cross post since it is for a multi-language
>> programming challenge and everyone can learn from comparing the
>> results.
> 
> Even if so (which I seriously doubt, see also my sig), you cannot reasonably 
> deny that "Xah Lee" is a well-known Usenet troll, and that this "challenge" 
> is nothing more than yet another sophisticated attempt at trolling.  Please 
> do not feed.

You know what you're doing? You're feeding the troll.

Yes, I know Xah Lee. Yes, he is known for trolling. So what? That alone
does not mean that every single thing he posts has to be bad. I'm all
with Raymond here.

There's nothing wrong with this post. This is the one time when it's
okay to feed the troll: reinforce good behaviour.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Dotan Cohen]

On Sun, Jul 17, 2011 at 22:53, Thomas 'PointedEars' Lahn
 wrote:
>> It simply isn't an issue.
>
> Apparently it is *has not been* an issue for *you* *yet*.  There are
> languages (like Python) that are compiled just-in-time.  Besides, neither an
> IDE nor a compiler can (always) recognize that foo["b0r"] is not foo["bOr"]
> (which really is not a far-fetched example as the O and zero keys are
> adjacent to each other on in keyboard layouts).  You do not want such an
> ambiguity to bite you later.
>

I do agree that in a weakly-typed language such as python one might
conceivably try to use an undeclared variable and the IDE and compiler
won't catch that. However 0 vs. O would more likely be 0 vs. o as one
would really have to mess up bad to not only press the wrong key but
also hit shift at the same time. 0 and o are no harder to distinguish
in a VWF than in a FWF.

For that matter, why is it assumed that fixed-width fonts by nature
better distinguish 0 from O, or any other ambiguous characters? My
current system (Kubuntu 11.04, default VWF font in Firefox whatever it
may be) distinguished 0 from O just fine. Also I/1 and l/1 are easy to
distinguish, but I agree that I/l are not.

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[rantingrick]

On Jul 17, 2:34 pm, Thorsten Kampe  wrote:

> Indentation alignment will (because you're using only spaces). Otherwise
> it doesn't align (it can't), simply because of the "variable-width".
>
> For instance (in a variable-width font):
>
> if a == b:
>     var123    = 22
>     varxyz456 = 333
>           ^
> aligned       not aligned
>
> Thorsten

Tabs will align properly in variable width font if the editor is NOT
broken. When displaying a variable width font the editor should switch
from using the sum of N glyphs to a user defined total width in
absolute measurements (like millimeters). Alternatively if the editor
had to guess it could just use the widest glyph of the current set.

People, please stop using broken tools. If you stop using them people
won't keep producing them. Just imagine how great the world would be
if we could convince windows users!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[Thomas 'PointedEars' Lahn]

Raymond Hettinger wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Did you notice the excessive crosspost?  Please do not feed the troll.
> 
> IMO, this was a legitimate cross post since it is for a multi-language
> programming challenge and everyone can learn from comparing the
> results.

Even if so (which I seriously doubt, see also my sig), you cannot reasonably 
deny that "Xah Lee" is a well-known Usenet troll, and that this "challenge" 
is nothing more than yet another sophisticated attempt at trolling.  Please 
do not feed.


PointedEars
-- 
No article in the world is relevant to more than a small handful of
groups. If WW III is announced, it will be announced in
net.announce.important. -- Peter da Silva, bofh.cabal, "Usenet II rules"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[rantingrick]

On Jul 17, 1:54 pm, Ian Kelly  wrote:
> On Sun, Jul 17, 2011 at 10:29 AM, rantingrick  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?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[Raymond Hettinger]

On Jul 17, 8:49 am, Thomas Boell  wrote:
> But why do you enumerate with start=1? Shouldn't you start with index 0?

The problem specification says that the the char number should match
the emacs goto-char function which is indexed from one, not from
zero.  This is testable by taking the output of the program and
running it through emacs to see that the cursor gets moved exactly to
the location of the mismatched delimiter.


Raymond

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[rantingrick]

On Jul 17, 1:48 pm, Ian Kelly  wrote:

> Let me get this straight.  You want us to use tabs so that individuals
> can set their tab width to however many spaces they want, but then you
> want everybody to set their tab widths to 4 spaces.  You're
> contradicting yourself here.

In my mind people are free to use whatever width they like. A tab is a
tab is a tab. However for judging line widths we must pick one size
tab (since 8 space tabs will create longer lines than four space tabs.
This four space mandate is ONLY for determining line width. Let me
repeat. ONLY FOR DETERMINING LINE WIDTH.

How else could we decide what is truly 80 chars and what is not?


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thomas 'PointedEars' Lahn]

Dotan Cohen wrote:

> On Sun, Jul 17, 2011 at 15:53, Thomas 'PointedEars' Lahn
>> […]  I do not understand how you can consider using a non-fixed-width
>> font in programming "a real pleasure" as many them show a lot of
>> ambiguities in source code.  Take for example the lowercase "l" (el) vs.
>> the capital "I" (ai) vs. the "|" (pipe) character, or the "0" (zero) vs.
>> the capital "O" (oh) character in Arial.
> 
> The ambiguity has never been an issue for me. In the unlikely event
> that an l (el) is in the place of a pipe, the code won't compile and
> I'll get an error on the line in question. Though that has never
> actually happened: the IDE is double-checking way before the code gets
> to the compiler. Zero vs. O (oh), I've never had this issue either and
> even if one key was hit in place of the other (they are close by) then
> either the IDE or compiler would catch it, or it would result in a
> minor bug in a text string.
> 
> It simply isn't an issue.

Apparently it is *has not been* an issue for *you* *yet*.  There are 
languages (like Python) that are compiled just-in-time.  Besides, neither an 
IDE nor a compiler can (always) recognize that foo["b0r"] is not foo["bOr"] 
(which really is not a far-fetched example as the O and zero keys are 
adjacent to each other on in keyboard layouts).  You do not want such an 
ambiguity to bite you later.

-- 
PointedEars

Bitte keine Kopien per E-Mail. / Please do not Cc: me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[rantingrick]

On Jul 17, 1:22 pm, Tim Chase  wrote:

> > Solution: STOP USING BROKEN TOOLS!!!
>
> Unbroken tools that do anything worthwhile are usually
> complicated tools.
>
> Just pointing that out in case you missed the irony...

You make a good point, albeit a very well know point. It's the same
kind of point Newton made when he wrote the laws of physics. Everyone
since cavemen knew that a falling apple would continue to fall until
the ground stopped it from falling. They just did not have the
eloquent phrasing of Newton to express the idea in words.

You've made the exact same well know expression as Newton. However we
do need to explore this subject of "broken tools vs unbroken tools" a
bit more. First let's start by understanding the difference between
broken and unbroken editors in the arena of tab width.


 Tabs Explained:

But what IS tab width exactly? Is it a simple unit of measurement like
four inches or 22 millimeters, or etc? Well it can be, but for the
most part it is something more. Especially in the arena of source code
editors!

In any plain text editor (i am not speaking of rich text editors or a
plain text editor in rich-text mode) where you have only one global
font choice at any given time a tab width should be the sum of N
glyphs multiplied by the current glyph width.

Here is some python code:

|>>> glyphW = 10.0 # in milimeters
|>>> def set_tab_width(nSpaces):
|   return glyphW * nSpaces
|>>> set_tab_width(1)
|10.0
|>>> set_tab_width(10)
|100.0

We as humans use "numbers of spaces" to define a tab width but
"numbers of spaces" is only an abstraction so we don't have to deal
with absolute measurements.


 Fixed Width Fonts:

If you are using a fixed-width-font you want the editor to use
relative spacing (relative to a glyph width) when defining tab width
in "spaces".


 Non Fixed Width Fonts:

On the other hand if you use non-fixed-width-font you want the editor
to use absolute measurements (since glyphs can be different widths)
when defining tab width.


 Conclusion

If your editor does not support as minimum the fixed width version, it
is broken. There is NOTHING complicated about creating tab width based
on the sum of N glyphs.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thomas 'PointedEars' Lahn]

Anders J. Munch wrote:

> Steven D'Aprano wrote:
>> I can't fathom why 8 position tabs were *ever* the default, let alone
>> why they are still the default.
> 
> That's because they were not invented as a means for programmers to vary
> indentation.
> 
> Originally, tabs were a navigation device: When you press the tab key, you
> skip ahead to the next tab column.

No, when you pressed the Tab key on a typewriter (BTDT), you advanced to the 
next tab _stop_.  This made it easier to write tables ("tab" from 
"tabulate") on a typewriter (the alternative was time-consuming and error-
prone use of the space and backspace keys).  With the evolution of the 
(personal) computer, its use in offices and at home, and peripheral devices 
like the dot matrix printer, typewriters fell out of common use, but the 
terms associated with them were incorporated into information technology 
language (cf. "TTY", originally "teletypewriter", e. g.).

> The reason the tab stop is a full 8 positions: for faster navigation.

No, the reason is that table columns should be as far enough away from each 
other to be distinguishable.

> If it were 3 positions, it would take forever to skip from the start of
> line to column 60.  You'd appreciate that, if you were e.g. writing a
> fiduciary report with some text to the left and two number columns to the
> right, back in the day before spreadsheets and word processor tables. 
> Skip a column or two too far?

I am getting the idea here that you mean the right thing, but that you 
explain it wrong.

-- 
PointedEars

Bitte keine Kopien per E-Mail. / Please do not Cc: me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Waldek M.]

>> I'm still looking for the perfect programming font. Suggestions
>> welcomed.
> 
> When you find it Dotan, let me know, I've been looking since the later 
> '70's.

For me, it's Terminus* (from sourceforge).

Br.
Waldek
[*] As long as you don't need anything but iso8859-1.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Dotan Cohen]

On Sun, Jul 17, 2011 at 21:20, Thorsten Kampe  wrote:
>> The past is bickering over selfish personal freedoms, the future of is
>> unity.
>
> And a tab is *exactly* four spaces. Not three. Not five. Not eight. For
> you, for me, and for the rest of the world. Amen!
>

Four is the number thou shalt indent, and the number of the indenting
shall be four. Six thou shalt not indent, neither indent thou two,
excepting that thou then proceed to four. Eight is right out.


-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ordered list question

[Dan Stromberg]

If you need "read everything, then sort once", then a dictionary (or
collections.defaultdict if you require undefined's) and a single sort at the
end is probably the way to go.

If you truly need an ordered datastructure (because you're reading one
element, using things sorted, reading another element, using things sorted),
then you're better off with a treap (good average case time) or red-black
tree (decent average case time, but without as much fluctuation).

On Sun, Jul 17, 2011 at 9:28 AM,  wrote:

> I'm currently working on a project where I'm looping through xml elements,
> pulling the 'id' attribute (which will be coerced to a number) as well as
> the
> element tag.  I'm needing these elements in numerical order (from the id).
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Dotan Cohen]

On Sun, Jul 17, 2011 at 20:57, rantingrick  wrote:
> Such a system of rigorous formatting rules requires much less
> interpreter logic. Python will be leaner and meaner. There won't be
> any more arguing about how to format code. There will only be one way;
> the correct way! Choose to follow it or die of exceptions; your
> choice.
>

Do you know that Python 4000 is the only language in the world whose
vocabulary gets smaller every year?'

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thorsten Kampe]

* Dotan Cohen (Sun, 17 Jul 2011 22:20:15 +0300)
> 
> On Sun, Jul 17, 2011 at 14:51, Thorsten Kampe  
> wrote:
> > * Dotan Cohen (Sun, 17 Jul 2011 14:11:40 +0300)
> >> So long as the indentation lines up (which it does, with tabs or
> >> spaces) then I do not see any problem with variable-width.
> >
> >> What are the counter-arguments?
> >
> > Alignment doesn't line up.
> >
> 
> They do with tabs.

Indentation alignment will (because you're using only spaces). Otherwise 
it doesn't align (it can't), simply because of the "variable-width".

For instance (in a variable-width font):

if a == b:
var123= 22
varxyz456 = 333
  ^
aligned   not aligned

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Dotan Cohen]

On Sun, Jul 17, 2011 at 17:29, gene heskett  wrote:
>> I'm still looking for the perfect programming font. Suggestions
>> welcomed.
>
> When you find it Dotan, let me know, I've been looking since the later
> '70's.
>

Hey there Gene! Are you not on every mailing list on the internet old man?!?

I have also come to the conclusion that the perfect woman, the perfect
physics theory, and the perfect programming font are all illusions
that men will stride their entire lives in search for but will never
find.

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Dotan Cohen]

On Sun, Jul 17, 2011 at 15:53, Thomas 'PointedEars' Lahn
 wrote:
>> I am also a recent spaces-to-tabs convert. One of the reasons is that
>> I've discovered that programing in a non-fixed width font is a real
>> pleasure, but the spaces are too narrow. Tabs alleviate that.
>
> Not using a fixed-width font avoids this problem and others in the first
> place.
>
>> I'm still looking for the perfect programming font. Suggestions welcomed.
>
> I can recommend Consolas (Windows) or Inconsolata (elsewhere), which are
> designed for programming and are near perfect in that regard.  However, I
> have decided for "Deja Vu Sans Mono" for reading and writing Usenet articles
> because it supports more Unicode characters and can be sized appropriately
> for running text.
>

I have used those three in the past. Terrific fonts each of them,
especially Inconsolata if I remember correctly.


> But, all of them are fixed-width fonts.  I do not understand how you can
> consider using a non-fixed-width font in programming "a real pleasure" as
> many them show a lot of ambiguities in source code.  Take for example the
> lowercase "l" (el) vs. the capital "I" (ai) vs. the "|" (pipe) character,
> or the "0" (zero) vs. the capital "O" (oh) character in Arial.
>

The ambiguity has never been an issue for me. In the unlikely event
that an l (el) is in the place of a pipe, the code won't compile and
I'll get an error on the line in question. Though that has never
actually happened: the IDE is double-checking way before the code gets
to the compiler. Zero vs. O (oh), I've never had this issue either and
even if one key was hit in place of the other (they are close by) then
either the IDE or compiler would catch it, or it would result in a
minor bug in a text string.

It simply isn't an issue.


-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[Raymond Hettinger]

On Jul 17, 7:15 am, Thomas 'PointedEars' Lahn 
wrote:
> Did you notice the excessive crosspost?  Please do not feed the troll.

IMO, this was a legitimate cross post since it is for a multi-language
programming challenge and everyone can learn from comparing the
results.


Raymond
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[rantingrick]

On Jul 17, 1:20 pm, Thorsten Kampe  wrote:

> > The past is bickering over selfish personal freedoms, the future of is
> > unity.
>
> And a tab is *exactly* four spaces. Not three. Not five. Not eight. For
> you, for me, and for the rest of the world. Amen!

Not *exactly*.

A tab is just a control char in a string that meant to convey a "user
defined space". When a text editor see's a tab in a string it uses the
current "user defined tab width" and creates the proper space (or
moves the proper distance) in the display. The tab control char
carries no information as to how WIDE a tab must be, no, the editor
makes that choice (based on user input or default).

However a tab can be EQUAL to four spaces, or eight spaces , or even
eight-eight spaces if the user wants it to.

The same is true for font. A string contains chars and the display
font is a decision for the editor to make (based on user input or
default).

We cannot always offer unity and freedom in a programming language.
But there are some exceptions; one of which being tabs.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Dotan Cohen]

On Sun, Jul 17, 2011 at 14:51, Thorsten Kampe  wrote:
> * Dotan Cohen (Sun, 17 Jul 2011 14:11:40 +0300)
>> So long as the indentation lines up (which it does, with tabs or
>> spaces) then I do not see any problem with variable-width.
>
>> What are the counter-arguments?
>
> Alignment doesn't line up.
>

They do with tabs.

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thomas 'PointedEars' Lahn]

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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ordered list question

[Thomas 'PointedEars' Lahn]

jyoun...@kc.rr.com wrote:
^^
Something is missing there.

> I'm currently working on a project where I'm looping through xml elements,
> pulling the 'id' attribute (which will be coerced to a number)

No, usually it won't.

> as well as the element tag.

That's element _type name_.

> I'm needing these elements in numerical order (from the id).

Attribute values of type ID MUST NOT start with a decimal digit in XML [1].

> Example xml might look like:
> 
> 
> 
> 

That is not even well-formed, as the end tags of the `address', `copyright', 
and `price' elements (in that order) are missing.  Well-formed XML would be 
either

  



  

or

  

  


  

or

  


  

  

or

  




or

  

  



but neither might be Valid (or make sense).  Check your DTD or XML Schema.

> There will be cases where elements might be excluded, but I'd still need
> to put what I find in id numerical order.  In the above example I would
> need the order of 1, 3, 5 (or copyright, address, price).  In javascript I
> can easily index an array, and any preceding elements that don't exist
> will be set to 'undefined':
> 
> -
> var a = [];
> 
> a[parseInt('5')] = 'price';
> a[parseInt('1')] = 'copyright';
> a[parseInt('3')] = 'address';
> 
> //  a is now   [undefined, copyright, undefined, address, undefined,
> price] -

This is nonsense even in "javascript" (there really is no such language 
[1]).  In ECMAScript implementations like JavaScript you would write

  var a = [];
  a[5] = "price";
  a[1] = "copyright";
  a[3] = "address";

as array indexes are only special object properties, and properties are 
stored as strings anyway.  However, the highest index you can store this 
way, in the sense that it increases the `length' of the array, would be 
2³²−2 (as the value of the `length' property ranges from 0 to 2³²–1).

Python's `list' type is roughly equivalent to ECMAScript's `Array' type.  
Important differences include that apparently you cannot store as much items 
in a Python list as in an ECMAScript Array – 

>>> for p in range(0, pow(2, 31)-1): a.append(p)
... 
Traceback (most recent call last):
  File "", line 1, in 
MemoryError

  [Kids, don't try this at home!]

>>> for p in range(0, pow(2, 31)): a.append(p)
... 
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: range() result has too many items 

–, and that you need to add enough items in order to access one (so there 
are no sparse lists):

>>> a[23] = 42
Traceback (most recent call last):
  File "", line 1, in 
IndexError: list assignment index out of range

(I was not aware of that.)  Also, the access parameter must be integer:

>>> a["23"] = 42
Traceback (most recent call last):
  File "", line 1, in 
TypeError: list indices must be integers, not str

>>> a["foo"] = "bar"
Traceback (most recent call last):
  File "", line 1, in 
TypeError: list indices must be integers, not str

[Using a non-numeric or out-of-range parameter (see above) for bracket 
property access on an ECMAScript Array means that the number of elements in 
the array does not increase, but that the Array instance is augmented with a 
non-element property, or an existing non-element property is overwritten; 
this cannot happen with Python lists.]

> Next, I can loop through the array and remove every 'undefined' in order
> to get the ordered array I need:

Or you could be using an ECMAScript Object instance in the first place, and 
iterate over its enumerable properties.  This would even work with proper 
IDs, but if you are not careful – chances of which your statements about the 
language indicate – you might need further precautions to prevent showing up 
of user-defined enumerable properties inherited from Object.prototype:

  var o = {
5: "price",
1: "copyright",
3: "address"
  };

or programmatically:

  var o = {};
  o[5] = "price";
  o[1] = "copyright";
  o[3] = "address";

Then:

  for (var prop in o)
  {
/* get prop or o[prop] */
  }

> -
>> var newA = [];
> 
>> for (var x = 0; x < a.length; x++) {

Unless a.length changes:

  for (var x = 0, len = a.length; x < len; ++x) {

The variable name `x' should also be reserved for non-counters, e. g. object 
references.  Use i, j, k, and so forth in good programming tradition here 
instead.

> if (a[x] != undefined) {

  if (typeof a[x] != "undefined") {

as your variant would also evaluate to `false' if a[x] was `null', and would 
throw an exception in older implementations at no advantage (however, you 
might want to consider using `a[x] !== undefined' for recent implementations 
only).

> newA.push(a[x]);
> }
> }
> 
> // newA is now   [copyright, address, price]

Or you would be using Array.prototype.push() (or a[a.length] = …) in the 
first place instead of this, as contrary to what you stated above you appear 
to be only interested in the element type names:

  var a = [];
  a.push("price");
 

Re: Tabs -vs- Spaces: Tabs should have won.

[Ian Kelly]

On Sun, Jul 17, 2011 at 10:29 AM, rantingrick  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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Ian Kelly]

On Sun, Jul 17, 2011 at 9:15 AM, rantingrick  wrote:
>>  I can write my code to 80
>> columns using 4-space tabs, but if somebody later tries to edit the
>> file using 8-space tabs, their lines will be too long.
>
> THEIR LINES is the key words. A tab control is a tab control is a (you
> guessed it!) a tab control. No matter how small or large your tab
> settings are the source only reflects one tab control char per press
> of the tab key. Heck, people are already (unwisely) using "8-space-
> spaces" and i don't hear you making the same argument.

Because the problem does not apply.  If I use 4 spaces, and somebody
else opens my file who uses 8, the code will still be limited to 80
columns.  They will just have to see my ugly 4-space indentation
instead of their preferred 8-space indentation.  You know what?  They
can cope.

>> Rick's answer
>> to this might be to just mandate that everybody uses 4-space tabs, but
>> then this would pretty much defeat the purpose of using tabs in the
>> first place.
>
> We already mandate four space spaces so what is the difference? I'll
> tell you, the difference is Freedom and Unity living in perfect
> harmony.

Let me get this straight.  You want us to use tabs so that individuals
can set their tab width to however many spaces they want, but then you
want everybody to set their tab widths to 4 spaces.  You're
contradicting yourself here.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thorsten Kampe]

* rantingrick (Sun, 17 Jul 2011 10:57:10 -0700 (PDT))
> Choose to follow it or die of exceptions; your choice.

One of the best things I've read for a long time :-).

> The past is bickering over selfish personal freedoms, the future of is
> unity.

And a tab is *exactly* four spaces. Not three. Not five. Not eight. For 
you, for me, and for the rest of the world. Amen!

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Tim Chase]

4) Tabs remove the need for complicated
indention/detention tools.


On 07/17/2011 10:15 AM, rantingrick wrote:

On Jul 17, 2:32 am, Ian Kelly  wrote:

This.  I used to think that tabs were better, for pretty
much the reasons Rick outlined, but I've had enough
problems with editors munging my tabs that I eventually
found it simpler in practice to just go with the flow and
use spaces.


Solution: STOP USING BROKEN TOOLS!!!


Unbroken tools that do anything worthwhile are usually 
complicated tools.


Just pointing that out in case you missed the irony...

-tkc





--
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Chris Angelico]

On Mon, Jul 18, 2011 at 3:57 AM, rantingrick  wrote:
> It's funny you mention this because i am creating a specification for
> a Python 4000 fork that removes all ambiguities and multiplicity from
> the language. Very soon i will be posting the spec for review within
> this group. Maybe some of you will come to your senses and start
> implementing these important features in CPython. If not, i am not
> going to waste my time forever trying to convince idiots that the
> world is in fact round.

Oh, I totally agree. And mailman is open source software so you can
even host the new Python-4000 mailing list yourself! Gather unto
thyself thy followers, and begin anew the creation of the world.

Chris Angelico
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[rantingrick]

On Jul 17, 12:11 pm, Chris Angelico  wrote:
> On Mon, Jul 18, 2011 at 2:53 AM, rantingrick  wrote:
> > [a whole lot of guff]
>
> Rick, you need to:
>
> 1) Grab the Python source code
> 2) Make your own version of Python that works the way you want it
> 3) Call it something different
> 4) Start your own mailing list.

It's funny you mention this because i am creating a specification for
a Python 4000 fork that removes all ambiguities and multiplicity from
the language. Very soon i will be posting the spec for review within
this group. Maybe some of you will come to your senses and start
implementing these important features in CPython. If not, i am not
going to waste my time forever trying to convince idiots that the
world is in fact round.

Python as it stands now will be defunct unless we make some serious
changes starting with formatting. We cannot continue to create code
bases that are so haphazardly written just for the sake of personal
freedom. Since people will not self-police we must create a mandate
that forces compliance to a style guide. Years have passed since the
first program was written. It is high time to set the standards for
formatting.

Such a system of rigorous formatting rules requires much less
interpreter logic. Python will be leaner and meaner. There won't be
any more arguing about how to format code. There will only be one way;
the correct way! Choose to follow it or die of exceptions; your
choice.

I am looking to the future and leaving the past where it belongs.
After i get a format style nailed down i will start culling the other
language specific multiplicities. Then it will be time to look outside
of Python and see what is the future of high level programming
languages.

You can choose to join me or choose to rot of old age in the self-
induced hell of antiquity. The past is bickering over selfish personal
freedoms, the future of is unity.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Proposal to extend PEP 257 (New Documentation String Spec)

[rantingrick]

On Jul 17, 6:11 am, Tim Chase  wrote:
> On 07/16/2011 10:10 PM, Steven D'Aprano wrote:
>
> > But I've never come across an email client that messes with
> > attachments. Just send your code as an attached .py file and
> > it's all good.
>
> However I'm on a couple mailing lists (e.g. lurking on OpenBSD)
> that strip all attachments...


If this IS true then format your source with "indentation-
markers" ("--->") and tell the receiver to run str.replace() on the
source. Also you should send a rant to the list owner concerning this
atrocious striping behavior.

But then again, you could just post it to a paste bin or email it to
group members directly.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Chris Angelico]

On Mon, Jul 18, 2011 at 2:53 AM, rantingrick  wrote:
> [a whole lot of guff]

Rick, you need to:

1) Grab the Python source code
2) Make your own version of Python that works the way you want it
3) Call it something different
4) Start your own mailing list.

Put your money - or, in this case, development time - where your big
ranting mouth is. Prove that your ideas are worth something by acting
on them.

Chris Angelico
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[rantingrick]

On Jul 17, 4:49 am, "Anders J. Munch" <2...@jmunch.dk> wrote:

> Originally, tabs were a navigation device: When you press the tab key, you 
> skip
> ahead to the next tab column.  The notion that whitespace characters are
> inserted into the text would have been very alien to someone using text
> processing software anno 1970.  Same thing with space and enter; on 
> typewriters
> the space bar doesn't "type" anything onto the paper, it moves to the next
> column, and that thinking carried over to computers.

And how much longer are we going to live in the past? Who cares about
backward compatible tabs. Mandate the four space tab now! Mandate that
Python takes four space and four space only! We shall lead the charge
for universal tab unity in all programming languages.

How long are you going to accept this multiplicity? It's ridiculous.

> The reason the tab stop is a full 8 positions: for faster navigation.  If it
> were 3 positions, it would take forever to skip from the start of line to 
> column
> 60.  You'd appreciate that, if you were e.g. writing a fiduciary report with
> some text to the left and two number columns to the right, back in the day
> before spreadsheets and word processor tables.

Just in case you were not aware this the year 2011. Spreadsheets have
been around for a LONG time. Stop living the past.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[Robert Klemme]

On 07/17/2011 06:01 PM, Robert Klemme wrote:

On 07/17/2011 03:55 PM, mhenn wrote:

Am 17.07.2011 15:20, schrieb Robert Klemme:

On 07/17/2011 11:48 AM, Raymond Hettinger wrote:

On Jul 17, 12:47 am, Xah Lee wrote:

i hope you'll participate. Just post solution here. Thanks.


http://pastebin.com/7hU20NNL


Ruby solution: https://gist.github.com/1087583


I acutally don't know Ruby that well, but it looks like your program
recognizes "[(])" as correct although it is not, because you translate
"[(])" to "(())" (which is indeed correct, but does not resemble the
input correctly anymore).


Right you are. The optimization breaks the logic. Good catch!


Turns out with a little possessiveness I can fix my original approach 
which has the added benefit of not needing three passes through the file 
(the two #tr's are obsolete now).


https://gist.github.com/1087583

Cheers

robert
--
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Chris Angelico]

On Mon, Jul 18, 2011 at 2:29 AM, rantingrick  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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[rantingrick]

On Jul 17, 5:42 am, Thorsten Kampe  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,
)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[rantingrick]

On Jul 17, 2:35 am, Thorsten Kampe  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!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ordered list question

[Chris Angelico]

On Mon, Jul 18, 2011 at 2:28 AM,   wrote:
> My question is, does python have a similar way to do something like this?
> I'm assuming the best way is to create a dictionary and then sort it by
> the keys?
>

That would be one way to do it. If you know beforehand what the
highest ID is, you could create a list and treat it exactly the way
you're treating the Javascript array, but I think the dictionary is
probably a better option.

Chris Angelico
-- 
http://mail.python.org/mailman/listinfo/python-list

Ordered list question

[jyoung79]

I'm currently working on a project where I'm looping through xml elements, 
pulling the 'id' attribute (which will be coerced to a number) as well as the 
element tag.  I'm needing these elements in numerical order (from the id).  
Example xml might look like:





There will be cases where elements might be excluded, but I'd still need to 
put what I find in id numerical order.  In the above example I would need 
the order of 1, 3, 5 (or copyright, address, price).  In javascript I can 
easily 
index an array, and any preceding elements that don't exist will be set to 
'undefined':

-
var a = [];

a[parseInt('5')] = 'price';
a[parseInt('1')] = 'copyright';
a[parseInt('3')] = 'address';

//  a is now   [undefined, copyright, undefined, address, undefined, price]
-

Next, I can loop through the array and remove every 'undefined' in order to 
get the ordered array I need:

-
> var newA = [];

> for (var x = 0; x < a.length; x++) { 
if (a[x] != undefined) { 
newA.push(a[x]); 
}
}

// newA is now   [copyright, address, price]
-

My question is, does python have a similar way to do something like this?  
I'm assuming the best way is to create a dictionary and then sort it by 
the keys?

Thanks.

Jay
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Corey Richardson]

Excerpts from Thorsten Kampe's message of Sun Jul 17 11:10:57 -0400 2011:
> The "perfect programming font" is just the one that looks so good that 
> you would also use it for writing email. Dejavu Sans Mono is pretty 
> good. Consolas looks also looks good but it is Windows only.
> 

I use inconsolata, but I  hate the look of it un-bold at small sizes, so
I keep it bold all the time. I've started using DejaVu very recently because
of that, it looks better on screen at small sizes (pixelsize=9 in my 
~/.Xdefaults, as opposed to the 12 and bold with inconsolata). Inconsolata
looks great on paper, though. DejaVu Sans Mono isn't the prettiest thing
but it certainly gets the job done.
-- 
Corey Richardson
  "Those who deny freedom to others, deserve it not for themselves"
 -- Abraham Lincoln


signature.asc
Description: PGP signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[Robert Klemme]

On 07/17/2011 03:55 PM, mhenn wrote:

Am 17.07.2011 15:20, schrieb Robert Klemme:

On 07/17/2011 11:48 AM, Raymond Hettinger wrote:

On Jul 17, 12:47 am, Xah Lee   wrote:

i hope you'll participate. Just post solution here. Thanks.


http://pastebin.com/7hU20NNL


Ruby solution: https://gist.github.com/1087583


I acutally don't know Ruby that well, but it looks like your program
recognizes "[(])" as correct although it is not, because you translate
"[(])" to "(())" (which is indeed correct, but does not resemble the
input correctly anymore).


Right you are.  The optimization breaks the logic.  Good catch!

Kind regards

robert
--
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[Thomas Boell]

On Sun, 17 Jul 2011 02:48:42 -0700 (PDT)
Raymond Hettinger  wrote:

> On Jul 17, 12:47 am, Xah Lee  wrote:
> > i hope you'll participate. Just post solution here. Thanks.
> 
> http://pastebin.com/7hU20NNL

I'm new to Python. I think I'd have done it in a similar way (in any
language). Your use of openers/closers looks nice though. In the
initialization of openers, I guess you implicitly create a kind of
hash, right? Then the 'in' operator checks for the keys. That is elegant
because you have the openers and closers right next to each other, not
in separate lists.

But why do you enumerate with start=1? Shouldn't you start with index 0?


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[Thomas Jollans]

On Jul 17, 9:47 am, Xah Lee  wrote:
> 2011-07-16
>
> folks, this one will be interesting one.
>
> the problem is to write a script that can check a dir of text files
> (and all subdirs) and reports if a file has any mismatched matching
> brackets.
>
> • The files will be utf-8 encoded (unix style line ending).
>
> • If a file has mismatched matching-pairs, the script will display the
> file name, and the  line number and column number of the first
> instance where a mismatched bracket occures. (or, just the char number
> instead (as in emacs's “point”))
>
> • the matching pairs are all single unicode chars. They are these and
> nothing else: () {} [] “” ‹› «» 【】 〈〉 《》 「」 『』
> Note that ‘single curly quote’ is not consider matching pair here.
>
> • You script must be standalone. Must not be using some parser tools.
> But can call lib that's part of standard distribution in your lang.
>
> Here's a example of mismatched bracket: ([)], (“[[”), ((, 】etc. (and
> yes, the brackets may be nested. There are usually text between these
> chars.)
>
> I'll be writing a emacs lisp solution and post in 2 days. Ι welcome
> other lang implementations. In particular, perl, python, php, ruby,
> tcl, lua, Haskell, Ocaml. I'll also be able to eval common lisp
> (clisp) and Scheme lisp (scsh), Java. Other lang such as Clojure,
> Scala, C, C++, or any others, are all welcome, but i won't be able to
> eval it. javascript implementation will be very interesting too, but
> please indicate which and where to install the command line version.
>
> I hope you'll find this a interesting “challenge”. This is a parsing
> problem. I haven't studied parsers except some Wikipedia reading, so
> my solution will probably be naive. I hope to see and learn from your
> solution too.
>
> i hope you'll participate. Just post solution here. Thanks.

I thought I'd have some fun with multi-processing:

https://gist.github.com/1087682
-- 
http://mail.python.org/mailman/listinfo/python-list

HOT HOT HOT

[SAHITHI]

FOR GOOD JOBS SITES TO YOU
 http://goodjobssites.blogspot.com/

FOR HOT PHOTO&VIDEOS

 KATRINA KAIF RARE PHOTOS
http://southactresstou.blogspot.com/2011/07/katrina-kaif-wallpapers.html
TAMANNA HOT SEXY PHOTOS & VIDEOS
http://southactresstou.blogspot.com/2011/07/tamanna-wallpapers.html
  PRANITHA LATEST BEAUTIFUL PHOTOS
http://southactresstou.blogspot.com/2011/06/about-pranitha-praneetha-is-beautiful.html
   KAJAL AGARWAL HOT SEXY PHOTOS
http://southactresstou.blogspot.com/2011/05/kajal-agarwal.html
 KATRINA KAIF IN BEAUTIFUL RED DRESS
http://southactresstou.blogspot.com/2011/05/katrina-kaif_22.html
GOOD LOOKING DEEPIKA PADUKONE
http://southactresstou.blogspot.com/2011/05/deepika-padukone_22.html
  AISHWARYA RAI UNBELIVABLE PHOTO
http://southactresstou.blogspot.com/2011/05/aishwarya-rai.html




FOR FAST UPDATES IN TELUGU FILM INDUSTRY
http://allyouwants.blogspot.com



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[rantingrick]

On Jul 17, 2:32 am, Ian Kelly  wrote:

> This.  I used to think that tabs were better, for pretty much the
> reasons Rick outlined, but I've had enough problems with editors
> munging my tabs that I eventually found it simpler in practice to just
> go with the flow and use spaces.

Solution: STOP USING BROKEN TOOLS!!!

> Of course, there is also another major problem with tabs that I have
> not seen pointed out yet, which is that it's not possible to strictly
> adhere to 80-column lines with tabs.

Of course it is. The litmus test will be "four-space-tab-view". If the
code overflows in this "view type" then the code will fail the 80 char
maximum limit. This argument is ridiculous anyhow. It is up to you how
to view the source. If you view it in 80 width tabs don't start
complaining later when one indention goes off the page. Would you view
the source with 50 point font? Jeez.

>  I can write my code to 80
> columns using 4-space tabs, but if somebody later tries to edit the
> file using 8-space tabs, their lines will be too long.

THEIR LINES is the key words. A tab control is a tab control is a (you
guessed it!) a tab control. No matter how small or large your tab
settings are the source only reflects one tab control char per press
of the tab key. Heck, people are already (unwisely) using "8-space-
spaces" and i don't hear you making the same argument.

> Rick's answer
> to this might be to just mandate that everybody uses 4-space tabs, but
> then this would pretty much defeat the purpose of using tabs in the
> first place.

We already mandate four space spaces so what is the difference? I'll
tell you, the difference is Freedom and Unity living in perfect
harmony.

Yes, we mandate that all code must meet the 80 line limit in "four-
space-tab-view", and if it doesn't, it's not allowed in the stdlib.
Plain and simple.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thorsten Kampe]

* gene heskett (Sun, 17 Jul 2011 10:29:03 -0400)
> On Sunday, July 17, 2011 10:28:16 AM Dotan Cohen did opine:
> > I'm still looking for the perfect programming font. Suggestions
> > welcomed.
> 
> When you find it Dotan, let me know, I've been looking since the later
> '70's.

The "perfect programming font" is just the one that looks so good that 
you would also use it for writing email. Dejavu Sans Mono is pretty 
good. Consolas looks also looks good but it is Windows only.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thorsten Kampe]

* 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[gene heskett]

On Sunday, July 17, 2011 10:28:16 AM Dotan Cohen did opine:

> On Sat, Jul 16, 2011 at 19:51, rantingrick  wrote:
> > --
> >  Evidence: Tabs ARE superior!
> > --
> 
> I am also a recent spaces-to-tabs convert. One of the reasons is that
> I've discovered that programing in a non-fixed width font is a real
> pleasure, but the spaces are too narrow. Tabs alleviate that.
> 
> I'm still looking for the perfect programming font. Suggestions
> welcomed.

When you find it Dotan, let me know, I've been looking since the later 
'70's.

Cheers, gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Men will always be men -- no matter where they are.
-- Harry Mudd, "Mudd's Women", stardate 1329.8
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[gene heskett]

On Sunday, July 17, 2011 10:12:27 AM Xah Lee did opine:

> 2011-07-16
> 
> folks, this one will be interesting one.
> 
> the problem is to write a script that can check a dir of text files
> (and all subdirs) and reports if a file has any mismatched matching
> brackets.
> 
> • The files will be utf-8 encoded (unix style line ending).
> 
> • If a file has mismatched matching-pairs, the script will display the
> file name, and the  line number and column number of the first
> instance where a mismatched bracket occures. (or, just the char number
> instead (as in emacs's “point”))
> 
> • the matching pairs are all single unicode chars. They are these and
> nothing else: () {} [] “” ‹› «» 【】 〈〉 《》 「」 『』
> Note that ‘single curly quote’ is not consider matching pair here.
> 
> • You script must be standalone. Must not be using some parser tools.
> But can call lib that's part of standard distribution in your lang.
> 
> Here's a example of mismatched bracket: ([)], (“[[”), ((, 】etc. (and
> yes, the brackets may be nested. There are usually text between these
> chars.)
> 
> I'll be writing a emacs lisp solution and post in 2 days. Ι welcome
> other lang implementations. In particular, perl, python, php, ruby,
> tcl, lua, Haskell, Ocaml. I'll also be able to eval common lisp
> (clisp) and Scheme lisp (scsh), Java. Other lang such as Clojure,
> Scala, C, C++, or any others, are all welcome, but i won't be able to
> eval it. javascript implementation will be very interesting too, but
> please indicate which and where to install the command line version.
> 
> I hope you'll find this a interesting “challenge”. This is a parsing
> problem. I haven't studied parsers except some Wikipedia reading, so
> my solution will probably be naive. I hope to see and learn from your
> solution too.
> 
> i hope you'll participate. Just post solution here. Thanks.
> 
>  Xah

This is a very old solution, some of it nearly 30 years old.
Written in C, the trick is in doing it in python I guess.
==begin cntx.c===
/*^k^s
.ds2
.hb
.fb^k^s^b Cntx.c, page #^k^s^b
*
*   *
*   CC (C Checker)  *
*   *
* C Source Brackets, Parenthesis, brace,*
*quote and comment Checker  *
*   *
*T. Jennings  -- Sometime in 1983   *
*Slightly tweaked and renamed MINILINT  *
*   KAB Aug 84  *
*Ported to OS9 and further tweaked  *
*   Brian Paquette March 91 *
*  Brackets, single, double quote counters added*
*   & renamed Cntx  04/09/91*
*   by   Gene Heskett   *
*   *
*  some additional code for ignoring "syntax" chars inside of   *  
*  double quoted strings added 3/21/93 by Gene Heskett  *
*  same for single quoted stuffs 7/10/93 by Gene Heskett*
* And long lines handling ability added too.*
* Adding tab ignorers and a counter to tally how many 11/21/93  *
/
#define OS9   /* used for nested comment handling*/
  /* comment out for non OS9/6809*/

#include 
#include 
#include 
#define  FALSE 0
#define  TRUE  1

#ifdef   OS9
#define  NO  " No "
#define  YES " Yes "
char *cmnt;
#endif

/* Very crude but very effective C source debugger. Counts the numbers of
matching braces, parentheses and comments, and displays them at the left 
edge of the screen. The best way to see what it does is to do it; try

cntx -v cntx.c

Properly handles parens and braces inside comments; they are ignored.
Also ignores single quotes if doubles are odd number, so singles
can be used in a printf string for punctuation.  IF you see the doubles
are odd at line end (the printout tally), all bets are OFF! 
Enter cntx on the command line by itself for a usage note.
*/

main(argc,argv)
int argc;
char *argv[];
{
 FILE *f;
 char c,secnd_c,lastc;
 int bracket,parens,braces,squote,dquote,comments;
 int perr,bkerr,brerr,sqerr,dqerr;
 int verbose,okay;
 int filearg = 0;
 int line, col, tabc;

 if ((argc < 2)||(argc > 3)) getout(0);
 if (argc == 3)
 {
   verbose = TRUE;  /* already tested for -v switch  */
   if((argv[1][0] == '-') && (toupper(argv[1][1]) == 'V'))
 filearg = 2;   /*file name pointed to by argv[2] */
   if((argv[2][0] == '-') && (toupper(argv[2][1]) == 'V'))
 filearg 

Re: a little parsing challenge ☺

[Thomas 'PointedEars' Lahn]

Chris Angelico wrote:

> On Sun, Jul 17, 2011 at 5:47 PM, Xah Lee  wrote:
>> the problem is to write a script that can check a dir of text files
>> (and all subdirs) and reports if a file has any mismatched matching
>> brackets.
> 
> I wonder will it be possible to code the whole thing as a single
> regular expression... I'm pretty sure it could be done as a sed or awk
> script, but I'm insufficiently expert in either to do the job.

Did you notice the excessive crosspost?  Please do not feed the troll.

In the classical sense is not possible, as classical regular expressions 
have no concept of recursion.  Indeed, matching brackets are a textbook 
example for a non-regular¹ context-free language L = {a^n b^n; n > 0} that 
can only be recognized by a pushdown automaton (PDA).  (Finite automata 
"cannot count".)

However, it is possible (and done) to use classical regular expressions or 
non-recursive Regular Expressions (note the different character case) to 
match tokens more efficiently with a PDA implementation.  This is commonly 
called a parser.  (Programming languages tend to be specified in terms of a 
context-free grammar – they tend to be context-free languages –, which is 
why a parser is a part of a compiler or interpreter.  See for example 
Python.²)

It is possible, with Perl-compatible Regular Expressions (PCRE), provided 
that you have enough memory, to use such an extended Regular Expression (not 
to be confused with EREs³)⁴:

  \((([^()]*|(?R))*)\)

However, even Python 3.2 does not support those expressions (although it 
supports some other PCRE patterns, like named subexpressions)⁵, neither do 
standard and forked versions of sed(1) (BREs, EREs, using an NFA) nor awk 
(EREs, using a DFA or NFA).  [That is not to say it would not be possible 
with Python, or sed or awk (both of which are off-topic here), but that more 
than a Regular Expression would be required.]

On this subject, I recommend reading the preview chapters of the second and 
third editions, respectively, of Jeffrey E. F. Friedl's "Mastering Regular 
Expressions", which are available online for free at O'Reilly.com⁶.

HTH.

__
¹ because it can be proved that the pumping lemma for regular languages
  does not apply to it; see also
   pp.
² 
³ 
⁴ Cf. 
⁵ 
⁶ ,
  
-- 
PointedEars

Bitte keine Kopien per E-Mail. / Please do not Cc: me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[mhenn]

Am 17.07.2011 15:20, schrieb Robert Klemme:
> On 07/17/2011 11:48 AM, Raymond Hettinger wrote:
>> On Jul 17, 12:47 am, Xah Lee  wrote:
>>> i hope you'll participate. Just post solution here. Thanks.
>>
>> http://pastebin.com/7hU20NNL
> 
> Ruby solution: https://gist.github.com/1087583

I acutally don't know Ruby that well, but it looks like your program
recognizes "[(])" as correct although it is not, because you translate
"[(])" to "(())" (which is indeed correct, but does not resemble the
input correctly anymore).

> 
> Kind regards
> 
> robert

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[Robert Klemme]

On 07/17/2011 11:48 AM, Raymond Hettinger wrote:

On Jul 17, 12:47 am, Xah Lee  wrote:

i hope you'll participate. Just post solution here. Thanks.


http://pastebin.com/7hU20NNL


Ruby solution: https://gist.github.com/1087583

Kind regards

robert
--
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[TheSaint]

Ian Kelly wrote:

> but if somebody later tries to edit the
> file using 8-space tabs

I came across this and I like to put a note on top of the script
to remember to modify it accordingly.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thomas 'PointedEars' Lahn]

Dotan Cohen wrote:

> On Sat, Jul 16, 2011 at 19:51, rantingrick  wrote:
>> --
>> Evidence: Tabs ARE superior!
>> --
> 
> I am also a recent spaces-to-tabs convert. One of the reasons is that
> I've discovered that programing in a non-fixed width font is a real
> pleasure, but the spaces are too narrow. Tabs alleviate that.

Not using a fixed-width font avoids this problem and others in the first 
place.
 
> I'm still looking for the perfect programming font. Suggestions welcomed.

I can recommend Consolas (Windows) or Inconsolata (elsewhere), which are 
designed for programming and are near perfect in that regard.  However, I 
have decided for "Deja Vu Sans Mono" for reading and writing Usenet articles 
because it supports more Unicode characters and can be sized appropriately 
for running text.

But, all of them are fixed-width fonts.  I do not understand how you can 
consider using a non-fixed-width font in programming "a real pleasure" as 
many them show a lot of ambiguities in source code.  Take for example the 
lowercase "l" (el) vs. the capital "I" (ai) vs. the "|" (pipe) character,
or the "0" (zero) vs. the capital "O" (oh) character in Arial.

-- 
PointedEars

Bitte keine Kopien per E-Mail. / Please do not Cc: me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thomas 'PointedEars' Lahn]

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

___
¹ 
² 
³ 
-- 
PointedEars

Bitte keine Kopien per E-Mail. / Please do not Cc: me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Anders J. Munch]

Steven D'Aprano wrote:
> I can't fathom why 8 position tabs were *ever* the default, let alone why
> they are still the default.

That's because they were not invented as a means for programmers to vary 
indentation.


Originally, tabs were a navigation device: When you press the tab key, you skip 
ahead to the next tab column.  The notion that whitespace characters are 
inserted into the text would have been very alien to someone using text 
processing software anno 1970.  Same thing with space and enter; on typewriters
the space bar doesn't "type" anything onto the paper, it moves to the next 
column, and that thinking carried over to computers.


The reason the tab stop is a full 8 positions: for faster navigation.  If it 
were 3 positions, it would take forever to skip from the start of line to column 
60.  You'd appreciate that, if you were e.g. writing a fiduciary report with 
some text to the left and two number columns to the right, back in the day 
before spreadsheets and word processor tables.  Skip a column or two too far? 
Adjust by backspacing (another navigation key).


As for why 8 is still the default - well, what else should it be? 2, 3, 4, 5?  I 
for one am thankful that we have so far been spared the flamewar armegeddon of 
all the world's programmers trying to agree on that.


> Cameron Simpson wrote:
>> Personally, I like to use the tab _key_ as an input device, but to have
>> my editor write real spaces to the file in consequence.

Just like in the old days:)

regards, Anders

--
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[rusi]

On Jul 17, 4:34 pm, Chris Angelico  wrote:
> On Sun, Jul 17, 2011 at 5:47 PM, Xah Lee  wrote:
> > the problem is to write a script that can check a dir of text files
> > (and all subdirs) and reports if a file has any mismatched matching
> > brackets.
>
> I wonder will it be possible to code the whole thing as a single
> regular expression... I'm pretty sure it could be done as a sed or awk
> script, but I'm insufficiently expert in either to do the job.
>
> ChrisA

No possible: See 
http://en.wikipedia.org/wiki/Pumping_lemma_for_regular_languages#Use_of_lemma

Informally stated as regexes cant count.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thorsten Kampe]

* Dotan Cohen (Sun, 17 Jul 2011 14:11:40 +0300)
> So long as the indentation lines up (which it does, with tabs or
> spaces) then I do not see any problem with variable-width.

> What are the counter-arguments?

Alignment doesn't line up.

Thorsten
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[Chris Angelico]

On Sun, Jul 17, 2011 at 5:47 PM, Xah Lee  wrote:
> the problem is to write a script that can check a dir of text files
> (and all subdirs) and reports if a file has any mismatched matching
> brackets.

I wonder will it be possible to code the whole thing as a single
regular expression... I'm pretty sure it could be done as a sed or awk
script, but I'm insufficiently expert in either to do the job.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[rusi]

On Jul 17, 4:11 pm, Dotan Cohen  wrote:
> On Sun, Jul 17, 2011 at 11:35, Andrew Berg  wrote:
> >> programing in a non-fixed width font is a real pleasure
> > If you're masochistic, maybe. Do you find fixed-width fonts ugly?
>
> I don't find that fixed-width fonts are ugly, but variable-width fonts
> sure are more of a pleasure. And with code-colouring in any good IDE,
> there is no real need to have the dot or other tiny characters jump
> out and announce their presence. So long as the indentation lines up
> (which it does, with tabs or spaces) then I do not see any problem
> with variable-width.
>
> What are the counter-arguments?
>
> > I
> > really would like to know why anyone would use a non-fixed-width font
> > for programming.
>
> Aesthetics.

Its more (or less depending...) than just aesthetics.  Its about
optimization.
On a fixed width font an 'i' is as wide as an 'm' as a '.'
This means that a fwf is either a unreasonably small or the lines are
too long.

[Note: I use only fwf because all the tools I know/use/tried are
broken for vwf]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Dotan Cohen]

On Sun, Jul 17, 2011 at 11:35, Andrew Berg  wrote:
>> programing in a non-fixed width font is a real pleasure
> If you're masochistic, maybe. Do you find fixed-width fonts ugly?

I don't find that fixed-width fonts are ugly, but variable-width fonts
sure are more of a pleasure. And with code-colouring in any good IDE,
there is no real need to have the dot or other tiny characters jump
out and announce their presence. So long as the indentation lines up
(which it does, with tabs or spaces) then I do not see any problem
with variable-width.

What are the counter-arguments?


> I
> really would like to know why anyone would use a non-fixed-width font
> for programming.

Aesthetics.

>> I'm still looking for the perfect programming font. Suggestions
>> welcomed.
> I use Courier New.
>

Have you looked at the Droid fixed-width fonts? Very nice, and easy to
distinguish 0 from o or O.

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Proposal to extend PEP 257 (New Documentation String Spec)

[Tim Chase]

On 07/16/2011 10:10 PM, Steven D'Aprano wrote:

But I've never come across an email client that messes with
attachments. Just send your code as an attached .py file and
it's all good.


However I'm on a couple mailing lists (e.g. lurking on OpenBSD) 
that strip all attachments...


-tkc



--
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thorsten Kampe]

* 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 = '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.'
)

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Code hosting services

[Thomas Jollans]

On 07/17/2011 12:08 PM, Ben Finney wrote:
> Thomas Jollans  writes:
> 
>> Launchpad has a cross-project bug tracker.
> 
> With which you can (so I'm told) interact with completely using email.
> 
>> Launchpad also uses the excruciatingly slow (but distributed, and
>> written-in-python) bzr for version control.
> 
> Citation needed. While Git is the fastest, Bazaar (so long as you're
> using a non-ancient version) is plenty fast enough for most needs.
> 

You asked for it:
I cite: http://whygitisbetterthanx.com/#git-is-fast

Of course, I haven't used bzr in ages, and the data on that website is
pretty old. You say bzr has improved, and I'll take your word for it.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Code hosting services

[Ben Finney]

Thomas Jollans  writes:

> Launchpad has a cross-project bug tracker.

With which you can (so I'm told) interact with completely using email.

> Launchpad also uses the excruciatingly slow (but distributed, and
> written-in-python) bzr for version control.

Citation needed. While Git is the fastest, Bazaar (so long as you're
using a non-ancient version) is plenty fast enough for most needs.

-- 
 \  “The face of a child can say it all, especially the mouth part |
  `\of the face.” —Jack Handey |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Andrew Berg]

-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-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: a little parsing challenge ☺

[Raymond Hettinger]

On Jul 17, 12:47 am, Xah Lee  wrote:
> i hope you'll participate. Just post solution here. Thanks.

http://pastebin.com/7hU20NNL


Raymond
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: FULL TIME PYTHON DEVELOPER OPPORTUNITY IN CHICAGO, IL

[Chris Withers]

On 07/07/2011 21:48, Aimee Gerzofsky wrote:

Python Developer

Major financial clients is seeking a PythonDeveloper for a *full time
position in Chicago, IL*.


It's better to post this kind of thing to the python job board:

http://www.python.org/community/jobs/howto/

cheers,

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
--
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Thorsten Kampe]

* 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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Andrew Berg]

-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-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Andrew Berg]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On 2011.07.17 03:15 AM, Dotan Cohen wrote:
> programing in a non-fixed width font is a real pleasure
If you're masochistic, maybe. Do you find fixed-width fonts ugly? I
really would like to know why anyone would use a non-fixed-width font
for programming.
> I'm still looking for the perfect programming font. Suggestions
> welcomed.
I use 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/

iQEcBAEBAwAGBQJOIp7iAAoJEPiOA0Bgp4/LWzcH/0iHzlOF47JOnIJfPjbhhTu5
KbrkE3mkQEwDtdNT4FUQb/aklHqvlmd4DWgxg25eXZ8PWAfQBPjnfKWHDSvWz7+2
rt6MNXLfh/6wzAAAT2nJNl5QabeANYBEbSE3EvgnMe5LfVWR/vVl2upmTfxAaoWJ
gH1Vp6TstAZluh8kcmii8dyrHXiubh9K84YS+FdRzLX3lz5mtGe+c20DWeeMiMxU
NlIzfWQVzZa4avU+1GdWFXwgKJP5chf7lyrg1UKFmSeQUeR4MeOx1PP8spkQy51i
fl4+VCCHOxL3Z5KVrM/aO0wTNwjYy+QddkGr+Hdk/QDNoqJwwYi8e2Nao/06HUY=
=3pB7
-END PGP SIGNATURE-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Tabs -vs- Spaces: Tabs should have won.

[Dotan Cohen]

On Sat, Jul 16, 2011 at 19:51, rantingrick  wrote:
> --
>  Evidence: Tabs ARE superior!
> --

I am also a recent spaces-to-tabs convert. One of the reasons is that
I've discovered that programing in a non-fixed width font is a real
pleasure, but the spaces are too narrow. Tabs alleviate that.

I'm still looking for the perfect programming font. Suggestions welcomed.

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com
-- 
http://mail.python.org/mailman/listinfo/python-list