Prothon Prototypes vs Python Classes

[Christian Tismer]

Re: Prothon Prototypes vs Python Classes

Michael wrote:
[color=blue]
>[color=green]
>> I think there are enough editors available to be able
>> to use one with fixed font.[/color]
>
>
> Exactly. I'd say the same thing about the problem with tabs. If your
> editor has some weird issue with tabs then fix it or use a different
> editor. It seems a bit odd to me that it's an issue at all.
>[color=green]
>> worse: you can lose indentation and totally mess up
>> The problems with mixed tabs and spaces are even
>>
>> You gave the best example by yourself: Use different editors,
>> even with fixed fonts, and you will wonder how they try
>> to "optimize" your tabs. Some try to help you with the indentation,
>> but they use tabs, even if you are not aware of it.
>> I don't say it is a hard problem. But it is an extra complication
>> which consumes a reasonable amount of Python code to check/repair,
>> like tabnanny.[/color]
>
>
> Why should an editor change anything in your program at all unless you
> tell it to? If it's changing tabs to spaces or vice versa then it sucks.
> If I want something optimized I'll enter a command telling it to do so.
> Otherwise hands off.[/color]

If you are on anyone's machine, maybe some Linux server, and
you don't find time to install an editor, then you use vim
for instance, and it depends on its configuration how it
handles Python code. Some indent for you the wrong way.
You have no choice if you are fixing something in a hurry.

....
[color=blue]
> A tab is a tab. This sounds like adding complexity in the effort to
> avoid complexity. If your editors are broken then stop using them.[/color]

I make my living by using several editors on several machines,
all the time. 95 % is ok, but it often comes to situations where
I have to hack "that code on this machine right now", and the user
won't give me the rights or the time to fine-tune my editor
environment.
There is also no choice of "hands-off". The customer wants me
to handle such minor problems as "the expert".
This is no matter of choice but daily practice :-)
--
Christian Tismer :^) <mailto:tismer@ stackless.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

[Michael]

Re: Prothon Prototypes vs Python Classes

[color=blue]
>I don't have very much sympathy for people who
>use poor editors to write programs. I've got a lot of
>sympathy for people who are stuck with defective
>rendering and printing programs for analyzing programs
>that they didn't write in the first place, though. Note that
>Python, which is mostly what we're talking about on this
>newsgroup, comes with a reasonably competent editor
>called Idle. There are very few environments where you
>can use Python at all where you can't use Idle.
>
>[/color]
I have sympathy for neither. If your editor sucks then change it. If
your printing program sucks than change it. I've never bothered using
Idle as I don't like GUI-based editors so I wouldn't really be familiar
with how it behaves.
[color=blue]
>I've never seen variable width fonts to change the width
>of spaces on the left, unless it was doing something like
>full justification.
>
>[/color]
I have, but then I throw such editors out after a single glance.
[color=blue]
>As far as rendering programs, the most obvious
>culprit is OE, which for all of its defects and security
>problems, is still one of the most used mail and newsgroup
>clients out there.
>
>[/color]
Do people actually post and read a lot of source code on mail or
newsgroup lists? Is that the main reason for not using tabs in code?
That'd seem a bit odd to me. Never actually tried using OE to read code.
I really don't use OE. Why wouldn't you just open the code in your code
editor of choice?
[color=blue]
>I'll also point out that even programs that properly follow
>the tab "standard" will not render well since the standard
>is that a tab goes to the next multiple of 8. The number
>8 has nothing to do with readability: it was decided on
>as the best compromise on compressing the number of
>characters going over a line when line speeds were *very*
>slow and teletypes really were electromechanic al monsters
>with these little metal stops called 'tabs' in the back.
>
>[/color]
What difference does it make what the standard length of a tab is as
long as it remains the same throughout the program? As long as the size
is uniform it should render just fine.
[color=blue]
>There is, of course, no standard at all for how to change
>the default tabbing in programs, which means that one
>has to deal with each and every one on an individual
>basis - if it's even possible.
>
>[/color]
Again, as long as it's uniform does it matter? It won't change the logic
of the code as long as it opens a tab as a tab and saves a tab as a tab.
If you can't trust your editor to do something that basic then trash it.
[color=blue]
>Reading the source for Idle is quite
>enlightening : there is a comment about Tk doing something
>rather absurd if you change the tab default.
>
>[/color]
I've glanced at it but never really read it. Why would Tk care what the
tab default of your editor is? In the source it's still a single tab
character.
[color=blue]
>Any programming editor worth the name will insert spaces
>when you use the tab key; likewise it will adjust with the
>backspace key. This is not a problem unique to Python,
>after all.
>
>[/color]
No, a good editor will do nothing you don't tell it to do. A good editor
will insert a tab when you insert a tab and delete a tab when you delete
a tab. Why should it use spaces to simulate a tab when you can just use
a tab? That sounds like needless complexity.
[color=blue]
>The same comment applies to variable width fonts. A good
>programming editor will not use them.
>
>[/color]
Agreed. I wouldn't use one that did use them.

