python coding contest

60 views
Skip to first unread message

Simon Hengel

unread,
Dec 25, 2005, 10:39:47 AM12/25/05
to pytho...@python.org
Hello,
we are hosting a python coding contest an we even managed to provide a
price for the winner...

http://pycontest.net/

The contest is coincidentally held during the 22c3 and we will be
present there.

https://events.ccc.de/congress/2005/wiki/Python_coding_contest

Please send me comments, suggestions and ideas.

Have fun,

--
Simon Hengel

Christian Tismer

unread,
Dec 25, 2005, 11:42:34 AM12/25/05
to Simon Hengel, pytho...@python.org
Simon Hengel wrote:
> Hello,
> we are hosting a python coding contest an we even managed to provide a
> price for the winner...
>
> http://pycontest.net/

Nice idea to have a contest, of course!

What I dislike a bit is the winning criterion:
Shortest possible Python module?
I'm envisioning lots of convoluted one-liners which
are more suitable to a different P-language... :-)

How about """best compromize between shortness and readibility
plus elegance of design"""?
Well, this slightly raises the skill level of the reviewers,
but will clearly make the results more enjoyable...

cheers - chris
--
Christian Tismer :^) <mailto:tis...@stackless.com>
tismerysoft GmbH : 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 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

Simon Hengel

unread,
Dec 25, 2005, 12:05:37 PM12/25/05
to Christian Tismer, pytho...@python.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I'm envisioning lots of convoluted one-liners which
> are more suitable to a different P-language... :-)

I feel that python is more beautiful and readable, even if you write
short programs.

> How about """best compromize between shortness and readibility
> plus elegance of design"""?

I would love to choose those criteria for future events. But I'm not
aware of any algorithm that is capable of creating a ranking upon them.
Maybe we can come up with a solution. Any ideas?

Cheers, Simon.

- --
python coding contest - http://www.pycontest.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDrtFhd4QlweXdn3ERAn7tAJ9PEpOdqyfDhvHo7+TVy7RravwA/QCg4g9g
TdCYEDqOsL5qxQarsUI7jow=
=/KN6
-----END PGP SIGNATURE-----

Christian Tismer

unread,
Dec 25, 2005, 12:29:27 PM12/25/05
to Simon Hengel, pytho...@python.org
Simon Hengel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> I'm envisioning lots of convoluted one-liners which
>> are more suitable to a different P-language... :-)
> I feel that python is more beautiful and readable, even if you write
> short programs.
>
>> How about """best compromize between shortness and readibility
>> plus elegance of design"""?
> I would love to choose those criteria for future events. But I'm not
> aware of any algorithm that is capable of creating a ranking upon them.
> Maybe we can come up with a solution. Any ideas?

Me neither :-)

Maybe a compromize proposal could be like this:

- Squeezing many lines into one using semicola does not help,
the program will be expanded to use one statement per line

- blank lines are allowed and not counted if they are not
needed as part of the code

- the length of names does not count, unless the code depends on it.

Some harmonization procedure might be applied to every solution
before counting lines, in order to avoid spectacular cryptic stuff.

I have no idea whether I'm serious about this.
Having this said, I'm trashing my one-liner :-))

if-it-doesn't-look-like-Python-it-is-not-Python - ly y'rs -- chris

Tim Hochberg

unread,
Dec 25, 2005, 1:42:50 PM12/25/05
to pytho...@python.org
Christian Tismer wrote:
> Simon Hengel wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>
>>>I'm envisioning lots of convoluted one-liners which
>>>are more suitable to a different P-language... :-)
>>
>>I feel that python is more beautiful and readable, even if you write
>>short programs.
>>
>>
>>>How about """best compromize between shortness and readibility
>>>plus elegance of design"""?
>>
>>I would love to choose those criteria for future events. But I'm not
>>aware of any algorithm that is capable of creating a ranking upon them.
>>Maybe we can come up with a solution. Any ideas?
>
>
> Me neither :-)
>
> Maybe a compromize proposal could be like this:
>
> - Squeezing many lines into one using semicola does not help,
> the program will be expanded to use one statement per line
>
> - blank lines are allowed and not counted if they are not
> needed as part of the code

These two would be easy to acomplish using something like:

def countchars(text):
n = 0
for line in text.split('\n'):
n += len(line.strip())
return n

This would ignore leading and trailing white space as well as blank lines.

Also makes

a=5; b=10

measure as one character longer than

a = 5
b = 10

which can only be good.

>
> - the length of names does not count, unless the code depends on it.

Probably too hard.

>
> Some harmonization procedure might be applied to every solution
> before counting lines, in order to avoid spectacular cryptic stuff.

I thought the metric was characters, not lines. At least that's what the
'about' page says. You still get hit by leading whitespace on multiple
line programs though.


