python coding contest
Simon Hengel
we are hosting a python coding contest an we even managed to provide a
price for the winner...
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
> 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
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
> -----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
> 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
> 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
...
> 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
...
> 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é
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
> 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
> -----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
Christian Tismer
>> 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
> should be ignored, as well.
Cheers, Simon
Steven D'Aprano
Yes, but the question is, is two lines and 347 characters ugly enough to
win?
--
Steven.
Simon Hengel
> 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
> 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
> 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
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
No. I have 8 lines and 175 chars at present. And, I expect that's gonna
get beaten.
-tim
Tim Hochberg
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
isn't the word 'input' a special word anyway???
Simon Hengel
> 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
>>> len(c)
251
>>> len(c.replace(" ",""))
152
:-)
Knowing me, I'll forget to submit it.
Remi Villatel
>>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
> * 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
> 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
> > 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
> 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
> 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
> 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
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
> 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
spaces/newlines. (it'd be three characters shorter if it didn't have
to end with a "\n")
-T. "unclean... unclean..."
Peter Otten
>> 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
Brian Beck
> 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
> 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
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
> 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
>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
> 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
> 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
You guys are pretty agressive!
Dody Suria Wijaya
lines. hint please... :D
Claudio Grondi
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
> 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
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
Wouldn't using test_vectors.py somehow be lame?
Steven D'Aprano
> 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
> 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
> 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
> import test;seven_seg=test.test_vectors.get
Oupps, good (being blinded after all the other from imports
and __import__(...) )
Tim Hochberg
[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.
Or maybe not. An earlier version did, but this one seems OK.
-tim
Justin Azoff
> 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
>> 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
> 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
> 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>
>
sounds like a non-cheat version).
--Scott David Daniels
scott....@acm.org
Paul McGuire
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
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
>
>
Duncan Booth
>> 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
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
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. :-)
>
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
grin>
-T.
ZeD
> 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.)
$ wc -c seven_seg.py
137 seven_seg.py
$ sed 's/ //g' seven_seg.py|wc -c
120
(yeah, too much spaces, I think)
> 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. :-)
why using 3 longint is better than one?! Trying to "split" my BIG int in 3
just make my code longer...
ok, ok... I will wait the end of the contest... :)
--
Firma in costruzione
Tim Hochberg
This is interesting. I have a six line solution that is 133 characters
long. I use no long integers, which is what's interesting; two distinct
solutions with the same length. I played with long integers for a bit,
and I can see how one could use a single long integer, but no idea how
one would use three.
-tim
Shane Hathaway
> long.
133 characters according to 'wc -c'? If so, that will surely win style
points over my one-line monster. But I bet someone's going to do better
(without cheating.)
Shane
Duncan Booth
> This is interesting. I have a six line solution that is 133 characters
> long. I use no long integers, which is what's interesting; two
> distinct solutions with the same length. I played with long integers
> for a bit, and I can see how one could use a single long integer, but
> no idea how one would use three.
>
out how to use 3 numbers there's actually quite a variety of options to use
different numbers in subtly different ways: I was stuck on 133 characters
for quite a while, but I think the trick is to think of ways to make the
numbers smaller.
Tim Hochberg
> Tim Hochberg wrote:
>
>>Paul McGuire wrote:
>>
>>
>>long.
>
>
Indeed:
C:\...\pycontest_01>wc -c seven_seg_8.py
133 seven_seg_8.py
I you strip leading and trailing whitespace, it's 122 characters. For
comparison, seven_seg_1.py is 816 characters long:)
> If so, that will surely win style
> points over my one-line monster.
It's pretty readable, at least with the right tabs setting in one's
editor, except for the guts of the thing, which consists of 21
characters of marvelously inscrutable goop.
> But I bet someone's going to do better
> (without cheating.)
I expect so. However, most people, at least those that are talking, seem
to be stalling out in the low 130s, so I predict the final winner will
be 127-130 characters long.
-tim
Guyon Morée
i managed in 199 bytes :)
i'll send it in anyway
ciao
James Tanis
> -----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.
.. yes but there's a difference, some users of that "other" P-language
seem to actually take some sort of ritualistic pride in their ability
to condense code down to one convoluted line. The language is also a
little more apt at it since it has a great deal of shorthand built in
to the core language. Shorter is not necessarily better and I do
support his opinion that reinforcing short as good isn't really what
most programmers (who care about readability and quality) want to
support.
>
> > 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?
>
I think code efficiency would be a better choice. A "longer" program
is only worse if its wasting cycles on badly implemented algorithms.
Code size is a really bad gauge, If your actually comparing size as in
byte-to-byte comparison, you'll be getting a ton of implementations
with absolutely no documentation and plenty of one letter variable
names. I haven't checked the web site either, are you allowing third
party modules to be used? If so, that causes even more problems in the
comparison. How are you going to compare those who use a module vs
implement it themselves in pure python?
--
James Tanis
jta...@pycoder.org
http://pycoder.org
Tim Hochberg
> When you guys say 127~150 characters, did you guys mean
> usinging test_vectors.py in some way? Or there's no import at all?
>
No import at all. The shortest solution reported so far is 131
characters. Getting down to 127 is just a guess as to where the lower
bound is likely to be.
Note that in principle it's possible to encode the data for how to
display a digit in one byte. Thus it's at least theoretically possible
to condense all of the information about the string into a string that's
10 bytes long. In practice it turns out to be hard to do that, since a
10 byte string will generally have a representation that is longer than
10 bytes because of the way the escape sequences get printed out. As a
result various people seem to be encoding the data in long integers of
one sort or another. The data is then extracted using some recipe
involving shifts and &s.
-tim
Tim Hochberg
> 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. :-)
I see now how three large integers could be useful, but the best I could
do with that is 136 characters on 1-line. Yesterday that would have been
great, but it's not so hot today.
>
> 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()
>
And another one from me as well.
class a:
def __eq__(s,o):return 1
seven_seg=lambda i:a()
-tim
Duncan Booth
> py pan wrote:
>> When you guys say 127~150 characters, did you guys mean
>> usinging test_vectors.py in some way? Or there's no import at all?
>>
>
> No import at all. The shortest solution reported so far is 131
> characters. Getting down to 127 is just a guess as to where the lower
> bound is likely to be.
Sorry about the 131, I had a spurious whitespace character so it should
have been 130.
> The data is then extracted using some recipe
> involving shifts and &s.
My 130 character solution has a shift and an &. My 133 character solution
didn't. I feel sure that 130 isn't the limit, my guess would be that 127 or
128 ought to be possible.
Jean-Paul Calderone
This is shorter as "__eq__=lambda s,o:1".
But I can't find the first post in this thread... What are you
guys talking about?
Jean-Paul
Claudio Grondi
the 32 version five minutes later, but thougt that instead of posting it
I can maybe use it as entry on the contest ... Now this hope is over and
as the 32 bytes are the lowest possible limit I can currently think of
the dream of winning the contest seems to be over.
Anyone below 32 bytes?
Claudio
Justin Azoff
> Note that in principle it's possible to encode the data for how to
> display a digit in one byte. Thus it's at least theoretically possible
> to condense all of the information about the string into a string that's
> 10 bytes long. In practice it turns out to be hard to do that, since a
> 10 byte string will generally have a representation that is longer than
> 10 bytes because of the way the escape sequences get printed out. As a
> result various people seem to be encoding the data in long integers of
> one sort or another. The data is then extracted using some recipe
> involving shifts and &s.
>
> -tim
I have a 163 character version(on 8 lines, haven't tried to compress it
further) that does something like that.. the string ended up being
printable enough to be included in the source unescaped.
I think for most approaches, any space you save by using a string you
lose after quoting it and using ord() to turn a character back into a
number.
I'm sure this particular method is a dead end, but it is a very
intersting and probably unique solution :-)
--
- Justin
Tim Hochberg
There's a contest described at http://www.pycontest.net/. People have
been working on two sorts of solutions: 'honest' solutions that actually
do what's described there. The best of these are around 130 characters.
There's also a set of 'cheat' solutions that fool the supplied test
program. I suspect that these will not pass muster when they actually
get submitted, but we'll see I suppose. A couple of people have figured
out how to write these cheating solution extremely compactly (32 bytes).
One of the simpler ones is:
import test;seven_seg=test.test_vectors.get
This will make sense if you look at the kit supplied by the above site.
-tim
Christian Tismer
> On 12/25/05, Simon Hengel <si...@airlangen.de> 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.
Looking at what I produced the last days, I'm not convinced...
> .. yes but there's a difference, some users of that "other" P-language
> seem to actually take some sort of ritualistic pride in their ability
> to condense code down to one convoluted line. The language is also a
> little more apt at it since it has a great deal of shorthand built in
> to the core language. Shorter is not necessarily better and I do
> support his opinion that reinforcing short as good isn't really what
> most programmers (who care about readability and quality) want to
> support.
And that's what puzzled me a bit about the approach and the intent
of this contest: Should this evolute into a language war about
goals (shortness, conciseness, brevity, whatnot) that Python
doesn't have as its main targets?
Sure, I see myself hacking this unfortunate little 7-seg code
until it becomes unreadable for me, the trap worked for me,
but why do I do this???
...
> I think code efficiency would be a better choice. A "longer" program
> is only worse if its wasting cycles on badly implemented algorithms.
And we are of course implementing algorithms with a twisted goal-set
in mind: How to express this the shortest way, not elegantly,
just how to shave off one or even two bytes, re-iterating the
possible algorithms again and again, just to find a version that is
lexically shorter? To what a silly, autistic crowd of insane people
do I belong? But it caught me, again!
> Code size is a really bad gauge, If your actually comparing size as in
> byte-to-byte comparison, you'll be getting a ton of implementations
> with absolutely no documentation and plenty of one letter variable
> names. I haven't checked the web site either, are you allowing third
> party modules to be used? If so, that causes even more problems in the
> comparison. How are you going to compare those who use a module vs
> implement it themselves in pure python?
I think it is legal to use any standard pre-installed package you
like, if it belongs to the set of default batteries included.
In a sense, using these tools in a good manner, gives you some
measure about how much the programmer knows about these batteries,
and using them is ok. Actually, I don't see so much applications
for the given problem, but in general, I like the idea to try
many very different approaches to get to a maybe surprizing result.
After all, I'd really love to set up another contest with
different measures and criteria.
One reason btw. might be that I'm not able to win this one, due to
personal blocking. I can't really force myself to go all the
ridiculous paths to save one byte. My keyboard blocks as well.
Maybe I don't consider myself a hacker so much any longer :-)
ciao - chris
Remi Villatel
[--CUT---]
>> 39 bytes... 53 bytes... It gives me the impression to follow a jet
>> plane with a bike with my 179 bytes!
[--CUT--]
> And I am sadly stuck at 169. Not even spitting distance from 149 (which
> sounds like a non-cheat version).
Try harder! ;-) I thought I was stuck at 179 but with a strict diet, I
managed to loose some bones :-D and get down to a one-liner of 153 bytes.
No cheating with import but it's so ugly that I'm not sure I will
understand my own code next month. And this time I'm sure at 99% that
I'm really stuck...
Christian Tismer
> Scott David Daniels wrote:
>
> [--CUT---]
>>> 39 bytes... 53 bytes... It gives me the impression to follow a jet
>>> plane with a bike with my 179 bytes!
> [--CUT--]
>
>> And I am sadly stuck at 169. Not even spitting distance from 149 (which
>> sounds like a non-cheat version).
>
> Try harder! ;-) I thought I was stuck at 179 but with a strict diet, I
> managed to loose some bones :-D and get down to a one-liner of 153 bytes.
>
> No cheating with import but it's so ugly that I'm not sure I will
> understand my own code next month. And this time I'm sure at 99% that
> I'm really stuck...
Don't try harder!
Sit back and think of what you're doing,
and what you'd like to do, instead.
And then help me to setup a different contest about content -- chris
Tim Hochberg
[SNIP]
> And then help me to setup a different contest about content -- chris
As usual, I expect that actually having some working code measuring
'Pythonic' length (and I'm sure we could get into all sorts of fun
arguments about the exact definition of that) would go a long way
towards convincing the next contest thrower who's measuring length to
use something a little less distorting than program length.
I've been thinking about writing something, but I've been distracted.
Perhaps I'll take a stab at it tomorrow and see what I come up with.
That being said, the result I've come up with for the contest are pretty
cool in a perverse way, at least while there it's spread out over six
lines. Once it gets folded up, it become unbearable. And, sadly, it only
saves 3 characters. If one was ignoring leading and trailing whitespace
the unfolded version would be the much shorter of the two, but ya gotta
play with the rules as they is.
-tim
Remi Villatel
>>> I feel that python is more beautiful and readable, even if you write
>>> short programs.
> Looking at what I produced the last days, I'm not convinced...
Me neither. Especially since I've taken the one-liner road. Python can
be very unreadable... sometimes.
> And that's what puzzled me a bit about the approach and the intent
> of this contest: Should this evolute into a language war about
> goals (shortness, conciseness, brevity, whatnot) that Python
> doesn't have as its main targets?
Maybe to prove to the others that Python is a "real" language that can
produce "uglinesses" too?
> Sure, I see myself hacking this unfortunate little 7-seg code
> until it becomes unreadable for me, the trap worked for me,
> but why do I do this???
For the pleasure of twisting your mind in every possible way, for the
challenge, for the luxury price if you win? Whatever... I'm trapped too
and I can't give any reason off the top of my head.
[---CUT---]
> I think it is legal to use any standard pre-installed package you
> like, if it belongs to the set of default batteries included.
[---CUT---]
If you use more than the built-ins, you've already lost. It costs you at
least 9 bytes, well, 10 since I don't know any module with a
single-letter name.
"\t"+"import"+" "+name_of_module+"\n"
And knowing how much I struggled to remove the last 10 bytes I removed
from my code, the idea doesn't sound very attractive.
> After all, I'd really love to set up another contest with
> different measures and criteria.
Go on! I don't think that "shortest code" is a very pythonic goal if you
count in bytes. The same contest with the length of the code measured in
"pythonic units" would be better. When I say "pythonic unit", I mean
to count 1 unit for each variable, literal, operator or key-word. That
would be more pythonic.
...but maybe less challenging. To try to do with Python things it wasn't
meant to do is more "fun" for a contest. ;-)
Bengt Richter
[23:28] C:\pywk\clp\seven\pycontest_01>py24 test.py
.
--------------------------------------------------------------
Ran 1 test in 0.391s
OK
[23:28] C:\pywk\clp\seven\pycontest_01>wc -lc seven_seg.py
2 136 seven_seg.py
2 lines, 136 chars including unix-style lineseps (is that cheating on windows?)
No imports.
Guess I'll have to try another tack ;-/
Regards,
Bengt Richter
Roman Susi
> py pan wrote:
>
>>When you guys say 127~150 characters, did you guys mean
>>usinging test_vectors.py in some way? Or there's no import at all?
>>
>
>
> No import at all. The shortest solution reported so far is 131
> characters. Getting down to 127 is just a guess as to where the lower
> bound is likely to be.
>
> display a digit in one byte. Thus it's at least theoretically possible
> to condense all of the information about the string into a string that's
> 10 bytes long. In practice it turns out to be hard to do that, since a
> 10 byte string will generally have a representation that is longer than
> 10 bytes because of the way the escape sequences get printed out. As a
> result various people seem to be encoding the data in long integers of
> one sort or another. The data is then extracted using some recipe
> involving shifts and &s.
>
> -tim
Condensing is good but only as far as code for decompressing is small...
By the way, after I noticed that I program for 2.3, I tried with 2.4 and
get out extra characters thanks for generator expression and .join()
integration. So now I am at 147. Probably a lot of reserve as I have 3
fors... One for just for the purpose of getting a name:
...x.... for x in [scalar]
Probably its time rething solution from scratch...
Roman Susi
Duncan Booth
> And then help me to setup a different contest about content -- chris
>
Count me in.
Shane Hathaway
readable than the 133 character solution (though it's still obscure.)
It depends on Python 2.4. If Python 2.3 compatibility is required for
the contest, I have to add 4 characters.
Shane
[shane@tiger pycontest_01]$ wc -c seven_seg.py
125 seven_seg.py
[shane@tiger pycontest_01]$ python test.py
.
----------------------------------------------------------------------
Ran 1 test in 0.084s
OK
Tim Hochberg
> I just found a 125 character solution. It's actually faster and more
> readable than the 133 character solution (though it's still obscure.)
>
> It depends on Python 2.4. If Python 2.3 compatibility is required for
> the contest, I have to add 4 characters.
I asked, 2.4 is OK.
Drat: I had a 128 char solution I was keeping in reserve. Now it's back
to the drawing board....
-tim
Marius Gedminas
> On Tue, 27 Dec 2005 14:02:57 -0700, Tim Hochberg <tim.ho...@ieee.org> wrote:
> >Shane Hathaway wrote:
> >> Paul McGuire wrote:
> >>
> >>
> >> 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()
> >>
> >And another one from me as well.
> >
> >class a:
> > def __eq__(s,o):return 1
> >seven_seg=lambda i:a()
> >
>
> This is shorter as "__eq__=lambda s,o:1".
Or even
class seven_seg(str):__eq__=lambda*a:1
39 characters; passes the test suite. I'm sure it would be
disqualified for cheating, though. :-)
> But I can't find the first post in this thread... What are you
> guys talking about?
Tim Hochberg
> Jean-Paul Calderone wrote:
>
>>On Tue, 27 Dec 2005 14:02:57 -0700, Tim Hochberg <tim.ho...@ieee.org> wrote:
>>
>>>Shane Hathaway wrote:
>>>
>>>>Paul McGuire wrote:
>>>>
>>>>
>>>>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()
>>>>
>>>
>>>And another one from me as well.
>>>
>>>class a:
>>> def __eq__(s,o):return 1
>>>seven_seg=lambda i:a()
>>>
>>
>>This is shorter as "__eq__=lambda s,o:1".
>
>
> Or even
>
> class seven_seg(str):__eq__=lambda*a:1
>
> 39 characters; passes the test suite. I'm sure it would be
> disqualified for cheating, though. :-)
Tricky. That leads to this 30 character gem:
class seven_seg(str):__eq__=id
-tim
Tim Peters
> ...
> [23:28] C:\pywk\clp\seven\pycontest_01>wc -lc seven_seg.py
> 2 136 seven_seg.py
>
> 2 lines, 136 chars including unix-style lineseps (is that cheating on windows?)
Na. Most native Windows apps (including native Windows Python) don't
care whether \n or \r\n in used as the line terminator in text files.
This is because the platform C library changes \r\n to \n on input of
a text-mode file, and leaves \n alone: the difference is literally
invisible to most apps.
Claudio Grondi
> 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,
>
A funny thing happened to me.
The http://www.pycontest.net/ site was down for some minutes because :
"A problem occurred in a Python script. "
it seems, that
'some clever cheat'
has crashed it.
Claudio
Simon Hengel
Sorry for that, I'm considering doing a ranking on the nicest cheats too.
Have fun,
Simon Hengel
--
python coding contest - http://www.pycontest.net/
Simon Hengel
> After all, I'd really love to set up another contest with
> different measures and criteria.
for future events i will take a close look at other possibilities for
doing a ranking. At the moment the 22c3 and the contest is eating up all
my time. Pleas appreciate that i may not keep up with all mails. Sorry
for that.
Cheers,
Simon Hengel
>
> The http://www.pycontest.net/ site was down for some minutes because :
>
> "A problem occurred in a Python script. "
>
> it seems, that
>
> 'some clever cheat'
>
> has crashed it.
Sorry for the inconveniences,
Simon Hengel
Marius Gedminas
Claudio Grondi
> 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,
>
It seems, that the site had some trouble to stay online and especially
to provide the ranking today.
I am a bit dissapointed, that my idea of not duplicating, but utilizing
the efforts others put into solving the job (titled by the submitter ID
'TheParasite') which resulted in a submission of a 15 Bytes large full
functional module was evaluated as having a 'syntax error' problem and
was placed in the ranking at the position according to the size of the
331 byte large .zip archive it was put into along with some necessary
installation instructions.
By the way: trying to submit along with the module complete installation
instructions and comments failed because there is a 345 bytes limit for
size of allowed uploads.
Claudio
Simon Hengel
> to provide the ranking today.
Have fun,
Simon Hengel
Christian Tismer
Great! Let's find a problem small enough to solve in reasonably
time and large enough to exploit Python qualities.
sincerely -- chris (below 130)