> I'll try. Is there some predefined symbol by which I can recognize
> sunos-3 from SunOS 4?
I just added #ifdef sun, which is defined. I don't know if sunOS 4
adds another define to distinguish it from earlier versions.
> When I print it the pages are numbered. Maybe you should shorten the
> page height in "myformat.sty" -- I set it for European paper size,
> which is about 12 inches high, while yours is likely to be 11 inches.
Ah, that explains it. Would be nice if your style worked for
either size (may be we need a4.sty).
> Actually, Python lacks explicit declarations as well -- and indeed it
True. I was just adding up perl's sins! It seems funny that you
have to import definitions but not declare variable! Even a `def
<var>' will help. I would also like `def <var> <type>' or
something similar.
> Python on purpose gives you one way to do most things (one way for
> each things, not one way for all things together!), on the account
> that it makes the choice easier, and makes programs more readable --
Perl does go overboard in the number of choices it provides but
common idioms can become easier to read if they have a special
form. Even though x[i*j] += y is equiv. to x[i*j] = x[i*j] + y, I
favor the first form. And the same is true of other idioms. So
`only one way' seems limiting.
> There is a demo directory in the distribution which tries to give the
> examples, and part of the library is also intended as such -- but more
> examples always help.
You may also want to post new useful scripts to lang.misc to
stimulate discussion (and may be flames. But we can ignore those)
and to give people an opportunity to see python in action.
(Mailing lists tend to be overwhelming for beginners).
> >I should be able to say
> > result += b
> >or better still,
> > result += [a,b,c]
>
> The latter should automatically work if we let x += y be syntactic
> sugar for x = x+y. Note that result = result + [x] has a different
> meaning than result.append(x)...
I understand the difference -- that is why I think overloading
operators is worth considering. The '+' in result += b is a
different operator from 'result + [a,b,c]'. As long as the type
signature is different, there should not be a problem in resolving
operators, right?
> For simple cases you can use tuples -- this keeps values together but
> you reference them by position. For larger cases you indeed have to
> use classes -- but what's ugly about that?
Because all I want is to name tuple constituents. A class is a
much heavier weight feature. I think what is lacking is *syntax*
as in a referentially transparent language you can easily translate
tuple.field to tuple.position. I suppose you do need declarations.
> You can do this! If a is a list of three elements, just write
> [x, y, z] = a
Good! Guess I should reread the tutorial!
> import posix, string
> pipe = posix.popen('ls -l', 'r')
> for line in pipe.readlines():
> if line[:5] = 'total': continue
> [perm,links,user,group,size,mon,day,YoT,name] = string.split(line)[:9]
> print size, '\t' + name
This is exactly the kind of thing that will let people compare
python with other languages. Shouldn't that `string.split' be
`line.split'? Why is '\t' + name preferable to '\t', name?
> 'total', which makes this kind of scripts so dangerously non-portable.
Though that does not depend on the scripting language.
> There's already a built-in module 'regexp', which does what you want.
> Access is slightly clumsier than Perl (there's no special syntax to
> handle regular expressions) and the expressions are simpler (just
> Henry Spencer's regexp package), but what you want is there...
I should really get reacquainted with python. It has been while
and my short term memory is getting worse:-(
- -- bakul
PS: one more comment. The fact that for built in things you can
use unqualfied procedures (operators?) such as `len(string)' but
for user defined class instances you have to do `foo.len()' seems
inconsistent -- I don't know what can be done though.
------- End of Forwarded Message