-tim

Christian Tismer

unread,
Dec 25, 2005, 2:21:02 PM12/25/05
to Tim Hochberg, pytho...@python.org
Tim Hochberg wrote:
> Christian Tismer wrote:

...

>> - Squeezing many lines into one using semicola does not help,
>> the program will be expanded to use one statement per line
>>
>> - blank lines are allowed and not counted if they are not
>> needed as part of the code
>
> These two would be easy to acomplish using something like:
>
> def countchars(text):
> n = 0
> for line in text.split('\n'):
> n += len(line.strip())
> return n
>
> This would ignore leading and trailing white space as well as blank lines.
>
> Also makes
>
> a=5; b=10
>
> measure as one character longer than
>
> a = 5
> b = 10
>
> which can only be good.

Good point!

>> - the length of names does not count, unless the code depends on it.
>
> Probably too hard.

I don't want to reward people for using ultra-short, unreadable
variable names, but also not to enable them to code algorithms
by them :-)
My idea was to rename all variables by a simple transformation
of the code objects, with the side rule that the program still works.
This can be automated rather easily.

> I thought the metric was characters, not lines. At least that's what the
> 'about' page says. You still get hit by leading whitespace on multiple
> line programs though.

So why not simply count length of code objects? :-)
Plus count every changeable name as one, others by length.
Same for constants, so we don't get tricked by encoding
the whole program by a tuple engine :-)

ciao - chris

Alex Martelli

unread,
Dec 25, 2005, 3:13:54 PM12/25/05
to
Christian Tismer <tis...@stackless.com> wrote:
...

> Maybe a compromize proposal could be like this:
>
> - Squeezing many lines into one using semicola does not help,
> the program will be expanded to use one statement per line
>
> - blank lines are allowed and not counted if they are not
> needed as part of the code

I would suggest that all whitespace (except within string literals)
should be ignored, as well.

Alex

Alex Martelli

unread,
Dec 25, 2005, 3:29:11 PM12/25/05
to
Tim Hochberg <tim.ho...@ieee.org> wrote:
...

> These two would be easy to acomplish using something like:
>
> def countchars(text):
> n = 0
> for line in text.split('\n'):
> n += len(line.strip())
> return n
>
> This would ignore leading and trailing white space as well as blank lines.

However, it would still make
a=23
"better" than
a = 23
and there's really no reason for that. I would instead suggest using
the tokenize module.

> > - the length of names does not count, unless the code depends on it.
>
> Probably too hard.

Ignoring the length of identifiers is easy if you're tokenizing anyway.
Checking if "the code depends on" the exact spelling of its identifiers
is a lot harder, admittedly -- you could try emitting a variant of the
code where all identifiers which are not builtins are systematically
replaced with 'x0001', 'x0002', etc, and verify that the variant still
passes the test, but it's definitely a nontrivial one. I think we'll
have to accept the fact that the "shortest program" will use one-letter
identifiers for everything except builtins.


> > Some harmonization procedure might be applied to every solution
> > before counting lines, in order to avoid spectacular cryptic stuff.
>
> I thought the metric was characters, not lines. At least that's what the
> 'about' page says. You still get hit by leading whitespace on multiple
> line programs though.

Definitely, characters. A high-granularity measure is essential to
reduce the chance of ties. Even so there may well be equal-first-place
winners -- hope they're not solved in terms of first submission, since
submitting at 14:00 UTC is WAY easier for Europe residents (residents of
the Americas would have to go to bed VERY late, get up VERY early, or
spend extra effort setting up cron jobs), and that would bias everything
in a most unfair manner.


Alex

André

unread,
Dec 25, 2005, 5:58:28 PM12/25/05
to
Neat idea!

I'm far from being a decent Python programmer but I managed (for fun)
to do it in a one-liner; however, it was definitely longer (in term of
number of characters) than the more readable multi-line solution.

André

Tobias Bell

unread,
Dec 25, 2005, 6:57:01 PM12/25/05
to
André schrieb:
> Neat idea!
Indeed

>
> I'm far from being a decent Python programmer but I managed (for fun)
> to do it in a one-liner; however, it was definitely longer (in term of
> number of characters) than the more readable multi-line solution.

I made a readable version with 352 bytes and a non-readable with 290
bytes. But it's a really ugly lambda, map, reduce kludge. Looks like Perl.

>
> André
>

Tobias

Steven D'Aprano

unread,
Dec 25, 2005, 7:10:41 PM12/25/05
to
On Sun, 25 Dec 2005 18:05:37 +0100, Simon Hengel wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> I'm envisioning lots of convoluted one-liners which
>> are more suitable to a different P-language... :-)
> I feel that python is more beautiful and readable, even if you write
> short programs.
>
>> How about """best compromize between shortness and readibility
>> plus elegance of design"""?
> I would love to choose those criteria for future events. But I'm not
> aware of any algorithm that is capable of creating a ranking upon them.


