Yes Steven a C book I am reading has a quote "Every programmer is fluent in
swearing" After my blow ups and confusion I am happy with my program anyway. I
will get better at it eventually. I did change things to "raw_input" and works
fine.
--
http://mail.python.org/mailman/listinfo/python-list
On Wed, 05 Jun 2013 07:40:52 -0700, Armando Montes De Oca wrote:
> Traceback (most recent call last):
> File "Guessing_Game.py", line 32, in
> input (enter)
> File "", line 0
> ^
> SyntaxError: unexpected EOF while parsing
Your problem is that you should not be using input(), but ra
On 05/06/2013 23:51, Armando Montes De Oca wrote:
Well I am sure this will end up a simple solution which is not solved by the
geniuses with no sense of humor. Programmers are known for being odd nerds and
I just got two of them. Goldstick Jesus what a couple of lazy minded nonsense.
Your an a
Well I am sure this will end up a simple solution which is not solved by the
geniuses with no sense of humor. Programmers are known for being odd nerds and
I just got two of them. Goldstick Jesus what a couple of lazy minded nonsense.
Your an ass hole.
--
http://mail.python.org/mailman/listinf
Not to make excuses as to my forum etiquette I apologize. I am half Cuban and
simple. I meant no disrespect I like Mr. Goldstick's name. Maybe I can find the
answer somewhere else true. However a simple code to close the program like in
Visual Basic "Me.close" seems like something that should c
On Wed, Jun 5, 2013 at 4:18 PM, Thomas Murphy
wrote:
> Goldstick which seems Jewish to me. I would think as a Gentile Heathen
> Jesus save us this would project a need for a good sex life
>
> *WAT*
> *
> *
>
I second the WAT. You are a strange person. I think you were being
offensive. I can't
On Thu, Jun 6, 2013 at 5:59 AM, Armando Montes De Oca
wrote:
> Well I am replying to To whom it may concern at this point I am a bit lost. I
> posted all my code. I am not taking classes on this nor do I have a book I
> followed a guy on You Tube. I am a student but I heard Python is a good
> l
Goldstick which seems Jewish to me. I would think as a Gentile Heathen
Jesus save us this would project a need for a good sex life
*WAT*
*
*
*
*
Armando, are you understanding that input and raw_input make Python do very
different things, and this is dependent of the version of Python you're
using
Well I am replying to To whom it may concern at this point I am a bit lost. I
posted all my code. I am not taking classes on this nor do I have a book I
followed a guy on You Tube. I am a student but I heard Python is a good
language to learn in conjunction with C++ and Perl for example. I have
On Wed, Jun 5, 2013 at 12:15 PM, Zachary Ware wrote:
> On Wed, Jun 5, 2013 at 10:35 AM, Armando Montes De Oca
> wrote:
> > Thank You now the program exits with:
> > (program exited with code: 0)
> > Press return to continue
> >
> >
> > Is there a way to get the line (program exited with code: 0)
On Wed, Jun 5, 2013 at 10:35 AM, Armando Montes De Oca
wrote:
> Thank You now the program exits with:
> (program exited with code: 0)
> Press return to continue
>
>
> Is there a way to get the line (program exited with code: 0) to say something
>
> like: "The game will end now"
>
> Press return to
try:
input = raw_input
except NameError:
pass
This gave me the same output exited with code zero
Same with or without.
I am happy with the code 0 in it for now but if anyone knows with Geany in
Linux Mint 14 Nadia what I can do to get it to say something nice and proper I
would ap
Thank You I will give it a try
I am using Linux Mint 14 Nadia
and my Python is with Geany 1.22 and I think it is python 2
--
http://mail.python.org/mailman/listinfo/python-list
Thank You now the program exits with:
(program exited with code: 0)
Press return to continue
Is there a way to get the line (program exited with code: 0) to say something
like: "The game will end now"
Press return to contine
--
http://mail.python.org/mailman/listinfo/python-list
On Wed, Jun 5, 2013 at 10:14 AM, Armando Montes De Oca
wrote:
> On Wednesday, June 5, 2013 10:40:52 AM UTC-4, Armando Montes De Oca wrote:
>> Traceback (most recent call last):
>>
>> File "Guessing_Game.py", line 32, in
>>
>> input (enter)
>>
>> File "", line 0
>>
>> ^
>>
>> SyntaxErr
On 05/06/2013 16:18, Armando Montes De Oca wrote:
I just post all my code I have for the guessing game.
Please post with some context so we don't have to go to other parts of
the thread to find out what you're talking about, thanks.
--
"Steve is going for the pink ball - and for those of yo
import random
import sys
enter = "Please Press Enter To Continue..."
print " Hello! Welcome to a Guessing game!"
print " Please Guess a number between 1 - 100"
computernum = random.randint (1, 100)
Guess1 = input ( "My First Guess Is: ")
if Guess1 == computernum:
print "You Win !"
On 05/06/2013 16:14, Armando Montes De Oca wrote:
> On Wednesday, June 5, 2013 10:40:52 AM UTC-4, Armando Montes De Oca wrote:
>> Traceback (most recent call last):
>>
>> File "Guessing_Game.py", line 32, in
>>
>> input (enter)
>>
>> File "", line 0
>>
>> ^
>>
>> SyntaxError: unexpecte
I just post all my code I have for the guessing game.
--
http://mail.python.org/mailman/listinfo/python-list
On Wed, 05 Jun 2013 07:40:52 -0700, Armando Montes De Oca wrote:
> Traceback (most recent call last):
> File "Guessing_Game.py", line 32, in
> input (enter)
> File "", line 0
> ^
> SyntaxError: unexpected EOF while parsing --
> (program exited with code: 1)
> This is t
On Wednesday, June 5, 2013 10:40:52 AM UTC-4, Armando Montes De Oca wrote:
> Traceback (most recent call last):
>
> File "Guessing_Game.py", line 32, in
>
> input (enter)
>
> File "", line 0
>
> ^
>
> SyntaxError: unexpected EOF while parsing
>
> --
>
> (program
> Date: Wed, 5 Jun 2013 07:40:52 -0700
> Subject: I just wrote my first Python program a guessing game and it exits
> with an error I get this.
> From: armandomontesdeoca...@gmail.com
> To: python-list@python.org
>
> Traceback (most recent call last):
> File "G
Traceback (most recent call last):
File "Guessing_Game.py", line 32, in
input (enter)
File "", line 0
^
SyntaxError: unexpected EOF while parsing
--
(program exited with code: 1)
This is the only place a string is used:
else:
print "Sorry you loose the game."
Seebs writes:
>> For long strings, another option is triple-quoting as you've seen in doc
>> strings: print """foo
>> bar""".
>
> I assume that this inserts a newline, though, and in this case I don't
> want that.
True.
$ python
>>> """foo
... bar"""
'foo\nbar'
>>> """foo\
On 2010-10-14, Hallvard B Furuseth wrote:
> A class which holds an OS resource like a file, should provide a context
> manager and/or a release function, the latter usually called in a
> 'finally:' block. When the caller doesn't bother with either, the class
> often might as well depend on the de
On Wed, Oct 13, 2010 at 3:53 PM, Ethan Furman wrote:
> Ian Kelly wrote:
>
>> here is an example
>> where the order of assignment actually matters:
>>
>> >>> d['a'] = d = {}
>> Traceback (most recent call last):
>> File "", line 1, in
>> NameError: name 'd' is not defined
>> >>> d = d['a'] =
Seebs writes:
>> You can't really rely on the destructor __del__ being called.
>
> Interesting. Do I just rely on files getting closed?
Sometimes, but that's not it. Think Lisp, not C++. __del__ is not that
useful. Python is garbage-collected and variables have dynamic lifetime,
so the class c
Ian Kelly wrote:
here is an example
where the order of assignment actually matters:
>>> d['a'] = d = {}
Traceback (most recent call last):
File "", line 1, in
NameError: name 'd' is not defined
>>> d = d['a'] = {}
>>> d
{'a': {...}}
As you can see, they're assigned left-to-right.
Ah!
Christian Heimes writes:
> msg = ("WARNING: "
>"Pants on fire")
Ick. When the name changes to something with a different length, you'll
need to change every continuation line. A name change is easily
predicted and quite likely to happen often in one's code, so why invite
more work when it
"Jonas H." writes:
> On 10/13/2010 11:26 PM, Seebs wrote:
> >> stderr.write(
> >> "WARNING:"
> >> " Pants on fire\n")
> >
> > Hmm. So I just indent stuff inside the ()s or whatever? I can work with
> > that.
>
> I think common is
>
> stderr.write("WARNING: ",
>
Seebs writes:
> On 2010-10-13, Ben Finney wrote:
> > Python borrows from C in that consecutive literal strings are
> > concatenated in the bytecode::
> >
> > stderr.write(
> > "WARNING:"
> > " Pants on fire\n")
>
> Hmm. So I just indent stuff inside the ()s or whatever? I can
Am 14.10.2010 00:00, schrieb Jonas H.:
> If you haven't got braces around an expression and you want it to be
> multi-line, you need a '\' at the end of each line, just like C macros:
>
> msg = "WARNING: " \
>"Pants on fire"
or
msg = ("WARNING: "
"Pants on fire")
Christ
On 10/13/2010 11:26 PM, Seebs wrote:
stderr.write(
"WARNING:"
" Pants on fire\n")
Hmm. So I just indent stuff inside the ()s or whatever? I can work with
that.
I think common is
stderr.write("WARNING: ",
"Pants on fire")
or
stderr.write(
On 2010-10-13, Ben Finney wrote:
> Python borrows from C in that consecutive literal strings are
> concatenated in the bytecode::
>
> stderr.write(
> "WARNING:"
> " Pants on fire\n")
Hmm. So I just indent stuff inside the ()s or whatever? I can work with
that.
-s
--
Copyri
Ethan Furman writes:
>Seebs wrote:
>>On 2010-10-12, Hallvard B Furuseth wrote:
self.type, self.name = None, None
>>
>>> Actually you can write self.type = self.name = None,
>>> though assignment statements are more limited than in C.
>>> (And I think they're assigned left-to-right.)
>
> Pytho
> Seebs writes:
> > On 2010-10-13, Chris Rebert wrote:
> > > For future reference, the significant majority of things in Python
> > > raise exceptions upon encountering errors rather than returning
> > > error values of some sort.
> >
> > Yes. I'm getting used to that -- it's a bit of a shift,
Seebs writes:
> 1. If I have a message that I wish to print, it is quite possible that
> message + indentation exceeds 80 lines. What's the idiomatic way to
> solve this? Do I just break the string up into parts, or do I just
> accept that some lines are over 80 characters, or what?
Python borro
Seebs writes:
> On 2010-10-13, Chris Rebert wrote:
> > For future reference, the significant majority of things in Python
> > raise exceptions upon encountering errors rather than returning
> > error values of some sort.
>
> Yes. I'm getting used to that -- it's a bit of a shift, because I'm
>
On 13/10/2010 20:03, Seebs wrote:
On 2010-10-13, Chris Rebert wrote:
For future reference, the significant majority of things in Python
raise exceptions upon encountering errors rather than returning error
values of some sort.
Yes. I'm getting used to that -- it's a bit of a shift, because I
On Wed, Oct 13, 2010 at 12:12 PM, Seebs wrote:
> On 2010-10-13, Jonas H. wrote:
> > Not really. Files will be closed when the garbage collector collects the
> > file object, but you can't be sure the GC will run within the next N
> > seconds/instructions or something like that. So you should *al
On Wed, Oct 13, 2010 at 12:13 PM, Seebs wrote:
> On 2010-10-13, Chris Torek wrote:
> > Unfortunately "with" is newish and this code currently has to
> > support python 2.3 (if not even older versions).
>
> I think it might be 2.4 and later. I'm not sure. Of course, this being
> the real world,
On Wed, Oct 13, 2010 at 12:10 PM, Seebs wrote:
> On 2010-10-13, Jean-Michel Pichavant wrote:
> > If you wonder about some defects reported by such linters, you can then
> > ask in this list why something is not that good, because it may not be
> > always obvious.
>
> > 'pylint' is one them, pret
On 2010-10-13, Chris Torek wrote:
> Unfortunately "with" is newish and this code currently has to
> support python 2.3 (if not even older versions).
I think it might be 2.4 and later. I'm not sure. Of course, this being
the real world, the chances that I'll be able to stick with "Python 2" and
On 2010-10-13, Jonas H. wrote:
> Not really. Files will be closed when the garbage collector collects the
> file object, but you can't be sure the GC will run within the next N
> seconds/instructions or something like that. So you should *always* make
> sure to close files after using them. Tha
On 2010-10-13, Jean-Michel Pichavant wrote:
> If you wonder about some defects reported by such linters, you can then
> ask in this list why something is not that good, because it may not be
> always obvious.
> 'pylint' is one them, pretty effective.
Okay, several questions about stuff pylint
On 2010-10-13, Chris Rebert wrote:
> For future reference, the significant majority of things in Python
> raise exceptions upon encountering errors rather than returning error
> values of some sort.
Yes. I'm getting used to that -- it's a bit of a shift, because I'm
used to exceptions being *exc
In article
Jonas H. wrote:
>On 10/13/2010 06:48 PM, Seebs wrote:
>> Is it safe for me to assume that all my files will have been flushed and
>> closed? I'd normally assume this, but I seem to recall that not every
>> language makes those guarantees.
>
>Not really. Files will be closed when the g
In article
Seebs wrote:
>> * raising `Exception` rather than a subclass of it is uncommon.
>
>Okay. I did that as a quick fix when, finally having hit one of them,
>I found out that 'raise "Error message"' didn't work. :) I'm a bit unsure
>as to how to pick the right subclass, though.
For ex
On Wed, Oct 13, 2010 at 11:28 AM, Ethan Furman wrote:
> Seebs wrote:
>
>> On 2010-10-12, Hallvard B Furuseth wrote:
>>
> >
>
>> self.type, self.name = None, None
>>>
>> Actually you can write self.type = self.name = None,
>>> though assignment statements are more limited than in C.
>>> (A
On 10/13/2010 06:48 PM, Seebs wrote:
Is it safe for me to assume that all my files will have been flushed and
closed? I'd normally assume this, but I seem to recall that not every
language makes those guarantees.
Not really. Files will be closed when the garbage collector collects the
file ob
On 13/10/2010 18:17, Chris Rebert wrote:
On Wed, Oct 13, 2010 at 9:56 AM, Seebs wrote:
On 2010-10-12, MRAB wrote:
Line 51
The __init__ method should always return None. There's no need to be
explicit about it, just use a plain "return".
The real issue here is that I was assuming that o
Seebs wrote:
So, I'm new to Python, though I've got a bit of experience in a few other
languages. My overall impressions are pretty mixed, but overall positive;
it's a reasonably expressive language which has a good mix between staying
out of my way and taking care of stuff I don't want to waste
Seebs wrote:
On 2010-10-12, Hallvard B Furuseth wrote:
>
self.type, self.name = None, None
Actually you can write self.type = self.name = None,
though assignment statements are more limited than in C.
(And I think they're assigned left-to-right.)
Python 2.5.4 (r254:67916, Dec 23 2008, 15:
On Wed, Oct 13, 2010 at 9:56 AM, Seebs wrote:
> On 2010-10-12, MRAB wrote:
>> Line 51
>
>> The __init__ method should always return None. There's no need to be
>> explicit about it, just use a plain "return".
>
> The real issue here is that I was assuming that open('nonexistent') returned
> None
On 2010-10-12, Hallvard B Furuseth wrote:
>> list = map(lambda x: x.call(), self.args)
>> return ', '.join(list)
>
> return ', '.join([x.call() for x in self.args])
I think I wrote that before I found out about list comprehensions. How
new are list comprehensions?
I do like that, it's clearer
On 2010-10-12, MRAB wrote:
> The code does require Python 2 and the use of except ... as ... requires
> at least version 2.6.
Whoops.
> Line 51
> The __init__ method should always return None. There's no need to be
> explicit about it, just use a plain "return".
The real issue here is that I
On 2010-10-12, Chris Rebert wrote:
> 2.
> self.f = file(path, 'r')
> if not self.f:
> return None
>
> The "if" here is pointless; I'm reasonably sure files are always
> considered boolean true.
I actually seem to have done this wrong anyway -- I was thinking in
terms of the C-like idiom of re
On 2010-10-12, Jonas H. wrote:
> Just a few pointers, looks quite good to me for a newbie :)
Thanks!
> * Less action in __init__.
I'm a bit curious about this. The __init__ functions in this are, at
least for now, pretty much doing only what's needed to create the objects
from their inputs.
>
I wrote:
> except IOError:
> if e.errno != errno.ENOENT: raise# if you are picky
Argh, I meant "except IOError, e:". That's for Python 2 but not
Python 3. "except IOError as e:" works on Python 2.6 and above.
--
Hallvard
--
http://mail.python.org/mailman/listinfo/python-list
Seebs writes:
> http://github.com/wrpseudo/pseudo/blob/master/makewrappers
>self.f = file(path, 'r')
>if not self.f:
>return None
No. Failures tend to raise exceptions, not return error codes.
Except in os.path.exists() & co.
$ python
>>> open("nonesuch")
Tracebac
On 12/10/2010 20:40, Jonas H. wrote:
On 10/12/2010 09:14 PM, Seebs wrote:
http://github.com/wrpseudo/pseudo/blob/master/makewrappers
Just a few pointers, looks quite good to me for a newbie :)
* Less action in __init__.
* Use `open` instead of `file` to open a file
* Have a look at context ma
On 12/10/2010 20:14, Seebs wrote:
So, I'm new to Python, though I've got a bit of experience in a few other
languages. My overall impressions are pretty mixed, but overall positive;
it's a reasonably expressive language which has a good mix between staying
out of my way and taking care of stuff
On Tue, Oct 12, 2010 at 12:14 PM, Seebs wrote:
> So, I'm new to Python, though I've got a bit of experience in a few other
> languages. My overall impressions are pretty mixed, but overall positive;
> it's a reasonably expressive language which has a good mix between staying
> out of my way and t
On 10/12/2010 09:14 PM, Seebs wrote:
http://github.com/wrpseudo/pseudo/blob/master/makewrappers
Just a few pointers, looks quite good to me for a newbie :)
* Less action in __init__.
* Use `open` instead of `file` to open a file
* Have a look at context managers for file handling (avoids doing
So, I'm new to Python, though I've got a bit of experience in a few other
languages. My overall impressions are pretty mixed, but overall positive;
it's a reasonably expressive language which has a good mix between staying
out of my way and taking care of stuff I don't want to waste attention on.
Thomas Mlynarczyk <[EMAIL PROTECTED]> writes:
> John Machin schrieb:
>
>> *IF* you need to access the regex associated with a token in O(1)
>> time, a dict is indicated.
>
> O(1) - Does that mean `mydict[mykey]` takes the same amount of time,
> no matter if mydict has 10 or 10 entries? How
Thomas Mlynarczyk wrote:
> John Machin schrieb:
>
>> *IF* you need to access the regex associated with a token in O(1)
>> time, a dict is indicated.
>
> O(1) - Does that mean `mydict[mykey]` takes the same amount of time, no
> matter if mydict has 10 or 10 entries? How does this magic wor
John Machin schrieb:
*IF* you need to access the regex associated with a token in O(1)
time, a dict is indicated.
O(1) - Does that mean `mydict[mykey]` takes the same amount of time, no
matter if mydict has 10 or 10 entries? How does this magic work?
O(log n) I would understand, but
On Nov 12, 2:54 am, Thomas Mlynarczyk <[EMAIL PROTECTED]>
wrote:
> John Machin schrieb:
>
> > You are getting closer. A better analogy is that using a dict is like
> > transporting passengers along an autobahn in an aeroplane or
> > helicopter that never leaves the ground.
>
> It is not a bad idea
Steve Holden schrieb:
Suppose I use the dict and I want to access the regex associatetd with
the token named "tokenname" (that is, no iteration, but a single
access). I could simple write tokendict["tokenname"]. But with the list
of tuples, I can't think of an equally easy way to do that. But th
Thomas Mlynarczyk wrote:
> John Machin schrieb:
>
>> You are getting closer. A better analogy is that using a dict is like
>> transporting passengers along an autobahn in an aeroplane or
>> helicopter that never leaves the ground.
>
> It is not a bad idea to transport passengers in an airplane, b
John Machin schrieb:
You are getting closer. A better analogy is that using a dict is like
transporting passengers along an autobahn in an aeroplane or
helicopter that never leaves the ground.
It is not a bad idea to transport passengers in an airplane, but then
the airplane should not follow
On Nov 11, 8:35 am, Thomas Mlynarczyk <[EMAIL PROTECTED]>
wrote:
> [Using dict]
>
> > No, not at all. The point is that you were not *using* any of the
> > mapping functionality of the dict object, only ancillary methods like
> > iteritems -- hence, you should not have been using a dict at all.
>
John Machin schrieb:
Single-character tokens like "<" may be more efficiently handled by
doing a dict lookup after failing to find a match in the list of
(name, regex) tuples.
Yes, I will keep that in mind. For the time being, I will use only
regexes to keep the code simpler. Later, or when t
On Nov 11, 12:26 am, Thomas Mlynarczyk <[EMAIL PROTECTED]
webdesign.de> wrote:
> John Machin schrieb:
>
> >> On the other hand: If all my tokens are "mutually exclusive" then,
> > But they won't *always* be mutually exclusive (another example is
> > relational operators (< vs <=, > vs >=)) and AFAI
Paul McGuire schrieb:
Just be sure to account for tabs when computing the column, which this
simple-minded algorithm does not do.
Another thing I had not thought of -- thanks for the hint.
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
Some pratt wrote:
> BLAST YOUR AD [...]
and curse yours
--
http://mail.python.org/mailman/listinfo/python-list
On Nov 10, 7:29 am, Thomas Mlynarczyk <[EMAIL PROTECTED]>
wrote:
> Paul McGuire schrieb:
>
> > loc = data.index("list")
> > print data[:loc].count("\n")-1
> > print loc-data[:loc].rindex("\n")-1
>
> > prints 5,14
>
> > I'm sure it's non-optimal, but it *is* an algorithm that does not
> > require ke
Paul McGuire schrieb:
loc = data.index("list")
print data[:loc].count("\n")-1
print loc-data[:loc].rindex("\n")-1
prints 5,14
I'm sure it's non-optimal, but it *is* an algorithm that does not
require keeping track of the start of every line...
Yes, I was thinking of something like this. As l
John Machin schrieb:
On the other hand: If all my tokens are "mutually exclusive" then,
But they won't *always* be mutually exclusive (another example is
relational operators (< vs <=, > vs >=)) and AFAICT there is nothing
useful that the lexer can do with an assumption/guess/input that they
Robert Lehmann schrieb:
You don't have to introduce a `next` method to your Lexer class. You
could just transform your `tokenize` method into a generator by replacing
``self.result.append`` with `yield`. It gives you the just in time part
for free while not picking your algorithm into tiny unr
On Sun, 09 Nov 2008 15:53:01 +0100, Thomas Mlynarczyk wrote:
> Arnaud Delobelle schrieb:
>
>> Adding to John's comments, I wouldn't have source as a member of the
>> Lexer object but as an argument of the tokenise() method (which I would
>> make public). The tokenise method would return what you
On Nov 9, 8:34 pm, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On Sun, 09 Nov 2008 23:33:30 +0100, Thomas Mlynarczyk
> <[EMAIL PROTECTED]> declaimed the following in
> comp.lang.python:
>
>
>
> > Of course. For the actual message I would use at least the line number.
> > Still, the offset could
On Nov 10, 9:33 am, Thomas Mlynarczyk <[EMAIL PROTECTED]>
wrote:
> John Machin schrieb:
>
> >>> dict.iter() will return its results in essentially random
> >>> order.
> > A list of somethings does seem indicated.
>
> On the other hand: If all my tokens are "mutually exclusive" then,
But they won't
John Machin schrieb:
[...] You have TWO problems: (1) Reporting the error location as
(offset from the start of the file) instead of (line number, column
position) would get you an express induction into the User Interface
Hall of Shame.
Of course. For the actual message I would use at least
On Nov 10, 1:39 am, Thomas Mlynarczyk <[EMAIL PROTECTED]>
wrote:
> John Machin schrieb:
>
> > Be consistent with your punctuation style. I'd suggest *not* having a
> > space after ( and before ), as in the previous line. Read
> >http://www.python.org/dev/peps/pep-0008/
>
> What were the reasons for
Arnaud Delobelle schrieb:
Adding to John's comments, I wouldn't have source as a member of the
Lexer object but as an argument of the tokenise() method (which I would
make public). The tokenise method would return what you currently call
self.result. So it would be used like this.
mylexer =
John Machin schrieb:
Be consistent with your punctuation style. I'd suggest *not* having a
space after ( and before ), as in the previous line. Read
http://www.python.org/dev/peps/pep-0008/
What were the reasons for preferring (foo) over ( foo )? This PEP gives
recommendations for coding styl
Thomas Mlynarczyk <[EMAIL PROTECTED]> writes:
> Hello,
>
> I started to write a lexer in Python -- my first attempt to do
> something useful with Python (rather than trying out snippets from
> tutorials). It is not complete yet, but I would like some feedback --
> I'm a Python newbie and it seems
On Nov 9, 7:55 am, Thomas Mlynarczyk <[EMAIL PROTECTED]>
wrote:
> Hello,
>
> I started to write a lexer in Python -- my first attempt to do something
> useful with Python (rather than trying out snippets from tutorials). It
> is not complete yet, but I would like some feedback -- I'm a Python
> new
Hello,
I started to write a lexer in Python -- my first attempt to do something
useful with Python (rather than trying out snippets from tutorials). It
is not complete yet, but I would like some feedback -- I'm a Python
newbie and it seems that, with Python, there is always a simpler and
bett
On Aug 26, 7:40 pm, Michele Simionato <[EMAIL PROTECTED]>
wrote:
> On Aug 26, 5:56 pm, [EMAIL PROTECTED] wrote:
>
> > Hi,
> > to extend my skills, I am learning python. I have written small
> > program which computes math expression like "1+2*sin(y^10)/cos(x*y)"
> > and similar, so far only + - *
Michele Simionato wrote:
> On Aug 26, 5:56 pm, [EMAIL PROTECTED] wrote:
> > Hi,
> > to extend my skills, I am learning python. I have written small
> > program which computes math expression like "1+2*sin(y^10)/cos(x*y)"
> > and similar, so far only + - * / ^ sin con tan sqrt are supported. But
>
On Aug 26, 5:56 pm, [EMAIL PROTECTED] wrote:
> Hi,
> to extend my skills, I am learning python. I have written small
> program which computes math expression like "1+2*sin(y^10)/cos(x*y)"
> and similar, so far only + - * / ^ sin con tan sqrt are supported. But
> my program is quite inextensible,
Thanks a lot for comments! I am going to fix the source according to
your advices ;)
Nep
On Aug 26, 6:32 pm, Steven D'Aprano <[EMAIL PROTECTED]
THIScybersource.com.au> wrote:
> On Sun, 26 Aug 2007 15:56:08 +, neptundancer wrote:
> > Hi,
> > to extend my skills, I am learning python. I have
On Sun, 26 Aug 2007 15:56:08 +, neptundancer wrote:
> Hi,
> to extend my skills, I am learning python. I have written small
> program which computes math expression like "1+2*sin(y^10)/cos(x*y)" and
> similar, so far only + - * / ^ sin con tan sqrt are supported. But my
> program is quite in
Hi,
to extend my skills, I am learning python. I have written small
program which computes math expression like "1+2*sin(y^10)/cos(x*y)"
and similar, so far only + - * / ^ sin con tan sqrt are supported. But
my program is quite inextensible, I have to change the code to add new
functions... Could
97 matches
Mail list logo
