Few things

[bearophile]

Hello,
here are a four more questions (or suggestions) for the language
(probably people have already discussed some of/all such things:

I've seen the contracts for Python:
http://www.wayforward.net/pycontract/
http://www.python.org/peps/pep-0316.html
They look interesting and nice, how Python developers feel about
accepting something like this in the standard language? (Maybe they
are a bit complex).
I think it can be useful a little stat standard module that computes
permutations, combinations, median (quickselect), etc. There is even a
C implementation (of most of them):
http://probstat.sourceforge.net/
Probably some Win users can appreciate to have this already compiled
(and built in).
A command like this:
print 0x9f, 054135
This prints an hex and octal. I think the syntax for the hex is a bit
ugly; and the syntax for the octal looks just dangerous (and wrong) to
me.
In some python source codes that I'm finding around, I find things
like:
def foo():
'''This is just a
silly text'''
....

Because:
def foo():
'''This is just a
silly text'''
print foo.__doc__

Outputs:
This is just a
silly text

I think a better syntax for such multiline strings can be something
like: remove from all the beginnings of the lines successive to the
first one a number of spaces equal to the position of ''' in the
soucecode.
With this sintax such print outputs:
This is just a
silly text

Note: even less indentation of the lines successive the first one can
be simply ignored:
def foo2():
'''This is just a
silly text'''
print foo.__doc__

Outputs:
This is just a
silly text

Hello,
Bearophile

[bearophile]

Thank you Josiah Carlson for your answers. If certain parts of my
messages upset you, then you can surely skip those parts.
(Now I am reading a big good manual: "Learning Python, II ed.", so in
the future I hope to write better things about this language.)

That is simple and clean?<
Well, it's a clean way to express such complexity.
And now I think decorators aren't so fit for such purpose (they
produce less clear pre-post). The pre-posts in the docs seem better to
me.

Then again, I document and test, and haven't used pre/post conditions in 5+ years.<

Yep, documentation and doctests (etc) are useful.

but I've seen that lots of people have already discussed such topic).<<
Discussion of the @ decorator syntax is a moot point.<
I know, I noticed that... Still, only few things are fixed in stone
:-]

Think of it like an 'example' in the documentation, where the code is provided for doing both permutations and combinations.<

Ah, now I see.
In my original post of this thread I have given an URL of some
routines written in C because they are about 10 times faster than the
routines that I can write in Python.

If you are interested I can give the Python Quickselect code, etc.<<

No thank you, I have my own.<
I see. I haven't tried to force you to take my routines, but to offer
any interested person a way to cheek my words.

Ick. In Python, the language is generally read left to right, in a similar fashion to english. The prefix notation of 0<octal> and
0x<hex>, in my opinion, reads better than your
postfix-with-punctuation notation.<

As you say, it's your opinion, and I respect it, but in mathematics I
think you usually put the base at the end of the number, as a small
subscripted number (but I understand your following explanations).

I'll also mention that two of your examples; afa35a_16 and Fi3pK_64, are valid python variable names<

Uh, I am sorry... As I feared, I have written a silly thing :-)

I much prefer just using decimal and offering the proper base

notation afterwards in a comment...<

I agree.

I'll avoid to give hugs,
Bearophile

[Scott David Daniels]

Josiah Carlson wrote:

An option if you want to get all of the base representations available
is a prefix notation that is similar to what already exists. I'm not
advocating it (because I also think its crap), but the following fixes
the problems with your postfix notation, and is explicit about bases.
0<base>_<number >
like:
016_feff
02_10010010101
010_9329765872
08_767

The above syntax is:
1. unambiguous
2. readable from left-to-right

I built an interpreted language where based numbers were of the form:
<base-1>..<number>
It has 1 & 2, can often be snagged from standard lexers, and keeps _
available for group-separator (for things like 1_000_000_000).
The nice thing is that it is unambiguous no matter what base you
read in. It also worked for floating point values, but we were never
happy with how the exponent should be done.
f..feff == 1..1111_1110_11 11_1111
== 1..1_111_111_01 1_111_111 == 7..77377
1..10010010101
9..9329765872
7..767
Takes a bit to associate 9 with base ten, but lexing the number is
duck soup. Note I am not advocating this syntax any more than Josiah
is advocating his. I just find alternate representations interesting.

--Scott David Daniels
Sc***********@A cm.Org