In <[EMAIL PROTECTED]>, Zeljko Vrba wrote:
> Actually, after I learned Python, I value "funny squiggles" in other
> languages even more. It's very annoying, for example, that I can't split
> a long line in the following way:
>
> print a + b +
> c + d
> print "other statement"
>
> I guess I'm
Marc 'BlackJack' Rintsch wrote:
> In <[EMAIL PROTECTED]>, JohnBMudd
> wrote:
>
> > Python could take over the programming world except one of it's best
> > features (scope by indent) is a primary reason why it never will. It's
> > not flexible enough. A large percentage of programmers won't even
Antoon Pardon <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> Op 2005-12-11, Rick Wotnaz schreef <[EMAIL PROTECTED]>:
>>
>> Because you're accustomed to one set of conventions, you
>> may find Python's set strange at first. Please try it, and
>> don't fight it. See if your objections don
Op 2005-12-11, Rick Wotnaz schreef <[EMAIL PROTECTED]>:
>
> Because you're accustomed to one set of conventions, you
> may find Python's set strange at first. Please try it, and
> don't fight it. See if your objections don't fade away. If
> you're like most Python newbies, you'll stop thinking a
On Sun, 11 Dec 2005, Steven D'Aprano wrote:
On Sat, 10 Dec 2005 16:34:13 +, Tom Anderson wrote:
On Sat, 10 Dec 2005, Sybren Stuvel wrote:
Zeljko Vrba enlightened us with:
Find me an editor which has folds like in VIM, regexp search/replace
within two keystrokes (ESC,:), marks to easily
Zeljko Vrba <[EMAIL PROTECTED]> writes:
> An obvious defficieny of the current way we write code now is its inherent
> tree-structure resulting from {}, indentation, begin/end markers or whatnot.
> But the flow of code is often not a tree but a cycle.. Yet we are always
> dealing with a tree-like r
Zeljko Vrba wrote:
> Nobody bothers to figure out something better? Now you will argue that then
> the indendation is good enough.. and I can just reply that then it's an
> open research question..
huh? people mention existing research (including formal usability studies),
and your response is t
On 2005-12-11, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Welcome to c.l.py
>
Oh, thank you.
--
http://mail.python.org/mailman/listinfo/python-list
Zeljko Vrba wrote:
> >
> > I'm sorry you find the indentation unnatural and inconvenient, but you
> > may have to accept that for this feature you are actually in a minority.
> >
> I have no problem accepting that I'm in a minority. I have a problem with
> offensive people using my example argumen
On 2005-12-11, Steve Holden <[EMAIL PROTECTED]> wrote:
>
> I don't suppose there's any good reason, then, why (for example)
> outlining tools use indentation to indicate different levels of
> significance.
>
Nobody bothers to figure out something better? Now you will argue that then
the indendati
Zeljko Vrba wrote:
> On 2005-12-11, Rick Wotnaz <[EMAIL PROTECTED]> wrote:
>
>>Make a grocery list. Do you terminate each item with
>>punctuation? Write a headline for a newspaper. Is
>>
>
> actually, I do. i write as much as fits in one line and separate items
> with comma.
>
>
>>may find Py
On 2005-12-11, Rick Wotnaz <[EMAIL PROTECTED]> wrote:
>
> Make a grocery list. Do you terminate each item with
> punctuation? Write a headline for a newspaper. Is
>
actually, I do. i write as much as fits in one line and separate items
with comma.
>
> may find Python's set strange at first. Plea
On Sat, 10 Dec 2005 22:01:07 +, Zeljko Vrba wrote:
> On 2005-12-10, Tom Anderson <[EMAIL PROTECTED]> wrote:
>>
>> ED IS THE STANDARD TEXT EDITOR.
>>
> And:
> INDENTATION
> SUCKS
> BIG
> TIME.
>
> Using indentation without block termination marke
On Sat, 10 Dec 2005 16:34:13 +, Tom Anderson wrote:
> On Sat, 10 Dec 2005, Sybren Stuvel wrote:
>
>> Zeljko Vrba enlightened us with:
>>
>>> Find me an editor which has folds like in VIM, regexp search/replace
>>> within two keystrokes (ESC,:), marks to easily navigate text in 2
>>> keystro
Zeljko Vrba <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> On 2005-12-10, Tom Anderson <[EMAIL PROTECTED]> wrote:
>>
>> ED IS THE STANDARD TEXT EDITOR.
>>
> And:
> INDENTATION
> SUCKS
>BIG
> TIME.
>
> Using indentation without block termination markers
Zeljko Vrba wrote:
> Using indentation without block termination markers is opposite of the way we
> write spoken language, terminating each sentence with . Ever wondered why
> we use such things in written language, when people are much better in
> guessing what the writer wanted to say then comp
On 2005-12-10, Tom Anderson <[EMAIL PROTECTED]> wrote:
>
> ED IS THE STANDARD TEXT EDITOR.
>
And:
INDENTATION
SUCKS
BIG
TIME.
Using indentation without block termination markers is opposite of the way we
write spoken language, terminating eac
On Sat, 10 Dec 2005, Sybren Stuvel wrote:
> Zeljko Vrba enlightened us with:
>
>> Find me an editor which has folds like in VIM, regexp search/replace
>> within two keystrokes (ESC,:), marks to easily navigate text in 2
>> keystrokes (mx, 'x), can handle indentation-level matching as well as
>>
Zeljko Vrba wrote:
> On 2005-12-10, Steve Holden <[EMAIL PROTECTED]> wrote:
>
>>My advice would be to stop using punch cards and start using a sensible
>>text editor.
>>
>
> Such as..?
>
Since choice of text editor tends to be a religious issue, that will
have to be your decision, not mine.
>
Zeljko Vrba enlightened us with:
> Find me an editor which has folds like in VIM, regexp search/replace
> within two keystrokes (ESC,:), marks to easily navigate text in 2
> keystrokes (mx, 'x), can handle indentation-level matching as well
> as VIM can handle {}()[], etc. And, unlike emacs, respe
On 2005-12-10, Steve Holden <[EMAIL PROTECTED]> wrote:
>
> My advice would be to stop using punch cards and start using a sensible
> text editor.
>
Such as..?
Find me an editor which has folds like in VIM, regexp search/replace within
two keystrokes (ESC,:), marks to easily navigate text in 2 key
Zeljko Vrba wrote:
> On 2005-12-08, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>
>>Making a mistake in indentation level is precisely analogous to leaving
>>out markers in other languages. If your editor is smart enough, and the
>>
>
> But look at the following example:
>
> if a:
> some_code1
On Fri, 09 Dec 2005 02:59:44 -0600, D H wrote:
> Fredrik Lundh wrote:
>> Zeljko Vrba wrote:
>>
>>
>>>But look at the following example:
>>>
>>>if a:
>>> some_code1
>>>if b:
>>> some_code2
>>>
>>>If I accidentaly delete if b:, then some_code2 gets under the if a: which is
>>>not intended.
>>
>
On Fri, 09 Dec 2005 08:15:14 +, Zeljko Vrba wrote:
> On 2005-12-08, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>>
>> Making a mistake in indentation level is precisely analogous to leaving
>> out markers in other languages. If your editor is smart enough, and the
>>
> But look at the following
On Fri, 09 Dec 2005 09:34:44 +0100, Fredrik Lundh wrote:
> do you often remove code by accident? is this some vi-specific problem ?
+1 QOTW
I wish I had thought of saying that! In fact, I think I will have done!
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
Christophe wrote:
> David Rasmussen a écrit :
>
>>Antoon Pardon wrote:
>>
>>
Write shorter functions ;)
>>>
>>>
>>>This has little to do with long functions. A class can contain
>>>a large number of methods, whitch are all rather short, and your
>>>class will still be spread over several pages
David Rasmussen a écrit :
> Antoon Pardon wrote:
>
>>>
>>> Write shorter functions ;)
>>
>>
>> This has little to do with long functions. A class can contain
>> a large number of methods, whitch are all rather short, and your
>> class will still be spread over several pages.
>>
>
> Write classes
Fredrik Lundh wrote:
> Zeljko Vrba wrote:
>
>
>>But look at the following example:
>>
>>if a:
>> some_code1
>>if b:
>> some_code2
>>
>>If I accidentaly delete if b:, then some_code2 gets under the if a: which is
>>not intended.
>
>
> not to mention that if you have
>
> if a:
> so
Op 2005-12-08, Steven D'Aprano schreef <[EMAIL PROTECTED]>:
> On Thu, 08 Dec 2005 08:23:52 +, Antoon Pardon wrote:
>
>> Op 2005-12-07, Steven D'Aprano schreef <[EMAIL PROTECTED]>:
>>> On Wed, 07 Dec 2005 15:26:59 +, Zeljko Vrba wrote:
>>>
Braces are very convenient to match block start
Zeljko Vrba wrote:
> But look at the following example:
>
> if a:
> some_code1
> if b:
> some_code2
>
> If I accidentaly delete if b:, then some_code2 gets under the if a: which is
> not intended.
not to mention that if you have
if a:
some_code1
some_code2
and accidental
On 2005-12-08, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>
> Making a mistake in indentation level is precisely analogous to leaving
> out markers in other languages. If your editor is smart enough, and the
>
But look at the following example:
if a:
some_code1
if b:
some_code2
If I accidenta
On Thu, 08 Dec 2005 08:23:52 +, Antoon Pardon wrote:
> Op 2005-12-07, Steven D'Aprano schreef <[EMAIL PROTECTED]>:
>> On Wed, 07 Dec 2005 15:26:59 +, Zeljko Vrba wrote:
>>
>>> Braces are very convenient to match block start and end. Open a C program
>>> in the VI editor, and press % in com
On 8 Dec 2005 08:17:14 GMT in comp.lang.python, Antoon Pardon
<[EMAIL PROTECTED]> wrote:
[...]
>I just think braces are the worst solution for it, as python is
>concerned.
Agreed. A model like Modula-2's would be much preferable, and in fact
is supported (but not enforced) today (as long as you
Op 2005-12-07, Steven D'Aprano schreef <[EMAIL PROTECTED]>:
> On Wed, 07 Dec 2005 15:26:59 +, Zeljko Vrba wrote:
>
>> Braces are very convenient to match block start and end. Open a C program
>> in the VI editor, and press % in command mode on some brace.. It will take
>> you to its matching br
Op 2005-12-07, Zeljko Vrba schreef <[EMAIL PROTECTED]>:
> On 2005-12-07, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>>
>> What I don't understand is, that most people who have a problem
>> with scope by indentation, want to introduce braces. I think
>> braces are the worst solution.
>>
> Braces are v
Antoon Pardon wrote:
>>
>>Write shorter functions ;)
>
> This has little to do with long functions. A class can contain
> a large number of methods, whitch are all rather short, and your
> class will still be spread over several pages.
>
Write classes with a smaller interface ;-)
/David
--
htt
On Wed, 07 Dec 2005 15:26:59 +, Zeljko Vrba wrote:
> Braces are very convenient to match block start and end. Open a C program
> in the VI editor, and press % in command mode on some brace.. It will take
> you to its matching brace. How do you do something like that with python code
> (or any
On Wed, 07 Dec 2005 07:58:55 -0800, JohnBMudd wrote:
> So...
>
> Python is already flexible. It supports use of (1) tabs, (2) space or
> (3) a mix of tabs and space to indicate scope.
>
> Some people think this is too flexible. It should be cut back to tabs
> or spaces. The fewer people comfo
[EMAIL PROTECTED] enlightened us with:
> Some people (a lot of the ones that don't give Python a chance) want
> one more choice, braces. Is that so much to ask for?
I say: use #{ and #} instead. If you want to have braces, what's wrong
with
if condition: #{
some statement
other statement
[EMAIL PROTECTED] wrote:
> Some people like it just as it is. Don't change ANYTHING!
search for NIMPY
> Some people (a lot of the ones that don't give Python a chance) want
> one more choice, braces. Is that so much to ask for?
If you like curly brace style, there are always other scripting
l
So...
Python is already flexible. It supports use of (1) tabs, (2) space or
(3) a mix of tabs and space to indicate scope.
Some people think this is too flexible. It should be cut back to tabs
or spaces. The fewer people comfortable with Python, the better. It's
better to be "right" than popu
Zeljko Vrba <[EMAIL PROTECTED]> wrote:
> On 2005-12-07, Antoon Pardon <[EMAIL PROTECTED]> wrote:
> >
> > What I don't understand is, that most people who have a problem
> > with scope by indentation, want to introduce braces. I think
> > braces are the worst solution.
> >
> Braces are very conveni
On 2005-12-07, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
> What I don't understand is, that most people who have a problem
> with scope by indentation, want to introduce braces. I think
> braces are the worst solution.
>
Braces are very convenient to match block start and end. Open a C program
in
[EMAIL PROTECTED] wrote:
,,
However there is one thing I don't like in python,
> that is, scoping by indentation. But it would not annoy me so much that
> make me decide to implement a new language^_^.
>
>
> Regards,
>
> Limin
>
I find these comments interesting. It is very common for
On Mon, 05 Dec 2005 05:16:04 -0800, JohnBMudd wrote:
> From "The Design of Everyday Things", docs are a sign of poor design.
> Even a single word, such as the word "Push" on the face of a door, is
> an indication that the design can be improved.
I find it ironic that you are using a book that doc
Op 2005-12-07, Christophe schreef <[EMAIL PROTECTED]>:
> Paul Rubin a écrit :
>> Antoon Pardon <[EMAIL PROTECTED]> writes:
>>
>>>But lately I have been wondering about doing the following:
>>>end = None
>>>...
>>> if ...:
>>>...
>>> end
>>>IMO it looks better, but I'm reluctant because it su
Op 2005-12-07, Ben Sizer schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-12-06, Ben Sizer schreef <[EMAIL PROTECTED]>:
>> > Of course. However I would argue that indented scope is one way of
>> > doing so. Scope is instantly visible, and no longer a game of 'hunt the
>> > punctuation
Op 2005-12-07, Paul Rubin schreef :
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> But lately I have been wondering about doing the following:
>> end = None
>> ...
>> if ...:
>> ...
>> end
>> IMO it looks better, but I'm reluctant because it suggest
>> some checking by the compilor, which j
Antoon Pardon wrote:
> Op 2005-12-06, Ben Sizer schreef <[EMAIL PROTECTED]>:
> > Of course. However I would argue that indented scope is one way of
> > doing so. Scope is instantly visible, and no longer a game of 'hunt the
> > punctuation character, which is in a different place depending on the
>
Paul Rubin a écrit :
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>
>>But lately I have been wondering about doing the following:
>>end = None
>>...
>> if ...:
>>...
>> end
>>IMO it looks better, but I'm reluctant because it suggest
>>some checking by the compilor, which just doesn't happen.
Antoon Pardon <[EMAIL PROTECTED]> writes:
> But lately I have been wondering about doing the following:
> end = None
> ...
> if ...:
> ...
> end
> IMO it looks better, but I'm reluctant because it suggest
> some checking by the compilor, which just doesn't happen.
I don't think you can alw
Op 2005-12-06, Ben Sizer schreef <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] wrote:
>> > Just because a few people dislike something,
>> > doesn't make it a defect.
>>
>> Actually, it does.
>
> Whose definition of defect are we using? And how small a sample
> population are we going to require in ord
Op 2005-12-06, [EMAIL PROTECTED] schreef <[EMAIL PROTECTED]>:
>> Just because a few people dislike something,
>> doesn't make it a defect.
>
> Actually, it does. Unless you're in the business of building security
> systems. Then the goals are reversed.
>
> I can accept that you like scope by ind
[EMAIL PROTECTED] wrote:
> > Just because a few people dislike something,
> > doesn't make it a defect.
>
> Actually, it does.
Whose definition of defect are we using? And how small a sample
population are we going to require in order to find a 'something' which
less than 'a few' people dislike?
> Just because a few people dislike something,
> doesn't make it a defect.
Actually, it does. Unless you're in the business of building security
systems. Then the goals are reversed.
I can accept that you like scope by indent and don't want to see any
changes gong forward. That's your choice.
"Zeljko Vrba" wrote:
> >> Python recognizes the TAB character as valid indentation. TAB
> >> characters are evil. They should be banned from Python source code.
> >
> > AGREE! AGREE! AGREE!
> >
> The day TABs are banned from the source, I drop python forever. It took me
> too long to get used
Zeljko Vrba a écrit :
> On 2005-12-02, Micah Elliott <[EMAIL PROTECTED]> wrote:
>
>>On Dec 02, Dave Hansen wrote:
>>
>>>Python recognizes the TAB character as valid indentation. TAB
>>>characters are evil. They should be banned from Python source code.
>>
>>AGREE! AGREE! AGREE!
>>
>
> The da
On 2005-12-02, Micah Elliott <[EMAIL PROTECTED]> wrote:
> On Dec 02, Dave Hansen wrote:
>> Python recognizes the TAB character as valid indentation. TAB
>> characters are evil. They should be banned from Python source code.
>
> AGREE! AGREE! AGREE!
>
The day TABs are banned from the source, I
[EMAIL PROTECTED] wrote:
> > a decent description or tutorial... is better
>
> Sound good but... we're programmers, not documentation specialist or
> motivational speakers. Why, when I suggest fixing a design defect with
> code, do so many programmers want to respond with... documentation and
>
Christopher Subich <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>>
>>>From "The Design of Everyday Things", docs are a sign of poor design.
>> Even a single word, such as the word "Push" on the face of a door, is
>> an indication that the design can be improved. Please, rethink the
>> de
Peter Decker <[EMAIL PROTECTED]> wrote:
>
>I'm starting to suspect that the same people who are zealous about
>spaces are also the same people who look down on anyone who doesn't
>agree with their choice of text editor.
Text editors are like underwear. Everyone has their own favorite brand,
and n
> Try this:: from __future__ import braces
>>> from __future__ import braces
File "", line 1
SyntaxError: not a chance
>>>
Thanks, that's funny.
John
--
http://mail.python.org/mailman/listinfo/python-list
In <[EMAIL PROTECTED]>, JohnBMudd
wrote:
> Python could take over the programming world except one of it's best
> features (scope by indent) is a primary reason why it never will. It's
> not flexible enough. A large percentage of programmers won't even try
> the language.
Their loss. :-)
> An
Richard Brodie wrote:
> I doubt it: a lot of people have asserted something similar over
> the years but I don't remember anyone ever bothering to post
> a patch
people have posted more than just patches; see e.g.
http://www.google.com/search?q=corbascript
> (and if someone has it disappear
> the only programming language, for
> example, which does not need documentation is the natural language, and
> that contains so many ambiguities that humans often get instructions wrong.
Natural languag (e.g. English) does not need documentation? Was there
a shortage of big fat text books in y
On Dec 5, 2005, at 3:13 PM, Paul McNett wrote:
> Indeed, there is only one user interface that needs no
> documentation whatsoever.
Yeah, and it sucks! ;-)
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
--
http://mail.python.org/mailman/listinfo/python-list
Christopher Subich wrote:
> [EMAIL PROTECTED] wrote:
>
>>>From "The Design of Everyday Things", docs are a sign of poor design.
>>Even a single word, such as the word "Push" on the face of a door, is
>>an indication that the design can be improved. Please, rethink the
>>design instead of trying t
[EMAIL PROTECTED] wrote:
>
>>From "The Design of Everyday Things", docs are a sign of poor design.
> Even a single word, such as the word "Push" on the face of a door, is
> an indication that the design can be improved. Please, rethink the
> design instead of trying to compensate with more docume
> But you don't want it to be Python, is all.
No, the opposite. I'm pro-Python but anti-stagnant, anti-dogma and
anti-bad design.
If Python never changes that will be okay too. It *is* great!
John
--
http://mail.python.org/mailman/listinfo/python-list
> Meanwhile, see Tools/scripts/pindent.py
Yes, thanks, that's very close to what I was thinking of.
If it just went a little further and used semi-colons and braces then
it would be complete. Granted, that might still not be enough for
people who don't like scope by indent. It would be interes
Rick Wotnaz wrote:
> So, for instance, even a single character (like an opening or
> closing bracket or a semicolon) is an indication that the design
> can be improved.
Or a colon
--
http://mail.python.org/mailman/listinfo/python-list
Paul McNett wrote:
> Having .NET and Java in the world makes me into more of a hero when I
> can swoop in and get the real business problem solved using Python.
+1QOTW
--
http://mail.python.org/mailman/listinfo/python-list
Richard Brodie enlightened us with:
> I'm sure some folk can remember local coding styles that suggested
> using BEGIN and END as macros for curly brackets in C because { and
> } aren't intuitive.
I think that if you sink that low, you shouldn't be programming
anyway. Come on, if someone can't ev
Richard Brodie wrote:
> I'm sure some folk can remember local coding styles that suggested
> using BEGIN and END as macros for curly brackets in C because
> { and } aren't intuitive.
Indeed. Meanwhile, see Tools/scripts/pindent.py in the Python source
code distribution for a tool which understands
> If someone doesn't want
> to give Python a second look because of their own bigoted ideas, I say Python
> doesn't want that type of person to begin with.
Some days I feel the same way. I've described Python as a filter where
only the best get through. That's leads to a concentration of talent
[EMAIL PROTECTED] wrote:
>> even a single character (like an opening or closing bracket or a semicolon)
>> is an indication that the design can be improved.
>
>
> Close, there are two principles for good design: Afford proper use and
> Don't afford improper use. I could argue that not having to
[EMAIL PROTECTED] wrote:
> Python is the superior design, today. But, like Betamax tape format,
> Python isn't mainstream yet. And, sadly, maybe it never will be. I
> want that changed. I want Python to take over the world so I don't
> have to beg my next boss to let me use it. And if adding a
"Tom Anderson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Which is not to say that it's a bad idea - if it really is scaring off
> potential converts, then a dumbed-down dialect of python which uses curly
> brackets and semicolons might be a useful evangelical tool.
I doubt
> even a single character (like an opening or closing bracket or a semicolon)
> is an indication that the design can be improved.
Close, there are two principles for good design: Afford proper use and
Don't afford improper use. I could argue that not having to type extra
characters falls into t
[EMAIL PROTECTED] wrote:
> Where does that misconception that 2-3 spaces for indenting makes
> things less readable come from? There was an article in Comm. of the
> ACM on research into readability back in 1984 or so, that indicated 2-4
> spaces has very similar readability and 8 spaces significan
[EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
>> a decent description or tutorial... is better
>
> Sound good but... we're programmers, not documentation
> specialist or motivational speakers. Why, when I suggest fixing
> a design defect with code, do so many programmers want to
> respon
> a decent description or tutorial... is better
Sound good but... we're programmers, not documentation specialist or
motivational speakers. Why, when I suggest fixing a design defect with
code, do so many programmers want to respond with... documentation and
arguments instead of code?
>From "T
Tom Anderson wrote:
> Which is not to say that it's a bad idea - if it really is scaring off
> potential converts, then a dumbed-down dialect of python which uses curly
> brackets and semicolons might be a useful evangelical tool.
If we're going to be creating evangelical tools, I think a decent
d
D H wrote:
>
> How is that a problem that some editors use 8 columns for tabs and
> others use less? So what?
> A bigger problem I see is people using only 2 or 3 spaces for indenting.
> That makes large amounts of code much less readable. And of course it
> is a problem if you mix tabs and s
> It seems to me that the tabs-vs-spaces thing is really about who controls
the indentation: with spaces, it's the writer, and with tabs, it's the
reader.
Agreed.
> if [scope by indent] really is scaring off
potential converts, then a dumbed-down dialect of python which uses
curly
brackets and
On Sun, 4 Dec 2005 [EMAIL PROTECTED] wrote:
>> you're about 10 years late
>
> The same could be said for hoping that the GIL will be eliminated.
> Utterly hopeless.
>
> Until... there was PyPy. Maybe now it's not so hopeless.
No - structuring by indentation and the global lock are entirely diff
Peter Decker wrote:
> On 12/4/05, Mike Meyer <[EMAIL PROTECTED]> wrote:
See, I can make up bizarre scenarios where spaces cause
problems, too.
>>>
>>>Only if you don't know how decent editors behave. :)
>>
>>But the same is also true of tabs causing problems :-).
>
> I'm starting to s
On 12/4/05, Mike Meyer <[EMAIL PROTECTED]> wrote:
> >> See, I can make up bizarre scenarios where spaces cause
> >> problems, too.
> > Only if you don't know how decent editors behave. :)
>
> But the same is also true of tabs causing problems :-).
I'm starting to suspect that the same people
Benji York <[EMAIL PROTECTED]> writes:
>> See, I can make up bizarre scenarios where spaces cause
>> problems, too.
> Only if you don't know how decent editors behave. :)
But the same is also true of tabs causing problems :-).
http://www.mired.org/home/mwm/
Independent
Ed Leafe enlightened us with:
> See, I can make up bizarre scenarios where spaces cause problems,
> too.
You make me glad I'm always using tabs :)
Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
saf
Ed Leafe wrote:
> So let's say that you are using 4 spaces as your standard, but
> by accident type 5. You hit backspace, which deletes 4 spaces,
Nope, it would delete a single space. Then an additional backspace
would delete the 4.
> See, I can make up bizarre scenarios where space
[EMAIL PROTECTED] wrote:
> Python could take over the programming world except one of it's best
> features (scope by indent) is a primary reason why it never will. It's
> not flexible enough. A large percentage of programmers won't even try
> the language.
you're about 10 years late for this ki
> you're about 10 years late
The same could be said for hoping that the GIL will be eliminated.
Utterly hopeless.
Until... there was PyPy. Maybe now it's not so hopeless.
--
http://mail.python.org/mailman/listinfo/python-list
Ed Leafe wrote:
> > That depends on your editor. Mine (vim) can be instructed to insert
> > the appropriate amount of spaces on a tab, and remove them on a
> > backspace.
>
> So let's say that you are using 4 spaces as your standard, but
> by accident type 5. You hit backspace, which deletes
This is amazing.
Python could take over the programming world except one of it's best
features (scope by indent) is a primary reason why it never will. It's
not flexible enough. A large percentage of programmers won't even try
the language.
And even amongst Python enthusiast who appreciate the
Dave Hansen wrote:
> It's far more interesting to me _why_ people think indentation scoping
> is a bad thing. The answer I get back fall into two general
> categories: 1) I've heard/read/been told it's a bad thing, and 2) It
> causes portability problems.
I can tell you why it freightened me at f
On Dec 3, 2005, at 5:55 PM, Sybren Stuvel wrote:
> That depends on your editor. Mine (vim) can be instructed to insert
> the appropriate amount of spaces on a tab, and remove them on a
> backspace.
So let's say that you are using 4 spaces as your standard, but
by accident type 5. You hit b
On Dec 3, 2005, at 3:37 PM, Scott David Daniels wrote:
> They appear in different positions on different terminals (older hard-
> copy),
Is anyone still using such devices to program Python?
> do different things on different OS's,
Such as? I use OS X, Windows and Linux daily, and tab
D H enlightened us with:
> How is that a problem that some editors use 8 columns for tabs and
> others use less? So what?
I don't care either. I always use tabs, and my code is always
readable. Some people suggest one indents with four spaces, and
replaces eight spaces of indenting with a tab. No
Scott David Daniels wrote:
> Tom Anderson wrote:
>> So, could someone explain what's so evil about tabs?
>
>
> They appear in different positions on different terminals (older hard-
> copy), do different things on different OS's, and in general do not
> behave nicely. On many (but not all) syste
1 - 100 of 117 matches
Mail list logo