What is your algorithm for determining "shortest" program? Are you
counting tokens, lines or characters? Does whitespace count?


--
Steven.

rbt

unread,
Dec 25, 2005, 7:14:43 PM12/25/05
to
If whitespace and var names count, these things are going to be ugly :)

Christian Tismer

unread,
Dec 25, 2005, 7:50:10 PM12/25/05
to Simon Hengel, pytho...@python.org
Simon Hengel wrote:
>> I would suggest that all whitespace (except within string literals)
>> should be ignored, as well.

> Good point, but i assume that is not possible with regular expressions.

No, but a trivial task using the compiler.

they should have taken this as a second challenge :-) -- chris

Simon Hengel

unread,
Dec 25, 2005, 7:43:44 PM12/25/05
to pytho...@python.org
> I would suggest that all whitespace (except within string literals)
> should be ignored, as well.
Good point, but i assume that is not possible with regular expressions.

Cheers, Simon

Steven D'Aprano

unread,
Dec 25, 2005, 7:58:49 PM12/25/05
to

Yes, but the question is, is two lines and 347 characters ugly enough to
win?

--
Steven.

Simon Hengel

unread,
Dec 25, 2005, 7:56:54 PM12/25/05
to pytho...@python.org
> Definitely, characters. A high-granularity measure is essential to
> reduce the chance of ties. Even so there may well be equal-first-place
> winners -- hope they're not solved in terms of first submission, since
> submitting at 14:00 UTC is WAY easier for Europe residents (residents of
> the Americas would have to go to bed VERY late, get up VERY early, or
> spend extra effort setting up cron jobs), and that would bias everything
> in a most unfair manner.

Not sure what to do about it, is there something more fair
than first come first serve?

Simon Hengel

unread,
Dec 25, 2005, 8:07:42 PM12/25/05
to pytho...@python.org
> What is your algorithm for determining "shortest" program? Are you
> counting tokens, lines or characters? Does whitespace count?

like:
$wc -c seven_seg.py

At the moment we have to live with characters, and yes whitespace
characters do count. Sorry for that.

Have fun,

Simon Hengel

André Malo

unread,
Dec 25, 2005, 8:21:11 PM12/25/05
to
* Steven D'Aprano wrote:

> is two lines and 347 characters ugly enough to win?

Nope. 3 lines / 179 chars here >:->
Yes, it's quite unreadable.

(The problem is that I need to find an internet cafe on 28/29th in order to
be able to submit)

nd
--
my @japh = (sub{q~Just~},sub{q~Another~},sub{q~Perl~},sub{q~Hacker~});
my $japh = q[sub japh { }]; print join #########################
[ $japh =~ /{(.)}/] -> [0] => map $_ -> () # André Malo #
=> @japh; # http://www.perlig.de/ #

rbt

unread,
Dec 25, 2005, 8:43:49 PM12/25/05
to

Does positioning matter? For example, say I give it '123' is it ok to
output this:

1
2
3

Or does it have to be 123

Tim Hochberg

unread,
Dec 25, 2005, 9:05:40 PM12/25/05
to pytho...@python.org

No. I have 8 lines and 175 chars at present. And, I expect that's gonna
get beaten.

-tim

Tim Hochberg

unread,
Dec 25, 2005, 9:14:24 PM12/25/05
to pytho...@python.org

Is it necessary to keep the input parameter as 'input'? Reducing that to
a single character drops the length of a program by at least 8
characters. Technically it changes the interface of the function, so
it's a little bogus, but test.py doesn't check. (Personally I prefer
that if be illegal, but if it's legal I'll have to do it).

-tim

rbt

unread,
Dec 25, 2005, 9:27:28 PM12/25/05
to

isn't the word 'input' a special word anyway???

Simon Hengel

unread,
Dec 25, 2005, 9:33:19 PM12/25/05
to pytho...@python.org
> Is it necessary to keep the input parameter as 'input'? Reducing that to
> a single character drops the length of a program by at least 8
> characters. Technically it changes the interface of the function, so
> it's a little bogus, but test.py doesn't check. (Personally I prefer
> that if be illegal, but if it's legal I'll have to do it).

You may change input to something more short, like x. Everything that
passes the test, has a good chance to be accepted.

Cheers,

Simon Hengel

Justin Azoff

unread,
Dec 25, 2005, 9:42:17 PM12/25/05
to
>>> c=open("seven_seg.py").read()
>>> len(c)
251
>>> len(c.replace(" ",""))
152

:-)

Knowing me, I'll forget to submit it.

Remi Villatel

