cache__ is if you
have a directory with lots of stuff and one or two python files in the
mix; and then you add that directory to sys.path and import the
files. It creates the __pycache__ in that directory. It's a bit of a
shock compared to the *.pyc files because it's at a very
anything really difficult. (I don't think a lot of people
know about -prune; it tells find don't recursively descend.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
mand for it. If your users
are loading 1.5 GB arrays into memory, it's probably not unreasonable
to expect them to have numpy installed.
Other than that you're probably stuck emulating 2D with the array
module.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 10, 8:29 am, Tim wrote:
> I think I may have included too much fluff in my original question.
> The main thing I wonder is whether I can attach a log handler to
> stdout in such a way that os.system calls will write to that handler
> instead of the console.
--
http://mail.python.org/mailma
obably should
only do this if you know that it works with all the commands it
issues.
The better way might be to call the subprocess module instead, where
you can dispatch the command with redirection to any stream. I doubt
there's a foolproof way to do that given an arbitrary os.system
command, but the subprocess way is probably safer.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
) as f:
g = f
print g
It would print . The object still exists
because there is a reference to it, but the file has been closed.
If you can tell us why it's so important that the object be destroyed
at that given time, even while a reference to it exists, maybe we can
give you better
t weak
referencing. (Look at the documentation for the weakref module.
Also, this has nothing to do with A and B being C-defined types; this
exact same behavior would happen even with Python types.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 6, 8:32 am, Tim Harig wrote:
> 2. Your so-called PEP probably clashes with Python's use of @ for
> decorators.
He said it was just for simplicity's sake.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ding a better syntax, I'll give it a +0; and the only reason I
don't give it a +1 is it's such a drastic change.
The syntax probably would deserve a lot of thought (being such a
drastic change) but drawing from C++ a postfix operator would seem to
fit.
sys:: -> evaulates to the sys module
sys::version -> evaluates to sys.version
xml::etree::ElementTree:: -> as expected
That has the unfortunate effect of making Python look like C++ though.
Won't ever happen though.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Public API is
to get performance benefits (most Python built-in classes access the
internal structure directly for this reason). There are occasions
where a function really needs to access the internals and not the
"visible" value.
Also, in Python it's reasonable to consider an in
ly to C" is going to be a tall order.
If you can get this to work reasonably well, and manage to get it
successfully deployed it somewhere, I'd recommend petitioning to have
this be considered an official platform.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
"/usr/lib/python2.6/re.py", line 245, in _compile
raise error, v # invalid expression
sre_constants.error: unbalanced parenthesis
OHMYGOD HOW DARE the standard library allow the traceback list an
internal function that does input valididation!
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
en I get an error like the one shown above.
Python makes no attempt to hide its machinery in tracebacks (that I'm
aware of); in fact stack points from internal Python functions,
classes, and modules appear in tracebacks all the time. The reason
you don't see traceback lines for Python's argument validation is it's
written in C. If it bothers you that much, you're welcome to write
you own argument validation in C, too.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ary builds the tags with "with" statements, which could be
convenient for xml files with rigid structure, but I would think it'd
be inconvenient if the format were relatively loose.
If you're going to recommend a more specialized solution, you should
also give the conditions for which it is suitable.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Dec 25, 6:21 am, Robert Kern wrote:
> On 12/24/10 4:24 AM, Steven D'Aprano wrote:
>
> > On Thu, 23 Dec 2010 22:38:05 -0800, Carl Banks wrote:
> >> OTOH, going the extra mile to hide useful information from a user is
> >> asinine. As a user, I will
ever has been, about hiding internal details.
It's about openness, and there's no reason a traceback should hide
internal details any more than a class should--in fact hiding
information in the traceback is far worse, because you're suppressing
information that could be crucial for
On Dec 24, 1:24 am, Steven D'Aprano wrote:
> On Thu, 23 Dec 2010 22:38:05 -0800, Carl Banks wrote:
> > OTOH, going the extra mile to hide useful information from a user is
> > asinine. As a user, I will decide for myself how I want to use
> > implementation-defined inf
On Dec 23, 8:55 pm, Steven D'Aprano wrote:
> On Thu, 23 Dec 2010 02:54:52 -0800, Carl Banks wrote:
> > On Dec 22, 7:22 pm, Steven D'Aprano > +comp.lang.pyt...@pearwood.info> wrote:
> >> There should be a mechanism for Python functions to distinguish between
&g
exceptions, which should be reported as coming from the function
> regardless of how deep the function call stack really is.
No, -100. The traceback isn't the place for this. I've never
disagreed with you more, and I've disagreed with you and awful lot.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
back?
> It is of no use (certainly no *immediate*
> use) to this audience to see tracebacks that go deep into code that
> they don't know anything about and cannot change.
Seriously, quit trying to do the user favors. There's nothing that
pisses me off than a self-important dev
On Dec 17, 12:23 am, Steven D'Aprano wrote:
> On Thu, 16 Dec 2010 20:32:29 -0800, Carl Banks wrote:
> > Even without the cleanup issue, sometimes you want to edit a function to
> > affect all return values somehow. If you have a single exit point you
> > just make the
was to remove lines for endemic
wrapper functions.
The traceback lines showing the wrapper functions in the stack were
useless, and since pretty much every function was wrapped it meant
half the lines in that traceback were useless. (Really. I was scanning
the loaded modules and adding wrappers to e
Assuming you're using "with" or "try-finally" then you just
> don't need such guarantees in python.
Even without the cleanup issue, sometimes you want to edit a function
to affect all return values somehow. If you have a single exit point
you just make the change
tious there's some stuff you can do with netfilter to
attach user ids to network packets which you might be able to read
with your logging software. How are you logging web site accesses
anyway? That would be helpful to know.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
#x27;d recommend f2py, which is part of the numpy package.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ability since the operators could be
expected to act in consistent ways, but Python isn't that language.
So you might as well use the operators for whatever seems like it
works, + for concatenation, > for superset, and so on.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
of comparisons.
I think that feeling the need to sort non-homogenous lists is
indictative of bad design.
If the order of the items doesn't matter, then there must be some
small bit of homogeneity to exploit to use as a sort criterion. In
that case you should use key= parameter or DSU.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Dec 6, 2:42 pm, Carl Banks wrote:
> Or, you could just put your try...finally inside a loop.
er, try...except
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ne):
> me._escape(value)
> def __enter__(me):
> me._bind = FluidBinding(RESTARTS, Link(me, RESTARTS.value))
> me._bind.__enter__()
> return super(restart, me).__enter__()
> def __exit__(me, ty, val, tb):
> ## Poor man's PROG1.
> try:
> return super(restart, me).__exit__(ty, val, tb)
> finally:
> me._bind.__exit__(ty, val, tb)
>
> def find_restart(name):
> r = RESTARTS.value
> while r:
> if r.item.name == name:
> return r.item
> r = r.next
> return None
>
> Using all of this is rather cumbersome, and Python doesn't allow
> syntactic abstraction so there isn't really much we can do to sweeten
> the pill. But I ought to provide an example of this machinery in
> action.
>
> def toy(x, y):
> r = restart('use-value')
> with r:
> if y == 0:
> error(ZeroDivisionError())
> r.result = x/y
> return r.result
>
> def example():
> def zd(exc):
> if not isinstance(exc, ZeroDivisionError):
> return
> r = find_restart('use-value')
> if not r: return
> r.invoke(42)
> print toy(5, 2)
> with handler(zd):
> print toy(1, 0)
>
> Does any of that help?
You could do that.
Or, you could just put your try...finally inside a loop.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
for a Python runtime which has fast path code for the common case, the
> case
> where the meaning of "+" doesn't change between every opcode. PyPy
> has
> produced some pretty good results with this approach.
Right. The key is to be able to dispatch on the type of object once
for a given chunk of code, which is possible if you do some kind of
flow path analysis on the function/chunk.
PyPy is starting to look much better of late, I kind of thought their
first approach was wrong (or at least too much) but they seem to have
pushed though it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
n Python it's (start,stop,step), so you should
be using this:
xx = range(-kappa,kappa+1,h)
Other than that, you might jus have to pepper your scripts with prints
and disps to catch the exact point where the discrepancy occurs.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
aryFile creates the temporary file itself.
So, if you trust your OS more than Python, use os.tempfile.
I-only-use-tempfile-module-ly yr's,
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Nov 5, 4:21 pm, Stefan Behnel wrote:
> Hi all,
>
> I am happy to announce the release of Lupa 0.17, Lua in Python.
>
> http://pypi.python.org/pypi/lupa/0.17
>
> Have fun,
>
> Stefan
Thanks, interesting projection. Good idea.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
you
should have long ago refactored it into a function-call dispatch
(which is what others have posted) for the sake of organizing code.
For this program, what you have it fine.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
eturn True
(Unless you meant worst case, which I don't consider important for
dictionary lookups.)
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
heritance, so when you have a class library in C++ you tend
to get hierarchies where classes with all kinds of abstract base
classes so that types can be polymorphic. In Python you don't need
abstract base classes so libraries tend to be flatter, only inheriting
when behavior is shared.
However it's not really that big of a difference.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Oct 21, 11:53 am, Brendan wrote:
> On Oct 21, 3:47 pm, Carl Banks wrote:
> > On Oct 21, 11:09 am, Brendan wrote:
>
> > > Two modules:
> > > x.py:
> > > class x(object):
> > > pass
>
> > > y.py:
> > > from x import x
hat's in the namesace; therefore it
lists x. dir() doesn't care, and can't know, if something was defined
in a namespace, or merely imported.
If it bothers you, you can put "del x" after the class y definition,
but I recommend against doing that in general. If there's a
x27;ve done is to hide it from everyone,
so I wouldn't call it Data Hiding(tm), even if you have, technically,
hidden data.
The term I use for what you did here is "enforcing an invariant", and
I think it is an interesting feature and occasionally indispensible,
but it's also s
On Oct 19, 8:59 pm, Lawrence D'Oliveiro wrote:
> In message
> , Carl
>
> Banks wrote:
> > On Oct 18, 4:15 pm, Lawrence D'Oliveiro
> > wrote:
>
> >> In message
> >> <42d82f8a-4ee6-44a7-914d-86dfc21f1...@a36g2000yqc.googlegroups.com>,
&
on of
objects. If you drop an item, does it disappear, or does it become an
object of the room? Weak referencing won't help you in the latter
case because you have to take care of references at both ends anyway.
That's what I mean by shaky: it lets you forget about half of the
transaction, which might not be the best thing. YMMV
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
t then the answer is no longer completely deterministic.
Yes it is, unless you're using your Geiger counter random bit
generator function.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
good idea to let an item disappear from your
inventory by a weak reference disappearing. It seems a little shaky
to not know where your objects are being referenced, but that's yout
decision.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
bject, and apply them
> later?
Your objects should have two sets of attributes (beginning of round,
end of round) and a method to copy the end-of-round attributes to the
beginning-of-round area at the end of the round.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
hing like:
ns = np.ndarray(len(s),np.uint8,s)
return np.all(np.logical_and(ns>=32,ns<=127))
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Oct 14, 10:53 am, Paul Rubin wrote:
> Carl Banks writes:
> > In general, the only way to test if a generator is empty is to try to
> > consume an item. (It's possible to write an iterator that consumes an
> > item and caches it to be returned on the next next(), an
up if the there are no items. It's a PITA to use EAFP for
that, which is why an iterator that consumes and caches can be a
useful thing.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
other iterators return True.) The
better thing would be if boolean wasn't used to test for emptiness at
all; the whole concept of booleans in Python is overloaded and that
hurts duck typing.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ol called f. If I make g return
> self.f
> instead, things work as expected, but the code loses some readability.
>
> Is there any way around this or is that simply "a matter of life"?
Matter of life. It's that way by design.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
subclass, but it won't. Another example is float.__divmod__, which
returns a tuple. Your coercive type would fail to convert the items
of that tuple. A metaclass like this I think would be possible, with
the understanding that it can never be foolproof, but it needs more
work.
Pointers:
Defining __init__ isn't necessary for this metaclass.
The "len(cls_bases) > 1" test can be thwarted if the base type
multiply inherits from other types itself. The best thing to do is
handle the case of arbitrary type hierarchies, but if you don't want
to do that then the right way to catch it is to create the subtype
then check that the __mro__ is (type, base_type, object).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Oct 4, 3:09 pm, Gregory Ewing wrote:
> Carl Banks wrote:
> > Numpy uses + for elementwise addition, and a function
> > called concatenate for concatenation. If Python lists used a separate
> > concatenation operator, then Numpy arrays could use that for
> > con
t things hurts duck typing. Numpy
arrays quack like a duck, but they aren't ducks. That's bad.
The point is, the reason to have separate operators for addition and
concatenation is not that it's so wonderfully useful, it's that it
avoids serious drawbacks.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
f a class is specifically designed to be subclassed by third-
party users, and it's not using name mangling or some other way to
avoid name collisions, then I would call it defective.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
it's a deliberate enhancement, as with slicing)
but because Python chose to use + for something other than addition it
has to diverge.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Yes. It's not the end of the world, but a separate concatenation
operator would have been better. Then there's no temptation to
special case a failure of sum(list_of_strings), because it's not a sum
any more.
As for repeat, I can't personally think of a time I ever repeated
an
program source file.
That's funny because I went to PEP 263 and the line he used was listed
there. Apparently, you're the one that needs to read PEP 263.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Sep 19, 5:10 am, Thomas Jollans wrote:
> On Sunday 19 September 2010, it occurred to Carl Banks to exclaim:
> > I am creating a ctypes buffer from an existing non-ctypes object that
> > supports buffer protocol using the following code:
>
> > from ctypes import *
>
works
because it is actually tacked on.
Apart from occasions like this and throwaway one-liners I use regular
if-then statements. If Python had added the C-like a ? b : c, then
I'd use it a lot more, since that version is not inherently
unbalanced.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
6 for now.
Thanks.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ply because you want to share code. I think that's what you meant.
> Just make it a
> function and place it in one of your modules (files):
Or even just make it a global variable in the module (which would work
in this case, unless you plan to update the environment within the
program).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
:,:,1,2] = a[:,:,1,2]*b[:,:,1,1] + a[:,:,2,2]*b[:,:,1,2]
etc.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
xception or have undefined behavior, not
segfault. I would check to see if the same problem exists on 2.7, and
file a bug report if so. If they fix it in 2.7 maybe you could apply
the same fix to your own 2.5.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Sep 6, 4:44 pm, Dave Angel wrote:
> On 2:59 PM, Carl Banks wrote:> On Sep 5, 5:07 pm, Dave Angel
> wrote:
> >> On 2:59 PM, Carl Banks wrote:
> >>> All of this gets a lot more complicated when packages are involved.
> >> Perhaps a better answer woul
, so when documentation says "Compare the files named f1 and f2" I
think it has that covered. I understand the os.stat comparison to be
a (non-foolproof) optimization.
Anyway, if you just want to compare the os.stat parameters you should
just use os.stat.
os.stat(filename1) == os.stat
On Sep 5, 5:07 pm, Dave Angel wrote:
> On 2:59 PM, Carl Banks wrote:
> > All of this gets a lot more complicated when packages are involved.
>
> Perhaps a better answer would be to import __main__ from the second module.
Then what if the module is imported from a different script
oiding side
effects due to it being named __main__, the easiest thing to do is to
put something like the following boilerplate at the top of the module
(this causes the module to rename itself).
import sys
if __name__ == '__main__':
is_main = True # since you're overwriting __name__ you'll need
this later
__name__ = 'foo'
sys.modules['foo'] = sys.modules['__main__']
else:
is_main = False
All of this gets a lot more complicated when packages are involved.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Sep 2, 1:37 pm, Baba wrote:
> level: beginner
In this economy, simulating the value of retirement funds with
bisection is easy. Look:
def retirement_fund_value(n_years,initial_value):
for i in xrange(n_years):
value /= 2 # <- bisect value of fund
return value
Carl
write it in C it'll run a lot faster.
numpy is terrific when you can use it, and I've found that it can do a
lot more than most people expect. The hard part is figuring out how.
In particular, numpy will trounce Matlab's performance for large
amounts of data, because of the aforementioned memory management
problem.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ut at least there's that setrecursionlimit call.
>
> But be warned that if you set the limit too high instead of giving you a
> RuntimeError your program will segfault.
Ah, an advantage of iteration I forgot: no recursion limits or stack
overflows.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
rsion is better.
So I'm not suggesting that recursion be avoided (I've probably written
a dozen recursive functions in the last week), I'm just saying
sometimes it makes sense to use iteration even for problems recursion
is tailor-made for.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
f if there wasn't an error
def main():
try:
run_program()
except MyException as exc:
print >> sys.stderr, str(exc)
sys.exit(1)
If you call sys.exit() deep within your call tree, the world won't
come to an end, but raising an exception is the preferred
building up some
> kind of stack overflow or something which will bite me later.
What do you think a few words of data the stack are going to do?
Just do it this way.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
If you're going to send me unsolicited email, the least you can do it
include pics of Erin.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Aug 10, 12:06 am, Ulrich Eckhardt wrote:
> Carl Banks wrote:
> > I highly doubt the Python source would build with a C++ compiler.
>
> As Christian showed, it doesn't. However, look around the sources a bit.
> There are lots of places where e.g. the returnvalue of mall
e modules according to "dependencies", so
as to remove the circular import, makes it more confusing. Sometimes
organizing by function makes more sense than organizing by dependency,
and it's better to live with circular imports than to use a less-
sensical organization.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
cally
equivalent) C++. But if you don't actively try to write code that is
compatible with both languages, chances are the C code will invoke one
of those "'minor' 'backwards' incompatibilies", the most common one
being failure to cast a pointer.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
xpected ctc:
> notice period:
#1: You should post this on the Python jobs board.
http://www.python.org/community/jobs/
#2: I know the economy's bad but not everyone is going to apply to
every job posting they see. You should include a least a little
information about the job.
Carl Ban
On Aug 7, 8:18 pm, Dennis Lee Bieber wrote:
> On Sat, 7 Aug 2010 13:02:56 -0700 (PDT), Carl Banks
> declaimed the following in
> gmane.comp.python.general:
>
>
>
> > Not really. Very few people call int(), float(), and company "type
> > casts".
esn't use type-
casting?
int a, b;
double ratio;
ratio = (double)a/b;
> It is unfortunate that cast's in Python share the same name, but
> it is kind of unavoidable because it is about the proper CS name to use.
Not really. Very few people call int(), float(), and company "type
casts". They aren't type casts at all, they are constructors that
sometimes have the same semantics as type casts in C.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
arch), then you have an numpy integer array
that stores the indices into this string where the word boundaries
are, and then an Nx7 numpy integer array storing the int return
vslues. That's three compact arrays.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
y, actually. However, omitting generics was probably
the second worst thing about Java (the worst thing being the awful AWT
design).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
was C++ able to get popular in the first place?
>
> Building on C's popularity helped.
AT&T + Money + C backward compatibility
> > And how was Java able to grab some share from it?
>
> Good question. Both IBM and Sun put a lot of effort/money behind
> Java.
Sun + IBM
>
> and then later,
>
> C('Hello')
>
> does not work; the first argument, self, is assigned all rigth, but
> you cannot write the second argument with a dot, self.name .
> Or can I somehow?
__init__=lambda self,name:setattr(self,'name',name)
However
#x27;m starting to get the feeling one of these languages is going to hit
a sweet spot and turn C into the next Cobol.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Aug 3, 3:19 pm, John Bokma wrote:
> Carl Banks writes:
> > On Aug 3, 2:29 am, John Bokma wrote:
>
> [..]
>
> >> But they call both the C libraries in the same way.
>
> > Go look at the original claim, the one that you responded to. "It's
&g
On Aug 3, 2:29 am, John Bokma wrote:
> Carl Banks writes:
> > On Aug 1, 6:09 pm, John Bokma wrote:
> >> Roy Smith writes:
> >> > In article <4c55fe82$0$9111$426a3...@news.free.fr>,
> >> > candide wrote:
>
> >> &g
so there's a risk of these objects escaping
from the context where they make sense.
This is just a bad idea. The type is not the place to implement
behavior that makes sense only in a limited context. Instead, do
something like this:
print "Item %d is %s." % (i+1, s[i])
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
want that in *.pyc files. In PEP
3147 they proposed a fat-format file (so a glob for each version) and
it was not popular.
> I have
> no idea what it does now,
There's a short header, then the rest of the file is a single
marshaled glob.
> but I suspect not that. It might make
ass:
class Bar {
virtual int foo(int);
virtual int bar(int);
};
might be generated like this in one cfront:
struct Bar$$Vtable$ {
int (*Bar$$bar$d)(int);
int (*Bar$$foo$d)(int);
};
and like this in another:
struct class_Foo___vtable_ {
int (*foo)(int);
in
On Aug 1, 5:43 pm, Lawrence D'Oliveiro wrote:
> In message
> <96e47fd8-c939-48a2-9a2b-92afa720c...@k1g2000prl.googlegroups.com>, Carl
>
> Banks wrote:
> > My general feeling is that ElementTree is a lot handier for reading
> > and writing your own XML formats, t
e a way to do this.
My general feeling is that ElementTree is a lot handier for reading
and writing your own XML formats, than for handling XML files produced
by other tools.
The lxml package has an ElementTree like interface but with some
methods to handle namespace abbreviations.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Jul 31, 8:48 pm, Carl Banks wrote:
> When you have a class you that don't anything about the implementation
> of, that is NOT the place for inheritance.
And, just to be clear, if the class is explicity documented as being
subclassable and the documentation states the proper pr
a wonderful, holy thing. But, sex outside of marriage, and
inheriting from classes you don't know, is deadly sin and you will
burn in Hell.
> and in my current view from a
> maintenance perspective, best practice is to only use super() in the
> multiple-inheritance scenarios it was specifically designed for
I use super() exclusively for all types of inheritance, unless I'm
inheriting from a class I know uses old form (which is none of mine,
and I only rarely inherit from classes I don't own).
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
ust
throwing it out there.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
On Jul 28, 7:45 pm, Steven D'Aprano wrote:
> On Wed, 28 Jul 2010 08:47:52 -0700, Carl Banks wrote:
> > On Jul 28, 7:32 am, Steven D'Aprano > cybersource.com.au> wrote:
> >> On Wed, 28 Jul 2010 09:35:52 -0400, wheres pythonmonks wrote:
> >> > Thank
ope that it won't explode when you try to use it :/
Type casts in C and non-pathlogical C++ don't modify the object they
are casting.
int (and str, float, etc.) is the closest thing to a type cast in
Python.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
umented as supporting inheritance
Furthermore, if you want to stay sane, don't mulitply inherit from any
class unless
A. you own it, or
B. it's explicitly documented as supporting MULTIPLE inheritance
Inheritance is always risky if you don't know what you're inheriting
from.
Carl
ate a module called foo.py,
and it have it import all the objects from the most recent release
module. IOW, you should have a foo.py module that looks like this:
from foo1 import *
Which you update whenever there's a new release. Then in your code
you simply use:
import foo
This is, in
guage.
And yet your previous thoughts seem oddly constrained by Perl
If you really want a language that can accommodate any thought you
could possibly have, you should check out Lisp.
(defmacro swap (a b)
'(let ((t1 ,a)
(t2 ,b))
(setq ,b t1)
(setq ,a t2)))
hygiene-le
the special variables, like __foo__?
Python Language Reference
> 4. Is there any work on deparsing (like Perl's deparse) lambda
> functions to inline algebra and get a performance gain?
psyco (q.g.) might help, not sure if it'll help much for lambdas,
though.
> Thanks
101 - 200 of 1709 matches
Mail list logo
