Python! Is! Truly! Amazing!
Erik Bethke
I have to say:
Python! Is! Truly! Amazing!
So I started with python about a month ago and put in 24 hours across
three weekends.
My first project was to recreate a simple maze-let thingie that I
remember as my first program way back on the Vic-20. That was a quick
snap and a pleasure.
Since then I have settled down into working on a Mahjong game. I have
uploaded a current version at my personal website:
www.erikbethke.com/Python/mahjong.zip
also note screenshots:
www.erikbethke.com/Python/screenshot01.jpg
www.erikbethke.com/Python/screenshot02.pg
www.erikbethke.com/Python/screenshot03.pg
www.erikbethke.com/Python/screenshot04.pg
www.erikbethke.com/Python/screenshot05.pg
So I have been using Python 2.3.4 as that is what was compatible with
the excellent PyGame last month. After reading the posts here I am
using wing IDE, and over all I like it... some minor issues and I am
sure if I RTFM I would have these handled. I will be buying a bunch of
licenses for us.
I also used this project to learn a little about XML, so I used XML to
fully describe the UI, the tilesets and the tile layouts and have it
able to go back and forth between 3 different tilesets, and backgounds.
The XML is crappy as you can see I am experimenting with putting some
data in attributes and elsewhere in elements.
So now I have it laying out the tiles, tile picking correctly, and I
was even able to write many new little feature-ettes in wickedly fast
single edit-run passes such as this to highlight the currently
available matches:
def findMatchingTiles(self):
matchList = []
visibleTiles = []
for i, c in enumerate ( self.tiles ):
if c.state != 'clear':
visibleTiles.append( c )
for i, c in enumerate ( visibleTiles ):
if self.testForClear( c ):
for j, d in enumerate ( visibleTiles ):
if d != c and d.tileNum == c.tileNum and self.testForClear( d ):
matchList.append( [c, d] )
return matchList
def showHint(self):
matchList = self.findMatchingTiles()
for i, c in enumerate( matchList ):
c[0].state='clicked'
c[1].state='clicked'
self.draw()
I have NEVER experienced this kind of programming joy. I am a 33
year-old professional game developer (www.gopetslive.com) and have been
in the industry for 11 years, and have been programming since 4th grade
like all the rest of you guys. And I am not saying all this to brag,
no seriously I am delirious in joy right now. I have a bad cold and
went to sleep at 1am last night and woke at 5am just to get back to
playing with Python!
I have been looking into Python to see if it is a good answer for
getting a lot of new fresh mini-game and UI work done for our project
GoPets, and clearly it is. I haven't yet explored the server-side
but I will. The Mahjong game in the future will take its tile art
dynamically from the portraits of the users that are your friends and
the people your GoPet has visited recently.
Anyways, I am now a super gushing fan-boy. I have worked my way up
from a scripter working in crappy proprietary languages to a c++
programmer, to now biz guy. But when I walked away from programming I
gave it a grim farewell, c++ work is good, but so much mind goes into
it to make progree compared to other creative uses of the mind. But
Python rocks, it makes programming very fun again and now I finding
myself coming home earlier so I can get to work on Python and I have an
entire heap of new projects I wanted to get done.
Anyways, the Mahjong game code is quite crappy. No effort has been
made to optimize it, nor have I handled any sorts of errors whatsoever.
I know it sucks. But I posted the code there anyways in case any one
else is just coming along and wants some more example code.
I also have no real UI going on. Hit R to randomize the tiles, M to
try to setup a solvable game (but my algorithm for this is not very
effective yet), and H for hints on tiles that can be matched.
Other than the tile art anyone can do what the feel with it.
Thank you all for posting here, you have already solved dozens and
dozens of questions for me with a little help of google groups.
Truly thank you.
-Erik
Erik Bethke
fixing the problem with pygame2exe i just got disctracted getting other
things done so fast!
-Erik
www.gopetslive.com
Erik Bethke
Miklós P
"Erik Bethke" <erikb...@NO-S-PA-M-gmail.com> wrote:
> Hello Everyone,
>
> I have to say:
>
> Python! Is! Truly! Amazing!
>
> So I started with python about a month ago and put in 24 hours across
> three weekends.
...
>
> Truly thank you.
>
> -Erik
>
I enjoyed to read about your enthusiasm about Python you have recently
discovered. :)
After checking out your personal and business site, I'm sure you'll be even
more pleased when Python will be an essential component in your business
and, say, GoPets take on a bit of snake-like inner working. :-)
Best,
Miklós
---
Jegenye 2001 Bt.
Egyedi szoftverkészítés, tanácsadás | Custom software development,
consulting
Magyarul: http://jegenye2001.parkhosting.com
In English: http://jegenye2001.parkhosting.com/en
Nelson Minar
> I have NEVER experienced this kind of programming joy.
Yep, I feel the same way since learning Python. It's really a
productive and pleasant language.
Congratulations on all your game successes!
Ron Garret
"Erik Bethke" <erikb...@gmail.com> wrote:
>
> I have NEVER experienced this kind of programming joy.
Just wait until you discover Lisp!
;-)
rg
Roy Smith
Ron Garret <rNOS...@flownet.com> wrote:
Shouldn't that be ;-)))))))))))))) ?
Aahz
Roy Smith <r...@panix.com> wrote:
>In article <rNOSPAMon-35B48...@news.gha.chartermi.net>,
> Ron Garret <rNOS...@flownet.com> wrote:
>> In article <1104657461.8...@c13g2000cwb.googlegroups.com>,
>> "Erik Bethke" <erikb...@gmail.com> wrote:
>>>
>>> I have NEVER experienced this kind of programming joy.
>>
>> Just wait until you discover Lisp!
Taking this more seriously than it deserves, I've tried poking at Lisp a
couple of times -- each time, I walk away shaking my head in disgust.
Lisp just ain't as *READABLE* as Python.
>> ;-)
>
>Shouldn't that be ;-)))))))))))))) ?
http://www.netfunny.com/rhf/jokes/90q2/lispcode.html
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"19. A language that doesn't affect the way you think about programming,
is not worth knowing." --Alan Perlis
Kamilche
> Anyways, I am now a super gushing fan-boy. I have worked my way up
> from a scripter working in crappy proprietary languages to a c++
> programmer, to now biz guy. But when I walked away from programming I
> gave it a grim farewell, c++ work is good, but so much mind goes into
> it to make progree compared to other creative uses of the mind. But
> Python rocks, it makes programming very fun again and now I finding
> myself coming home earlier so I can get to work on Python and I have an
> entire heap of new projects I wanted to get done.
Yeah, it is really a great language. For me, it matches my internal idea
of 'pseudocode' to a T. Executable shorthand - does it get any better
than that?
--Kamilche
Ron Garret
wrote:
> In article <roy-D9F00D.1...@reader1.panix.com>,
> Roy Smith <r...@panix.com> wrote:
> >In article <rNOSPAMon-35B48...@news.gha.chartermi.net>,
> > Ron Garret <rNOS...@flownet.com> wrote:
> >> In article <1104657461.8...@c13g2000cwb.googlegroups.com>,
> >> "Erik Bethke" <erikb...@gmail.com> wrote:
> >>>
> >>> I have NEVER experienced this kind of programming joy.
> >>
> >> Just wait until you discover Lisp!
>
> Taking this more seriously than it deserves, I've tried poking at Lisp a
> couple of times -- each time, I walk away shaking my head in disgust.
> Lisp just ain't as *READABLE* as Python.
Readability is in the eye of the beholder, but this is not the place to
argue this.
But this topic does bring up a legitimate question: I have a bunch of
code that generates HTML using PRINT statements. I need to convert all
this code to return strings rather than actually printing them (so I can
use the results to populate templates). In Lisp I could do this:
(with-output-to-string (s)
(let ( (*standard-output* s) )
(call-html-generating-code)
s))
Is there an equivalent Python trick to capture a function call's output
as a string?
Thanks,
rg
Mark McEahern
> But this topic does bring up a legitimate question: I have a bunch of
> code that generates HTML using PRINT statements. I need to convert
> all this code to return strings rather than actually printing them (so
> I can use the results to populate templates). In Lisp I could do this:
>
> (with-output-to-string (s)
> (let ( (*standard-output* s) )
> (call-html-generating-code)
> s))
>
> Is there an equivalent Python trick to capture a function call's
> output as a string?
>
>
Just to make sure I understand, I'm going to restate your question:
Is there a way to capture stdout?
The answer: Sure, replace it with something file-like:
>>> import sys, StringIO
>>> default = sys.stdout
>>> writer = StringIO.StringIO()
>>> sys.stdout = writer
>>> print 'Whatever'
>>> sys.stdout = default
>>> print writer.getvalue()
Whatever
>>>
// m
Ron Garret
Mark McEahern <mark...@mceahern.com> wrote:
That's exactly what I was looking for. Thanks!
rg
StvB
($$$$$$$$$$$$)))yes!)))))
)
"Roy Smith" <r...@panix.com> wrote in message
news:roy-D9F00D.1...@reader1.panix.com...
JanC
> But this topic does bring up a legitimate question: I have a bunch of
> code that generates HTML using PRINT statements. I need to convert all
> this code to return strings rather than actually printing them (so I can
> use the results to populate templates). In Lisp I could do this:
>
> (with-output-to-string (s)
> (let ( (*standard-output* s) )
> (call-html-generating-code)
> s))
>
> Is there an equivalent Python trick to capture a function call's output
> as a string?
Something like this:
py> import cStringIO
py> import sys
py>
py> def foo():
... print "test"
...
py> f = cStringIO.StringIO()
py> sys.stdout = f
py> foo()
py> s = f.getvalue()
py> sys.stdout = sys.__stdout__
py> f.close()
py> print s.capitalize()
Test
--
JanC
"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9
Just
JanC <usene...@janc.invalid> wrote:
> Something like this:
>
> py> import cStringIO
> py> import sys
> py>
> py> def foo():
> ... print "test"
> ...
> py> f = cStringIO.StringIO()
> py> sys.stdout = f
> py> foo()
> py> s = f.getvalue()
> py> sys.stdout = sys.__stdout__
You should always save stdout instead of using __stdout__. It may not be
the same! I don't think anyone should *ever* use __stdout__ except when
debugging. See also:
http://mail.python.org/pipermail/python-dev/2000-October/010144.html
> py> f.close()
> py> print s.capitalize()
> Test
Just
Simo Melenius
> (with-output-to-string (s)
> (let ( (*standard-output* s) )
> (call-html-generating-code)
> s))
>
> Is there an equivalent Python trick to capture a function call's output
> as a string?
I've sometimes replaced sys.stdout (and/or sys.stderr) to
capture/redirect debugging information in existing code that has
unwisely just "print"ed error and warning messages, instead of using
sys.stderr or error logging modules.
py> def with_output_to_string (func):
... try:
... sys.stdout = StringIO.StringIO ()
... func ()
... return sys.stdout.getvalue ()
... finally:
... sys.stdout = sys.__stdout__
...
py> def printing_code ():
... print "Foobar"
...
py> with_output_to_string (printing_code)
'Foobar\n'
py>
br,
S
Just
Simo Melenius <firstname...@iki.fi-spam> wrote:
> I've sometimes replaced sys.stdout (and/or sys.stderr) to
> capture/redirect debugging information in existing code that has
> unwisely just "print"ed error and warning messages, instead of using
> sys.stderr or error logging modules.
>
> py> def with_output_to_string (func):
> ... try:
> ... sys.stdout = StringIO.StringIO ()
> ... func ()
> ... return sys.stdout.getvalue ()
> ... finally:
> ... sys.stdout = sys.__stdout__
Aargh, I can't believe how widespread this idiom is :-(. See my other
reply in this thread: DON'T use sys.__stdout__. Ever.
Just
jfj
I've had it with all those lisp posts lately ;-)
There were functional and non-functional programming languages (the
first being *much* simpler to implement). There is a *reason* people
chose C over lisp. It's not that we were all blind and didn't see the
amazingness of lisp. Procedural languages are simply better, and I'm not
replying to this flamewar.
Thank you:)
G.
Ville Vainio
jfj> There were functional and non-functional programming
jfj> languages (the first being *much* simpler to
jfj> implement). There is a *reason* people chose C over
jfj> lisp. It's not that we were all blind and didn't see the
jfj> amazingness of lisp. Procedural languages are simply better,
jfj> and I'm not replying to this flamewar.
You did already ;). Lisp is not a functional programming language, if
that was the case it would be even less popular than it is now. Lisp
had it's heyday, while pure FP languages didn't even have that much.
Hey, it's 2005, I don't think we've used up our yearly Lisp flamewar
quota yet.
--
Ville Vainio http://tinyurl.com/2prnb
Christopher Koppler
Lisp will strike back! Someday, it will be popular again! When all else is
dust, Lisp will rule the skies!
In the meantime, let's do Python.
--
Christopher
root@creation # python
Python inf (day 1)
[PyPy inf (Pythonix inf)] on pynuxinf
Type "help", "copyright", "credits" or "license" for more information.
>>> from Creation import lux
>>> lux.fiat()
michele....@gmail.com
michele....@gmail.com
I am guilty of using this idiom, too.
The standard library
http://www.python.org/dev/doc/devel/lib/module-sys.html#l2h-396
says:
"""
__stdin__
__stdout__
__stderr__
These objects contain the original values of stdin, stderr and
stdout at the start of the program. They are used during finalization,
and could be useful to restore the actual files to known working file
objects in case they have been overwritten with a broken object.
"""
Notice the "during finalization" sentence.
Maybe you should change the doc and explain what __stdout__ is intended
for?
Michele Simionato
Ron Garret
Just <ju...@xs4all.nl> wrote:
It's helpful to provide an explanation when saying things like this.
In this case, it's best to save the original value of sys.stdout and
restore that, otherwise nested calls to with_output_to_string can fail,
e.g.
def f():
print 123
def g():
print 456
x = with_output_to_string(f)
print 789
with_outupt_to_string(g) # Will miss the 789
rg
Ron Garret
jfj <j...@freemail.gr> wrote:
Then neither am I.
Yes, there's a reason people choose C over Lisp, just as there is a
reason that people choose Windows over OS X, the Ford Taurus over the
Lexus SC400, and Perl over Python. But I'm pretty sure joy isn't that
reason. If joy is part of your quality metric for a programming
language then Lisp is worth a look. (And it costs a lot less than a
Lexus.)
rg
JanC
> You should always save stdout instead of using __stdout__. It may not be
> the same!
You're right, especially when this code would execute in an (at
programming time) unknown context.
Steve Holden
Well, in the Computer Programming for Everyone stakes I'm pretty sure
that LISP and its derivatives don't stand a chance, simply because of
the rebarbative syntax one must use to express even relatively simple
algorithms and data structures.
While the language has a lot going for it in the hands of an experienced
and determined LISPer, the average programmer just isn't going to "get it".
regards
Steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119
Simo Melenius
It probably does the right thing, if someone is copypasting code off
the Usenet and tries it out at the Python prompt (and possibly gets
stuck in getting nothing printed on his tty).
If we're talking about real code it might be advisable to start by
first introducing the import statements omitted from the above
snippet, then worry about someone copypasting code into a serious
program instead of copythinkpasting it. :)
br,
S