unread,
Dec 25, 2005, 9:47:02 PM12/25/05
to
André Malo wrote:

>>is two lines and 347 characters ugly enough to win?

> Nope. 3 lines / 179 chars here >:->
> Yes, it's quite unreadable.

I'm in for the second place with 4 lines / 228 chars.

> (The problem is that I need to find an internet cafe on 28/29th in order to
> be able to submit)

Do your best! I'd really like to see your code. Right now, 179 chars
doesn't seem enough for me to write a "Hello world". ;-)

--
==================
Remi Villatel
maxilys_@_tele2.fr
==================

Steven D'Aprano

unread,
Dec 25, 2005, 9:46:21 PM12/25/05
to
On Mon, 26 Dec 2005 02:21:11 +0100, André Malo wrote:

> * Steven D'Aprano wrote:
>
>> is two lines and 347 characters ugly enough to win?
>
> Nope. 3 lines / 179 chars here >:->
> Yes, it's quite unreadable.

I think Perl coders should be banned from this contest, as they have an
unfair advantage in that they have more experience with write-only code.

*grin*


--
Steven.

Alex Martelli

unread,
Dec 25, 2005, 9:54:14 PM12/25/05
to
Christian Tismer <tis...@stackless.com> wrote:

> Simon Hengel wrote:
> >> I would suggest that all whitespace (except within string literals)
> >> should be ignored, as well.
>
> > Good point, but i assume that is not possible with regular expressions.
>
> No, but a trivial task using the compiler.

Actually, the tokenize module of the standard library is plenty for this
(and any other merely lexical-level task).

> they should have taken this as a second challenge :-) -- chris

I guess there can be more challenges, particularly because I don't think
having the prize is really that important -- one does it for fun and
kudos (a nicely designed, color-printed certificate of victory, suitable
for framing and displaying prominently, would be better, if there are
funds to make it, than a keyboard which one might not use...;-).


Alex

Alex Martelli

unread,
Dec 25, 2005, 9:54:14 PM12/25/05
to
Simon Hengel <si...@airlangen.de> wrote:

> > Definitely, characters. A high-granularity measure is essential to
> > reduce the chance of ties. Even so there may well be equal-first-place
> > winners -- hope they're not solved in terms of first submission, since
> > submitting at 14:00 UTC is WAY easier for Europe residents (residents of
> > the Americas would have to go to bed VERY late, get up VERY early, or
> > spend extra effort setting up cron jobs), and that would bias everything
> > in a most unfair manner.
>
> Not sure what to do about it, is there something more fair
> than first come first serve?

Random choice between entries with identical number of characters would
be more fair, because "first come first served" strongly favours
European residents, given the timing at which entries are first
accepted, as I mentioned. Time of entry could be made a factor if the
geographical bias was removed (all entries in the first N hours of the
context could be considered as "postmarked" at the same instant, with N
computed so as to ensure some reasonable time in the evening for
residents of Asia and the Americas -- for later entries, using time of
submission is indeed fine).

If you just sent PDFs of a nicely designed color certificate of "First
Prize Ex Aequo" to all entrants who are tied for victory on the basis of
number of characters, I would not mind if the keyboard went to the
"first tied winner to submit" (since I'm not particularly keen to get
the keyboard, just the fun and kudos of claiming I'm the/a winner, in
the unlikely event my submission should be among the shortest;-).


Alex

Alex Martelli

unread,
Dec 25, 2005, 9:56:08 PM12/25/05
to
rbt <r...@athop1.ath.vt.edu> wrote:

> Tim Hochberg wrote:
> >
> > Is it necessary to keep the input parameter as 'input'? Reducing that to
> > a single character drops the length of a program by at least 8
> > characters. Technically it changes the interface of the function, so
> > it's a little bogus, but test.py doesn't check. (Personally I prefer
> > that if be illegal, but if it's legal I'll have to do it).
>

> isn't the word 'input' a special word anyway???

No, just the name of a builtin -- no problem overriding it.


Alex

Tim Hochberg

unread,
Dec 25, 2005, 9:54:12 PM12/25/05
to pytho...@python.org
Remi Villatel wrote:
> André Malo wrote:
>
>
>>>is two lines and 347 characters ugly enough to win?
>
>
>>Nope. 3 lines / 179 chars here >:->
>>Yes, it's quite unreadable.
>
>
> I'm in for the second place with 4 lines / 228 chars.
>
>
>>(The problem is that I need to find an internet cafe on 28/29th in order to
>>be able to submit)
>
>
> Do your best! I'd really like to see your code. Right now, 179 chars
> doesn't seem enough for me to write a "Hello world". ;-)
>

