On Monday 07 September 2009 20:26:02 John Nagle wrote:
Right. Tracking mutablity and ownership all the way down without
making the language either restrictive or slow is tough.
In multi-thread programs, though, somebody has to be clear on who owns
what. I'm trying to figure out a
Hendrik van Rooyen hend...@microcorp.co.za writes:
In any case - if you do not actually like juggling with knives, then you
should not be mucking around with concurrency, and by making the language
safe, you are taking the fun out.
Oh come on, Erlang and Haskell both take care of it rather
On Tue, 08 Sep 2009 09:38:51 +0200, Hendrik van Rooyen wrote:
On Monday 07 September 2009 20:26:02 John Nagle wrote:
Right. Tracking mutablity and ownership all the way down without
making the language either restrictive or slow is tough.
In multi-thread programs, though, somebody
Steven D'Aprano wrote:
On Tue, 08 Sep 2009 09:38:51 +0200, Hendrik van Rooyen wrote:
On Monday 07 September 2009 20:26:02 John Nagle wrote:
Right. Tracking mutablity and ownership all the way down without
making the language either restrictive or slow is tough.
In multi-thread
Is the difference because of mutability versus immutability, or
because of C code in Numpy versus Matlab code? Are you comparing
bananas and pears?
It consisted of something like this
Your code does a lot of unnecessary work if you're just trying to
demonstrate immutability is faster
2009/9/7 Terry Reedy tjre...@udel.edu:
Dennis Lee Bieber wrote:
I'd say the
mutables are in the majority G
I think it depends on whether one counts classes or instances. Typical
programs have a lot of numbers and strings.
Ah, but immutable instances can be, and often are, interned. This
John Nagle wrote:
In the beginning, strings, tuples, and numbers were immutable, and
everything else was mutable. That was simple enough. But over time,
Python has acquired more immutable types - immutable sets and immutable
byte arrays. Each of these is a special case.
snip
Graham Breed wrote:
John Nagle wrote:
In the beginning, strings, tuples, and numbers were immutable, and
everything else was mutable. That was simple enough. But over time,
Python has acquired more immutable types - immutable sets and immutable
byte arrays. Each of these is a special
John Nagle na...@animats.com writes:
Right. Tracking mutablity and ownership all the way down without
making the language either restrictive or slow is tough.
In multi-thread programs, though, somebody has to be clear on who owns
what. I'm trying to figure out a way for the
On Sep 5, 7:38 pm, Steven D'Aprano st...@remove-
No. Lambdas are a *syntactical construct*, not an object. You wouldn't
talk about while objects and if objects and comment objects
*because they're not objects*.
This rhetoric precludes functions objects as well and is entirely non-
compelling.
On Sep 5, 10:34 pm, Terry Reedy tjre...@udel.edu wrote:
Adam Skutt wrote:
On Sep 5, 11:29 am, Terry Reedy tjre...@udel.edu wrote:
This is a pointless replacement for 'def b(x): return x+a'
And? That has nothing to do with anything I was saying whatsoever.
Agreed. However, posts are
John Nagle:
The concept here is that objects have an owner, which is either
a thread or some synchronized object. Locking is at the owner
level. This is simple until ownership needs to be transferred.
Can this be made to work in a Pythonic way, without explicit
syntax?
What we want to
Adam Skutt wrote:
On Sep 5, 10:34 pm, Terry Reedy tjre...@udel.edu wrote:
Adam Skutt wrote:
On Sep 5, 11:29 am, Terry Reedy tjre...@udel.edu wrote:
This is a pointless replacement for 'def b(x): return x+a'
And? That has nothing to do with anything I was saying whatsoever.
Agreed.
Bearophile wrote:
John Nagle:
The concept here is that objects have an owner, which is either
a thread or some synchronized object. Locking is at the owner
level. This is simple until ownership needs to be transferred.
Can this be made to work in a Pythonic way, without explicit
syntax?
On Sun, 06 Sep 2009 06:18:23 -0700, Adam Skutt wrote:
On Sep 5, 7:38 pm, Steven D'Aprano st...@remove-
No. Lambdas are a *syntactical construct*, not an object. You wouldn't
talk about while objects and if objects and comment objects
*because they're not objects*.
This rhetoric precludes
On Sun, 06 Sep 2009 10:12:56 -0400, Terry Reedy wrote:
Adam Skutt wrote:
There's nothing inappropriate about using a lambda for a function I
don't care to give a name. That's the entire reason they exist.
But you did give a name -- 'b' -- and that is when a lambda expression
is
Dennis Lee Bieber wrote:
On Sun, 06 Sep 2009 20:29:47 -0700, John Nagle na...@animats.com
declaimed the following in gmane.comp.python.general:
Python has the advantage that a sizable fraction of its objects, especially
the very common ones like numbers and strings, are immutable.
On Fri, 04 Sep 2009 22:30:44 -0700, sturlamolden wrote:
On 5 Sep, 07:04, Steven D'Aprano st...@remove-this- cybersource.com.au
wrote:
How does Matlab speed compare to Python in general?
Speed-wise Matlab is slower, but it is not the interpreter limiting the
speed here.
How do you know?
On 5 Sep, 08:47, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
How do you know?
After more than 10 years experience with scientific programming I just
do. When it comes to numerics I have a gut feeling for what is fast
and what is slow.
It's not difficult actually. You just have
On Sep 5, 12:06 am, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
On Fri, 04 Sep 2009 06:36:59 -0700, Adam Skutt wrote:
Nope, preventing mutation of the objects themselves is not enough. You
also have to forbid variables from being rebound (pointed at another
object).
Adam Skutt wrote:
\
This is a side-effect of writing code that relies on global variables.
Global variables are generally a bad idea. Global constants are fine.
Nope, the variables don't have to be global to have this problem, they
just have to be shared:
a = 3
b = lambda x: x + a
On Sep 5, 11:29 am, Terry Reedy tjre...@udel.edu wrote:
This is a pointless replacement for 'def b(x): return x+a'
And? That has nothing to do with anything I was saying whatsoever.
Point is: any mutable shared state is bad, and making objects
immutable isn't enough to remove all shared state,
On Sat, 05 Sep 2009 14:09:57 -0700, Adam Skutt wrote:
Python does not have lambda objects. It has lambda expressions that
produce function objects identical except for .__name__ to the
equivalent def statement output.
Sure sounds like python has lambda objects to me then... the fact
they're
On Sat, 05 Sep 2009 04:57:21 -0700, Adam Skutt wrote:
so the fact Foo and Bar are immutable isn't enough to solve the
problem.
This is a side-effect of writing code that relies on global variables.
Global variables are generally a bad idea. Global constants are fine.
Nope, the variables
Adam Skutt wrote:
On Sep 5, 11:29 am, Terry Reedy tjre...@udel.edu wrote:
This is a pointless replacement for 'def b(x): return x+a'
And? That has nothing to do with anything I was saying whatsoever.
Agreed. However, posts are read by newbies.
Posts that promote bad habits are fair game
Steven D'Aprano wrote:
On Fri, 04 Sep 2009 06:36:59 -0700, Adam Skutt wrote:
Nope, preventing mutation of the objects themselves is not enough. You
also have to forbid variables from being rebound (pointed at another
object).
Right. What's needed for safe concurrency without global
The future of Python immutability
Define future:
The future is a time period commonly understood to contain all
events that have yet to occur. It is the opposite of the past, and is
the time after the present
Define immutability:
Not subject or susceptible to change. In object-oriented and
On Sep 3, 9:07 pm, Nigel Rantor wig...@wiggly.org wrote:
Right, this is where I would love to have had more experience with Haksell.
Yes, as soon as you get to a situation where no thread can access shared
state that is mutable your problems go away, you're also getting no work
done becasue
Nigel Rantor wrote:
John Nagle wrote:
Immutability is interesting for threaded programs, because
immutable objects can be shared without risk. Consider a programming
model where objects shared between threads must be either immutable or
synchronized in the sense that Java uses the term.
Ulrich Eckhardt eckha...@satorlaser.com writes:
Lastly, for the message passing, you also need shared, mutable structures
(queues), so you can't live completely without conventional locking.
But that can be completely behind the scenes in the language or
library implementation. The application
On Thursday 03 September 2009 21:07:21 Nigel Rantor wrote:
That is not the challenge, that's the easy part. The challenge is
getting useful information out of a system that has only been fed
immutable objects.
Is it really that difficult? (completely speculative):
class MyAnswer(object):
On Sep 3, 2:03 pm, John Nagle na...@animats.com wrote:
Suppose, for discussion purposes, we had general immutable objects.
Objects inherited from immutableobject instead of object would be
unchangeable once __init__ had returned. Where does this take us?
You can create this in various
John Nagle wrote:
... Suppose, for discussion purposes, we had general immutable objects.
Objects inherited from immutableobject instead of object would be
unchangeable once __init__ had returned. Where does this take us?
Traditionally in Python we make that, once __new__ had returned.
On 4 Sep, 06:20, John Nagle na...@animats.com wrote:
In the current CPython implementation, every object has a reference
count, even immutable ones. This must be a writable field - and here you
have your race condition, even for immutable objects.
That's an implementation problem with
On 3 Sep, 20:03, John Nagle na...@animats.com wrote:
Python doesn't have immutable objects as a general concept, but
it may be headed in that direction. There was some fooling around
with an immmutability API associated with NumPy back in 2007, but
that was removed. As more immutable
On Fri, 04 Sep 2009 19:23:06 -0700, sturlamolden wrote:
I one did a test of NumPy's mutable arrays against Matlab's immutable
arrays on D4 wavelet transforms. On an array of 64 MB of double
precision floats, the Python/NumPy version was faster by an order of
magnitude.
Is the difference
On 5 Sep, 05:12, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
Is the difference because of mutability versus immutability, or because
of C code in Numpy versus Matlab code? Are you comparing bananas and
pears?
It consisted of something like this
import numpy
def
On Fri, 04 Sep 2009 06:36:59 -0700, Adam Skutt wrote:
Nope, preventing mutation of the objects themselves is not enough. You
also have to forbid variables from being rebound (pointed at another
object). Consider this simple example:
-- Thread 1 -- | -- Thread 2
On Fri, 04 Sep 2009 20:48:13 -0700, sturlamolden wrote:
Is the difference because of mutability versus immutability, or
because of C code in Numpy versus Matlab code? Are you comparing
bananas and pears?
It consisted of something like this
Your code does a lot of unnecessary work if
On 5 Sep, 07:04, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
Your code does a lot of unnecessary work if you're just trying to
demonstrate immutability is faster or slower than mutability.
No ... I was trying to compute D4 wavelet transforms. I wanted to see
how NumPy compared
On 5 Sep, 07:04, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
How does Matlab speed compare to Python in general?
Speed-wise Matlab is slower, but it is not the interpreter limiting
the speed here.
--
http://mail.python.org/mailman/listinfo/python-list
John Nagle wrote:
Python's concept of immutability is useful, but it could be more
general.
In the beginning, strings, tuples, and numbers were immutable, and
everything else was mutable. That was simple enough. But over time,
Python has acquired more immutable types - immutable sets
Nigel Rantor wrote:
John Nagle wrote:
Immutability is interesting for threaded programs, because
immutable objects can be shared without risk. Consider a programming
model where objects shared between threads must be either immutable or
synchronized in the sense that Java uses the
Stefan Behnel wrote:
Nigel Rantor wrote:
John Nagle wrote:
Immutability is interesting for threaded programs, because
immutable objects can be shared without risk. Consider a programming
model where objects shared between threads must be either immutable or
synchronized in the sense that
Nigel Rantor wrote:
My comment you quoted was talking about Java and the use of
synchronized. I fthat was unclear I apologise.
Well, it was clear. But it was also unrelated to what the OP wrote. He was
talking about the semantics of synchronized in Java, not the use.
Stefan
--
John Nagle wrote:
With this mechanism, multi-thread programs with shared data
structures can be written with little or no explicit locking by
the programmer. If the restrictions are made a bit stricter,
strict enough that threads cannot share mutable unsynchronized data,
removal of the
Stefan Behnel stefan...@behnel.de writes:
Read again what he wrote. In a language with only immutable data types
(which doesn't mean that you can't efficiently create modified versions of
a data container), avoiding race conditions is trivial. The most well known
example is clearly Erlang.
En Thu, 03 Sep 2009 15:03:13 -0300, John Nagle na...@animats.com
escribió:
Python's concept of immutability is useful, but it could be more
general.
Immutability is interesting for threaded programs, because
immutable objects can be shared without risk. Consider a programming
Gabriel Genellina wrote:
En Thu, 03 Sep 2009 15:03:13 -0300, John Nagle na...@animats.com
escribió:
Python's concept of immutability is useful, but it could be more
general.
Immutability is interesting for threaded programs, because
immutable objects can be shared without risk.
49 matches
Mail list logo