[Jeff Epler]

Re: Prothon Prototypes vs Python Classes

On Sun, Mar 28, 2004 at 04:40:03PM +0000, Joe Mason wrote:[color=blue]
> In article <mailman.11.108 0489481.20120.p ython-list@python.org >, Jeff Epler wrote:[color=green]
> > def __call__(
> > __metaclass__ = PrototypeMeta
> >
> > class Thing:[/color]
>
> You're missing most of call() there.[/color]

whoops .. that was from the moment when I thought "I'd better do
something about calling a prototype" .. just remove it.
[color=blue]
>
> BTW, I've got three pure-python solutions now (four when this one's
> fixed) but it turns out they all suffer from a flaw:
>[color=green][color=darkred]
> >>> class TestProto: l = [][/color][/color]
> ...[color=green][color=darkred]
> >>> class Test2(TestProto ): pass[/color][/color]
> ...[color=green][color=darkred]
> >>> TestProto.l[/color][/color]
> [][color=green][color=darkred]
> >>> Test2.l[/color][/color]
> [][color=green][color=darkred]
> >>> Test2.l.append( 0)
> >>> Test2.l[/color][/color]
> [0][color=green][color=darkred]
> >>> TestProto.l[/color][/color]
> [0]
>
> We really need copy-on-write lists and dicts - and large objects in
> general - for this to work.[/color]

Can't you just follow the Python rule for classes with a little
difference?
* if you want some data to be shared by reference among the Prototype
and all its children, declare it at 'prototype' ('class') scope
* if you don't, create it in __init__

Jeff

[Christian Tismer]

Tabbing probs (was: Prothon Prototypes vs Python Classes)

Michael wrote:
....
[color=blue]
> Do people actually post and read a lot of source code on mail or
> newsgroup lists? Is that the main reason for not using tabs in code?
> That'd seem a bit odd to me. Never actually tried using OE to read code.
> I really don't use OE. Why wouldn't you just open the code in your code
> editor of choice?[/color]

No, I think you don't get at the real problem:
People do use tabs which are 8 spaces, but they
want their code to be indented by steps of four.
This creates mixed tabbing, and that's what you
see way too often when reading foreign code.
You have to adjust your editor to *that* tabbing,
before editing the file, and then convert or
live with it.

--
Christian Tismer :^) <mailto:tismer@ stackless.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

[Michael]

Re: Prothon Prototypes vs Python Classes

[color=blue]
> If you are on anyone's machine, maybe some Linux server, and
> you don't find time to install an editor, then you use vim
> for instance, and it depends on its configuration how it
> handles Python code. Some indent for you the wrong way.
> You have no choice if you are fixing something in a hurry.[/color]