I'm down to below 160 characters at this point. And 9 lines, so 22 of
those characters are leading white space or returns :( I'd really like
to get down to 150, but I'm having a hard time figuring where I can do
any more compaction.

-tim

Remi Villatel

unread,
Dec 25, 2005, 10:22:14 PM12/25/05
to
rbt wrote:

> Does positioning matter? For example, say I give it '123' is it ok to
> output this:
>
> 1
> 2
> 3
>
> Or does it have to be 123

Download the test suite and you'll see that only 123 on one line passes
the test. Sorry...

Tim Peters

unread,
Dec 25, 2005, 10:28:29 PM12/25/05
to pytho...@python.org
Over at

http://spoj.sphere.pl/problems/SIZECON/

the task is to come up with the shortest program that solves a
different problem. There's a twist in this one:

Score equals to size of source code of your program except symbols with
ASCII code <= 32.

So blanks, newlines and tabs aren't counted at all. However, no
"control characters" of any kind are counted, and I found a convoluted
way to transform any Perl program so that only 7 "readable" characters
remain. That's currently the shortest solution known (given the
stated metric -- my Perl source is actually over 400 bytes! all but 7
of them have ord < 33, though).

There's probably still room for improvement in the "shortest" Python
program known for this task. No deadlines, no prizes, and you don't
get to see anyone else's code, but as a form of programming
masturbation it's great ;-)

http://spoj.sphere.pl/problems/KAMIL/

is another program-size task, but this one counts all bytes.

phil_nosp...@yahoo.com

unread,
Dec 25, 2005, 11:07:45 PM12/25/05
to
Tim Hochberg wrote:

> No. I have 8 lines and 175 chars at present. And, I expect that's gonna
> get beaten.


I wasn't going to get into this, but I couldn't resist :).

I'm already behind though... 198 characters on 1 line. It's ugly, but
it works.

tar...@gmail.com

unread,
Dec 26, 2005, 2:00:23 AM12/26/05
to
Currently I'm on 149 characters in <urgh> one line - 128 without
spaces/newlines. (it'd be three characters shorter if it didn't have
to end with a "\n")

-T. "unclean... unclean..."

Peter Otten

unread,
Dec 26, 2005, 4:05:04 AM12/26/05
to
Simon Hengel wrote:

>> Is it necessary to keep the input parameter as 'input'? Reducing that to
>> a single character drops the length of a program by at least 8
>> characters. Technically it changes the interface of the function, so
>> it's a little bogus, but test.py doesn't check. (Personally I prefer
>> that if be illegal, but if it's legal I'll have to do it).
>
> You may change input to something more short, like x. Everything that
> passes the test, has a good chance to be accepted.

How good is "good" for

import test_vectors
seven_seg = test_vectors.test_vectors.get

or code using the test suite in general?

Peter

anonymous

unread,
Dec 26, 2005, 5:26:32 AM12/26/05
to pytho...@python.org
<taroso <at> gmail.com> writes:

are you importing zlib or bz2 ?


Brian Beck

unread,
Dec 26, 2005, 5:59:50 AM12/26/05
to
anonymous wrote:
> are you importing zlib or bz2 ?

I don't think either of these would help in this case. While the
length of the compressed string might be significantly shorter than
your solution, the resulting string *literal* you decompress will
contain a bunch of \-escaped characters, so it will end up being longer.

Brian Beck

unread,
Dec 26, 2005, 6:08:50 AM12/26/05
to
> I don't think either of these would help in this case. While the
> length of the compressed string might be significantly shorter than
> your solution, the resulting string *literal* you decompress will
> contain a bunch of \-escaped characters, so it will end up being longer.

PS: I'm at 155, damn you taroso...

tar...@gmail.com

unread,
Dec 26, 2005, 7:55:21 AM12/26/05
to
(Current status: 147 characters)
Nope - no imports at all. The horrible thing is it's NOT the the most
unpleasant piece of Python I've written.

-T. "A gentleman is someone who knows how to play the bagpipes but
doesn't"

André Malo

unread,
Dec 26, 2005, 8:14:50 AM12/26/05
to
* anonymous wrote:

> are you importing zlib or bz2 ?

Haha, I've tried that myself. Funnily the bz2 result had exactly the same
length as the original. Code with that entropy is... nasty ;)

Still 179. It seems, I need to rethink the algorithm ;-)

nd
--
die (eval q-qq:Just Another Perl Hacker
:-)

# André Malo, <http://www.perlig.de/> #

Bengt Richter

unread,
Dec 26, 2005, 11:19:40 AM12/26/05
to
On Sun, 25 Dec 2005 16:39:47 +0100, Simon Hengel <si...@airlangen.de> wrote:

>Hello,
>we are hosting a python coding contest an we even managed to provide a
>price for the winner...

^^^^^
>
How much are you going to sell him or her for? ;-)

Regards,
Bengt Richter

