Sunday, February 21, 2010

comp.lang.python - 6 new messages in 4 topics - digest

comp.lang.python
http://groups.google.com/group/comp.lang.python?hl=en

comp.lang.python@googlegroups.com

Today's topics:

* Efficient way to break up a list into two pieces - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.python/t/67fbbfeadbce5b05?hl=en
* lists of variables - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.python/t/2d2d019695d2e6b2?hl=en
* Shipping Executables - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/297a2754b1ad0538?hl=en
* The future of "frozen" types as the number of CPU cores increases - 1
messages, 1 author
http://groups.google.com/group/comp.lang.python/t/7ef75c20d1be370d?hl=en

==============================================================================
TOPIC: Efficient way to break up a list into two pieces
http://groups.google.com/group/comp.lang.python/t/67fbbfeadbce5b05?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Feb 20 2010 10:38 pm
From: Carl Banks


On Feb 20, 4:55 pm, marwie <mar...@gmx.de> wrote:
> Hello,
>
> I recently read about augmented assignments and that (with l1, l2
> being lists)
>
>     l1.extend(l2)
>
> is more efficient than
>
>     l1 = l1 + l2
>
> because unnecessary copy operations can be avoided. Now my question is
> if there's a similar thing for breaking a list into two parts. Let's
> say I want to remove from l1 everything from and including position 10
> and store it in l2. Then I can write
>
>     l2 = l1[10:]
>     del l1[10:]
>
> But since I'm assigning a slice the elements will be copied.

That's about the best you can do with Python lists.


> Basically, I'm looking for something like l1.pop(10,len(l1)) which
> returns and removes a whole chunk of data. Is there such a thing (and
> if not, why not?)

Numpy arrays can share underlying data like that when you take
slices. For instance, this probably works the way you want:

a = numpy.array([1,2,3,4,5,6])
b = a[:3]
c = a[3:]

None of the actual data was copied here.

Carl Banks


== 2 of 2 ==
Date: Sat, Feb 20 2010 10:48 pm
From: Steven D'Aprano


On Sat, 20 Feb 2010 21:21:47 -0800, Jonathan Gardner wrote:

> On Sat, Feb 20, 2010 at 5:41 PM, Steven D'Aprano
> <steve@remove-this-cybersource.com.au> wrote:
>>
>> What the OP wants is:
>>
>> (1) assign the name l2 to l1[:10] without copying (2) resize l1 in
>> place to the first 10 items without affecting l2.
>>
>>
> For ten items, though, is it really faster to muck around with array
> lengths than just copying the data over? Array copies are extremely fast
> on modern processors.

My mistake, he actually wants l1[10:] copied. So you might be copying a
huge amount of data, not just ten items.

Or if you prefer, replace 10 by 100000000.

But in either case, I agree that *in practice* it's rarely an actual
problem.


> Programmer time and processor time being what it is, I still think my
> answer is the correct one. No, it's not what he says he wants, but it is
> what he needs.

You missed the point that your suggestion gives radically different
behaviour to what the OP indicated he is using. He mutates the list in
place, you rebind the list's name. That has *very* different semantics.


>>> a = b = [1, 2, 3, 4]
>>> del a[2:] # mutate in place
>>> b
[1, 2]
>>>
>>> a = b = [1, 2, 3, 4]
>>> a = a[2:] # rebind the name
>>> b
[1, 2, 3, 4]

The OP may not care about the difference, but if he does require the
first behaviour, then your solution doesn't help.


--
Steven

==============================================================================
TOPIC: lists of variables
http://groups.google.com/group/comp.lang.python/t/2d2d019695d2e6b2?hl=en
==============================================================================

== 1 of 2 ==
Date: Sat, Feb 20 2010 10:50 pm
From: Steven D'Aprano


On Sat, 20 Feb 2010 22:31:44 -0800, Carl Banks wrote:

> The one place where Python does have references is when accessing
> variables in an enclosing scope (not counting module-level).

What makes you say that?

> But these
> references aren't objects, so you can't store them in a list, so it
> can't help you:

I don't even understand this. Your own example clearly shows that the are
objects and you can store them in a list, so I have no understanding of
what you mean.


> def f():
> s = []
> a = 1
> def g():
> print a

a is a name bound to an object which inherits a __str__ method, hence you
can print it.

> s.append(a)

a is bound to an object you can put in a list.

> g() # prints 1
> a = 2
> g() # prints 2: g's a is a reference to f's a
> print s # prints [1,2] not [2,2]

Yes, you are correct that lexical scoping doesn't allow the OP to embed
references to names in lists. I'm just confused why you think that
lexical scoping is equivalent to references that can't be put in lists,
or why you think this behaviour is any different from lexical scoping
everywhere else?

# Instead of two scopes, f and g, use two scopes, the module (global)
# and local scope g:
s = []
a = 1
def g():
print a
s.append(a)

g() # prints 1
a = 2
g() # prints 2: g's a is a reference to the global a
print s # prints [1,2] not [2,2]


