On Tue, 08 Sep 2009 11:23:05 -0700, Daniel Fetchinson wrote:
>> How does Matlab speed compare to Python in general? Ruby, for example,
>> is an order of magnitude slower than Python (at least it was last time
>> I looked)
>
> For what operations? Under what circumstances? I'm just being pedantic
>> > 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 immutabi
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 progr
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,
Hendrik van Rooyen 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 well.
--
http://mail.
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
John Nagle 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 language, rather tha
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 cas
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.
Immutabil
2009/9/7 Terry Reedy :
> Dennis Lee Bieber wrote:
>> I'd say the
>> mutables are in the majority
>
> 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 will
cut dow
Dennis Lee Bieber wrote:
On Sun, 06 Sep 2009 20:29:47 -0700, John Nagle
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. Immutable objects
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 in
On Sun, 06 Sep 2009 06:18:23 -0700, Adam Skutt wrote:
> On Sep 5, 7:38 pm, Steven D'Aprano > 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 funct
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?
Adam Skutt wrote:
On Sep 5, 10:34 pm, Terry Reedy wrote:
Adam Skutt wrote:
On Sep 5, 11:29 am, Terry Reedy 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.
Post
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 w
On Sep 5, 10:34 pm, Terry Reedy wrote:
> Adam Skutt wrote:
> > On Sep 5, 11:29 am, Terry Reedy 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
On Sep 5, 7:38 pm, Steven D'Aprano 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.
> Funct
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 lock
Adam Skutt wrote:
On Sep 5, 11:29 am, Terry Reedy 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 for comment.
Py
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.
>
> No
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
>
On Sep 5, 11:29 am, Terry Reedy 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, or even reduce
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
On Sep 5, 12:06 am, 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). Consider this simple example:
>
> > -
On 5 Sep, 08:47, Steven D'Aprano 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 to imagine how often the
interpreter
On Fri, 04 Sep 2009 22:30:44 -0700, sturlamolden wrote:
> On 5 Sep, 07:04, Steven D'Aprano
> 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?
--
Steven
--
http://mail.p
On 5 Sep, 07:04, Steven D'Aprano 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
On 5 Sep, 07:04, Steven D'Aprano 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 with Matlab.
> How does Matlab sp
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 wor
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 5 Sep, 05:12, Steven D'Aprano 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 D4_Transform(x, s1=None, d1=None, d2=None):
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 b
On 3 Sep, 20:03, John Nagle 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 types are add
On 4 Sep, 06:20, John Nagle 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 CPython.
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 Sep 3, 2:03 pm, 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?
You can create this in various ways thro
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):
Ulrich Eckhardt 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 programmer doesn't ha
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
On Sep 3, 9:07 pm, Nigel Rantor 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 the threads,
"""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
Gabriel Genellina wrote:
En Thu, 03 Sep 2009 15:03:13 -0300, John Nagle
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 programmi
En Thu, 03 Sep 2009 15:03:13 -0300, John Nagle
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
model where objects sh
Stefan Behnel 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. Adding "synchronise
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 t
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
--
http://mail.
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:
>
> 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 us
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
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 and immutable
byte a
51 matches
Mail list logo