[color=blue]
> I make my living by using several editors on several machines,
> all the time. 95 % is ok, but it often comes to situations where
> I have to hack "that code on this machine right now", and the user
> won't give me the rights or the time to fine-tune my editor
> environment.
> There is also no choice of "hands-off". The customer wants me
> to handle such minor problems as "the expert".
> This is no matter of choice but daily practice :-)[/color]

I understand. It just seems a bad idea to try to make the language work
with the editors instead of fixing the editors to work with the
language. If you're using spaces to act like tabs instead of tabs just
because some editors munge tabs.

[Joe Mason]

Re: Prothon Prototypes vs Python Classes

In article <mailman.55.108 0568422.20120.p ython-list@python.org >, Jeff Epler wrote:[color=blue][color=green]
>> BTW, I've got three pure-python solutions now (four when this one's
>> fixed) but it turns out they all suffer from a flaw:
>>[color=darkred]
>> >>> class TestProto: l = [][/color]
>> ...[color=darkred]
>> >>> class Test2(TestProto ): pass[/color]
>> ...[color=darkred]
>> >>> TestProto.l[/color]
>> [][color=darkred]
>> >>> Test2.l[/color]
>> [][color=darkred]
>> >>> Test2.l.append( 0)
>> >>> Test2.l[/color]
>> [0][color=darkred]
>> >>> TestProto.l[/color]
>> [0]
>>
>> We really need copy-on-write lists and dicts - and large objects in
>> general - for this to work.[/color]
>
> Can't you just follow the Python rule for classes with a little
> difference?
> * if you want some data to be shared by reference among the Prototype
> and all its children, declare it at 'prototype' ('class') scope
> * if you don't, create it in __init__[/color]

Possibly. You need something, at least - full copy-on-write seems like
the most transparent, but also the most work to set up. (I'm still
reading up on Self and others to find out how they handle these things.)

Hmm, your method sounds like it would work. In fact, I guess it would
already do that as written, wouldn't it?

The use case I was thinking of was something like this (I'm going to use
"object" instead of "class" from now on for pseudocode):

object UrlDispatcher:

def __init__(self):
self.handlers = { "http:" : HttpHandler, "ftp:" : FtpHandler }

object SSLUrlDispatche r(UrlDispatcher ):

def __init__(self):
UrlDispatcher._ _init__(self)
self.handlers["https:"] = SSLHttpHandler

So each instance of URLDispatcher and descendants has its own, entirely
unshared copy of handlers. One drawback of this is that if you add a
handler to UrlDispatcher at runtime, it isn't inherited by clones that
have already been initialized.

The other approach I suggested - replacing lists and dicts in
prototype-baed objects with a customized version - could make this more
transparent. Say, look up the value in SSLUrlDispatche r.handlers, then
UrlDispatcher.h andlers only if not found, and only then throw an error
if the key still isn't found. The question is whether it's useful to
put this complexity in the prototype system, or just provide classes
that do this in a library (which can just be done by third parties as
needed) and give coders the option of saying "handlers = ProtoDict()"
instead of "handlers = {}".

Joe

[John Roth]

Re: Prothon Prototypes vs Python Classes


"Michael" <mogmios@mlug.m issouri.edu> wrote in message
news:406829FF.5 060304@mlug.mis souri.edu...[color=blue]
>[color=green]
> >[/color]
> What difference does it make what the standard length of a tab is as
> long as it remains the same throughout the program? As long as the size
> is uniform it should render just fine.[/color]

I think you misunderstood. There is no "standard" length of
a tab. A tab is supposed to insert (or otherwise render the
equivalent of inserting) enough spaces to go to the next "tab stop",
which by convention is a multiple of 8 columns on a fixed
width mechanical typewriter. This is where tabs originated.
[color=blue][color=green]
> >There is, of course, no standard at all for how to change
> >the default tabbing in programs, which means that one
> >has to deal with each and every one on an individual
> >basis - if it's even possible.
> >
> >[/color]
> Again, as long as it's uniform does it matter? It won't change the logic
> of the code as long as it opens a tab as a tab and saves a tab as a tab.
> If you can't trust your editor to do something that basic then trash it.[/color]