Tim Hochberg

unread,
Dec 26, 2005, 11:34:15 AM12/26/05
to pytho...@python.org
tar...@gmail.com wrote:
> Currently I'm on 149 characters in <urgh> one line - 128 without
> spaces/newlines. (it'd be three characters shorter if it didn't have
> to end with a "\n")


It'll be interesting to see what the short 1-line answers look like. I
have a hard time seeing how that's done. It'll especially be interesting
to see if we're all using similar tricks or if the multiline attemps
take a distinctly different tack than the single line attempts.

Currently, I'm down to 137 characters now in 6 lines. There's very
little left to trim at this point, so I don't know that I'll be able to
knock it down any further using my current approach. And since I don't
have any other approaches in the wings, I may be about washed up.


-tim


André Malo

unread,
Dec 26, 2005, 12:13:01 PM12/26/05
to
* Tim Hochberg wrote:

> Currently, I'm down to 137 characters now in 6 lines. There's very
> little left to trim at this point, so I don't know that I'll be able to
> knock it down any further using my current approach. And since I don't
> have any other approaches in the wings, I may be about washed up.

grmpf. Just reached 143 chars / 2 lines ;-)
There seems to be some more room for optimization...

nd
--
package Hacker::Perl::Another::Just;print
qq~@{[reverse split/::/ =>__PACKAGE__]}~;

# André Malo # http://pub.perlig.de #

Yaccck

unread,
Dec 26, 2005, 1:29:11 PM12/26/05
to pytho...@python.org

You guys are pretty agressive!

Dody Suria Wijaya

unread,
Dec 26, 2005, 2:24:34 PM12/26/05
to
omg, how do you guys do it? after 4 hours, i'm stucked at 182 chars, 8
lines. hint please... :D

Claudio Grondi

unread,
Dec 26, 2005, 3:21:41 PM12/26/05
to
This started to remind myself about the story of the contest where the
shortest program beeing able to output own source was the job to code.
The jury had a big trouble to justify why not give the prize to the one
who posted an empty file ...

I am currently at 39 bytes following the requirements and the principle
given above (my module passes the test). Anyone able to beat that?

Claudio

Tim Hochberg

unread,
Dec 26, 2005, 3:33:42 PM12/26/05
to pytho...@python.org
Claudio Grondi wrote:
> Peter Otten wrote:
[SNIP]

>>How good is "good" for
>>
>>import test_vectors
>>seven_seg = test_vectors.test_vectors.get
>>
>>or code using the test suite in general?
>>
>>Peter
>>
>
> This started to remind myself about the story of the contest where the
> shortest program beeing able to output own source was the job to code.
> The jury had a big trouble to justify why not give the prize to the one
> who posted an empty file ...
>
> I am currently at 39 bytes following the requirements and the principle
> given above (my module passes the test). Anyone able to beat that?

Wow! It'll be interesting to see how to do that. The obvious way gives
53 bytes. Hmmm, I'll have to see what can be done...

However they do say "We use a very *similar* test suite to either accept
or reject pending submissions." (Emphasis mine) So, it's possible, even
probable, that the file test.py either won't be available or won't be
helpful.

-tim

Duncan Booth

unread,
Dec 26, 2005, 4:43:46 PM12/26/05
to
Tim Hochberg wrote:

I think my main interest will be to see what different algorithms are
successful. I suspect I may have chosen the wrong approach to start with
since I stuck at 150 characters (1 line, no extraneous whitespace), but
then I started again with a different algorithm and I'm down to one line of
137 characters but nowhere obvious to go from there...

Malte Dik

unread,
Dec 26, 2005, 6:46:48 PM12/26/05
to
Tim Hochberg wrote:

Wouldn't using test_vectors.py somehow be lame?

Steven D'Aprano

unread,
Dec 26, 2005, 7:32:33 PM12/26/05
to
On Mon, 26 Dec 2005 13:33:42 -0700, Tim Hochberg wrote:

> Claudio Grondi wrote:

>> I am currently at 39 bytes following the requirements and the principle
>> given above (my module passes the test). Anyone able to beat that?
>
> Wow! It'll be interesting to see how to do that. The obvious way gives
> 53 bytes. Hmmm, I'll have to see what can be done...

OBVIOUS???

The only algorithm obvious to me came to two lines and about 300
characters with all the pruning I could come up with. Changing algorithms
made it longer. I am finding it hard enough to credit that half a dozen
people are claiming lengths of around 130-180 characters -- 39 or 53 bytes
just seems physically impossible to me, especially given that nine of
those bytes are the name of the function!

The identity function seven_seg=lambda s:s takes 20 bytes and does
nothing. That leaves NINETEEN bytes to implement the functionality. In the
immortal words of Bill and Ted: "No way dude!"

