I have been dabbling in Python for a while now. One of the things that
really appeals to me is that I can seem to be able to use C++-style
RAII idioms to deal with resource management issues.
For those that have no idea what I am talking about (I learn a lot
reading posts on subjects in which I a
Thanks to all who replied. This has definitely given me something to
chew on.
I looked at pep-0343, it looks interesting. It is not what I really
want (deterministic destruction) but it is a lot more than most GC'ed
languages give me (Java, I am looking at you... :-) ).
As far as my comment abo
Hi Paul,
>> I looked at pep-0343, it looks interesting. It is not what I really
>> want (deterministic destruction)
>
>I think it's better.
Is there something specific you have in mind that makes you say that?
I am not a python expert, so I probably do not understand all the
implications of the
Hi Paul,
> I didn't understand then. I thought by "deterministic destruction"
> you meant relying on what CPython does now, which is reference
> counting with destruction when the last reference is released.
I effectively do mean that. In C++ it is guaranteed that a destructor
will be called
Ok,
I give up. DRY = Don't Repeat Yourself (google Pragmatic Programmers)
but SPOT? Google is little help here, SPOT is too common a word.
Thanks!
--
http://mail.python.org/mailman/listinfo/python-list
> Oh, don't tell me, I love playing guessing games!
Don't you mean "No no... don't tell me. I'm keen to guess."
Sorry, I couldn't resist... :-)
(for those who just went huh?, see
http://www.aldo.com/sgt/CheeseShoppeSkit.htm)
--
http://mail.python.org/mailman/listinfo/python-list
stupid question, but did you try:
rsa = M2Crypto.RSA.load_pub_key( file("pubkey.pem") )
It is not clear from the documentation what they want for "file" (and
because Python has no type declarations, you are left to guess...).
May not work... just thought I would ask.
--
http://mail.python.org/
Looking at the api documentation again, it is possible that they want
this:
pubkey = open( 'pubkey.pem', 'rb' ).read() # binary read here?
rsa = M2Crypto.RSA.load_pub_key(pubkey)
Anyway, things to play with...
--
http://mail.python.org/mailman/listinfo/python-list
Hi,
1585 if sys.path[0][-12:] == "\library.zip": #for py2exe
how about
if sys.path[0].endswith( "\\library.zip" ):
(did you really mean one back-slash there?)
499 tuple = os.path.split(filename)
bad variable name... tuple(x) converts a sequence to a tuple.
You have a number of places
This may not be enough for what you really want to do, but, given what
you have shown above, regex is the wrong tool for the job.
Use the string method startswith:
for line in ProcMem.split('\n'):
if line.startswith( 'Mem' ):
# do stuff
--
http://mail.python.org/mailman/listinfo/pyt
Hi,
you have plenty of good responses. I thought I would add one more:
def data_iter(file_name):
data = file(file_name)
while True:
value = data.read(3)
if not value:
break
yield value
data.close()
With the above, you can grab the entire data set
Scott,
this was a really clever catch, but I don't agree with the solution.
The problem is your assumption of how zip/izip _must_ work. I don't
think there is any contract that states that they will always advance
the first argument first and the second argument second... that is an
implementatio
You don't _need_ to go the PYTHONPATH route (although that works).
Re-read Carsten's post (particularly step 1, see section 6.1.1).
You can use:
sys.path.append('..')
from brave import sir_robin
--
http://mail.python.org/mailman/listinfo/python-list
Doesn't this do what you want?
import re
DATE_TIME_RE =
re.compile(r'((\d{2}\/\d{2}\/\d{4})|(\d{2}:\d{2}))<\/td>')
test = '04/01/2006' \
'Wednesday' \
' ' \
'09:14' \
'12:44' \
'12:50' \
'17:58' \
' ' \
' '
I thought I understood raw strings, then I got bitten by this:
x=r'c:\blah\'
which is illegal! I thought that \ had no special meanning in a raw
string so why can't it be the last character?
making me do:
x=r'c:\blah' '\\'
is just silly...
--
http://mail.python.org/mailman/listinfo/python-l
Hi Duncan,
thanks for the reply. I figured that this was a technical problem
associated with the parser.
This one is going on my Python gotchas list. It is really silly from
an end user perspective to have \ not special in raw strings _except_
if it is the last character.
--
http://mail.pytho
>Yes, and that's the Right Thing(tm) to do. Source code don't lie. Source
> code don't get out of sync. So source code *is* the best documentation
>(or at least the most accurate).
I could not disagree more strongly with this. Not just no, but hell
no!
>Yes, and that's the Right Thing(tm) to do
Hi,
thanks for the reply. I was not aware of this in raw strings (and
frankly, don't like it... but who cares about that :-) )
When I needed embedded quotes in a raw string I went the triple quote
route:
a = r'''check \' this'''
which makes more sense to me.
--
http://mail.python.org/mailman
Hi Alex,
thanks for the reply. I can see that there is a choice that needed to
be made. Before I was aware of the \ issue I just used (yes it has
come up, but the example is at work) triple quotes to work around the
embedded quote issue:
x=r'''It's like this "c:\blah\" ok?'''
print x
It's like
Hi Steven,
thanks for the reply. I was/am aware that raw strings are mainly used
for regular expressions (and franky that was I usually use them for).
I was not aware that they still have "special powers" in raw strings
(thanks for the link!).
This one bit me when I was doing some quick and dirt
>Alas, somebody will now quote Emerson at you, I fear;-).
Let them come :-)
I almost always see this (mis)quoted as:
"consistency is the hobgoblin of little minds"
which is not really what Emerson said. The full quote is:
"A foolish consistency is the hobgoblin of little minds"
I would say t
Interesting, so thats where this comes from.
Of course the problem is that I thought that a raw string was a
different animal than a regular string (i.e. truely "raw" where no
characters are special, except of course the closing quote) so parsing
consistency is surprising to an end user (who has a
I have not looked into C programming and Python so I probably don't
understand the issues here but the above statement sounds very
troubling.
Does this mean that any integer or float created anywhere at anytime in
a (pure) python program will be stored away for all time (as long as
the program is
Sorry for responding to my own post.
I think I understand the original statement now. What you are really
saying is that there is a pool of Python float objects (which can, at
different times, wrap different values) which can grow but never
decrease in size. So the memory held by this pool is di
This exactly what I was thinking.
Are we wrong Alex?
--
http://mail.python.org/mailman/listinfo/python-list
Check out os.path.isdir(path_name)
http://docs.python.org/lib/module-os.path.html
--
http://mail.python.org/mailman/listinfo/python-list
26 matches
Mail list logo