It matters. 8 columns is much too wide for indents in readable code.
People do differ on that, but that seems to be the concensus.

John Roth

[Michael]

tabbing probs (was: Prothon Prototypes vs Python Classes)

[color=blue]
>I think you misunderstood. There is no "standard" length of
>a tab. A tab is supposed to insert (or otherwise render the
>equivalent of inserting) enough spaces to go to the next "tab stop",
>which by convention is a multiple of 8 columns on a fixed
>width mechanical typewriter. This is where tabs originated.
>
>[/color]
No, I just fail to see why it matters. A tab could be 4 columns, 8
columns, 15 columns, or whatever on a particular editor and code blocks
will still line up.
[color=blue]
>It matters. 8 columns is much too wide for indents in readable code.
>People do differ on that, but that seems to be the concensus.
>
>[/color]
So rather than switch editors or change your editors settings you'd
rather everyone be forced to use spaces? I presume four spaces? If
someone uses eight spaces to indent will that also break the code? It
seems to me that it'd be easier to configure an editor to show tabs as
four columns, if you so desire, than to configure an editor to show
eight spaces as four columns. Eight spaces is no easier to read than a
tab that takes eight columns. It's just more typing to correct the problem.

By my own preference, if I'm forced to use spaces to indent rather than
tabs, then I'll most likely use a single space to indent because I don't
want to deal with pressing the space and backspace keys multiple times
(trying to keep count) to make blocks line up correctly. I also don't
find it acceptable to use an editor which kludges together such space
using behavior for me to do what tabs would have done in the first
place. Overall, I think I find code that uses a single tab, rather than
a single space, to be easier to read.

[Michael]

Re: Tabbing probs

[color=blue]
> No, I think you don't get at the real problem:
> People do use tabs which are 8 spaces, but they
> want their code to be indented by steps of four.
> This creates mixed tabbing, and that's what you
> see way too often when reading foreign code.
> You have to adjust your editor to *that* tabbing,
> before editing the file, and then convert or
> live with it.[/color]

How would this create mixed tabbing unless sometimes they are using
spaces as tabs and sometimes using tabs as tabs? Will stopping the use
of tabs improve the situation or will that just mean that some people
use four spaces for indention and some people use eight.. both being a
hack to try to make spaces act like tabs. Why does it matter if a tab is
4 spaces long or 8 spaces long? Either way blocks should line up
assuming that nobody incorrectly tries to use spaces as tabs. If we get
rid of support for using tabs for indenting then what? Some people (like
myself) will continue using programs that insert tabs when they press
the tab key and everyone else will still be adjusting their editors to
try to substitute the desired number of spaces when the tab key is
pressed. What would be fixed?

It took a long time to convince me that Python wasn't insane for making
whitespace significant. If people really have so much trouble with it (I
don't) maybe it is a bad idea to use it to indicate code blocks?

[Christian Tismer]

Re: Tabbing probs

Michael wrote:
[color=blue]
>[color=green]
>> No, I think you don't get at the real problem:
>> People do use tabs which are 8 spaces, but they
>> want their code to be indented by steps of four.
>> This creates mixed tabbing, and that's what you
>> see way too often when reading foreign code.
>> You have to adjust your editor to *that* tabbing,
>> before editing the file, and then convert or
>> live with it.[/color]
>
>
> How would this create mixed tabbing unless sometimes they are using
> spaces as tabs and sometimes using tabs as tabs? Will stopping the use
> of tabs improve the situation or will that just mean that some people
> use four spaces for indention and some people use eight..[/color]

....

Once again:
They use tabs but they want to do 4 space indentation.
That means they use a tab when it fits, and 4 spaces when not...

def mixed_tabs():
.....if blah: # this is 4 spaces
--------pass # this is one tab

--
Christian Tismer :^) <mailto:tismer@ stackless.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