You excellent dudes are righteously bodacious!


--
Steven.

Christian Tismer

unread,
Dec 26, 2005, 8:09:15 PM12/26/05
to Steven D'Aprano, pytho...@python.org
Steven D'Aprano wrote:
> On Mon, 26 Dec 2005 13:33:42 -0700, Tim Hochberg wrote:
>
>> Claudio Grondi wrote:
>
>>> I am currently at 39 bytes following the requirements and the principle
>>> given above (my module passes the test). Anyone able to beat that?
>> Wow! It'll be interesting to see how to do that. The obvious way gives
>> 53 bytes. Hmmm, I'll have to see what can be done...
>
> OBVIOUS???

The obvious way seems to be to import the test_vectors.py file,
which gives me

import test_vectors as x;seven_seg=x.test_vectors.get

as one possible "obvious" solution with 53 chars.

But
from test_vectors import*;seven_seg=test_vectors.get
has only 52.

And if you observe that their "test.py" file already does
all the imports we want, you can get to

from test import*;seven_seg=test_vectors.get
with 44 chars.

But I simply cant see how to get below that.
And I think this is not the wanted solution at all,
which is why I have no problem posting it here :-)

ciao - chris
--
Christian Tismer :^) <mailto:tis...@stackless.com>
tismerysoft GmbH : 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 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

Tim Hochberg

unread,
Dec 26, 2005, 8:06:42 PM12/26/05
to pytho...@python.org
Steven D'Aprano wrote:
> On Mon, 26 Dec 2005 13:33:42 -0700, Tim Hochberg wrote:
>
>
>>Claudio Grondi wrote:
>
>
>>>I am currently at 39 bytes following the requirements and the principle
>>>given above (my module passes the test). Anyone able to beat that?
>>
>>Wow! It'll be interesting to see how to do that. The obvious way gives
>>53 bytes. Hmmm, I'll have to see what can be done...
>
>
> OBVIOUS???

Your misinterpreting me here. I meant the obvious way to cheat as
Claudio describes above. I don't actually think that kind of cheating
will work, since it relies on test_vectors.py being present and it
assumes that the test vectors used for checking the program are the same
as those in test_vectors.py. The documentation suggests that the later
at least is not likely. I still haven't figured out how he manages to
get his cheating one so short though, the smallest I can get is 43
characters and it looks like this:

import test;seven_seg=test.test_vectors.get

This works if you run test. It fails if you try to run it standalone
since the import order is wrong.


>
> The only algorithm obvious to me came to two lines and about 300
> characters with all the pruning I could come up with. Changing algorithms
> made it longer. I am finding it hard enough to credit that half a dozen
> people are claiming lengths of around 130-180 characters -- 39 or 53 bytes
> just seems physically impossible to me, especially given that nine of
> those bytes are the name of the function!

In the 130's is definately possible, but I haven't heard of anyone doing
better than that.

>
> The identity function seven_seg=lambda s:s takes 20 bytes and does
> nothing. That leaves NINETEEN bytes to implement the functionality. In the
> immortal words of Bill and Ted: "No way dude!"
>
> You excellent dudes are righteously bodacious!

Nah.

-tim

>
>

Christian Tismer

unread,
Dec 26, 2005, 8:15:10 PM12/26/05
to Tim Hochberg, pytho...@python.org
Tim Hochberg wrote:

> import test;seven_seg=test.test_vectors.get

Oupps, good (being blinded after all the other from imports
and __import__(...) )

Tim Hochberg

unread,
Dec 26, 2005, 8:09:11 PM12/26/05
to pytho...@python.org
Tim Hochberg wrote:
[CHOP]

>
> import test;seven_seg=test.test_vectors.get
>
> This works if you run test. It fails if you try to run it standalone
> since the import order is wrong.
[CHOP]

Or maybe not. An earlier version did, but this one seems OK.

-tim

Justin Azoff

unread,
Dec 26, 2005, 8:49:49 PM12/26/05
to
Tim Hochberg wrote:
> In the 130's is definately possible, but I haven't heard of anyone doing
> better than that.

I have a version that is 127, but only if you strip extra whitespace
:-(

--
- Justin

Remi Villatel

unread,
Dec 26, 2005, 9:12:49 PM12/26/05
to
Tim Hochberg wrote:

>> I am currently at 39 bytes following the requirements and the
>> principle given above (my module passes the test). Anyone able to beat
>> that?

> Wow! It'll be interesting to see how to do that. The obvious way gives
> 53 bytes. Hmmm, I'll have to see what can be done...

39 bytes... 53 bytes... It gives me the impression to follow a jet plane
with a bike with my 179 bytes!

There isn't a single superfluous byte. My code is so compressed that the
syntactic colorizer can't cope any more.

I definitively need a new algorythm. <g>

Christian Tismer

unread,
Dec 26, 2005, 9:23:35 PM12/26/05
to pytho...@python.org
Remi Villatel wrote:

> 39 bytes... 53 bytes... It gives me the impression to follow a jet plane
> with a bike with my 179 bytes!
>
> There isn't a single superfluous byte. My code is so compressed that the
> syntactic colorizer can't cope any more.
>
> I definitively need a new algorythm. <g>

You need a more careful reading algorithm.
We were talking about cheating by imports :-)

