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
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
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:
> 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
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
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
62 matches
Mail list logo