There is no difference between lexical scoping between a function and a
nested function, and the lexical scoping between the global namespace and
a nested function.

--
Steven


== 2 of 2 ==
Date: Sat, Feb 20 2010 11:44 pm
From: Carl Banks


On Feb 20, 10:50 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:
> On Sat, 20 Feb 2010 22:31:44 -0800, Carl Banks wrote:
> > The one place where Python does have references is when accessing
> > variables in an enclosing scope (not counting module-level).  
>
> What makes you say that?
>
> > But these
> > references aren't objects, so you can't store them in a list, so it
> > can't help you:
>
> I don't even understand this. Your own example clearly shows that the are
> objects and you can store them in a list, so I have no understanding of
> what you mean.
>
> > def f():
> >     s = []
> >     a = 1
> >     def g():
> >         print a
>
> a is a name bound to an object which inherits a __str__ method, hence you
> can print it.
>
> >         s.append(a)
>
> a is bound to an object you can put in a list.
>
> >     g() # prints 1
> >     a = 2
> >     g() # prints 2: g's a is a reference to f's a
> >     print s # prints [1,2] not [2,2]
>
> Yes, you are correct that lexical scoping doesn't allow the OP to embed
> references to names in lists. I'm just confused why you think that
> lexical scoping is equivalent to references that can't be put in lists,
> or why you think this behaviour is any different from lexical scoping
> everywhere else?
>
> # Instead of two scopes, f and g, use two scopes, the module (global)
> # and local scope g:
> s = []
> a = 1
> def g():
>     print a
>     s.append(a)
>
> g() # prints 1
> a = 2
> g() # prints 2: g's a is a reference to the global a
> print s # prints [1,2] not [2,2]
>
> There is no difference between lexical scoping between a function and a
> nested function, and the lexical scoping between the global namespace and
> a nested function.


http://tinyurl.com/8e7tm

Carl Banks

==============================================================================
TOPIC: Shipping Executables
http://groups.google.com/group/comp.lang.python/t/297a2754b1ad0538?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 20 2010 11:12 pm
From: Gib Bogle


Steven D'Aprano wrote:
> On Wed, 17 Feb 2010 02:00:59 -0500, geremy condra quoted Banibrata Dutta
> <banibrata.dutta@gmail.com>:
>
>>> BTW for people who are non-believers in something being worth stealing
>>> needing protection, need to read about the Skype client.
>
> Pardon me for breaking threading, but the original post has not come
> through to my provider, only the reply from Geremy.
>
> Many things are worth stealing and therefore need protection.
>
> In any case, reverse engineering software is not theft. And even if it
> were, keeping the source code secret is no barrier to a competent,
> determined attacker or investigator. Skype is a good example: despite the
> lack of source code and the secret protocol, analysts were able to
> discover that TOM-Skype sends personally identifiable information,
> encryption keys and private messages back to central servers.
>
> In my personal opinion, releasing closed source software is prima facie
> evidence that the software is or does something bad: leaking personal
> information, infringing somebody else's copyright or patent, or just
> being badly written. I'm not saying that every piece of closed source
> software is like that, but when you hide the source, the burden of proof
> is on you to prove that you're not hiding something unpleasant.

You are assuming that everyone who might be interested in copying your code is
able to reverse-engineer it. That might be true for software with a high
commercial value, but it is by no means true for all software. And in saying
"when you hide the source, the burden of proof is on you to prove that you're
not hiding something unpleasant" you are tacitly assuming that the users of the
software care about having such a thing proven. I submit that most users do not
have this "guilty until proven innocent" attitude.

To give a personal example: I plan soon to distribute (free) to anyone
interested some scientific software. For various reasons I do not intend to
distribute the source code at this stage. I'm quite confident that the users
(biologists) will have neither the desire nor the ability to reverse-engineer
it. Of course I'd be tremendously flattered if they did want to. I'm also
confident that they will not suspect me of "hiding something unpleasant". In
the worst case they might think the program is useless.

==============================================================================
TOPIC: The future of "frozen" types as the number of CPU cores increases
http://groups.google.com/group/comp.lang.python/t/7ef75c20d1be370d?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 20 2010 11:45 pm
From: "sjdevnull@yahoo.com"


On Feb 20, 9:58 pm, John Nagle <na...@animats.com> wrote:
> sjdevn...@yahoo.com wrote:
> > On Feb 18, 2:58 pm, John Nagle <na...@animats.com> wrote:
> >>     Multiple processes are not the answer.  That means loading multiple
> >> copies of the same code into different areas of memory.  The cache
> >> miss rate goes up accordingly.
>
> > A decent OS will use copy-on-write with forked processes, which should
> > carry through to the cache for the code.
>
>     That doesn't help much if you're using the subprocess module.  The
> C code of the interpreter is shared, but all the code generated from
> Python is not.

Of course. Multithreading also fails miserably if the threads all try
to call exec() or the equivalent.

It works fine if you use os.fork().


==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.python"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.python?hl=en

To unsubscribe from this group, send email to comp.lang.python+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.python/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home


Real Estate