Scott David Daniels

unread,
Dec 26, 2005, 10:48:24 PM12/26/05
to
Remi Villatel wrote:
> Tim Hochberg wrote:
>
>>> I am currently at 39 bytes following the requirements and the
>>> principle given above (my module passes the test). Anyone able to
>>> beat that?
>
>> Wow! It'll be interesting to see how to do that. The obvious way gives
>> 53 bytes. Hmmm, I'll have to see what can be done...
>
> 39 bytes... 53 bytes... It gives me the impression to follow a jet plane
> with a bike with my 179 bytes!
>
> There isn't a single superfluous byte. My code is so compressed that the
> syntactic colorizer can't cope any more.
>
> I definitively need a new algorythm. <g>
>
And I am sadly stuck at 169. Not even spitting distance from 149 (which
sounds like a non-cheat version).

--Scott David Daniels
scott....@acm.org

Paul McGuire

unread,
Dec 27, 2005, 2:58:52 AM12/27/05
to
"Scott David Daniels" <scott....@acm.org> wrote in message
news:43b0...@nntp0.pdx.net...

Well *I'm* certainly looking forward to learning some new tricks! My
(non-cheat) version is a comparatively-portly 245, and no alternatives are
popping into my head at the moment!

-- Paul


Paul McGuire

unread,
Dec 27, 2005, 3:21:50 AM12/27/05
to
"Paul McGuire" <pt...@austin.rr._bogus_.com> wrote in message
news:0v6sf.9742$9e....@tornado.texas.rr.com...
<snip>

> Well *I'm* certainly looking forward to learning some new tricks! My
> (non-cheat) version is a comparatively-portly 245, and no alternatives are
> popping into my head at the moment!
>
> -- Paul
>
>
down to 2 lines, 229 characters


Duncan Booth

unread,
Dec 27, 2005, 4:24:44 AM12/27/05
to
Scott David Daniels wrote:

>> I definitively need a new algorythm. <g>
>>
> And I am sadly stuck at 169. Not even spitting distance from 149 (which
> sounds like a non-cheat version).

Throw it away and start again with a fresh (clean) solution. That's what I
did when I'd reached the limit of nested maps and lambdas at 150
characters. I'm now on 134 characters and the solution is very nearly
legible. (Frustratingly, I'm away for the next few days, so I may not get a
chance to submit my solution).

It would be a nice idea to come up with a scoring system which better
reflects Python's ideals. For example, use the parser in Python to count up
various syntactic elements, score 0 for comments, indents, dedents,
newlines, docstrings, 1 for each name or operation used and higher scores
for things like lambda or overly complex expressions.

Shane Hathaway

unread,
Dec 27, 2005, 4:33:19 AM12/27/05
to Paul McGuire, pytho...@python.org

I'm down to 133 characters (counted according to 'wc -c') on a single
line. It contains about 11 whitespace characters (depending on what you
consider whitespace.) It's way too tricky for my taste, but it's fun to
play anyway. Has anyone done better so far? Here's a hint on my
strategy: the code contains three large integers. :-)

Also, here's another cheat version. (No, 7seg.com does not exist.)

import urllib2
def seven_seg(x):return urllib2.urlopen('http://7seg.com/'+x).read()

Shane

Paul McGuire

unread,
Dec 27, 2005, 4:39:49 AM12/27/05
to
"Shane Hathaway" <sh...@hathawaymix.org> wrote in message
news:mailman.2581.1135676...@python.org...

>
> I'm down to 133 characters (counted according to 'wc -c') on a single
> line. It contains about 11 whitespace characters (depending on what you
> consider whitespace.) It's way too tricky for my taste, but it's fun to
> play anyway. Has anyone done better so far? Here's a hint on my
> strategy: the code contains three large integers. :-)
>
With 1 large integer, I am down to 200 characters on 1 multiline line. I
can guess why you have 3 integers vs. 1, but I don't see how that saves you
any characters of code.

-- Paul


tar...@gmail.com

unread,
Dec 27, 2005, 5:47:01 AM12/27/05
to
I now have a version which passes the test suite in 32 bytes <evil
grin>

-T.

ZeD

unread,
Dec 27, 2005, 7:08:39 AM12/27/05