Re: Python 3.0 unfit for serious work?

Hey, > Python 3.x. I believe your fear is just a knee jerk reaction to the notion > that there will be some stated incompatibilities between 2.x and 3.x without > having done any investigation of the transition process. Nobody is forcing > you to do anything right now or completely abandon your

Re: Pep 3105: the end of print?

On Feb 23, 8:48 am, I V <[EMAIL PROTECTED]> wrote: > While that's true, C++ compiler vendors, for example, take backwards > compatibility significantly less seriously, it seems to me. A year or so > ago, I tried compiling something I'd written for g++ 2, using a > then-recent-ish g++ 3; it failed

Re: Python 3.0 unfit for serious work?

On Feb 21, 8:06 pm, [EMAIL PROTECTED] wrote: > I don't know the specifics of your app, but why does everyone insist > that they need to use the 'system' python? Hey Grant, don't worry it's not a rant. A completely valid question. Again it's a problem of dependency management ... one of the thing

Re: Python 3.0 unfit for serious work?

On Feb 21, 1:41 am, "BJörn Lindqvist" <[EMAIL PROTECTED]> wrote: [ citing me ] > "if 2.4 code doesn't run on 3.0, it's rather likely that strong > pressure will be applied to port *away* from Python into something > less capricious." > > Who are these people that are applying the strong pressure?

Re: Python 3.0 unfit for serious work?

Hi, Paul, thanks for this, I didn't realize the scope of the situation. I agree with your assessment to the extent that I understand what the whole python 3.0 thing is about. Let's see if I can scare up something I wrote about ten years ago on a now-dead language that I really wanted to use (wou

Re: How to test if one dict is subset of another?

, and leads to a less complex implementation. Rolling it into the next release is going to have to wait a few weeks, I hope I can remember it that long. Thanks!! JT On Feb 20, 8:54 pm, Paul Rubin <http://[EMAIL PROTECTED]> wrote: > "Jay Tee" <[EMAIL PROTECTED]> writes

Re: Python 3.0 unfit for serious work?

Hi, On Feb 20, 8:59 pm, Steven Bethard <[EMAIL PROTECTED]> wrote: > You snipped the rest of that comment: > > "It's not even clear yet that your average 2.6 code will work on 3.0 -- > though there's a pretty large contingent trying to make this true." Thanks for pointing this out. I voted for th

Re: How to test if one dict is subset of another?

On Feb 20, 6:44 pm, Paul Rubin wrote: > They are sets, not lists. > >from sets import Set as set # use in 2.3 and earlier > >l1= set([3, 4, 7, 2]) >l2 = set([2, 3]) >l2 = set([2, 3, 99]) >print l1 & l2 Thanks Paul, but: bosui:~> python Python 2.2.3

Re: How to test if one dict is subset of another?

Hi your post had the following construct: > for j in (index['user']['jeff'] & index['state']['running']): > do_something() but Python 2.3.4 (#1, Oct 11 2006, 06:18:43) [GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2 Type "help", "copyright", "credits" or "license" for more informat

Re: How to test if one dict is subset of another?

On Feb 20, 9:12 am, Paul Rubin wrote: > do_something() > > you'd just write: > > for j in (index['user']['jeff'] & index['state']['running']): > do_something() Hi, it looks very cool, except that one of the constraints mentioned is that the solution h

Python 3.0 unfit for serious work?

Yo, On Feb 16, 6:07 am, Steven Bethard <[EMAIL PROTECTED]> wrote: > Python 3.0 is determined not to be hampered by backwards incompatibility > concerns. It's not even clear yet that your average 2.6 code will work Then Python is pretty much determined to remove itself from consideration from vari

Re: How to test if one dict is subset of another?

On Feb 19, 11:07 am, Peter Otten <[EMAIL PROTECTED]> wrote: > Use a RDBMS (a database), they tend to be good at this kind of operations. yeah, one of the options is metakit ... sqlite and buzhug both looked promising but the constraint of pythons 2.2 and 2.3 ruled that out. disadvantage of metaki

How to test if one dict is subset of another?

Hi, I have some code that does, essentially, the following: - gather information on tens of thousands of items (in this case, jobs running on a compute cluster) - store the information as a list (one per job) of Job items (essentially wrapped dictionaries mapping attribute names to valu