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
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
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 things
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 various
On Feb 20, 9:12 am, Paul Rubin http://[EMAIL PROTECTED] 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 has to
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 information.
l1=
On Feb 20, 6:44 pm, Paul Rubin http://[EMAIL PROTECTED] 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 (#1, Oct 26
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 the
, 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:
Python 2.2.3 (#1, Oct 26 2003, 11
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
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? How can
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
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 metakit
13 matches
Mail list logo