[rzed]

Re: tabbing probs (was: Prothon Prototypes vs Python Classes)

Michael <mogmios@mlug.m issouri.edu> wrote in
news:406848CD.5 070100@mlug.mis souri.edu:
[color=blue]
>[color=green]
>>I think you misunderstood. There is no "standard" length of
>>a tab. A tab is supposed to insert (or otherwise render the
>>equivalent of inserting) enough spaces to go to the next "tab
>>stop", which by convention is a multiple of 8 columns on a fixed
>>width mechanical typewriter. This is where tabs originated.
>>
>>[/color]
> No, I just fail to see why it matters. A tab could be 4 columns,
> 8 columns, 15 columns, or whatever on a particular editor and
> code blocks will still line up.
>[color=green]
>>It matters. 8 columns is much too wide for indents in readable
>>code. People do differ on that, but that seems to be the
>>concensus.
>>
>>[/color]
> So rather than switch editors or change your editors settings
> you'd rather everyone be forced to use spaces? I presume four
> spaces? If someone uses eight spaces to indent will that also
> break the code? It seems to me that it'd be easier to configure
> an editor to show tabs as four columns, if you so desire, than
> to configure an editor to show eight spaces as four columns.
> Eight spaces is no easier to read than a tab that takes eight
> columns. It's just more typing to correct the problem.
>
> By my own preference, if I'm forced to use spaces to indent
> rather than tabs, then I'll most likely use a single space to
> indent because I don't want to deal with pressing the space and
> backspace keys multiple times (trying to keep count) to make
> blocks line up correctly. I also don't find it acceptable to use
> an editor which kludges together such space using behavior for
> me to do what tabs would have done in the first place. Overall,
> I think I find code that uses a single tab, rather than a single
> space, to be easier to read.
>[/color]

As long as you are the only one to work on your code, your
viewpoint may not cause you any problems. I and others are telling
you that tabs can cause problems with some software, and you can
rightly avoid using that software as long as you don't share your
code. Once that happens, though, things get more complicated.

One aspect of the tab/spaces issue involves working on other
people's code. You like tabs, I like spaces. Supposing that I
prefer to show a single level of indention as five spaces (for some
reason), what happens when I have to make a change to your code? If
I am aware that you use tabs, then I can adjust to it, but how do I
become aware? To me, it looks like you're putting five spaces in
for each level of indention. The chances are that I won't know
otherwise until I've made some changes, saved the file and tried to
run it. If some of those changes involve changing an indention
level, I may insert spaces before or after your tabs, so now such a
change leaves a line with mixed tabs and spaces, but no visible
indication of which is where. Now when someone else grabs the code
and displays it with tabs set to four spaces instead, what happens?
No sympathy there, either, I would bet, but you do see how things
like that can happen even using only your tools, don't you?

--
rzed

[Michael]

Re: tabbing probs

[color=blue]
>As long as you are the only one to work on your code, your
>viewpoint may not cause you any problems. I and others are telling
>you that tabs can cause problems with some software, and you can
>rightly avoid using that software as long as you don't share your
>code. Once that happens, though, things get more complicated.
>
>[/color]
That's what you're saying but what I'm hearing is that using tabs +
spaces causes problems with some (crappy) software. If I start using an
editor that only allows uppercase letters is Python going to disallow
lowercase letters to solve a problem with my editor? I'd hope not.
Likewise it makes no sense to remove tab indenting because some software
has a problem with the difference between tabs and spaces.
[color=blue]
>One aspect of the tab/spaces issue involves working on other
>people's code. You like tabs, I like spaces. Supposing that I
>prefer to show a single level of indention as five spaces (for some
>reason), what happens when I have to make a change to your code? If
>I am aware that you use tabs, then I can adjust to it, but how do I
>become aware? To me, it looks like you're putting five spaces in
>for each level of indention. The chances are that I won't know
>otherwise until I've made some changes, saved the file and tried to
>run it. If some of those changes involve changing an indention
>level, I may insert spaces before or after your tabs, so now such a
>change leaves a line with mixed tabs and spaces, but no visible
>indication of which is where. Now when someone else grabs the code
>and displays it with tabs set to four spaces instead, what happens?
>No sympathy there, either, I would bet, but you do see how things
>like that can happen even using only your tools, don't you?
>[/color]
Couldn't you just look at the code and see that it's using tabs or
spaces as long as it's uniform? How hard is it to tell the difference?
Or is it that your editor makes spaces look like tabs so that it's
difficult to tell? I can see how it could be a problem. I just can't see
how making tabs not work will fix the problem. If anything I'd make it
so one whitespace character counts as one level of indention..
regardless to if your editor shows you the fact. Using multiple spaces
or tabs or a combination thereof which don't add up correctly to the
required indention level should just throw an error. That's closer to
what happens currently and it makes more sense to me than limiting
indenting to using only spaces. I think the problem will exist as long
as whitespace is significant but I happen to have grown fond of Python's
use of whitespace.

[PF]

Re: Tabbing probs


I use tabs only. Can't stand spaces. I don't want to hit backspace 4
times to indent back after the end of a block.
When I open python files which use spaces, and I insert a code line into
them, my editor will insert tabs. And here is a bug. Then I set it to use
spaces. Then I open another files, which contains tabs. Argh. I'd like my
editor to test automatically if a file has spaces or tabs. Anyone knows a
good editor on linux which does this ? And also has good macros ?





--
Utilisant M2, le client e-mail révolutionnaire d'Opera :

http://www.opera.com/

[Michael]

tabbing probs (was: Prothon Prototypes vs Python Classes)

[color=blue]
>I think you misunderstood. There is no "standard" length of
>a tab. A tab is supposed to insert (or otherwise render the
>equivalent of inserting) enough spaces to go to the next "tab stop",
>which by convention is a multiple of 8 columns on a fixed
>width mechanical typewriter. This is where tabs originated.
>
>[/color]
No, I just fail to see why it matters. A tab could be 4 columns, 8
columns, 15 columns, or whatever on a particular editor and code blocks
will still line up.
[color=blue]
>It matters. 8 columns is much too wide for indents in readable code.
>People do differ on that, but that seems to be the concensus.
>
>[/color]
So rather than switch editors or change your editors settings you'd
rather everyone be forced to use spaces? I presume four spaces? If
someone uses eight spaces to indent will that also break the code? It
seems to me that it'd be easier to configure an editor to show tabs as
four columns, if you so desire, than to configure an editor to show
eight spaces as four columns. Eight spaces is no easier to read than a
tab that takes eight columns. It's just more typing to correct the problem.

By my own preference, if I'm forced to use spaces to indent rather than
tabs, then I'll most likely use a single space to indent because I don't
want to deal with pressing the space and backspace keys multiple times
(trying to keep count) to make blocks line up correctly. I also don't
find it acceptable to use an editor which kludges together such space
using behavior for me to do what tabs would have done in the first
place. Overall, I think I find code that uses a single tab, rather than
a single space, to be easier to read.

[Michael]

Re: Tabbing probs

[color=blue]
> Once again:
> They use tabs but they want to do 4 space indentation.
> That means they use a tab when it fits, and 4 spaces when not...
>
> def mixed_tabs():
> ....if blah: # this is 4 spaces
> --------pass # this is one tab[/color]

Ahh, I think I follow you. I think that'd be the mark of a bad coder.
Whichever method of indenting a program uses should be carried out in a
uniform manner. Either all spaces or all tabs. I just use one tab per
level of indention. One space per level of indention would also be
acceptable to me (but hard to read). Four spaces to me would be
confussing (because of the need to count) and annoying (because of the
need to press space four times per level of indention per line). Mixed
would be right out.