Re: bzr 2.2.1 released !

[Vincent Ladeuil]

> Sridhar Ratnakumar  writes:

> Hi,
> It seems that you forgot to update PyPI - which lists 2.1.0rc1 as the 
latest version.

> -srid

This should be fixed now. Let us know if you encounter problems.

 Vincent
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Nick]

Ian Collins  writes:

> On 09/30/10 05:57 PM, RG wrote:
>>
>> I'm not saying one should not use compile-time tools, only that one
>> should not rely on them.  "Compiling without errors" is not -- and
>> cannot ever be -- be a synonym for "bug-free."
>
> We is why wee all have run time tools called unit tests, don't we?

But you have to know a lot about the language to know that there's a
problem.  You cannot sensibly test your max function on every
combination of (even int) input which it's designed for (and, of course,
it works for those).
-- 
Online waterways route planner| http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[RG]

In article ,
 Seebs  wrote:

> On 2010-09-30, RG  wrote:
> > Of course.  Computers always do only exactly what you ask of them.  On 
> > this view there is, by definition, no such thing as a bug, only 
> > specifications that don't correspond to one's intentions.  
> 
> f00f.
> 
> That said... I think you're missing Keith's point.
> 
> > Unfortunately, correspondence to intentions is the thing that actually 
> > matters when writing code.
> 
> Yes.  Nonetheless, the maximum() function does exactly what it is intended
> to do *with the inputs it receives*.  The failure is outside the function;
> it did the right thing with the data actually passed to it, the problem
> was a user misunderstanding as to what data were being passed to it.
> 
> So there's a bug -- there's code which does not do what it was intended
> to do.  However, that bug is in the caller, not in the maximum()
> function.
> 
> This is an important distinction -- it means we can write a function
> which performs that function reliably.  Now we just need to figure out
> how to call it with valid data... :)

We lost some important context somewhere along the line:

> > > in C I can have a function maximum(int a, int b) that will always
> > > work. Never blow up, and never give an invalid answer. If someone
> > > tries to call it incorrectly it is a compile error.

Please take note of the second sentence.

One way or another, this claim is plainly false.  The point I was trying 
to make is not so much that the claim is false (someone else was already 
doing that), but that it can be demonstrated to be false without having 
to rely on any run-time input.

rg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[RG]

In article ,
 Keith Thompson  wrote:

> > I'm not saying one should not use compile-time tools, only that one 
> > should not rely on them.  "Compiling without errors" is not -- and 
> > cannot ever be -- be a synonym for "bug-free."
> 
> Agreed.  (Though C does make it notoriously easy to sneak buggy code
> past the compiler.)

Let's just leave it at that then.

rg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[TheFlyingDutchman]

>
> That argument can be made for dynamic language as well. If you write in
> dynamic language (e.g. python):
>
> def maximum(a, b):
>     return a if a > b else b
>
> The dynamic language's version of maximum() function is 100% correct --
> if you passed an uncomparable object, instead of a number, your call of
> it is incorrect; you just didn't pass the right sort of data. And that's
> your problem as a caller.
>
> In fact, since Python's integer is infinite precision (only bounded by
> available memory); in practice, Python's version of maximum() has less
> chance of producing erroneous result.

"in C I can have a function maximum(int a, int b) that will always
work. Never blow up, and never give an invalid answer. "

Dynamic typed languages like Python fail in this case on "Never blows
up".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Keith Thompson]

RG  writes:
> In article ,
>  Keith Thompson  wrote:
[...]
>> Even here, maximum() did exactly what was asked of it.
>
> Of course.  Computers always do only exactly what you ask of them.  On 
> this view there is, by definition, no such thing as a bug, only 
> specifications that don't correspond to one's intentions.  
> Unfortunately, correspondence to intentions is the thing that actually 
> matters when writing code.

Of course there's such a thing as a bug.

This version of maximum:

int maximum(int a, int b) {
return a > b ? a : a;
}

has a bug.  This version:

int maximum(int a, int b) {
return a > b ? a : b;
}

I would argue, does not.  The fact that it might be included in a
buggy program does not mean that it is itself buggy.

[...]

> I'm not saying one should not use compile-time tools, only that one 
> should not rely on them.  "Compiling without errors" is not -- and 
> cannot ever be -- be a synonym for "bug-free."

Agreed.  (Though C does make it notoriously easy to sneak buggy code
past the compiler.)

-- 
Keith Thompson (The_Other_Keith) ks...@mib.org  
Nokia
"We must do something.  This is something.  Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: utf-8 and ctypes

[Mark Tolonen]

"Brendan Miller"  wrote in message 
news:aanlkti=2f3l++398st-16mpes8wzfblbu+qa8ztpa...@mail.gmail.com...

2010/9/29 Lawrence D'Oliveiro :
In message , 
Brendan

Miller wrote:


It seems that characters not in the ascii subset of UTF-8 are
discarded by c_char_p during the conversion ...


Not a chance.


... or at least they don't print out when I go to print the string.


So it seems there’s a problem on the printing side. What happens when 
you
construct a UTF-8-encoded string directly in Python and try printing it 
the

same way?


Doing this seems to confirm something is broken in ctypes w.r.t. UTF-8...

if I enter:
str = "日本語のテスト"

Then:
print str
日本語のテスト

However, when I create a string buffer, pass it into my c++ code, and
write the same UTF-8 string into it, python seems to discard pretty
much all the text. The same code works for pure ascii strings.

Python code:
_std_string_size = _lib_mbxclient.std_string_size
_std_string_size.restype = c_long
_std_string_size.argtypes = [c_void_p]

_std_string_copy = _lib_mbxclient.std_string_copy
_std_string_copy.restype = None
_std_string_copy.argtypes = [c_void_p, POINTER(c_char)]

# This function works for ascii, but breaks on strings with UTF-8!
def std_string_to_string(str_ptr):
   buf = create_string_buffer(_std_string_size(str_ptr))
   _std_string_copy(str_ptr, buf)
   return buf.raw

C++ code:

extern "C"
long std_string_size(string* str)
{
return str->size();
}

extern "C"
void std_string_copy(string* str, char* buf)
{
std::copy(str->begin(), str->end(), buf);
}


I didn't see what OS you are using, but I fleshed out your example code and 
have a working example for Windows.  Below is the code for the DLL and 
script:


- x.cpp [cl /LD /EHsc /W4 
x.cpp] 

#include 
#include 
using namespace std;

extern "C" __declspec(dllexport) long std_string_size(string* str)
{
return str->size();
}

extern "C" __declspec(dllexport) void std_string_copy(string* str, char* 
buf)

{
std::copy(str->begin(), str->end(), buf);
}

extern "C" __declspec(dllexport) void* make(const char* s)
{
return new string(s);
}

extern "C" __declspec(dllexport) void destroy(void* s)
{
delete (string*)s;
}
 x.py -
# coding: utf8
from ctypes import *
_lib_mbxclient = CDLL('x')

_std_string_size = _lib_mbxclient.std_string_size
_std_string_size.restype = c_long
_std_string_size.argtypes = [c_void_p]

_std_string_copy = _lib_mbxclient.std_string_copy
_std_string_copy.restype = None
_std_string_copy.argtypes = [c_void_p, c_char_p]

make = _lib_mbxclient.make
make.restype = c_void_p
make.argtypes = [c_char_p]

destroy = _lib_mbxclient.destroy
destroy.restype = None
destroy.argtypes = [c_void_p]

# This function works for ascii, but breaks on strings with UTF-8!
def std_string_to_string(str_ptr):
   buf = create_string_buffer(_std_string_size(str_ptr))
   _std_string_copy(str_ptr, buf)
   return buf.raw

s = make(u'我是美国人。'.encode('utf8'))
print std_string_to_string(s).decode('utf8')
--

And output (in Pythonwin...US Windows console doesn't support Chinese):

我是美国人。

I used c_char_p instead of POINTER(c_char) and added functions to create and 
destroy a std::string for Python's use, but it is otherwise the same as your 
code.


Hope this helps you work it out,
-Mark




--
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[TheFlyingDutchman]

>
> More specifically, the claim made above:
>
> > in C I can have a function maximum(int a, int b) that will always
> > work. Never blow up, and never give an invalid answer.
>
> is false.  And it is not necessary to invoke the vagaries of run-time
> input to demonstrate that it is false.
>
I don't think you demonstrated it is false. Any values larger than an
int get truncated before they ever get to maximum. The problem does
not lie with the maximum function. It correctly returns the maximum of
whatever two integers it is provided. Calling it with values that are
larger than an int, that get converted to an int _before_ maximum is
called, is an issue outside of maximum.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Lie Ryan]

On 09/30/10 11:17, Seebs wrote:
> On 2010-09-30, RG  wrote:
>> That the problem is "elsewhere in the program" ought to be small 
>> comfort.
> 
> It is, perhaps, but it's also an important technical point:  You CAN write
> correct code for such a thing.
> 
>> int maximum(int a, int b) { return a > b ? a : b; }
> 
>> int main() {
>>   long x = 8589934592;
>>   printf("Max of %ld and 1 is %d\n", x, maximum(x,1));
> 
> You invoked implementation-defined behavior here by calling maximum() with
> a value which was outside the range.  The defined behavior is that the
> arguments are converted to the given type, namely int.  The conversion
> is implementation-defined and could include yielding an implementation-defined
> signal which aborts execution.
> 
> Again, the maximum() function is 100% correct -- your call of it is incorrect.
> You didn't pass it the right sort of data.  That's your problem.

That argument can be made for dynamic language as well. If you write in
dynamic language (e.g. python):

def maximum(a, b):
return a if a > b else b

The dynamic language's version of maximum() function is 100% correct --
if you passed an uncomparable object, instead of a number, your call of
it is incorrect; you just didn't pass the right sort of data. And that's
your problem as a caller.

In fact, since Python's integer is infinite precision (only bounded by
available memory); in practice, Python's version of maximum() has less
chance of producing erroneous result.

The /most/ correct version of maximum() function is probably one written
in Haskell as:

maximum :: Integer -> Integer -> Integer
maximum a b = if a > b then a else b

Integer in Haskell has infinite precision (like python's int, only
bounded by memory), but Haskell also have static type checking, so you
can't pass just any arbitrary objects.

But even then, it's still not 100% correct. If you pass a really large
values that exhaust the memory, the maximum() could still produce
unwanted result.

Second problem is that Haskell has Int, the bounded integer, and if you
have a calculation in Int that overflowed in some previous calculation,
then you can still get an incorrect result. In practice, the
type-agnostic language with *mandatory* infinite precision arithmetic
wins in terms of correctness. Any language which only has optional
infinite precision arithmetic can always produce erroneous result.

Anyone can dream of 100% correct program; but anyone who believes they
can write a 100% correct program is just a dreamer. In reality, we don't
usually need 100% correct program; we just need a program that runs
correctly enough most of the times that the 0.001% chance of
producing erroneous result becomes irrelevant.

In summary, in this particular case with maximum() function, static
checking does not help in producing the most correct code; if you need
to ensure the highest correctness, you must use a language with
*mandatory* infinite precision integers.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Supplementing the std lib (Was: partial sums problem)

[Paul Rubin]

Dennis Lee Bieber  writes:
>> Python's version would be like "scanl" with an optional arg to make it
>> like "scanl1".
>   Vs APL's "expand" operator?

I'm not familiar with that but maybe it's similar.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scheduler or infinite loop

[John Nagle]

On 9/29/2010 4:59 AM, harryos wrote:

hi
I am trying to write a program to read data from a site url.
The program must read the data from site every 5 minutes.

def get_data_from_site(pageurlstr):
 h=urllib.urlopen(pageurlstr)
 data=h.read()
 process_data(data)


   A key point here is that you're not handling network
failures.  The first time you have a brief network
outage, your program will fail.

   Consider something like this:



def get_data_from_site(pageurlstr):
try :
h=urllib.urlopen(pageurlstr)
data=h.read()
except EnvironmentError as message :
print("Error reading %s from network at %s: %s" %
(pageurlstr, time.asctime(), str(message))
return(False)
process_data(data)
return(True)


lastpoll = 0  # time of last successful read
POLLINTERVAL = 300.0
RETRYINTERVAL = 30.0
while True:
status = get_data_from_site('http://somesite.com/')
if not status : # if fail
time.sleep(RETRYINTERVAL) # try again soon
print("Retrying...")
continue
now = time.time() # success
# Wait for the next poll period.  Compensate for how
# long the read took.
waittime = max(POLLINTERVAL - (now - lastpoll), 1.0)
lastpoll = now
time.sleep(waittime)





--
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Ian Collins]

On 09/30/10 05:57 PM, RG wrote:


I'm not saying one should not use compile-time tools, only that one
should not rely on them.  "Compiling without errors" is not -- and
cannot ever be -- be a synonym for "bug-free."


We is why wee all have run time tools called unit tests, don't we?

--
Ian Collins
--
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Seebs]

On 2010-09-30, RG  wrote:
> Of course.  Computers always do only exactly what you ask of them.  On 
> this view there is, by definition, no such thing as a bug, only 
> specifications that don't correspond to one's intentions.  

f00f.

That said... I think you're missing Keith's point.

> Unfortunately, correspondence to intentions is the thing that actually 
> matters when writing code.

Yes.  Nonetheless, the maximum() function does exactly what it is intended
to do *with the inputs it receives*.  The failure is outside the function;
it did the right thing with the data actually passed to it, the problem
was a user misunderstanding as to what data were being passed to it.

So there's a bug -- there's code which does not do what it was intended
to do.  However, that bug is in the caller, not in the maximum()
function.

This is an important distinction -- it means we can write a function
which performs that function reliably.  Now we just need to figure out
how to call it with valid data... :)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scheduler or infinite loop

[Frank Millman]

harryos wrote


Here is a technique that allows the loop to run in the background, in its
own thread, leaving the main program to do other processing -

import threading

class DataGetter(threading.Thread):




thanks Frank


A pleasure.

I left out a line that will usually be desirable.

At the end of the program, you should have -

   data_getter.stop()
+   data_getter.join()

This forces the main program to wait until the thread has terminated before 
continuing.


Frank


--
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[RG]

In article ,
 Keith Thompson  wrote:

> RG  writes:
> [...]
> > That the problem is "elsewhere in the program" ought to be small 
> > comfort.
> 
> I don't claim that it's comforting, merely that it's true.
> 
> >   But very well, try this instead:
> >
> > [...@mighty:~]$ cat foo.c
> > #include 
> >
> > int maximum(int a, int b) { return a > b ? a : b; }
> >
> > int main() {
> >   long x = 8589934592;
> >   printf("Max of %ld and 1 is %d\n", x, maximum(x,1));
> >   return 0;
> > }
> > [...@mighty:~]$ gcc -Wall foo.c 
> > [...@mighty:~]$ ./a.out 
> > Max of 8589934592 and 1 is 1
> 
> That exhibits a very similar problem.
> 
> 8589934592 is 2**33.
> 
> Given the output you got, I presume your system has 32-bit int and
> 64-bit long.  The call maximum(x, 1) implicitly converts the long
> value 8589934592 to int.  The result is implementation-defined,
> but typically 0.  So maximum() is called with arguments of 0 and 1,
> as you could see by adding a printf call to maximum().
> 
> Even here, maximum() did exactly what was asked of it.

Of course.  Computers always do only exactly what you ask of them.  On 
this view there is, by definition, no such thing as a bug, only 
specifications that don't correspond to one's intentions.  
Unfortunately, correspondence to intentions is the thing that actually 
matters when writing code.

> I'll grant you that having a conversion from a larger type to a smaller
> type quietly discard high-order bits is unfriendly.

"Unfriendly" is not the adjective that I would choose to describe this 
behavior.

There is a whole hierarchy of this sort of "unfriendly" behavior, some 
of which can be caught at compile time using a corresponding hierarchy 
of ever more sophisticated tools.  But sooner or later if you are using 
Turing-complete operations you will encounter the halting problem, at 
which point your compile-time tools will fail.  (c.f. the Collatz 
problem)

I'm not saying one should not use compile-time tools, only that one 
should not rely on them.  "Compiling without errors" is not -- and 
cannot ever be -- be a synonym for "bug-free."

rg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Clarification of notation

[Terry Reedy]

On 9/29/2010 10:32 PM, Bruce Whealton wrote:


Would you, and could you combine a dictionary with a list in this fashion?


A python list is a mutable sequence of Python objects. Extremely mixed 
example.

>>> mixed = [1, 1.0, '1', [1], (1,), {1:1}, set((1,)), list, list.append]
>>> mixed.append(mixed) # make the list recursive
>>> mixed # list to string can handle that!
[1, 1.0, '1', [1], (1,), {1: 1}, {1}, , of 'list' objects>, [...]]



Next, from the documentation I see and this is just an example (this
kind of notation is seen elsewhere in the documentation:

str.count(sub[, start[, end]])


square bracket are standard for indicating optional items in extended 
Backus-Naur context-free grammar notations.

https://secure.wikimedia.org/wikipedia/en/wiki/Backus%E2%80%93Naur_Form

In Python3 docs, they have been removed as redundant when an explicit 
default value is given:

compile(source, filename, mode, flags=0, dont_inherit=False)

--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: Clarification of notation

[Chris Rebert]

On Wed, Sep 29, 2010 at 7:32 PM, Bruce Whealton
 wrote:
> Hello all,
>         I recently started learning python.  I am a bit thrown by a certain
> notation that I see.  I was watching a training course on lynda.com and this
> notation was not presented.  For lists, when would you use what appears to
> be nested lists, like:
> [[], [], []]
> a list of lists?

Lists are for working with a group of data. Sometimes each datum
happens to itself be a list; thus, one naturally ends up with a
list-of-lists.

Say I have, for each school in my school district, a list of its
students' test scores. I want to compute each school's average score.
So I put all the lists of scores into a nested list. I then iterate
over the nested list, taking the average of each inner list of scores.
(Do the analogous thing at higher and higher levels of aggregation
(e.g. county, state, country) and you naturally get progressively more
nested lists.)

> Would you, and could you combine a dictionary with a list in this fashion?

Yes, of course:
{'a' : [1,2,3]}
[{'a' : 1}, {'b' : 2}]

Just note that lists can't be dictionary keys due to their mutability.
{[1,2,3] : "one two three"} # ERROR

> Next, from the documentation I see and this is just an example (this kind of
> notation is seen elsewhere in the documentation:
>
> str.count(sub[, start[, end]])
> This particular example is from the string methods.

> I know that it would
> suggest that some of the arguments are optional, so perhaps if there are 2
> items the first is the sub, and the second is start?  Or did I read that
> backwards?

No, you read it exactly correctly. The []s here indicate levels of
optional-ness and have nothing to do with the list datatype.

Basically, if you want to pass an optional argument, you have to have
also specified any less-nested arguments (unless you use keyword
rather than positional arguments).
str.count(a) # sub = a
str.count(a, b) # sub = a, start = b
str.count(a, b, c) # sub = a, start = b, end = c

Usually, it's straightforward left-to-right as you specify more
arguments (doing otherwise requires kludges or black magic). However,
there are rare exceptions, the most common one being range()/xrange():

range(...)
range([start,] stop[, step]) -> list of integers

Thus:
range(a) # stop = a  (*not* start = a, as would be normal)
range(a, b) # start = a, stop = b
range(a, b, c) # start = a, stop = b, step = c

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Clarification of notation

[alex23]

Bruce Whealton  wrote:
> For lists, when would
> you use what appears to be nested lists, like:
> [[], [], []]
> a list of lists?

Well, you'd use it when you'd want a list of lists ;)

There's nothing magical about a list of lists, it's just a list with
objects inside like any other, in this case they just happen to be
lists. Possibly the canonical example is for a simple multidimensional
array:

>>> array5x5 = [[0]*5 for i in range(5)]
>>> array5x5[2][3] = 7
>>> array5x5[4][1] = 2
>>> array5x5
[[0, 0, 0, 0, 0],
 [0, 0, 0, 0, 0],
 [0, 0, 0, 7, 0],
 [0, 0, 0, 0, 0],
 [0, 2, 0, 0, 0]]

> Would you, and could you combine a dictionary with a list in this fashion?

Lists can contain dictionaries that contain dictionaries containing
lists :) So yes, they can easily be combined.

Here's a list with dictionaries:

elements = [
{'tag': 'strong', 'style': 'bold'},
{'tag': 'header', 'style': 'bolder', 'color': 'red},
]

And a dictionary of lists:

classes_2010 = {
'economics': ['John Crowley', 'Jack Savage', 'Jane Austen'],
'voodoo economics': ['Ronald Reagan', 'Ferris Beuller'],
}

(Note that the formatting style is a personal taste and not
essential).

Generally, you tend to use a list when you want to work on items in
sequence, and a dictionary when you want to work on an item on demand.

> Next, from the documentation I see and this is just an example (this
> kind of notation is seen elsewhere in the documentation:
>
> str.count(sub[, start[, end]])
> This particular example is from the string methods.
> Is this a nesting of two lists inside a a third list?  I know that it
> would suggest that some of the arguments are optional, so perhaps if
> there are 2 items the first is the sub, and the second is start?  Or did

In documentation (as opposed to code), [] represents optional
arguments, and have nothing at all to do with Python lists. The above
example is showing that the method can be called in the following
ways:

  'foobarbazbam'.count('ba')
  'foobarbazbam'.count('ba', 6)
  'foobarbazbam'.count('ba', 6, 9)

Hope this helps.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Clarification of notation

[Seebs]

On 2010-09-30, Bruce Whealton  wrote:
> Next, from the documentation I see and this is just an example (this 
> kind of notation is seen elsewhere in the documentation:

> str.count(sub[, start[, end]])
> This particular example is from the string methods.
> Is this a nesting of two lists inside a a third list?

No, it's not -- it's a different use of [] to indicate that things
are optional, a convention which dates back to long before Python
existed.

>I know that it 
> would suggest that some of the arguments are optional, so perhaps if 
> there are 2 items the first is the sub, and the second is start?  Or did 
> I read that backwards?

That is exactly correct.  The key is the implication that you can omit
end, or both start and end.  (But you can't omit start and provide end.)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Clarification of notation

[Bruce Whealton]

Hello all,
 I recently started learning python.  I am a bit thrown by a 
certain notation that I see.  I was watching a training course on 
lynda.com and this notation was not presented.  For lists, when would 
you use what appears to be nested lists, like:

[[], [], []]
a list of lists?
Would you, and could you combine a dictionary with a list in this fashion?

Next, from the documentation I see and this is just an example (this 
kind of notation is seen elsewhere in the documentation:


str.count(sub[, start[, end]])
This particular example is from the string methods.
Is this a nesting of two lists inside a a third list?  I know that it 
would suggest that some of the arguments are optional, so perhaps if 
there are 2 items the first is the sub, and the second is start?  Or did 
I read that backwards?

Thanks,
Bruce
--
http://mail.python.org/mailman/listinfo/python-list

Re: (and scheme lisp) x Python and modern langs [was Re: gossip, Guy Steel, Lojban, Racket]

[Seebs]

On 2010-09-30, namekuseijin  wrote:
> it generates a list from syntax comprehended in list-like syntax!

Okay, help me out here.  (Killed the crossposting.)

I am not understanding how the word applies.  I'm fine with it, but I don't
see any relation at all between the thing called a list comprehension and
the word "comprehension" as I normally understand it.

Who or what is doing the comprehending?  Is this a sense of "comprehension"
other than "to understand"?  It seems like it's perhaps related to
"comprehensive".  However, I've never seen "comprehension" used to refer
to anything other than understanding prior to encountering "list
comprehensions".

[... hmm.  maybe time to go searching...]

Looking around, it seems this is from mathematical jargon, to wit,
"set comprehensions".  Since I hadn't run into that jargon, I had no
clue what the etymology was, and "comprehended" is not a verb I would
ever have used with this.  However, looking around, it appears that
this usage also occurs in the same jargon; once you've got one of them
the other follows.

I guess the key, though, is that this is purely jargon, and jargon from
another field -- not all programmers have done all mathematics.  I even
took a ton of bonus math in college, but happened not to have done anything
where this terminology was used.  So the usage is, pardon the pun,
incomprehensible to me to begin with, and saying it's called a
comprehension because it's comprehended doesn't help -- that's two forms
of the same unfamiliar jargon.

Of course, the jargon is pretty reasonable as such goes, in no small
part because of the plain English sense of "comprehensive" in the
sense of covering something completely, so it's not awful.

But from where I'm coming, it would be every bit as obvious to call it
a "list exhaustion", by analagous derivation from "exhaustive".

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Certificate validation with HTTPSConnection

[John Nagle]

On 9/29/2010 3:51 PM, Antoine Pitrou wrote:

On Wed, 29 Sep 2010 13:41:15 -0700
John Nagle  wrote:


The really stupid thing about the current SSL module is that it
accepts a file of root certificates as a parameter, but ignores it.


That's not true. You have to pass CERT_OPTIONAL or CERT_REQUIRED as a
parameter (CERT_NONE is though).


   If you pass CERT_REQUIRED and a root certificate authority file,
there has to be some certificate, but the signature chain is
not validated against the CA file, so the cert doesn't certify
anything.  Phony web sites look valid to Python's SSL library.

John Nagle
--
http://mail.python.org/mailman/listinfo/python-list

Re: (and scheme lisp) x Python and modern langs [was Re: gossip, Guy Steel, Lojban, Racket]

[namekuseijin]

On 29 set, 17:46, Xah Lee  wrote:
> On Sep 29, 11:02 am, namekuseijin  wrote:
>
> > On 28 set, 19:38, Xah Lee  wrote:
>
> > > • “list comprehension” is a very bad jargon; thus harmful to
> > > functional programing or programing in general. Being a bad jargon, it
> > > encourage mis-communication, mis-understanding.
>
> > I disagree:  it is a quite intuitive term to describe what the
> > expression does.
>
> what's your basis in saying that “list comprehension” is intuitive?

it generates a list from syntax comprehended in list-like syntax!

> any statics, survery, research, references you have to cite?

how about common sense?

> to put this in context, are you saying that lambda, is also intuitive?

No.

> “let” is intuitive?

yes, it's focking everyday term used in the same way:  let this be
this and that be that and thus...

> “for” is intuitive?

yes, it's focking everyday term used in the same way:  for this and
this and this do that...

> “when” is intuitive?

when this, then that?

common sense, Xah!

> For example, let us know, in your view, how good are terms: currying,
> lisp1 lisp2, tail recursion, closure, subroutine, command, object.

These terms have a technical meaning coming from historic events in
the areas they are used.  It's like that in all areas, you may also
bash medicine jargon if you want.

Though subroutine, command and object are pretty intuitive by common
sense alone.

> perhaps expound on the comparative merits and meaning on the terms
> module vs package vs add-on vs library. I would like to see your view
> on this with at least few paragraphs of analysis on each.

They are all the same shit.  These were developed by managers and
buzzwriters... ;)

> Also, “being intuitive” is not the only aspect to consider whether a
> term is good or bad. For example, emacs's uses the term “frame”. It's
> quite intuitive, because frame is a common english word, everyone
> understands. You know, door frame, window frame, picture frame, are
> all analogous to emacs's “frame” on a computer. However, by some turn
> of history, in computer software we call such as “window” now, and by
> happance the term “window” also has a technical meaning in emacs, what
> we call “split window” or “pane” today. So, in emacs, the term “frame”
> and “window” is confusing, because emacs's “frame” is what we call
> “window”, while emacs's “window” is what me might call a pane of a
> split window. So here, is a example, that even when a term is
> intuitive, it can still be bad.

emacs is all FUBAR in more than one way.  being intuitive is not
exactly what it is known for... ;)

well, I shouldn't be bashing it, my vim is not that funky among
commoners anymore anyway... :p

> I wrote about 14 essays on various jargons in past decade. You can
> find them on my site.

yeah, I've read them once in a while...
-- 
http://mail.python.org/mailman/listinfo/python-list

Strange os.stat behavior

[Philip Bloom]

I'm on python 2.6.1:

 

Ran into some os.stat behavior that knocked me for a loop.  I was using
os.stat to retrieve file st_ctime and st_mtime from a remote server
through a unc path, and doing this I encountered that os.stat was
returning me st_ctime and st_mtime values  that were months off,
reporting values that not only were months in the past, but also
relatively wrong (Reporting a greater difference between Modified and
Created than there should be).  Below, run through localtime and
formatted a little for easier reading.).  C++ stat, Win32API, and
Windows own directory report all match with the same seen time (and are
correct).  Has anyone seen something like this before?   It's quite
scary to me that os.stat is returning a different value that it's
getting from somewhere and doesn't match with either the Windows API or
the C++ stat library.  I read over the release notes for 2.6.x and
didn't see any mention of os.stat relevant bugs or fixes.  I'm curious
what it could possibly be doing differently than the others (I thought
it used the windows api under the hood for Windows nt derived systems).

 

Ex:

\\mpkarc01\Build_stats\tras\MayaExportKernel_p.config\mabahazy~RWCWRK_70
01470.stats\9-27-2010_log.txt 1279755701.87 1285810489.65

Created:  time.struct_time(tm_year=2010, tm_mon=7, tm_mday=21,
tm_hour=16, tm_min=41, tm_sec=41, tm_wday=2, tm_yday=202, tm_isdst=1)

Modified:  time.struct_time(tm_year=2010, tm_mon=7, tm_mday=25,
tm_hour=0, tm_min=59, tm_sec=45, tm_wday=6, tm_yday=206, tm_isdst=1),
raw: 1280044785

Accessed:  time.struct_time(tm_year=2010, tm_mon=9, tm_mday=29,
tm_hour=17, tm_min=25, tm_sec=31, tm_wday=2, tm_yday=272, tm_isdst=1)

Raw Time.Time(): time.struct_time(tm_year=2010, tm_mon=9, tm_mday=29,
tm_hour=18, tm_min=34, tm_sec=49, tm_wday=2, tm_yday=272, tm_isdst=1),
raw: 1285810489.65

Win32API Ctime: 09/27/10 20:18:11 

Win32API MTime: 09/28/10 01:18:37

Win32API ATime: 09/29/10 00:24:46 

 

Relevant code segment:

import win32api

import win32con

import win32file

import time

import os

...

 
statinfo = os.stat(os.path.join(root, name))

print os.path.join(root, name) + " " +
str(statinfo.st_ctime) + " " + str(time.time())

print "Modified: ",
time.localtime(int(statinfo.st_mtime)),int(statinfo.st_mtime)

print "Created: ",
time.localtime(int(statinfo.st_ctime))

print "Accessed: ",
time.localtime(int(statinfo.st_atime))

print time.localtime(),time.time()

fh = win32file.CreateFile(os.path.join(root,
name), win32file.GENERIC_READ | win32file.GENERIC_WRITE, 0, None,
win32file.OPEN_EXISTING,0, 0)

sts, creationTime, accessTime, writeTime =
win32file.GetFileTime(fh)

print creationTime, accessTime, writeTime

win32file.CloseHandle(fh)

 

 

Platform of executing code: Windows XP, 64 bit.


__
This email has been scanned by the MessageLabs
__-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Supplementing the std lib (Was: partial sums problem)

[Ian Kelly]

On Wed, Sep 29, 2010 at 7:06 PM, Paul Rubin  wrote:

> As for the stdlib, the natural places for such a function would be
> either itertools or functools, and the function should probably be called
> "scan", inspired by this:
>
>  http://en.wikibooks.org/wiki/Haskell/List_processing#Scans
>
> Python's version would be like "scanl" with an optional arg to make it
> like "scanl1".
>

Something like this?

NoInitialValue = object()

def scan(function, iterable, initial=NoInitialValue):
iterator = iter(iterable)

if initial is NoInitialValue:
try:
accumulator = iterator.next()
except StopIteration:
return
else:
accumulator = initial

yield accumulator

for arg in iterator:
accumulator = function(accumulator, arg)
yield accumulator

Cheers,
Ian
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Ian Collins]

On 09/30/10 02:17 PM, Seebs wrote:

On 2010-09-30, RG  wrote:

That the problem is "elsewhere in the program" ought to be small
comfort.


It is, perhaps, but it's also an important technical point:  You CAN write
correct code for such a thing.


int maximum(int a, int b) { return a>  b ? a : b; }



int main() {
   long x = 8589934592;
   printf("Max of %ld and 1 is %d\n", x, maximum(x,1));


You invoked implementation-defined behavior here by calling maximum() with
a value which was outside the range.  The defined behavior is that the
arguments are converted to the given type, namely int.  The conversion
is implementation-defined and could include yielding an implementation-defined
signal which aborts execution.

Again, the maximum() function is 100% correct -- your call of it is incorrect.
You didn't pass it the right sort of data.  That's your problem.

(And no, the lack of a diagnostic doesn't necessarily prove anything; see
the gcc documentation for details of what it does when converting an out
of range value into a signed type, it may well have done exactly what it
is defined to do.)


Note that the mistake can be diagnosed:

lint /tmp/u.c -m64 -errchk=all
(7) warning: passing 64-bit integer arg, expecting 32-bit integer: 
maximum(arg 1)


--
Ian Collins
--
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Keith Thompson]

RG  writes:
[...]
> That the problem is "elsewhere in the program" ought to be small 
> comfort.

I don't claim that it's comforting, merely that it's true.

>   But very well, try this instead:
>
> [...@mighty:~]$ cat foo.c
> #include 
>
> int maximum(int a, int b) { return a > b ? a : b; }
>
> int main() {
>   long x = 8589934592;
>   printf("Max of %ld and 1 is %d\n", x, maximum(x,1));
>   return 0;
> }
> [...@mighty:~]$ gcc -Wall foo.c 
> [...@mighty:~]$ ./a.out 
> Max of 8589934592 and 1 is 1

That exhibits a very similar problem.

8589934592 is 2**33.

Given the output you got, I presume your system has 32-bit int and
64-bit long.  The call maximum(x, 1) implicitly converts the long
value 8589934592 to int.  The result is implementation-defined,
but typically 0.  So maximum() is called with arguments of 0 and 1,
as you could see by adding a printf call to maximum().

Even here, maximum() did exactly what was asked of it.

I'll grant you that having a conversion from a larger type to a smaller
type quietly discard high-order bits is unfriendly.  But it matches the
behavior of most CPUs.

Here's another example:

#include 

int maximum(int a, int b) { return a > b ? a : b; }

int main(void) {
  double x = 1.8;
  printf("Max of %f and 1 is %d\n", x, maximum(x, 1));
  return 0;
}

Output:

Max of 1.80 and 1 is 1

-- 
Keith Thompson (The_Other_Keith) ks...@mib.org  
Nokia
"We must do something.  This is something.  Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Seebs]

On 2010-09-30, RG  wrote:
> That the problem is "elsewhere in the program" ought to be small 
> comfort.

It is, perhaps, but it's also an important technical point:  You CAN write
correct code for such a thing.

> int maximum(int a, int b) { return a > b ? a : b; }

> int main() {
>   long x = 8589934592;
>   printf("Max of %ld and 1 is %d\n", x, maximum(x,1));

You invoked implementation-defined behavior here by calling maximum() with
a value which was outside the range.  The defined behavior is that the
arguments are converted to the given type, namely int.  The conversion
is implementation-defined and could include yielding an implementation-defined
signal which aborts execution.

Again, the maximum() function is 100% correct -- your call of it is incorrect.
You didn't pass it the right sort of data.  That's your problem.

(And no, the lack of a diagnostic doesn't necessarily prove anything; see
the gcc documentation for details of what it does when converting an out
of range value into a signed type, it may well have done exactly what it
is defined to do.)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: About __class__ of an int literal

[Steven D'Aprano]

On Wed, 29 Sep 2010 14:34:33 +0200, Hrvoje Niksic wrote:

> Steven D'Aprano  writes:
>> (This may change in the future. Given type(), and isinstance(), I'm not
>> sure what value __class__ adds.)
> 
> None whatsoever.  __class__ used to be necessary to tell the appart
> instances of different old-style classes:
> 
 class X: pass  # old-style
> ...
 X().__class__
> 
 type(X())
> 
> 
> Now that classes produce real types, they are equivalent.


I've been thinking about this, and I think that there may be a use-case 
for changing __class__ manually. I'm not entirely sure if this is a good 
idea or not, I'd need to spend some time experimenting, but imagine a 
class that wraps another object and uses delegation instead of 
inheritance.

If you also set __class__ (on the class itself, naturally, not the 
instance) appropriately, then type(instance) and instance.__class__ will 
be different. type() will return the "real" type of the delegation class, 
while instance.__class__ returns the class that it is trying to be.

And of course, presumably metaclasses can do anything they like with 
__class__, for good or ill.

I'm not sure if and when this would be useful, but it's a hint that 
perhaps the distinction is not entirely meaningless.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Supplementing the std lib (Was: partial sums problem)

[Paul Rubin]

kj  writes:
> But in the immediate term, cusum is not part of the standard library.
>
> Where would you put it if you wanted to reuse it?  Do you create
> a module just for it?  Or do you create a general stdlib2 module
> with all those workhorse functions that have not made it to the
> standard library?  Or something else entirely?

In a typical application you'd have a bunch of such utility functions in
a single "utils.py" module or something like that.  Java programs use
separate files for each class, so you get zillions of files, but Python
users tend to put more code in each file. 

As for the stdlib, the natural places for such a function would be
either itertools or functools, and the function should probably be called
"scan", inspired by this:

  http://en.wikibooks.org/wiki/Haskell/List_processing#Scans

Python's version would be like "scanl" with an optional arg to make it
like "scanl1".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[RG]

In article ,
 Keith Thompson  wrote:

> RG  writes:
> > In article ,
> >  Keith Thompson  wrote:
> >
> >> RG  writes:
> >> > In article 
> >> > <07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>,
> >> >  Squeamizh  wrote:
> >> >> On Sep 29, 3:02 pm, RG  wrote:
> >> [...]
> >> >> > This is a red herring.  You don't have to invoke run-time input to
> >> >> > demonstrate bugs in a statically typed language that are not caught 
> >> >> > by
> >> >> > the compiler.  For example:
> >> >> >
> >> >> > [...@mighty:~]$ cat foo.c
> >> >> > #include 
> >> >> >
> >> >> > int maximum(int a, int b) {
> >> >> >   return (a > b ? a : b);
> >> >> >
> >> >> > }
> >> >> >
> >> >> > int foo(int x) { return 9223372036854775807+x; }
> >> >> >
> >> >> > int main () {
> >> >> >   printf("%d\n", maximum(foo(1), 1));
> >> >> >   return 0;}
> >> >> >
> >> >> > [...@mighty:~]$ gcc -Wall foo.c
> >> >> > [...@mighty:~]$ ./a.out
> >> >> > 1
> >> >> >
> >> >> > Even simple arithmetic is Turing-complete, so catching all 
> >> >> > type-related
> >> >> > errors at compile time would entail solving the halting problem.
> >> >> >
> >> >> > rg
> >> >> 
> >> >> In short, static typing doesn't solve all conceivable problems.
> >> >
> >> > More specifically, the claim made above:
> >> >
> >> >> in C I can have a function maximum(int a, int b) that will always
> >> >> work. Never blow up, and never give an invalid answer.
> >> > 
> >> > is false.  And it is not necessary to invoke the vagaries of run-time 
> >> > input to demonstrate that it is false.
> >> 
> >> But the above maximum() function does exactly that.  The program's
> >> behavior happens to be undefined or implementation-defined for reasons
> >> unrelated to the maximum() function.
> >> 
> >> Depending on the range of type int on the given system, either the
> >> behavior of the addition in foo() is undefined (because it overflows),
> >> or the implicit conversion of the result to int either yields an
> >> implementation-defined result or (in C99) raises an
> >> implementation-defined signal; the latter can lead to undefined
> >> behavior.
> >> 
> >> Since 9223372036854775807 is 2**63-1, what *typically* happens is that
> >> the addition yields the value 0, but the C language doesn't require that
> >> particular result.  You then call maximum with arguments 0 and 1, and
> >> it quite correctly returns 1.
> >
> > This all hinges on what you consider to be "a function maximum(int a, 
> > int b) that ... always work[s] ... [and] never give[s] an invalid 
> > answer."
> 
> int maximum(int a, int b) { return a > b ? a : b; }
> 
> >   But if you don't consider an incorrect answer (according to 
> > the rules of arithmetic) to be an invalid answer then the claim becomes 
> > vacuous.  You could simply ignore the arguments and return 0, and that 
> > would meet the criteria.
> 
> I don't believe it's possible in any language to write a maximum()
> function that returns a correct result *when given incorrect argument
> values*.
> 
> The program (assuming a typical implementation) calls maximum() with
> arguments 0 and 1.  maximum() returns 1.  It works.  The problem
> is elsewhere in the program.

That the problem is "elsewhere in the program" ought to be small 
comfort.  But very well, try this instead:

[...@mighty:~]$ cat foo.c
#include 

int maximum(int a, int b) { return a > b ? a : b; }

int main() {
  long x = 8589934592;
  printf("Max of %ld and 1 is %d\n", x, maximum(x,1));
  return 0;
}
[...@mighty:~]$ gcc -Wall foo.c 
[...@mighty:~]$ ./a.out 
Max of 8589934592 and 1 is 1
-- 
http://mail.python.org/mailman/listinfo/python-list

ANNOUNCING Tahoe, the Least-Authority File System, v1.8.0

[Zooko O'Whielacronx]

Hello, people of python-list. This storage project uses Python for
almost everything, except we use C/C++ for the CPU-intensive
computations (cryptography and erasure coding) and we use JavaScript
for some user interface bits. We're even looking at the possibility of
replacing the C/C++ crypto code with pure-Python code, relying on JIT
compilers such as PyPy to make it efficient enough. :-)

http://twitter.com/#!/fijall/status/25314330015

Regards,

Zooko


ANNOUNCING Tahoe, the Least-Authority File System, v1.8.0

The Tahoe-LAFS team is pleased to announce the immediate
availability of version 1.8.0 of Tahoe-LAFS, an extremely
reliable distributed storage system. Get it here:

http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html

Tahoe-LAFS is the first distributed storage system to offer
"provider-independent security" — meaning that not even the
operators of your storage servers can read or alter your data
without your consent. Here is the one-page explanation of its
unique security and fault-tolerance properties:

http://tahoe-lafs.org/source/tahoe/trunk/docs/about.html

The previous stable release of Tahoe-LAFS was v1.7.1, which was
released July 18, 2010 [1].

v1.8.0 offers greatly improved performance and fault-tolerance
of downloads and improved Windows support. See the NEWS file
[2] for details.


WHAT IS IT GOOD FOR?

With Tahoe-LAFS, you distribute your filesystem across
multiple servers, and even if some of the servers fail or are
taken over by an attacker, the entire filesystem continues to
work correctly, and continues to preserve your privacy and
security. You can easily share specific files and directories
with other people.

In addition to the core storage system itself, volunteers
have built other projects on top of Tahoe-LAFS and have
integrated Tahoe-LAFS with existing systems, including
Windows, JavaScript, iPhone, Android, Hadoop, Flume, Django,
Puppet, bzr, mercurial, perforce, duplicity, TiddlyWiki, and
more. See the Related Projects page on the wiki [3].

We believe that strong cryptography, Free and Open Source
Software, erasure coding, and principled engineering practices
make Tahoe-LAFS safer than RAID, removable drive, tape,
on-line backup or cloud storage.

This software is developed under test-driven development, and
there are no known bugs or security flaws which would
compromise confidentiality or data integrity under recommended
use. (For all important issues that we are currently aware of
please see the known_issues.txt file [4].)


COMPATIBILITY

This release is compatible with the version 1 series of
Tahoe-LAFS. Clients from this release can write files and
directories in the format used by clients of all versions back
to v1.0 (which was released March 25, 2008). Clients from this
release can read files and directories produced by clients of
all versions since v1.0. Servers from this release can serve
clients of all versions back to v1.0 and clients from this
release can use servers of all versions back to v1.0.

This is the eleventh release in the version 1 series. This
series of Tahoe-LAFS will be actively supported and maintained
for the forseeable future, and future versions of Tahoe-LAFS
will retain the ability to read and write files compatible
with this series.


LICENCE

You may use this package under the GNU General Public License,
version 2 or, at your option, any later version. See the file
"COPYING.GPL" [5] for the terms of the GNU General Public
License, version 2.

You may use this package under the Transitive Grace Period
Public Licence, version 1 or, at your option, any later
version. (The Transitive Grace Period Public Licence has
requirements similar to the GPL except that it allows you to
delay for up to twelve months after you redistribute a derived
work before releasing the source code of your derived work.)
See the file "COPYING.TGPPL.html" [6] for the terms of the
Transitive Grace Period Public Licence, version 1.

(You may choose to use this package under the terms of either
licence, at your option.)


INSTALLATION

Tahoe-LAFS works on Linux, Mac OS X, Windows, Cygwin, Solaris,
*BSD, and probably most other systems. Start with
"docs/quickstart.html" [7].


HACKING AND COMMUNITY

Please join us on the mailing list [8]. Patches are gratefully
accepted -- the RoadMap page [9] shows the next improvements
that we plan to make and CREDITS [10] lists the names of people
who've contributed to the project. The Dev page [11] contains
resources for hackers.


SPONSORSHIP

Tahoe-LAFS was originally developed by Allmydata, Inc., a
provider of commercial backup services. After discontinuing
funding of Tahoe-LAFS R&D in early 2009, they continued
to provide servers, bandwidth, small personal gifts as tokens
of appreciation, and bug reports.

Google, Inc. sponsored Tahoe-LAFS development as part of the
Google Summer of Code 2010. They awarded four sponsorships to
students from around the world to hack on Tahoe-LAFS that
summer.

Thank you to Allmydata a

Re: "Strong typing vs. strong testing"

[Squeamizh]

On Sep 29, 3:14 pm, RG  wrote:
> In article
> <07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>,
>
>
>
>
>
>  Squeamizh  wrote:
> > On Sep 29, 3:02 pm, RG  wrote:
> > > In article
> > > <996bd4e6-37ff-4a55-8db5-6e7574fbd...@k22g2000prb.googlegroups.com>,
>
> > >  Squeamizh  wrote:
> > > > On Sep 27, 10:46 am, namekuseijin  wrote:
> > > > > On 27 set, 05:46, TheFlyingDutchman  wrote:
>
> > > > > > On Sep 27, 12:58 am, p...@informatimago.com (Pascal J. Bourguignon)
> > > > > > wrote:
> > > > > > > RG  writes:
> > > > > > > > In article
> > > > > > > > <7df0eb06-9be1-4c9c-8057-e9fdb7f0b...@q16g2000prf.googlegroups.com
> > > > > > > > >,
> > > > > > > >  TheFlyingDutchman  wrote:
>
> > > > > > > >> On Sep 22, 10:26 pm, "Scott L. Burson"  wrote:
> > > > > > > >> > This might have been mentioned here before, but I just came
> > > > > > > >> > across
> > > > > > > >> > it: a
> > > > > > > >> > 2003 essay by Bruce Eckel on how reliable systems can get
> > > > > > > >> > built in
> > > > > > > >> > dynamically-typed languages.  It echoes things we've all said
> > > > > > > >> > here, but
> > > > > > > >> > I think it's interesting because it describes a conversion
> > > > > > > >> > experience:
> > > > > > > >> > Eckel started out in the strong-typing camp and was won over.
>
> > > > > > > >> >    https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk
>
> > > > > > > >> > -- Scott
>
> > > > > > > >> If you are writing a function to determine the maximum of two
> > > > > > > >> numbers
> > > > > > > >> passed as arguents in a dynamic typed language, what is the
> > > > > > > >> normal
> > > > > > > >> procedure used by Eckel and others to handle someone passing in
> > > > > > > >> invalid values - such as a file handle for one varible and an
> > > > > > > >> array
> > > > > > > >> for the other?
>
> > > > > > > > The normal procedure is to hit such a person over the head with 
> > > > > > > > a
> > > > > > > > stick
> > > > > > > > and shout "FOO".
>
> > > > > > > Moreover, the functions returning the maximum may be able to work
> > > > > > > on
> > > > > > > non-numbers, as long as they're comparable.  What's more, there 
> > > > > > > are
> > > > > > > numbers that are NOT comparable by the operator you're thinking
> > > > > > > about!.
>
> > > > > > > So to implement your specifications, that function would have to 
> > > > > > > be
> > > > > > > implemented for example as:
>
> > > > > > > (defmethod lessp ((x real) (y real)) (< x y))
> > > > > > > (defmethod lessp ((x complex) (y complex))
> > > > > > >   (or (< (real-part x) (real-part y))
> > > > > > >       (and (= (real-part x) (real-part y))
> > > > > > >            (< (imag-part x) (imag-part y)
>
> > > > > > > (defun maximum (a b)
> > > > > > >   (if (lessp a b) b a))
>
> > > > > > > And then the client of that function could very well add methods:
>
> > > > > > > (defmethod lessp ((x symbol) (y t)) (lessp (string x) y))
> > > > > > > (defmethod lessp ((x t) (y symbol)) (lessp x (string y)))
> > > > > > > (defmethod lessp ((x string) (y string)) (string< x y))
>
> > > > > > > and call:
>
> > > > > > > (maximum 'hello "WORLD") --> "WORLD"
>
> > > > > > > and who are you to forbid it!?
>
> > > > > > > --
> > > > > > > __Pascal Bourguignon__                  
> > > > > > >  http://www.informatimago.com/-Hidequotedtext-
>
> > > > > > > - Show quoted text -
>
> > > > > > in C I can have a function maximum(int a, int b) that will always
> > > > > > work. Never blow up, and never give an invalid answer. If someone
> > > > > > tries to call it incorrectly it is a compile error.
> > > > > > In a dynamic typed language maximum(a, b) can be called with
> > > > > > incorrect
> > > > > > datatypes. Even if I make it so it can handle many types as you did
> > > > > > above, it could still be inadvertantly called with a file handle for
> > > > > > a
> > > > > > parameter or some other type not provided for. So does Eckel and
> > > > > > others, when they are writing their dynamically typed code advocate
> > > > > > just letting the function blow up or give a bogus answer, or do they
> > > > > > check for valid types passed? If they are checking for valid types 
> > > > > > it
> > > > > > would seem that any benefits gained by not specifying type are lost
> > > > > > by
> > > > > > checking for type. And if they don't check for type it would seem
> > > > > > that
> > > > > > their code's error handling is poor.
>
> > > > > that is a lie.
>
> > > > > Compilation only makes sure that values provided at compilation-time
> > > > > are of the right datatype.
>
> > > > > What happens though is that in the real world, pretty much all
> > > > > computation depends on user provided values at runtime.  See where are
> > > > > we heading?
>
> > > > > this works at compilation time without warnings:
> > > > > int m=numbermax( 2, 6 );
>
> > > > > this too:
> > > > > int a, b, m;
> > > > > scanf( "%d", &a );
> > > > > scanf( "%d", &b );
> > > > > m=numbermax( a, b )

Re: About __class__ of an int literal

[Steven D'Aprano]

On Wed, 29 Sep 2010 14:46:18 -0400, Terry Reedy wrote:

>> In that sense the user
>> should be calling iter(foo) instead of foo.__iter__(), next(foo)
>> instead of foo.__next__(), and foo+bar instead of foo.__add__(bar).
> 
> Yes. Guido added iter() and next() to the list of built-in functions,
> even though they seem reduncant.. I believe it is his intention that the
> use of special names outside of class statements should be fairly rare.

Fairly rare but not non-existent.

For example, there's nothing wrong with using a callback function of 
(say) instance.__sub__ instead of lambda b, a=instance: a - b. Not only 
is the direct call to the method slightly faster, but more importantly 
it's easier to read and more clear to intent.

Admittedly beginners may find instance.__sub__ to be a tad mysterious, 
but then beginners are likely to find the lambda form with its two 
arguments and default value mysterious too.



> If I remember right, in the old, pre-2.2 system that separated built-in
> types and user-written classes, the builtins did not have accessible
> special method attributes.

Yes, that's correct. But we're talking about Python *now*, not back in 
the mists of time before new-style classes. Would you argue that users 
shouldn't use decorators, iterators or closures because Python 2.1 didn't 
have them? I don't think so.


> They are only for customizing user classes.

Say "were" rather than "are" and I will agree with you.

Say "primarily for" rather than "only" and I will also agree with you.


> So one could not have generically written foo.__add__(bar).
> Special-method attribute were added to builtins so that they could be
> inherited (or replaced) by user-written subclasses, not so that one
> could replace normal syntax.

Of course one shouldn't prefer seq.__len__() over len(seq). But that's a 
readability issue, and not because Python implementations are free to 
change __len__ to something else.

If I gave the opposite impression, that was not my intention and I'm 
sorry for the failure to be more clear.



>> Direct
>> calls to special-name methods, such as __len__, often indicate that the
>> programmer hasn't grasped how those methods are intended to be used in
>> Python.
> 
> Right. That fact that *Python* interpreters implement syntax with
> special methods is an implementation detail of the *language*. The
> importance is that it allow *writers* of new classes to rather easily
> imitate built-in classes so that their classes seamlessly plug into the
> syntax.

If I've understood this paragraph correctly, you're trying to say that 
since *other languages* that aren't Python are free to implement syntax 
features using some other mechanism, *Python* developers shouldn't use 
special methods because they are implementation details.

If we're prohibited from using anything which is an implementation detail 
of "the *language*" (your emphasis), then we can't use *anything*. Yes, 
special methods are an implementation detail of Python, but only in the 
same sense that it is an implementation detail of Python that we write 
this:

def f(a, b):
x = a + b
return math.sqrt(x)


rather than this:

function f(a, b: integer):float:
  var
x: integer;
  begin
x := a + b;
f := sqrt(x)
  end;



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: list problem...

[Shashwat Anand]

On Thu, Sep 30, 2010 at 3:20 AM, Rog  wrote:

> On Wed, 29 Sep 2010 05:52:32 -0700, bruno.desthuilli...@gmail.com wrote:
>
> > On 29 sep, 14:17, Steven D'Aprano  >
> > wrote:
> >> On Tue, 28 Sep 2010 20:11:51 +0100, Rog wrote:
> >> > On Tue, 28 Sep 2010 11:59:08 -0700, geremy condra wrote:
> >>
> >> >> On Tue, Sep 28, 2010 at 11:44 AM, Rog  wrote:
> >> >>> Hi all,
> >> >>> Have been grappling with a list problem for hours... a = [2, 3, 4,
> >> >>> 5,.]
> >> >>> b = [4, 8, 2, 6,.]
> >> >>> Basicly I am trying to place a[0], b[0] in a seperate list IF a[2]
> >> >>> and b[2] is present.
> >> >>> I have tried sets, zip etc with no success. I am tackling Euler
> >> >>> projects with Python 3.1, with minimal knowledge, and having to
> >> >>> tackle the language as I progress. Enjoyable frustration  :)
> >>
> >> >> I'm not clear on what your actual problem is, could you restate it?
> >>
> >> >> It sounds like you want to copy the ith element out of a and b into
> >> >> some other list- call it c- when the (i+2)th element meets some
> >> >> condition. What's the condition?
> >>
> >> >> Geremy Condra
> >>
> >> > The condition is that the i-th element is inverted, but not equal. eg
> >> > 4,2 - 2,4 , 34,5 - 5,34 etc.
> >> > Hope that is clearer.
> >>
> >> Clear as mud.
> >>
> >> Perhaps you should given an example. Given input
> >>
> >> a = [2, 3, 4, 5, 6, 7]
> >> b = [4, 8, 2, 6, 10, 42]
> >>
> >> what output are you expecting,
> >
> > AFAICT, the OP expects [2, 4] in this case, but it's not clear what he'd
> > expect for let's say:
> >
> > a = [2, 3, 21, 4, 5, 6, 7]
> > b = [4, 8, 22, 2, 6, 10, 42]
> >
> > (the 'reversed' pair is at i+3, not i+2)
> >
> > or
> >
> > a = [0, 2, 3, 4, 5, 6, 7]
> > b = [3, 4, 8, 2, 6, 10, 42]
> >
> > (the first pair is at pos 1, not 0)
> >
> > or
> >
> > a = [2, 3, 4, 8, 6, 7]
> > b = [4, 8, 2, 3, 10, 42]
> >
> > (there's a second 'non-reversed/reversed' match at positions resp. 1 & 3)
>
>
> It is true that I would have needed any 'non-reversed/reversed' pairs,
> these would have been the amicable pairs I was looking for.
> The method to recognise them eluded me. Eyes are not good enough  :)
> I have now joined Python-List and will follow the correct route.
> I have used a method suggested that has made the problem redundant,
> though it will bug me from now on.
>
> g = []
>
> def divsum(n):
>return sum(i for i in range(1, n) if not n % i)
>

You can optimize divsum. Remember that factors exist in pairs except when
numbers are squares.
Like say 12 have factors = 1, 12, 2, 6, 3, 4
so you can run the loop till sqrt(n) for n since floor(sqrt(n)) = 3 where n
= 12
now factors are , (1, n/1), (2, n/2), (3, n/2).
for a square number say n = 9, the factors are (1, 3, 12)
If you run the loop till sqrt(n) for n since floor(sqrt(n)) = 3 where n = 9
we get the factors as (1, 9), (3, 3)
One of the factor will be redundant, so you need to take care of that.


>
> for x in range(1, 2, -1):
>c = divsum(x)
>v = divsum(c)
>

Can be done as,
c, v = divsum(x), divsum(divsum(x))


>if v == x and v != c:
>g.append(divsum(x))
>

No need for else part, what is the use ?


>else:
>continue
>
> print(sum(g))
>

You could pack this up as,

>>> sum(i for i in range(1, 0, -2) if divsum(divsum(i)) == i and
divsum(i) != i)
31626


> --
> Rog
> http://www.rog.pynguins.com
> --
> http://mail.python.org/mailman/listinfo/python-list
>



-- 
~l0nwlf
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Keith Thompson]

RG  writes:
> In article ,
>  Keith Thompson  wrote:
>
>> RG  writes:
>> > In article 
>> > <07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>,
>> >  Squeamizh  wrote:
>> >> On Sep 29, 3:02 pm, RG  wrote:
>> [...]
>> >> > This is a red herring.  You don't have to invoke run-time input to
>> >> > demonstrate bugs in a statically typed language that are not caught by
>> >> > the compiler.  For example:
>> >> >
>> >> > [...@mighty:~]$ cat foo.c
>> >> > #include 
>> >> >
>> >> > int maximum(int a, int b) {
>> >> >   return (a > b ? a : b);
>> >> >
>> >> > }
>> >> >
>> >> > int foo(int x) { return 9223372036854775807+x; }
>> >> >
>> >> > int main () {
>> >> >   printf("%d\n", maximum(foo(1), 1));
>> >> >   return 0;}
>> >> >
>> >> > [...@mighty:~]$ gcc -Wall foo.c
>> >> > [...@mighty:~]$ ./a.out
>> >> > 1
>> >> >
>> >> > Even simple arithmetic is Turing-complete, so catching all type-related
>> >> > errors at compile time would entail solving the halting problem.
>> >> >
>> >> > rg
>> >> 
>> >> In short, static typing doesn't solve all conceivable problems.
>> >
>> > More specifically, the claim made above:
>> >
>> >> in C I can have a function maximum(int a, int b) that will always
>> >> work. Never blow up, and never give an invalid answer.
>> > 
>> > is false.  And it is not necessary to invoke the vagaries of run-time 
>> > input to demonstrate that it is false.
>> 
>> But the above maximum() function does exactly that.  The program's
>> behavior happens to be undefined or implementation-defined for reasons
>> unrelated to the maximum() function.
>> 
>> Depending on the range of type int on the given system, either the
>> behavior of the addition in foo() is undefined (because it overflows),
>> or the implicit conversion of the result to int either yields an
>> implementation-defined result or (in C99) raises an
>> implementation-defined signal; the latter can lead to undefined
>> behavior.
>> 
>> Since 9223372036854775807 is 2**63-1, what *typically* happens is that
>> the addition yields the value 0, but the C language doesn't require that
>> particular result.  You then call maximum with arguments 0 and 1, and
>> it quite correctly returns 1.
>
> This all hinges on what you consider to be "a function maximum(int a, 
> int b) that ... always work[s] ... [and] never give[s] an invalid 
> answer."

int maximum(int a, int b) { return a > b ? a : b; }

>   But if you don't consider an incorrect answer (according to 
> the rules of arithmetic) to be an invalid answer then the claim becomes 
> vacuous.  You could simply ignore the arguments and return 0, and that 
> would meet the criteria.

I don't believe it's possible in any language to write a maximum()
function that returns a correct result *when given incorrect argument
values*.

The program (assuming a typical implementation) calls maximum() with
arguments 0 and 1.  maximum() returns 1.  It works.  The problem
is elsewhere in the program.

(And on a hypothetical system with INT_MAX >= 9223372036854775808,
the program's entire behavior is well defined and mathematically
correct.  C requires INT_MAX >= 32767; it can be as large as the
implementation chooses.  In practice, the largest value I've ever
seen for INT_MAX is 9223372036854775807.)

> If you try to refine this claim so that it is both correct and 
> non-vacuous you will find that static typing does not do nearly as much 
> for you as most of its adherents think it does.

Speaking only for myself, I've never claimed that static typing solves
all conceivable problems.  My point is only about this specific example
of a maximum() function.

[...]

-- 
Keith Thompson (The_Other_Keith) ks...@mib.org  
Nokia
"We must do something.  This is something.  Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Thomas A. Russ]

RG  writes:
> 
> More power to you.  What are you doing here on cll then?

This thread is massively cross-posted.

-- 
Thomas A. Russ,  USC/Information Sciences Institute
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[RG]

In article ,
 Keith Thompson  wrote:

> RG  writes:
> > In article 
> > <07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>,
> >  Squeamizh  wrote:
> >> On Sep 29, 3:02 pm, RG  wrote:
> [...]
> >> > This is a red herring.  You don't have to invoke run-time input to
> >> > demonstrate bugs in a statically typed language that are not caught by
> >> > the compiler.  For example:
> >> >
> >> > [...@mighty:~]$ cat foo.c
> >> > #include 
> >> >
> >> > int maximum(int a, int b) {
> >> >   return (a > b ? a : b);
> >> >
> >> > }
> >> >
> >> > int foo(int x) { return 9223372036854775807+x; }
> >> >
> >> > int main () {
> >> >   printf("%d\n", maximum(foo(1), 1));
> >> >   return 0;}
> >> >
> >> > [...@mighty:~]$ gcc -Wall foo.c
> >> > [...@mighty:~]$ ./a.out
> >> > 1
> >> >
> >> > Even simple arithmetic is Turing-complete, so catching all type-related
> >> > errors at compile time would entail solving the halting problem.
> >> >
> >> > rg
> >> 
> >> In short, static typing doesn't solve all conceivable problems.
> >
> > More specifically, the claim made above:
> >
> >> in C I can have a function maximum(int a, int b) that will always
> >> work. Never blow up, and never give an invalid answer.
> > 
> > is false.  And it is not necessary to invoke the vagaries of run-time 
> > input to demonstrate that it is false.
> 
> But the above maximum() function does exactly that.  The program's
> behavior happens to be undefined or implementation-defined for reasons
> unrelated to the maximum() function.
> 
> Depending on the range of type int on the given system, either the
> behavior of the addition in foo() is undefined (because it overflows),
> or the implicit conversion of the result to int either yields an
> implementation-defined result or (in C99) raises an
> implementation-defined signal; the latter can lead to undefined
> behavior.
> 
> Since 9223372036854775807 is 2**63-1, what *typically* happens is that
> the addition yields the value 0, but the C language doesn't require that
> particular result.  You then call maximum with arguments 0 and 1, and
> it quite correctly returns 1.

This all hinges on what you consider to be "a function maximum(int a, 
int b) that ... always work[s] ... [and] never give[s] an invalid 
answer."  But if you don't consider an incorrect answer (according to 
the rules of arithmetic) to be an invalid answer then the claim becomes 
vacuous.  You could simply ignore the arguments and return 0, and that 
would meet the criteria.

If you try to refine this claim so that it is both correct and 
non-vacuous you will find that static typing does not do nearly as much 
for you as most of its adherents think it does.

> >> We are all aware that there is no perfect software development process
> >> or tool set.  I'm interested in minimizing the number of problems I
> >> run into during development, and the number of bugs that are in the
> >> finished product.  My opinion is that static typed languages are
> >> better at this for large projects, for the reasons I stated in my
> >> previous post.
> >
> > More power to you.  What are you doing here on cll then?
> 
> This thread is cross-posted to several newsgroups, including
> comp.lang.c.

Ah, so it is.  My bad.

rg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Pascal J. Bourguignon]

Squeamizh  writes:

> In short, static typing doesn't solve all conceivable problems.
>
> We are all aware that there is no perfect software development process
> or tool set.  I'm interested in minimizing the number of problems I
> run into during development, and the number of bugs that are in the
> finished product.  My opinion is that static typed languages are
> better at this for large projects, for the reasons I stated in my
> previous post.

Our experience is that a garbage collector and native bignums are much
more important to minimize the number of problems we run into during
development and the number of bugs that are in the finished products.


-- 
__Pascal Bourguignon__ http://www.informatimago.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Keith Thompson]

RG  writes:
> In article 
> <07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>,
>  Squeamizh  wrote:
>> On Sep 29, 3:02 pm, RG  wrote:
[...]
>> > This is a red herring.  You don't have to invoke run-time input to
>> > demonstrate bugs in a statically typed language that are not caught by
>> > the compiler.  For example:
>> >
>> > [...@mighty:~]$ cat foo.c
>> > #include 
>> >
>> > int maximum(int a, int b) {
>> >   return (a > b ? a : b);
>> >
>> > }
>> >
>> > int foo(int x) { return 9223372036854775807+x; }
>> >
>> > int main () {
>> >   printf("%d\n", maximum(foo(1), 1));
>> >   return 0;}
>> >
>> > [...@mighty:~]$ gcc -Wall foo.c
>> > [...@mighty:~]$ ./a.out
>> > 1
>> >
>> > Even simple arithmetic is Turing-complete, so catching all type-related
>> > errors at compile time would entail solving the halting problem.
>> >
>> > rg
>> 
>> In short, static typing doesn't solve all conceivable problems.
>
> More specifically, the claim made above:
>
>> in C I can have a function maximum(int a, int b) that will always
>> work. Never blow up, and never give an invalid answer.
> 
> is false.  And it is not necessary to invoke the vagaries of run-time 
> input to demonstrate that it is false.

But the above maximum() function does exactly that.  The program's
behavior happens to be undefined or implementation-defined for reasons
unrelated to the maximum() function.

Depending on the range of type int on the given system, either the
behavior of the addition in foo() is undefined (because it overflows),
or the implicit conversion of the result to int either yields an
implementation-defined result or (in C99) raises an
implementation-defined signal; the latter can lead to undefined
behavior.

Since 9223372036854775807 is 2**63-1, what *typically* happens is that
the addition yields the value 0, but the C language doesn't require that
particular result.  You then call maximum with arguments 0 and 1, and
it quite correctly returns 1.

>> We are all aware that there is no perfect software development process
>> or tool set.  I'm interested in minimizing the number of problems I
>> run into during development, and the number of bugs that are in the
>> finished product.  My opinion is that static typed languages are
>> better at this for large projects, for the reasons I stated in my
>> previous post.
>
> More power to you.  What are you doing here on cll then?

This thread is cross-posted to several newsgroups, including
comp.lang.c.

-- 
Keith Thompson (The_Other_Keith) ks...@mib.org  
Nokia
"We must do something.  This is something.  Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Certificate validation with HTTPSConnection

[Antoine Pitrou]

On Wed, 29 Sep 2010 13:41:15 -0700
John Nagle  wrote:
> 
> The really stupid thing about the current SSL module is that it
> accepts a file of root certificates as a parameter, but ignores it.

That's not true. You have to pass CERT_OPTIONAL or CERT_REQUIRED as a
parameter (CERT_NONE is though).

Regards

Antoine.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: PyCObject & malloc creating memory leak

[Antoine Pitrou]

On Wed, 29 Sep 2010 06:50:05 -0700 (PDT)
Tom Conneely  wrote:
> 
> My original plan was to have the data processing and data acquisition
> functions running in separate processes, with a multiprocessing.Queue
> for passing the raw data packets. The raw data is read in as a char*,
> with a non constant length, hence I have allocated memory using
> PyMem_Malloc and I am returning from the acquisition function a
> PyCObject containing a pointer to this char* buffer, along with a
> destructor.

That sounds overkill, and I also wonder how you plan to pass that
object in a multiprocessing Queue (which relies on objects being
pickleable). Why don't you simply create a PyString object instead?

> So if I call these functions in a loop, e.g. The following will
> generate ~10GB of data
> 
> x = MyClass()
> for i in xrange(0, 10 * 2**20):
> c = x.malloc_buffer()
> x.retrieve_buffer(c)
> 
> All my memory disapears, until python crashes with a MemoryError. By
> placing a print in the destructor function I know it's being called,
> however it's not actually freeing the memory. So in short, what am I
> doing wrong?

Python returns memory to the OS by calling free(). Not all OSes
actually relinquish memory when free() is called; some will simply set
it aside for the next allocation.
Another possible (and related) issue is memory fragmentation. Again, it
depends on the memory allocator.

Regards

Antoine.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: utf-8 and ctypes

[MRAB]

On 29/09/2010 19:33, Brendan Miller wrote:
> 2010/9/29 Lawrence D'Oliveiro:
>> In message, Brendan
>> Miller wrote:
>>
>>> It seems that characters not in the ascii subset of UTF-8 are
>>> discarded by c_char_p during the conversion ...
>>
>> Not a chance.
>>
>>> ... or at least they don't print out when I go to print the string.
>>
>> So it seems there’s a problem on the printing side. What happens when you
>> construct a UTF-8-encoded string directly in Python and try printing it the
>> same way?
> 
> Doing this seems to confirm something is broken in ctypes w.r.t. UTF-8...
> 
> if I enter:
> str = "日本語のテスト"
> 
> Then:
> print str
> 日本語のテスト
> 
> However, when I create a string buffer, pass it into my c++ code, and
> write the same UTF-8 string into it, python seems to discard pretty
> much all the text. The same code works for pure ascii strings.
> 
> Python code:
> _std_string_size = _lib_mbxclient.std_string_size
> _std_string_size.restype = c_long
> _std_string_size.argtypes = [c_void_p]
> 
> _std_string_copy = _lib_mbxclient.std_string_copy
> _std_string_copy.restype = None
> _std_string_copy.argtypes = [c_void_p, POINTER(c_char)]
> 
> # This function works for ascii, but breaks on strings with UTF-8!
> def std_string_to_string(str_ptr):
>  buf = create_string_buffer(_std_string_size(str_ptr))
>  _std_string_copy(str_ptr, buf)
>  return buf.raw
> 
> C++ code:
> 
> extern "C"
> long std_string_size(string* str)
> {
>   return str->size();
> }
> 
> extern "C"
> void std_string_copy(string* str, char* buf)
> {
>   std::copy(str->begin(), str->end(), buf);
> }

It might have something to do with the character encoding of your
source files.

Also, try printing out the character codes of the string and the size
of the string's character in the C++ code.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Certificate validation with HTTPSConnection

[Ned Deily]

In article <4ca3a46b.4080...@animats.com>,
 John Nagle  wrote:
>  We've been through this.  Too many times.
> 
> http://bugs.python.org/issue1114345
> (2005: Broken in Python 2.2, eventually fixed)
> 
> http://www.justinsamuel.com/2008/12/25/the-importance-of-validating-ssl-certif
> icates/
> (2008: Why this matters)
> 
> http://www.mail-archive.com/python-list@python.org/msg281736.html
> (2010: Broken in new Python 2.6 SSL module.)
> 
> http://bugs.python.org/issue1589
> (2010: Developer "Bill Jansen" in denial, others disagree.
> Currently being debated.  See bug tracker.)
> 
> The really stupid thing about the current SSL module is that it
> accepts a file of root certificates as a parameter, but ignores it.
> So it creates the illusion of security without providing it.
> As someone pointed out, the current SSL module "lets you talk
> encrypted to your attacker".

I'll just note in passing that Issue1589 is being discussed again.  Feel 
free to contribute.

-- 
 Ned Deily,
 n...@acm.org

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[RG]

In article 
<07f75df3-778d-4e3d-8aa0-fbd4bd108...@k22g2000prb.googlegroups.com>,
 Squeamizh  wrote:

> On Sep 29, 3:02 pm, RG  wrote:
> > In article
> > <996bd4e6-37ff-4a55-8db5-6e7574fbd...@k22g2000prb.googlegroups.com>,
> >
> >
> >
> >
> >
> >  Squeamizh  wrote:
> > > On Sep 27, 10:46 am, namekuseijin  wrote:
> > > > On 27 set, 05:46, TheFlyingDutchman  wrote:
> >
> > > > > On Sep 27, 12:58 am, p...@informatimago.com (Pascal J. Bourguignon)
> > > > > wrote:
> > > > > > RG  writes:
> > > > > > > In article
> > > > > > > <7df0eb06-9be1-4c9c-8057-e9fdb7f0b...@q16g2000prf.googlegroups.com
> > > > > > > >,
> > > > > > >  TheFlyingDutchman  wrote:
> >
> > > > > > >> On Sep 22, 10:26 pm, "Scott L. Burson"  wrote:
> > > > > > >> > This might have been mentioned here before, but I just came 
> > > > > > >> > across
> > > > > > >> > it: a
> > > > > > >> > 2003 essay by Bruce Eckel on how reliable systems can get 
> > > > > > >> > built in
> > > > > > >> > dynamically-typed languages.  It echoes things we've all said
> > > > > > >> > here, but
> > > > > > >> > I think it's interesting because it describes a conversion
> > > > > > >> > experience:
> > > > > > >> > Eckel started out in the strong-typing camp and was won over.
> >
> > > > > > >> >    https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk
> >
> > > > > > >> > -- Scott
> >
> > > > > > >> If you are writing a function to determine the maximum of two
> > > > > > >> numbers
> > > > > > >> passed as arguents in a dynamic typed language, what is the 
> > > > > > >> normal
> > > > > > >> procedure used by Eckel and others to handle someone passing in
> > > > > > >> invalid values - such as a file handle for one varible and an 
> > > > > > >> array
> > > > > > >> for the other?
> >
> > > > > > > The normal procedure is to hit such a person over the head with a
> > > > > > > stick
> > > > > > > and shout "FOO".
> >
> > > > > > Moreover, the functions returning the maximum may be able to work 
> > > > > > on
> > > > > > non-numbers, as long as they're comparable.  What's more, there are
> > > > > > numbers that are NOT comparable by the operator you're thinking 
> > > > > > about!.
> >
> > > > > > So to implement your specifications, that function would have to be
> > > > > > implemented for example as:
> >
> > > > > > (defmethod lessp ((x real) (y real)) (< x y))
> > > > > > (defmethod lessp ((x complex) (y complex))
> > > > > >   (or (< (real-part x) (real-part y))
> > > > > >       (and (= (real-part x) (real-part y))
> > > > > >            (< (imag-part x) (imag-part y)
> >
> > > > > > (defun maximum (a b)
> > > > > >   (if (lessp a b) b a))
> >
> > > > > > And then the client of that function could very well add methods:
> >
> > > > > > (defmethod lessp ((x symbol) (y t)) (lessp (string x) y))
> > > > > > (defmethod lessp ((x t) (y symbol)) (lessp x (string y)))
> > > > > > (defmethod lessp ((x string) (y string)) (string< x y))
> >
> > > > > > and call:
> >
> > > > > > (maximum 'hello "WORLD") --> "WORLD"
> >
> > > > > > and who are you to forbid it!?
> >
> > > > > > --
> > > > > > __Pascal Bourguignon__                  
> > > > > >  http://www.informatimago.com/-Hidequotedtext -
> >
> > > > > > - Show quoted text -
> >
> > > > > in C I can have a function maximum(int a, int b) that will always
> > > > > work. Never blow up, and never give an invalid answer. If someone
> > > > > tries to call it incorrectly it is a compile error.
> > > > > In a dynamic typed language maximum(a, b) can be called with 
> > > > > incorrect
> > > > > datatypes. Even if I make it so it can handle many types as you did
> > > > > above, it could still be inadvertantly called with a file handle for 
> > > > > a
> > > > > parameter or some other type not provided for. So does Eckel and
> > > > > others, when they are writing their dynamically typed code advocate
> > > > > just letting the function blow up or give a bogus answer, or do they
> > > > > check for valid types passed? If they are checking for valid types it
> > > > > would seem that any benefits gained by not specifying type are lost 
> > > > > by
> > > > > checking for type. And if they don't check for type it would seem 
> > > > > that
> > > > > their code's error handling is poor.
> >
> > > > that is a lie.
> >
> > > > Compilation only makes sure that values provided at compilation-time
> > > > are of the right datatype.
> >
> > > > What happens though is that in the real world, pretty much all
> > > > computation depends on user provided values at runtime.  See where are
> > > > we heading?
> >
> > > > this works at compilation time without warnings:
> > > > int m=numbermax( 2, 6 );
> >
> > > > this too:
> > > > int a, b, m;
> > > > scanf( "%d", &a );
> > > > scanf( "%d", &b );
> > > > m=numbermax( a, b );
> >
> > > > no compiler issues, but will not work just as much as in python if
> > > > user provides "foo" and "bar" for a and b... fail.
> >
> > > > What you do if you're feeling insecure and paranoid?  Just wha

Re: "Strong typing vs. strong testing"

[Squeamizh]

On Sep 29, 3:02 pm, RG  wrote:
> In article
> <996bd4e6-37ff-4a55-8db5-6e7574fbd...@k22g2000prb.googlegroups.com>,
>
>
>
>
>
>  Squeamizh  wrote:
> > On Sep 27, 10:46 am, namekuseijin  wrote:
> > > On 27 set, 05:46, TheFlyingDutchman  wrote:
>
> > > > On Sep 27, 12:58 am, p...@informatimago.com (Pascal J. Bourguignon)
> > > > wrote:
> > > > > RG  writes:
> > > > > > In article
> > > > > > <7df0eb06-9be1-4c9c-8057-e9fdb7f0b...@q16g2000prf.googlegroups.com>,
> > > > > >  TheFlyingDutchman  wrote:
>
> > > > > >> On Sep 22, 10:26 pm, "Scott L. Burson"  wrote:
> > > > > >> > This might have been mentioned here before, but I just came 
> > > > > >> > across
> > > > > >> > it: a
> > > > > >> > 2003 essay by Bruce Eckel on how reliable systems can get built 
> > > > > >> > in
> > > > > >> > dynamically-typed languages.  It echoes things we've all said
> > > > > >> > here, but
> > > > > >> > I think it's interesting because it describes a conversion
> > > > > >> > experience:
> > > > > >> > Eckel started out in the strong-typing camp and was won over.
>
> > > > > >> >    https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk
>
> > > > > >> > -- Scott
>
> > > > > >> If you are writing a function to determine the maximum of two
> > > > > >> numbers
> > > > > >> passed as arguents in a dynamic typed language, what is the normal
> > > > > >> procedure used by Eckel and others to handle someone passing in
> > > > > >> invalid values - such as a file handle for one varible and an array
> > > > > >> for the other?
>
> > > > > > The normal procedure is to hit such a person over the head with a
> > > > > > stick
> > > > > > and shout "FOO".
>
> > > > > Moreover, the functions returning the maximum may be able to work on
> > > > > non-numbers, as long as they're comparable.  What's more, there are
> > > > > numbers that are NOT comparable by the operator you're thinking 
> > > > > about!.
>
> > > > > So to implement your specifications, that function would have to be
> > > > > implemented for example as:
>
> > > > > (defmethod lessp ((x real) (y real)) (< x y))
> > > > > (defmethod lessp ((x complex) (y complex))
> > > > >   (or (< (real-part x) (real-part y))
> > > > >       (and (= (real-part x) (real-part y))
> > > > >            (< (imag-part x) (imag-part y)
>
> > > > > (defun maximum (a b)
> > > > >   (if (lessp a b) b a))
>
> > > > > And then the client of that function could very well add methods:
>
> > > > > (defmethod lessp ((x symbol) (y t)) (lessp (string x) y))
> > > > > (defmethod lessp ((x t) (y symbol)) (lessp x (string y)))
> > > > > (defmethod lessp ((x string) (y string)) (string< x y))
>
> > > > > and call:
>
> > > > > (maximum 'hello "WORLD") --> "WORLD"
>
> > > > > and who are you to forbid it!?
>
> > > > > --
> > > > > __Pascal Bourguignon__                  
> > > > >  http://www.informatimago.com/-Hidequotedtext -
>
> > > > > - Show quoted text -
>
> > > > in C I can have a function maximum(int a, int b) that will always
> > > > work. Never blow up, and never give an invalid answer. If someone
> > > > tries to call it incorrectly it is a compile error.
> > > > In a dynamic typed language maximum(a, b) can be called with incorrect
> > > > datatypes. Even if I make it so it can handle many types as you did
> > > > above, it could still be inadvertantly called with a file handle for a
> > > > parameter or some other type not provided for. So does Eckel and
> > > > others, when they are writing their dynamically typed code advocate
> > > > just letting the function blow up or give a bogus answer, or do they
> > > > check for valid types passed? If they are checking for valid types it
> > > > would seem that any benefits gained by not specifying type are lost by
> > > > checking for type. And if they don't check for type it would seem that
> > > > their code's error handling is poor.
>
> > > that is a lie.
>
> > > Compilation only makes sure that values provided at compilation-time
> > > are of the right datatype.
>
> > > What happens though is that in the real world, pretty much all
> > > computation depends on user provided values at runtime.  See where are
> > > we heading?
>
> > > this works at compilation time without warnings:
> > > int m=numbermax( 2, 6 );
>
> > > this too:
> > > int a, b, m;
> > > scanf( "%d", &a );
> > > scanf( "%d", &b );
> > > m=numbermax( a, b );
>
> > > no compiler issues, but will not work just as much as in python if
> > > user provides "foo" and "bar" for a and b... fail.
>
> > > What you do if you're feeling insecure and paranoid?  Just what
> > > dynamically typed languages do:  add runtime checks.  Unit tests are
> > > great to assert those.
>
> > > Fact is:  almost all user data from the external words comes into
> > > programs as strings.  No typesystem or compiler handles this fact all
> > > that graceful...
>
> > I disagree with your conclusion.  Sure, the data was textual when it
> > was initially read by the program, but that should only be relevant to
> > the in

Re: Example or recomendation of a webserver

[Hidura]

I use Python3.1, TurboGears, webOb, CherryPy and the others don' t work on
Python 3, please somebody recomend me a web framework for Python3.1 I AM
DESPERATE

On Wed, Sep 29, 2010 at 6:08 PM, Hidura  wrote:

> I use Python3.1, TurboGears, webOb, CherryPy and the others don' t work on
> Python 3, please somebody recomend me a web framework for Python3.1 I AM
> DESPERATE
>
> On Wed, Sep 29, 2010 at 6:45 AM, Diez B. Roggisch  wrote:
>
>> Hidura  writes:
>>
>> > I am working on a web project written on Py3k and using mod_wsgi on
>> > the Apache that have to recibes the request client via a xml structure
>> > and i am facing a lot of troubles with the upload files mainly because
>> > i can' t see where they are, so i' ve decide to write my own web
>> > server-django and the others doen' t work for my propouse-, what you
>> > recomend me for start that?
>>
>> not doing it. Reading the HTTP-RFC and the WSGI-PEP. And trying
>>
>>  print environ["wsgi.input"].read()
>>
>> inside your wsgi-script. Then, use webob to wrap the whole WSGI-stuff to
>> have at least a minimum of sensible abstraction.
>>
>> Or simply use Django or TurboGears2, follow the advices in their docs on
>> how to depoly them using mod_wsgi, and be happy.
>>
>> Diez
>>
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>
>
>
> --
> Diego I. Hidalgo D.
>



-- 
Diego I. Hidalgo D.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[RG]

In article 
<996bd4e6-37ff-4a55-8db5-6e7574fbd...@k22g2000prb.googlegroups.com>,
 Squeamizh  wrote:

> On Sep 27, 10:46 am, namekuseijin  wrote:
> > On 27 set, 05:46, TheFlyingDutchman  wrote:
> >
> >
> >
> >
> >
> > > On Sep 27, 12:58 am, p...@informatimago.com (Pascal J. Bourguignon)
> > > wrote:
> > > > RG  writes:
> > > > > In article
> > > > > <7df0eb06-9be1-4c9c-8057-e9fdb7f0b...@q16g2000prf.googlegroups.com>,
> > > > >  TheFlyingDutchman  wrote:
> >
> > > > >> On Sep 22, 10:26 pm, "Scott L. Burson"  wrote:
> > > > >> > This might have been mentioned here before, but I just came across 
> > > > >> > it: a
> > > > >> > 2003 essay by Bruce Eckel on how reliable systems can get built in
> > > > >> > dynamically-typed languages.  It echoes things we've all said 
> > > > >> > here, but
> > > > >> > I think it's interesting because it describes a conversion 
> > > > >> > experience:
> > > > >> > Eckel started out in the strong-typing camp and was won over.
> >
> > > > >> >    https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk
> >
> > > > >> > -- Scott
> >
> > > > >> If you are writing a function to determine the maximum of two 
> > > > >> numbers
> > > > >> passed as arguents in a dynamic typed language, what is the normal
> > > > >> procedure used by Eckel and others to handle someone passing in
> > > > >> invalid values - such as a file handle for one varible and an array
> > > > >> for the other?
> >
> > > > > The normal procedure is to hit such a person over the head with a 
> > > > > stick
> > > > > and shout "FOO".
> >
> > > > Moreover, the functions returning the maximum may be able to work on
> > > > non-numbers, as long as they're comparable.  What's more, there are
> > > > numbers that are NOT comparable by the operator you're thinking about!.
> >
> > > > So to implement your specifications, that function would have to be
> > > > implemented for example as:
> >
> > > > (defmethod lessp ((x real) (y real)) (< x y))
> > > > (defmethod lessp ((x complex) (y complex))
> > > >   (or (< (real-part x) (real-part y))
> > > >       (and (= (real-part x) (real-part y))
> > > >            (< (imag-part x) (imag-part y)
> >
> > > > (defun maximum (a b)
> > > >   (if (lessp a b) b a))
> >
> > > > And then the client of that function could very well add methods:
> >
> > > > (defmethod lessp ((x symbol) (y t)) (lessp (string x) y))
> > > > (defmethod lessp ((x t) (y symbol)) (lessp x (string y)))
> > > > (defmethod lessp ((x string) (y string)) (string< x y))
> >
> > > > and call:
> >
> > > > (maximum 'hello "WORLD") --> "WORLD"
> >
> > > > and who are you to forbid it!?
> >
> > > > --
> > > > __Pascal Bourguignon__                   
> > > >  http://www.informatimago.com/-Hidequoted text -
> >
> > > > - Show quoted text -
> >
> > > in C I can have a function maximum(int a, int b) that will always
> > > work. Never blow up, and never give an invalid answer. If someone
> > > tries to call it incorrectly it is a compile error.
> > > In a dynamic typed language maximum(a, b) can be called with incorrect
> > > datatypes. Even if I make it so it can handle many types as you did
> > > above, it could still be inadvertantly called with a file handle for a
> > > parameter or some other type not provided for. So does Eckel and
> > > others, when they are writing their dynamically typed code advocate
> > > just letting the function blow up or give a bogus answer, or do they
> > > check for valid types passed? If they are checking for valid types it
> > > would seem that any benefits gained by not specifying type are lost by
> > > checking for type. And if they don't check for type it would seem that
> > > their code's error handling is poor.
> >
> > that is a lie.
> >
> > Compilation only makes sure that values provided at compilation-time
> > are of the right datatype.
> >
> > What happens though is that in the real world, pretty much all
> > computation depends on user provided values at runtime.  See where are
> > we heading?
> >
> > this works at compilation time without warnings:
> > int m=numbermax( 2, 6 );
> >
> > this too:
> > int a, b, m;
> > scanf( "%d", &a );
> > scanf( "%d", &b );
> > m=numbermax( a, b );
> >
> > no compiler issues, but will not work just as much as in python if
> > user provides "foo" and "bar" for a and b... fail.
> >
> > What you do if you're feeling insecure and paranoid?  Just what
> > dynamically typed languages do:  add runtime checks.  Unit tests are
> > great to assert those.
> >
> > Fact is:  almost all user data from the external words comes into
> > programs as strings.  No typesystem or compiler handles this fact all
> > that graceful...
> 
> I disagree with your conclusion.  Sure, the data was textual when it
> was initially read by the program, but that should only be relevant to
> the input processing code.  The data is likely converted to some
> internal representation immediately after it is read and validated,
> and in a sanely-designed program, it maintains this repre

Re: list problem...

[Rog]

On Wed, 29 Sep 2010 05:52:32 -0700, bruno.desthuilli...@gmail.com wrote:

> On 29 sep, 14:17, Steven D'Aprano 
> wrote:
>> On Tue, 28 Sep 2010 20:11:51 +0100, Rog wrote:
>> > On Tue, 28 Sep 2010 11:59:08 -0700, geremy condra wrote:
>>
>> >> On Tue, Sep 28, 2010 at 11:44 AM, Rog  wrote:
>> >>> Hi all,
>> >>> Have been grappling with a list problem for hours... a = [2, 3, 4,
>> >>> 5,.]
>> >>> b = [4, 8, 2, 6,.]
>> >>> Basicly I am trying to place a[0], b[0] in a seperate list IF a[2]
>> >>> and b[2] is present.
>> >>> I have tried sets, zip etc with no success. I am tackling Euler
>> >>> projects with Python 3.1, with minimal knowledge, and having to
>> >>> tackle the language as I progress. Enjoyable frustration  :)
>>
>> >> I'm not clear on what your actual problem is, could you restate it?
>>
>> >> It sounds like you want to copy the ith element out of a and b into
>> >> some other list- call it c- when the (i+2)th element meets some
>> >> condition. What's the condition?
>>
>> >> Geremy Condra
>>
>> > The condition is that the i-th element is inverted, but not equal. eg
>> > 4,2 - 2,4 , 34,5 - 5,34 etc.
>> > Hope that is clearer.
>>
>> Clear as mud.
>>
>> Perhaps you should given an example. Given input
>>
>> a = [2, 3, 4, 5, 6, 7]
>> b = [4, 8, 2, 6, 10, 42]
>>
>> what output are you expecting,
> 
> AFAICT, the OP expects [2, 4] in this case, but it's not clear what he'd
> expect for let's say:
> 
> a = [2, 3, 21, 4, 5, 6, 7]
> b = [4, 8, 22, 2, 6, 10, 42]
> 
> (the 'reversed' pair is at i+3, not i+2)
> 
> or
> 
> a = [0, 2, 3, 4, 5, 6, 7]
> b = [3, 4, 8, 2, 6, 10, 42]
> 
> (the first pair is at pos 1, not 0)
> 
> or
> 
> a = [2, 3, 4, 8, 6, 7]
> b = [4, 8, 2, 3, 10, 42]
> 
> (there's a second 'non-reversed/reversed' match at positions resp. 1 & 3)


It is true that I would have needed any 'non-reversed/reversed' pairs,
these would have been the amicable pairs I was looking for.
The method to recognise them eluded me. Eyes are not good enough  :)
I have now joined Python-List and will follow the correct route.
I have used a method suggested that has made the problem redundant,
though it will bug me from now on.

g = []

def divsum(n):
return sum(i for i in range(1, n) if not n % i)

for x in range(1, 2, -1):
c = divsum(x)
v = divsum(c)
if v == x and v != c:
g.append(divsum(x))
else:
continue

print(sum(g)) 

-- 
Rog
http://www.rog.pynguins.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: (and scheme lisp) x Python and modern langs [was Re: gossip, Guy Steel, Lojban, Racket]

[Ian Kelly]

On Wed, Sep 29, 2010 at 2:46 PM, Xah Lee  wrote:

> what's your basis in saying that “list comprehension” is intuitive?
>
> any statics, survery, research, references you have to cite?
>
> to put this in context, are you saying that lambda, is also intuitive?
> “let” is intuitive? “for” is intuitive? “when” is intuitive? I mean,
> give your evaluation of some common computer language termilogies, and
> tell us which you think are good and which are bad, so we have some
> context to judge your claim.
>
> For example, let us know, in your view, how good are terms: currying,
> lisp1 lisp2, tail recursion, closure, subroutine, command, object. Or,
> perhaps expound on the comparative merits and meaning on the terms
> module vs package vs add-on vs library. I would like to see your view
> on this with at least few paragraphs of analysis on each. If you, say,
> write a essay that's at least 1k words on this topic, then we all can
> make some judgement of your familiarity and understanding in this
> area.
>

Have you actually written an essay on this topic of the sort that you are
requesting here?  I googled your site, but all I could find was your
Perl-Python tutorial in which you simply stated that "This construct has
acquired a [sic] incomprehensible name 'list comprehension' in computing
industry and academia."

The obvious pun aside, I don't understand why you find the name to be
incomprehensible.  All it means is that the list is being defined by
comprehension (i.e. intension) in the logical sense, as opposed to the more
common extensive definition (e.g. myList = [1, 2, 3]).  The suggestion that
this nomenclature is any more obscure than "lambda", in either origin or
industry, is dubious to me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: (and scheme lisp) x Python and modern langs [was Re: gossip, Guy Steel, Lojban, Racket]

[Xah Lee]

On Sep 29, 11:02 am, namekuseijin  wrote:
> On 28 set, 19:38, Xah Lee  wrote:
>
> > • “list comprehension” is a very bad jargon; thus harmful to
> > functional programing or programing in general. Being a bad jargon, it
> > encourage mis-communication, mis-understanding.
>
> I disagree:  it is a quite intuitive term to describe what the
> expression does.

what's your basis in saying that “list comprehension” is intuitive?

any statics, survery, research, references you have to cite?

to put this in context, are you saying that lambda, is also intuitive?
“let” is intuitive? “for” is intuitive? “when” is intuitive? I mean,
give your evaluation of some common computer language termilogies, and
tell us which you think are good and which are bad, so we have some
context to judge your claim.

For example, let us know, in your view, how good are terms: currying,
lisp1 lisp2, tail recursion, closure, subroutine, command, object. Or,
perhaps expound on the comparative merits and meaning on the terms
module vs package vs add-on vs library. I would like to see your view
on this with at least few paragraphs of analysis on each. If you, say,
write a essay that's at least 1k words on this topic, then we all can
make some judgement of your familiarity and understanding in this
area.

Also, “being intuitive” is not the only aspect to consider whether a
term is good or bad. For example, emacs's uses the term “frame”. It's
quite intuitive, because frame is a common english word, everyone
understands. You know, door frame, window frame, picture frame, are
all analogous to emacs's “frame” on a computer. However, by some turn
of history, in computer software we call such as “window” now, and by
happance the term “window” also has a technical meaning in emacs, what
we call “split window” or “pane” today. So, in emacs, the term “frame”
and “window” is confusing, because emacs's “frame” is what we call
“window”, while emacs's “window” is what me might call a pane of a
split window. So here, is a example, that even when a term is
intuitive, it can still be bad.

as another example, common understanding by the target group the term
is to be used is also a important aspect. For example, the term
“lambda”, which is a name of greek char, does not convey well what we
use it for. The word's meaning by itself has no connection to the
concept of function. The char happens to be used by a logician as a
shorthand notation in his study of what's called “lambda
calculus” (the “calculus” part is basically 1700's terminology for a
systematic science, especially related to mechanical reasoning).
However, the term “lambda” used in this way in computer science and
programing has been long and wide, around 50 years in recent history
(and more back if we trace origins). So, because of established use,
here it may decrease the level of what we might think of it as a bad
jargon, by the fact that it already become a standard usage or
understanding. Even still, note that just because a term has establish
use, if  the term itself is very bad in many other aspects, it may
still warrant a need for change. For one example of a reason, the
argon will be a learning curve problem for all new generations.

You see, when you judge a terminology, you have to consider many
aspects. It is quite involved. When judging a jargon, some question
you might ask are:

• does the jargon convey its meaning by the word itself? (i.e. whether
the jargon as a word is effective in communication)

• how long has been the jargon in use?

• do people in the community understand the jargon? (e.g. what
percentage)

each of these sample questions can get quite involved. For example, it
calls for expertise in linguistics (many sub-fields are relevant:
pragmatics, history of language, etymology), practical experience in
the field (programing or computer science), educational expertise
(e.g. educators, professors, programing book authors/teachers),
scientific survey, social science of communication...

also, you may not know, there are bodies of professional scientists
who work on terminologies for publication. It is not something like “O
think it's good, becus it is intuitive to me.”.

I wrote about 14 essays on various jargons in past decade. You can
find them on my site.

i removed your arguments on other parts about “list comprehension”,
because i didn't find them valuable. (barely read them) However, i
appreciate your inputs on the “do” in Scheme lisp has a functional
usage, and some other misc chat info from the beginning of this thread
on comp.lang.lisp.

 Xah ∑ xahlee.org ☄
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Certificate validation with HTTPSConnection

[John Nagle]

On 9/29/2010 1:18 PM, Ned Deily wrote:

In article,
  Velko Ivanov  wrote:


I've always wandered why HTTPSConnection does not validate
certificates?

It is fairly simple to use the SSL socket's validation:

[...]

Perhaps you can write up your example as a documentation patch to the
http.client documentation page and submit it to the Python bug tracker
(http://bugs.python.org/).


We've been through this.  Too many times.

http://bugs.python.org/issue1114345
(2005: Broken in Python 2.2, eventually fixed)

http://www.justinsamuel.com/2008/12/25/the-importance-of-validating-ssl-certificates/
(2008: Why this matters)

http://www.mail-archive.com/python-list@python.org/msg281736.html
(2010: Broken in new Python 2.6 SSL module.)

http://bugs.python.org/issue1589
(2010: Developer "Bill Jansen" in denial, others disagree.
Currently being debated.  See bug tracker.)

The really stupid thing about the current SSL module is that it
accepts a file of root certificates as a parameter, but ignores it.
So it creates the illusion of security without providing it.
As someone pointed out, the current SSL module "lets you talk
encrypted to your attacker".

John Nagle

--
http://mail.python.org/mailman/listinfo/python-list

Re: File holes in Linux

[Grant Edwards]

On 2010-09-29, Ned Deily  wrote:
>,
>  Tom Potts  wrote:
>> Hi, all.  I'm not sure if this is a bug report, a feature request or what,
>> so I'm posting it here first to see what people make of it.  I was copying
>> over a large number of files using shutil, and I noticed that the final
>> files were taking up a lot more space than the originals; a bit more
>> investigation showed that files with a positive nominal filesize which
>> originally took up 0 blocks were now taking up the full amount.  It seems
>> that Python does not write back file holes as it should; here is a simple
>> program to illustrate:
>>   data = '\0' * 100
>>   file = open('filehole.test', 'wb')
>>   file.write(data)
>>   file.close()
>> A quick `ls -sl filehole.test' will show that the created file actually
>> takes up about 980k, rather than the 0 bytes expected.
>
> I would expect the file size to be 980k in that case.  AFAIK, simply 
> writing null bytes doesn't automatically create a sparse file on Unix-y 
> systems.

Correct.  As Ned says, you create holes by seeking past the end of the
file before writing data, not by writing 0x00 bytes.  Here's a
demonstration:

Writing 0x00 values:

  $ dd if=/dev/zero of=foo1 bs=1M count=10  
  10+0 records in
  10+0 records out
  10485760 bytes (10 MB) copied, 0.0315967 s, 332 MB/s

  $ ls -l foo1
  -rw-r--r-- 1 grante users 10485760 Sep 29 15:32 foo1

  $ du -s foo1
  10256   foo1

Seeking, then write a single byte:
  
  $ dd if=/dev/zero of=foo2 bs=1 count=1 seek=10485759
  1+0 records in
  1+0 records out
  1 byte (1 B) copied, 8.3075e-05 s, 12.0 kB/s
  
  $ ls -l foo2
  -rw-r--r-- 1 grante users 10485760 Sep 29 15:35 foo2

  $ du -s foo2
  16  foo2


-- 
Grant Edwards   grant.b.edwardsYow! Please come home with
  at   me ... I have Tylenol!!
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: File holes in Linux

[Christian Heimes]

Am 29.09.2010 11:05, schrieb Tom Potts:
> A quick `ls -sl filehole.test' will show that the created file actually
> takes up about 980k, rather than the 0 bytes expected.
> 
> If anyone can let me know if this is indeed a bug or feature request, how to
> get around it, or where to take it next, I'd really appreciate it.

It's not a bug in Python. You simply misunderstand how sparse files are
created. When you write null bytes to a file each null byte takes up
space on the file system, too. In order to create a hole, you have to
set the file handler's position beyond the file's end.

>>> with open("sparse", "w") as fh:
... fh.seek(1000**3)
... fh.write("data")
...

$  ls -l --si sparse
-rw-r--r-- 1 heimes heimes 1,1G 2010-09-29 22:25 sparse
$ ls -s sparse
4 sparse
$ du sparse
4   sparse

Christian

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Certificate validation with HTTPSConnection

[Ned Deily]

In article ,
 Velko Ivanov  wrote:

> I've always wandered why HTTPSConnection does not validate
> certificates? 
> 
> It is fairly simple to use the SSL socket's validation:
[...]

Perhaps you can write up your example as a documentation patch to the 
http.client documentation page and submit it to the Python bug tracker 
(http://bugs.python.org/).

-- 
 Ned Deily,
 n...@acm.org

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: File holes in Linux

[Ned Deily]

In article 
,
 Tom Potts  wrote:
> Hi, all.  I'm not sure if this is a bug report, a feature request or what,
> so I'm posting it here first to see what people make of it.  I was copying
> over a large number of files using shutil, and I noticed that the final
> files were taking up a lot more space than the originals; a bit more
> investigation showed that files with a positive nominal filesize which
> originally took up 0 blocks were now taking up the full amount.  It seems
> that Python does not write back file holes as it should; here is a simple
> program to illustrate:
>   data = '\0' * 100
>   file = open('filehole.test', 'wb')
>   file.write(data)
>   file.close()
> A quick `ls -sl filehole.test' will show that the created file actually
> takes up about 980k, rather than the 0 bytes expected.

I would expect the file size to be 980k in that case.  AFAIK, simply 
writing null bytes doesn't automatically create a sparse file on Unix-y 
systems.  Generally, on file systems that support it, files become 
sparse when you don't write to certain parts of it, i.e. by using 
lseek(2) to position forward past the end of the file when writing, 
thereby implying that the intermediate blocks should be treated as zero 
when reading.  Only files on certain file systems on certain platforms 
support operations like that.  Python makes no claim to do that 
optimization in either its lower-level i/o routines or in the shutil 
module.  The latter's copyfile just copies bytes from input to output.  
If you want to always preserve sparse files, you could use the GNU cp 
routine with --sparse=always.  If you look at its code, you see that it 
checks for all-zero blocks when copying and then uses lseek to skip over 
them when writing.  Something like that could be added to shutil, with 
the necessary tests for which platforms support it.  If you are 
interested in adding that feature, you could write a patch and open a 
feature request on the Python bug tracker (http://bugs.python.org/).  
It's not likely to progress without a supplied patch and even then maybe 
not.

-- 
 Ned Deily,
 n...@acm.org

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Determine sockets in use by python

[Jim Mellander]

Hi Gary:

Certainly not windows  I'm developing on OS/X but for production
probably Linux and FreeBSD

(I'm hoping for something a bit more portable than running 'lsof' and
parsing the output, but appreciate any/all advice)

On Wed, Sep 29, 2010 at 11:05 AM, Gary Herron  wrote:
> On 09/29/2010 09:50 AM, Jim Mellander wrote:
>>
>> Hi:
>>
>> I'm a newbie to python, although not to programming.  Briefly, I am
>> using a binding to an external library used for communication in a
>> client-server context, with the server in python.  Typically, I would
>> set this up with event callbacks, and then enter a select loop, which,
>> most the time idles and processes input events when the socket shows
>> activity, kinda like:
>>
>> while True:
>>     socket.select((my_socket),(),())
>>     process_event()
>>
>> Unfortunately, the API does not expose the socket to the script level,
>> and the developer recommends a busy loop:
>>
>> while True:
>>     sleep(1)
>>     process_event()
>>
>> which I hope to avoid, for many reasons.  If the socket can be exposed
>> to the script level, then the problem would be solved.
>>
>> Failing that, it would be nice to be able to pythonically determine
>> the sockets in use and select on those.  Does anyone have any
>> suggestions on how to proceed?
>>
>> Thanks in advance
>>
>
> It's certain that any answer to this will depend on which operating system
> you are using.  So do tell: What OS?
>
> --
> Gary Herron, PhD.
> Department of Computer Science
> DigiPen Institute of Technology
> (425) 895-4418
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Squeamizh]

On Sep 27, 10:46 am, namekuseijin  wrote:
> On 27 set, 05:46, TheFlyingDutchman  wrote:
>
>
>
>
>
> > On Sep 27, 12:58 am, p...@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> > > RG  writes:
> > > > In article
> > > > <7df0eb06-9be1-4c9c-8057-e9fdb7f0b...@q16g2000prf.googlegroups.com>,
> > > >  TheFlyingDutchman  wrote:
>
> > > >> On Sep 22, 10:26 pm, "Scott L. Burson"  wrote:
> > > >> > This might have been mentioned here before, but I just came across 
> > > >> > it: a
> > > >> > 2003 essay by Bruce Eckel on how reliable systems can get built in
> > > >> > dynamically-typed languages.  It echoes things we've all said here, 
> > > >> > but
> > > >> > I think it's interesting because it describes a conversion 
> > > >> > experience:
> > > >> > Eckel started out in the strong-typing camp and was won over.
>
> > > >> >    https://docs.google.com/View?id=dcsvntt2_25wpjvbbhk
>
> > > >> > -- Scott
>
> > > >> If you are writing a function to determine the maximum of two numbers
> > > >> passed as arguents in a dynamic typed language, what is the normal
> > > >> procedure used by Eckel and others to handle someone passing in
> > > >> invalid values - such as a file handle for one varible and an array
> > > >> for the other?
>
> > > > The normal procedure is to hit such a person over the head with a stick
> > > > and shout "FOO".
>
> > > Moreover, the functions returning the maximum may be able to work on
> > > non-numbers, as long as they're comparable.  What's more, there are
> > > numbers that are NOT comparable by the operator you're thinking about!.
>
> > > So to implement your specifications, that function would have to be
> > > implemented for example as:
>
> > > (defmethod lessp ((x real) (y real)) (< x y))
> > > (defmethod lessp ((x complex) (y complex))
> > >   (or (< (real-part x) (real-part y))
> > >       (and (= (real-part x) (real-part y))
> > >            (< (imag-part x) (imag-part y)
>
> > > (defun maximum (a b)
> > >   (if (lessp a b) b a))
>
> > > And then the client of that function could very well add methods:
>
> > > (defmethod lessp ((x symbol) (y t)) (lessp (string x) y))
> > > (defmethod lessp ((x t) (y symbol)) (lessp x (string y)))
> > > (defmethod lessp ((x string) (y string)) (string< x y))
>
> > > and call:
>
> > > (maximum 'hello "WORLD") --> "WORLD"
>
> > > and who are you to forbid it!?
>
> > > --
> > > __Pascal Bourguignon__                    
> > > http://www.informatimago.com/-Hidequoted text -
>
> > > - Show quoted text -
>
> > in C I can have a function maximum(int a, int b) that will always
> > work. Never blow up, and never give an invalid answer. If someone
> > tries to call it incorrectly it is a compile error.
> > In a dynamic typed language maximum(a, b) can be called with incorrect
> > datatypes. Even if I make it so it can handle many types as you did
> > above, it could still be inadvertantly called with a file handle for a
> > parameter or some other type not provided for. So does Eckel and
> > others, when they are writing their dynamically typed code advocate
> > just letting the function blow up or give a bogus answer, or do they
> > check for valid types passed? If they are checking for valid types it
> > would seem that any benefits gained by not specifying type are lost by
> > checking for type. And if they don't check for type it would seem that
> > their code's error handling is poor.
>
> that is a lie.
>
> Compilation only makes sure that values provided at compilation-time
> are of the right datatype.
>
> What happens though is that in the real world, pretty much all
> computation depends on user provided values at runtime.  See where are
> we heading?
>
> this works at compilation time without warnings:
> int m=numbermax( 2, 6 );
>
> this too:
> int a, b, m;
> scanf( "%d", &a );
> scanf( "%d", &b );
> m=numbermax( a, b );
>
> no compiler issues, but will not work just as much as in python if
> user provides "foo" and "bar" for a and b... fail.
>
> What you do if you're feeling insecure and paranoid?  Just what
> dynamically typed languages do:  add runtime checks.  Unit tests are
> great to assert those.
>
> Fact is:  almost all user data from the external words comes into
> programs as strings.  No typesystem or compiler handles this fact all
> that graceful...

I disagree with your conclusion.  Sure, the data was textual when it
was initially read by the program, but that should only be relevant to
the input processing code.  The data is likely converted to some
internal representation immediately after it is read and validated,
and in a sanely-designed program, it maintains this representation
throughout its life time.  If the structure of some data needs to
change during development, the compiler of a statically-typed language
will automatically tell you about any client code that was not updated
to account for the change.  Dynamically typed languages do not provide
this assurance.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: System idle time under Linux

[Grant Edwards]

On 2010-09-29, Hugo L?veill?  wrote:

> One I am looking for, is time since last user mouse or keyboard action.
> So I guess I am looking for the exact same thing a screensaver is
> looking for

Oh.  That's not what "idle" generally means in a Unix/Linux context,
so you can disregard previous answers involving /proc/stat et al.

-- 
Grant Edwards   grant.b.edwardsYow! It's some people
  at   inside the wall!  This is
  gmail.combetter than mopping!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: System idle time under Linux

[Seebs]

On 2010-09-29, Hugo L?veill?  wrote:
> One I am looking for, is time since last user mouse or keyboard action.
> So I guess I am looking for the exact same thing a screensaver is
> looking for

You can probably get it from X somehow, but... Basically, be aware that
it is entirely possible for a Linux user to invoke python scripts in an
enviromnent where this information cannot be obtained, and may not even
meaningfully exist.

So be sure you fail back gracefully when that happens.  Decide in advance
what you will infer from "there is no way to obtain this information".  Also
provide an override.  Imagine how helpful it would be to a user to have your
script act as though the user had gone idle based on what some OTHER user
was doing!

-s
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: About __class__ of an int literal

[Terry Reedy]

On 9/29/2010 8:34 AM, Hrvoje Niksic wrote:

Steven D'Aprano  writes:


On Wed, 29 Sep 2010 02:20:55 +0100, MRAB wrote:


On 29/09/2010 01:19, Terry Reedy wrote:



A person using instances of a class should seldom use special names
directly. They are, in a sense, implementation details, even if
documented. The idiom "if __name__ == '__main__':" is an exception.


__file__ is another exception.



As are __iter__, __next__, __add__, __dict__, and, yes, __class__, to
say nothing of all the other special methods.


I strongly disagree.


I think by "person using instances of a class" Terry referred to the
user of a class as opposed to the implementor.


Yes.


 In that sense the user
should be calling iter(foo) instead of foo.__iter__(), next(foo) instead
of foo.__next__(), and foo+bar instead of foo.__add__(bar).


Yes. Guido added iter() and next() to the list of built-in functions, 
even though they seem reduncant.. I believe it is his intention that the 
use of special names outside of class statements should be fairly rare.


If I remember right, in the old, pre-2.2 system that separated built-in 
types and user-written classes, the builtins did not have accessible 
special method attributes. They are only for customizing user classes. 
So one could not have generically written foo.__add__(bar). 
Special-method attribute were added to builtins so that they could be 
inherited (or replaced) by user-written subclasses, not so that one 
could replace normal syntax.


>  Direct

calls to special-name methods, such as __len__, often indicate that the
programmer hasn't grasped how those methods are intended to be used in
Python.


Right. That fact that *Python* interpreters implement syntax with 
special methods is an implementation detail of the *language*. The 
importance is that it allow *writers* of new classes to rather easily 
imitate built-in classes so that their classes seamlessly plug into the 
syntax.


--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: System idle time under Linux

[Hugo Léveillé]

Good point

One I am looking for, is time since last user mouse or keyboard action.
So I guess I am looking for the exact same thing a screensaver is
looking for



On Wed, 29 Sep 2010 17:27 +, "Seebs" 
wrote:
> On 2010-09-29, Hugo L?veill?  wrote:
> > I have found it for windows and mac, but no luck under linux. Any idea?
> 
> I don't think it's semantically well-defined.  What makes a system
> "idle"?
> 
> Is the machine in my basement idle?  I don't think anyone's touched the
> keyboard in a week, but it's spent a big chunk of that time with 100% CPU
> load across all eight processors, and I was running a bunch of work on
> it yesterday, including interactive sessions.
> 
> Windows and Mac systems *typically* have a well-defined "console" on
> which
> the primary user is active... But as a counterexample, my news reader is
> actually running on an OS X box that's about fifty feet from me, which I
> connect to via ssh.
> 
> I would be very curious to see whether your test for "system idle time"
> would realize that the machine I'm currently working on is actively in
> use,
> even though I don't think the console is even logged in...
> 
> Basically, I can't help you, but I can tell you that you are quite
> possibly
> asking the wrong question.
> 
> -s
> -- 
> Copyright 2010, all wrongs reversed.  Peter Seebach /
> usenet-nos...@seebs.net
> http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
> http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
> I am not speaking for my employer, although they do rent some of my
> opinions.
> -- 
> http://mail.python.org/mailman/listinfo/python-list
> 


-- 
  Hugo Léveillé
  hu...@fastmail.net

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: utf-8 and ctypes

[Brendan Miller]

2010/9/29 Lawrence D'Oliveiro :
> In message , Brendan
> Miller wrote:
>
>> It seems that characters not in the ascii subset of UTF-8 are
>> discarded by c_char_p during the conversion ...
>
> Not a chance.
>
>> ... or at least they don't print out when I go to print the string.
>
> So it seems there’s a problem on the printing side. What happens when you
> construct a UTF-8-encoded string directly in Python and try printing it the
> same way?

Doing this seems to confirm something is broken in ctypes w.r.t. UTF-8...

if I enter:
str = "日本語のテスト"

Then:
print str
日本語のテスト

However, when I create a string buffer, pass it into my c++ code, and
write the same UTF-8 string into it, python seems to discard pretty
much all the text. The same code works for pure ascii strings.

Python code:
_std_string_size = _lib_mbxclient.std_string_size
_std_string_size.restype = c_long
_std_string_size.argtypes = [c_void_p]

_std_string_copy = _lib_mbxclient.std_string_copy
_std_string_copy.restype = None
_std_string_copy.argtypes = [c_void_p, POINTER(c_char)]

# This function works for ascii, but breaks on strings with UTF-8!
def std_string_to_string(str_ptr):
buf = create_string_buffer(_std_string_size(str_ptr))
_std_string_copy(str_ptr, buf)
return buf.raw

C++ code:

extern "C"
long std_string_size(string* str)
{
return str->size();
}

extern "C"
void std_string_copy(string* str, char* buf)
{
std::copy(str->begin(), str->end(), buf);
}
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[George Neuner]

On Wed, 29 Sep 2010 12:40:58 +0200, p...@informatimago.com (Pascal J.
Bourguignon) wrote:

>George Neuner  writes:
>
>> On Tue, 28 Sep 2010 12:15:07 -0700, Keith Thompson 
>> wrote:
>>
>>>George Neuner  writes:
 On 28 Sep 2010 12:42:40 GMT, Albert van der Horst
  wrote:
>I would say the dimensional checking is underrated. It must be
>complemented with a hard and fast rule about only using standard
>(SI) units internally.
>
>Oil output internal : m^3/sec
>Oil output printed:  kbarrels/day

 "barrel" is not an SI unit.
>>>
>>>He didn't say it was.  Internal calculations are done in SI units (in
>>>this case, m^3/sec); on output, the internal units can be converted to
>>>whatever is convenient.
>>
>> That's true.  But it is a situation where the conversion to SI units
>> loses precision and therefore probably shouldn't be done.
>>
>>>
  And when speaking about oil there isn't
 even a simple conversion.

   42 US gallons  ?  34.9723 imp gal  ?  158.9873 L

 [In case those marks don't render, they are meant to be the
 double-tilda sign meaning "approximately equal".]
>>>
>>>There are multiple different kinds of "barrels", but "barrels of oil"
>>>are (consistently, as far as I know) defined as 42 US liquid gallons.
>>>A US liquid gallon is, by definition, 231 cubic inches; an inch
>>>is, by definition, 0.0254 meter.  So a barrel of oil is *exactly*
>>>0.158987294928 m^3, and 1 m^3/sec is exactly 13.7365022817792
>>>kbarrels/day.  (Please feel free to check my math.)  That's
>>>admittedly a lot of digits, but there's no need for approximations
>>>(unless they're imposed by the numeric representation you're using).
>>
>> I don't care to check it ... the fact that the SI unit involves 12
>> decimal places whereas the imperial unit involves 3 tells me the
>> conversion probably shouldn't be done in a program that wants
>> accuracy.
>
>
>Because perhaps you're thinking that oil is sent over the oceans, and
>sold retails in barrils of 42 gallons?
>
>Actually, when I buy oil, it's from a pump that's graduated in liters!
>
>It comes from trucks with citerns containing 24 m³.
>
>And these trucks get it from reservoirs of 23,850 m³.
>
>"Tankers move approximately 2,000,000,000 metric tons" says the English
>Wikipedia page...
>
>
>
>Now perhaps it all depends on whether you buy your oil from Total or
>from Texaco, but in my opinion, you're forgetting something: the last
>drop.  You never get exactly 42 gallons of oil, there's always a little
>drop more or less, so what you get is perhaps 158.987 liter or
>41.221 US gallons, or even 158.98 liter = 41.9980729 US gallons,
>where you need more significant digits.


No.  I'm just reacting to the "significant figures" issue.   Real
world issues like US vs Eurozone and measurement error aside - and
without implying anyone here - many people seem to forget that
multiplying significant figures doesn't add them, and results to 12
decimal places are not necessarily any more accurate than results to 2
decimal places.

It makes sense to break macro barrel into micro units only when
necessary.  When a refinery purchases 500,000 barrels, it is charged a
barrel price, not some multiple of gallon or liter price and
regardless of drop over/under.  The refinery's process is continuous
and it needs a delivery if it has less than 20,000 barrels - so the
current reserve figure of 174,092 barrels is as accurate as is needed
(they need to order by tomorrow because delivery will take 10 days).
OTOH, because the refinery sells product to commercial vendors of
gasoline/petrol and heating oil in gallons or liters, it does makes
sense to track inventory and sales in (large multiples of) those
units.

Similarly, converting everything to m³ simply because you can does not
make sense.  When talking about the natural gas reserve of the United
States, the figures are given in Km³ - a few thousand m³ either way is
irrelevant.

George
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[MRAB]

On 29/09/2010 18:54, Thomas A. Russ wrote:

George Neuner  writes:


On Tue, 28 Sep 2010 12:15:07 -0700, Keith Thompson
wrote:

He didn't say it was.  Internal calculations are done in SI units (in
this case, m^3/sec); on output, the internal units can be converted to
whatever is convenient.


That's true.  But it is a situation where the conversion to SI units
loses precision and therefore probably shouldn't be done.


I suppose that one has to choose between two fundamental designs for any
computational system of units.  One can either store the results
internally in a canonical form, which generally means an internal
representation in SI units.  Then all calculations are performed using
the interal units representation and conversion happens only on input or
output.

Or one can store the values in their original input form, and perform
conversions on the fly during calculations.  For calculations one will
still need to have some canonical representation for cases where the
result value doesn't have a preferred unit provided.  For internal
calculations this will often be the case.

Now whether one will necessarily have a loss of precision depends on
whether the conversion factors are exact or approximations.  As long as
the factors are exact, one can have the internal representation be exact
as well.  One method would be to use something like the Commmon Lisp
rational numbers or the Gnu mp library.

And a representation where one preserves the "preferred" unit for
display purposes based on the original data as entered is also nice.
Roman Cunis' Common Lisp library does that, and with the use of rational
numbers for storing values and conversion factors allows one to do nice
things like make sure that

 30mph * 3h = 90mi

even when the internal representation is in SI units (m/s, s, m).


You could compare it to handling strings, where Unicode is used
internally and the encoding can be preserved for when you want to
output.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Determine sockets in use by python

[Gary Herron]

On 09/29/2010 09:50 AM, Jim Mellander wrote:

Hi:

I'm a newbie to python, although not to programming.  Briefly, I am
using a binding to an external library used for communication in a
client-server context, with the server in python.  Typically, I would
set this up with event callbacks, and then enter a select loop, which,
most the time idles and processes input events when the socket shows
activity, kinda like:

while True:
 socket.select((my_socket),(),())
 process_event()

Unfortunately, the API does not expose the socket to the script level,
and the developer recommends a busy loop:

while True:
 sleep(1)
 process_event()

which I hope to avoid, for many reasons.  If the socket can be exposed
to the script level, then the problem would be solved.

Failing that, it would be nice to be able to pythonically determine
the sockets in use and select on those.  Does anyone have any
suggestions on how to proceed?

Thanks in advance
   


It's certain that any answer to this will depend on which operating 
system you are using.  So do tell: What OS?


--
Gary Herron, PhD.
Department of Computer Science
DigiPen Institute of Technology
(425) 895-4418

--
http://mail.python.org/mailman/listinfo/python-list

Re: (and scheme lisp) x Python and modern langs [was Re: gossip, Guy Steel, Lojban, Racket]

[namekuseijin]

On 28 set, 19:38, Xah Lee  wrote:
> • “list comprehension” is a very bad jargon; thus harmful to
> functional programing or programing in general. Being a bad jargon, it
> encourage mis-communication, mis-understanding.

I disagree:  it is a quite intuitive term to describe what the
expression does.

> • “list comprehension” is a redundant concept in programing. The
> concept is of historical interest. e.g. when people talk about the
> history of computer languages. The LC can simply be filter(map(func,
> list), predicate).

I agree it is redundant.  Like pretty much all syntax:  all one needs
is a way to define functions and to apply function to arguments (or
assignment and pre-defined loops for imperative folks).  Syntax may
still be more convenient, though.

Which is strange since you were an ardent syntax lover a few
iterations ago.

> • The special syntax of “list comprehension” as it exists in many
> langs, are not necessary. It can simply be a plain function, e.g
> LC(function, list, filter).

I disagree.  Syntax may be redundant, but it is there to be
convenient.

I'll quote it again:
"For instance, this is far more convenient:
[x+1 for x in [1,2,3,4,5] if x%2==0]
than this:
map(lambda x:x+1,filter(lambda x:x%2==0,[1,2,3,4,5]))

but on the other hand, this is more convenient:
map(inc,filter(evenp,[1,2,3,4,5]))

(ignoring the lines of code for inc and evenp, of course.  But as
long
as they are used in many parts, it *is* more convenient)

In short, list comprehensions are useful syntatic expressions
returning lists as long as you don't care for the short functions
used
in them."

> «do syntax does allow for imperative commands to be issued in scheme,
> just like let.  It does not mean it was used in said examples nor that
> do is automatically inherently imperative just because of choice of
> name.  imperative do -> (do (steppers ...) (final-condition? result)
> malign-imperative-code-here ...)»
>
> i don't think your argument is forceful enough.
>
> It appears that by this argument you even say that “let” is not
> functional.

In the case of Lisps, it depends on context:  let is an expression
returning a value, but Lisps are not purely functional languages and
you *may* use imperative statements in the body, resulting in useful
side-effect computations.

That's why I said do is no more imperative than let:  1) because it
*is* let and 2) because Lisps *allow* imperative constructs in the
body of lambdas.  do is not inherently imperative in the same sense
Lisp/Scheme is not inherently imperative:  they allow you to do purely
functional evaluation of expressions but also to tint the computations
with side-effects... your choice.

> So, overall, i consider your argument for “do” in Scheme lisp being
> functional is weak, or trivial. It seems to be a pet peeve.

It is a pet peeve in that you call `do' imperative without arguments
while a few other Schemers call `do' imperative on the basis of
political bickering.  Nobody gives `do' a chance of the base of it
being what it is: a macro transform into let.  Any imperative
programming you do with `do' will get the same effect as if you do the
same imperative programming with let.  Imperative or functional, it's
up to the user, not inherently from any language construct.

> You got
> annoyed because i seem to have ignored it entirely. But i got annoyed
> by you because you don't get the point about what i consider more
> significant opinion on “list comprehension”, which you totally ignored
> and kept at hacking the “do” in Scheme lisp.

It's because I don't think I have much to comment on list
comprehensions other than being useful syntax at times for an
expression returning a list.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Thomas A. Russ]

George Neuner  writes:

> On Tue, 28 Sep 2010 12:15:07 -0700, Keith Thompson 
> wrote:
> >He didn't say it was.  Internal calculations are done in SI units (in
> >this case, m^3/sec); on output, the internal units can be converted to
> >whatever is convenient.
> 
> That's true.  But it is a situation where the conversion to SI units
> loses precision and therefore probably shouldn't be done.

I suppose that one has to choose between two fundamental designs for any
computational system of units.  One can either store the results
internally in a canonical form, which generally means an internal
representation in SI units.  Then all calculations are performed using
the interal units representation and conversion happens only on input or
output.

Or one can store the values in their original input form, and perform
conversions on the fly during calculations.  For calculations one will
still need to have some canonical representation for cases where the
result value doesn't have a preferred unit provided.  For internal
calculations this will often be the case.

Now whether one will necessarily have a loss of precision depends on
whether the conversion factors are exact or approximations.  As long as
the factors are exact, one can have the internal representation be exact
as well.  One method would be to use something like the Commmon Lisp
rational numbers or the Gnu mp library.

And a representation where one preserves the "preferred" unit for
display purposes based on the original data as entered is also nice.
Roman Cunis' Common Lisp library does that, and with the use of rational
numbers for storing values and conversion factors allows one to do nice
things like make sure that

30mph * 3h = 90mi

even when the internal representation is in SI units (m/s, s, m).


-- 
Thomas A. Russ,  USC/Information Sciences Institute
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: System idle time under Linux

[Seebs]

On 2010-09-29, Hugo L?veill?  wrote:
> I have found it for windows and mac, but no luck under linux. Any idea?

I don't think it's semantically well-defined.  What makes a system "idle"?

Is the machine in my basement idle?  I don't think anyone's touched the
keyboard in a week, but it's spent a big chunk of that time with 100% CPU
load across all eight processors, and I was running a bunch of work on
it yesterday, including interactive sessions.

Windows and Mac systems *typically* have a well-defined "console" on which
the primary user is active... But as a counterexample, my news reader is
actually running on an OS X box that's about fifty feet from me, which I
connect to via ssh.

I would be very curious to see whether your test for "system idle time"
would realize that the machine I'm currently working on is actively in use,
even though I don't think the console is even logged in...

Basically, I can't help you, but I can tell you that you are quite possibly
asking the wrong question.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: sequence multiplied by -1

[Seebs]

On 2010-09-29, Lawrence D'Oliveiro  wrote:
> In message , Seebs wrote:
>> Helps, perhaps, that I got exposed to group theory early enough to be used
>> to redefining + and * to be any two operations which have interesting
>> properties ...

> But groups only have one such operation; it???s rings and fields (and number 
> systems) that have two.

They're covered in the same class, therefore, they're part of the same
field (of study, that is).  :P

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: if the else short form

[Seebs]

On 2010-09-29, Tracubik  wrote:
> Hi all,
> I'm studying PyGTK tutorial and i've found this strange form:
>
> button = gtk.Button(("False,", "True,")[fill==True])
>
> the label of button is True if fill==True, is False otherwise.
>
> i have googled for this form but i haven't found nothing, so can any of 
> you pass me any reference/link to this particular if/then/else form?

Oh, what a nasty idiom.

Here's the gimmick.
("False,", "True,")
is a tuple.  That means you can index it.  For instance:
("False,", "True,")[0]
is the string "False,".

So, what is the numeric value of "fill == True"?  Apparently, at least
at the time this was written, it was 0 if fill was not equal to True,
and 1 if fill was equal to True.

Let me say, though, that I'm a C programmer, so I'm coming from a language
where the result of 0-or-1 for test operators is guaranteed, and I still
wouldn't use this in live code.  It's insufficiently legible.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nos...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Supplementing the std lib (Was: partial sums problem)

[Ethan Furman]

kj wrote:

I'm interested in reading people's take on the question and their
way of dealing with those functions they consider worthy of the
standard library.)


Well, I have no functions than I'm lobbying to get into the stdlib, but 
for all those handy-dandy utility functions, decorators, and classes, I 
have a cookbook package that I add them to.  Mine currently looks like this:


cookbook
__init__.py
decorators.py
meters.py
simplegeneric.py
utils.py
collections
__init__.py
NamedTuple.py
RecordType.py
--
http://mail.python.org/mailman/listinfo/python-list

Determine sockets in use by python

[Jim Mellander]

Hi:

I'm a newbie to python, although not to programming.  Briefly, I am
using a binding to an external library used for communication in a
client-server context, with the server in python.  Typically, I would
set this up with event callbacks, and then enter a select loop, which,
most the time idles and processes input events when the socket shows
activity, kinda like:

while True:
socket.select((my_socket),(),())
process_event()

Unfortunately, the API does not expose the socket to the script level,
and the developer recommends a busy loop:

while True:
sleep(1)
process_event()

which I hope to avoid, for many reasons.  If the socket can be exposed
to the script level, then the problem would be solved.

Failing that, it would be nice to be able to pythonically determine
the sockets in use and select on those.  Does anyone have any
suggestions on how to proceed?

Thanks in advance
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python becoming orphaned over ssh

[John Nagle]

On 9/29/2010 7:24 AM, David wrote:

Hi there, I have a strange situation.

If I do this:

1. Make a script /tmp/test.py on a remote server, with this contents:

#!/usr/bin/python
from subprocess import check_call


   Python's signal handling for multithread and multiprocess programs
leaves something to be desired.

John Nagle
--
http://mail.python.org/mailman/listinfo/python-list

Re: bzr 2.2.1 released !

[Sridhar Ratnakumar]

Hi,

It seems that you forgot to update PyPI - which lists 2.1.0rc1 as the latest 
version.

-srid

On 2010-09-28, at 7:20 AM, Vincent Ladeuil wrote:

> The Bazaar team is happy to announce availability of a new
> release of the bzr adaptive version control system.
> Bazaar is part of the GNU system .
> 
> This is a bugfix release which also includes bugfixes from 2.0.6 and
> 2.1.3. None are critical, but upgrading is recommended for all users on
> earlier 2.2 releases.
> 
> Thanks to everyone who contributed patches, suggestions, and
> feedback.
> 
> Bazaar is now available for download from
> 
>  https://launchpad.net/bzr/2.2/2.2.1/
> 
> as a source tarball. Packages are already available for Ubuntu, FreeBSD
> and others. Installers are available for OSX, windows installers should
> be available Really Soon Now (watch the url above where they should pop
> up as soon as they become available).
> 
> bzr 2.2.1
> #
> 
> :2.2.1: 2010-09-17
> 
> This is a bugfix release which also includes bugfixes from 2.0.6 and
> 2.1.3. None are critical, but upgrading is recommended for all users on
> earlier 2.2 releases.
> 
> Bug Fixes
> *
> 
> * Additional merges after an unrelated branch has been merged with its
>  history no longer crash when deleted files are involved.
>  (Vincent Ladeuil, John Arbash Meinel, #375898)
> 
> * ``bzr add SYMLINK/FILE`` now works properly when the symlink points to a
>  previously-unversioned directory within the tree: the directory is
>  marked versioned too.
>  (Martin Pool, #192859)
> 
> * ``bzr commit SYMLINK`` now works, rather than trying to commit the
>  target of the symlink.
>  (Martin Pool, John Arbash Meinel, #128562)
> 
> * ``bzr upgrade`` now creates the ``backup.bzr`` directory with the same
>  permissions as ``.bzr`` directory on a POSIX OS.
>  (Parth Malwankar, #262450)
> 
> * CommitBuilder now uses the committer instead of _config.username to generate
>  the revision-id. (Aaron Bentley, #614404)
> 
> * Configuration files in ``${BZR_HOME}`` are now written in an atomic
>  way which should help avoid problems with concurrent writers.
>  (Vincent Ladeuil, #525571)
> 
> * Cope with Microsoft FTP server that returns reply '250 Directory
>  created' when mkdir succeeds. (Martin Pool, #224373)
> 
> * Don't traceback trying to unversion children files of an already
>  unversioned directory. (Vincent Ladeuil, #494221)
> 
> * Don't traceback when a lockdir's ``held/info`` file is corrupt (e.g.
>  contains only NUL bytes). Instead warn the user, and allow ``bzr
>  break-lock`` to remove it. (Andrew Bennetts, #619872)
> 
> * Fix ``AttributeError on parent.children`` when adding a file under a
>  directory that was a symlink in the previous commit.
>  (Martin Pool, #192859)
> 
> * Fix ``AttributeError: 'NoneType' object has no attribute 'close'`` in
>  ``_close_ssh_proc`` when using ``bzr+ssh://``. This was causing
>  connections to pre-1.6 bzr+ssh servers to fail, and causing warnings on
>  stderr in some other circumstances. (Andrew Bennetts, #633745)
> 
> * Only call ``setlocale`` in the bzr startup script on posix systems. This
>  avoids an issue with the newer windows C runtimes used by Python 2.6 and
>  later which can mangle bytestrings printed to the console.
>  (Martin [gz], #631350)
> 
> * Prevent ``CHKMap.apply_delta`` from generating non-canonical CHK maps,
>  which can result in "missing referenced chk root keys" errors when
>  fetching from repositories with affected revisions.
>  (Andrew Bennetts, #522637)
> 
> * Raise ValueError instead of a string exception.
>  (John Arbash Meinel, #586926)
> 
> * Reduce peak memory by one copy of compressed text.
>  (John Arbash Meinel, #566940)
> 
> * Repositories accessed via a smart server now reject being stacked on a
>  repository in an incompatible format, as is the case when accessing them
>  via other methods. This was causing fetches from those repositories via
>  a smart server (e.g. using ``bzr branch``) to receive invalid data.
>  (Andrew Bennetts, #562380)
> 
> * Selftest with versions of subunit that support ``stopTestRun`` will no 
> longer
>  error. This error was caused by 2.0 not being updated when upstream
>  python merged the end of run patch, which chose ``stopTestRun`` rather than
>  ``done``. (Robert Collins, #571437)
> 
> * Stop ``AttributeError: 'module' object has no attribute 'ElementTree'``
>  being thrown from ``xml_serializer`` on certain cElementTree setups.
>  (Martin [gz], #254278)
> 
> * Upgrading or fetching from a non-rich-root repository to a rich-root
>  repository (e.g. from pack-0.92 to 2a) no longer fails with
>  ``'Inter1and2Helper' object has no attribute 'source_repo'``. This was
>  a regression from Bazaar 2.1. (Andrew Bennetts, #636930)
> 
> * When passing a file to ``UTF8DirReader`` make sure to close the current
>  directory file handle after the chdir fails. Otherwise when passing many
>  filenames into a command line ``bzr status`` we would leak descr

Re: if the else short form

[Andreas Waldenburger]

On Wed, 29 Sep 2010 08:53:17 -0400 Philip Semanchuk
 wrote:

> Does Python make any guarantee that int(True) == 1 and int(False) ==
> 0 will always hold, or are their values an implementation detail?
> 



Booleans (bool)

These represent the truth values False and True. The two objects
representing the values False and True are the only Boolean
objects. The Boolean type is a subtype of the integer type, and
Boolean values behave like the values 0 and 1, respectively, in
almost all contexts, the exception being that when converted to a
string, the strings "False" or "True" are returned, respectively.


/W


-- 
INVALID? DE!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: if the else short form

[Emile van Sebille]

On 9/29/2010 5:53 AM Philip Semanchuk said...


Does Python make any guarantee that int(True) == 1 and int(False) == 0 will 
always hold, or are their values an implementation detail?



I had exactly this same question occur to me yesterday, and yes, I 
believe it does.  From 
http://docs.python.org/reference/datamodel.html#objects-values-and-types


Booleans
These represent the truth values False and True. The two objects 
representing the values False and True are the only Boolean objects. The 
Boolean type is a subtype of plain integers, and Boolean values behave 
like the values 0 and 1, respectively, in almost all contexts, the 
exception being that when converted to a string, the strings "False" or 
"True" are returned, respectively.


Emile

--
http://mail.python.org/mailman/listinfo/python-list

how to test get_special_folder_path()?

[Philip Semanchuk]

Hi all,
The documentation for get_special_folder_path() and friends says that they're 
"available as additional built-in functions in the installation script". 
http://docs.python.org/distutils/builtdist.html#the-postinstallation-script

Does anyone know of a way to play around with these functions outside of a 
post-install script? It's time-consuming to install something just to 
experiment with a single function.

Thanks
Philip
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: System idle time under Linux

[Grant Edwards]

On 2010-09-29, Hugo L?veill?  wrote:

> Sorry, I am not a linux guy. Did not know it was a text file

And the "file" command (the usual way to figure that out) doesn't
appear to be helpful:

  $ file /etc/passwd
  /etc/passwd: ASCII text

[That's helpful]

  $ file /proc/stat 
  /proc/stat: empty

[That's not]  

However, as usual, Google comes to rescue.  The first hit for
"/proc/stat" has a detailed description:

http://www.linuxhowtos.org/System/procstat.htm

-- 
Grant Edwards   grant.b.edwardsYow! My mind is a potato
  at   field ...
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: if the else short form

[Philip Semanchuk]

On Sep 29, 2010, at 7:19 AM, Tom Potts wrote:

> This is just a sneaky shorthand, which is fine if that's what you want, but
> it makes it harder to read.  The reason it works is that 'fill==True' is a
> boolean expression, which evaluates to True or False, but if you force a
> True into being an integer, it will be 1, and a False will become 0.  Try
> writing 'True == 1' on the Python interpreter to see what I mean.  So this
> code snippet is creating a tuple with two elements, and then selecting the
> first if 'fill==True' is False, or 0, and selecting the second if
> 'fill==True' is True, or 1.
> 
> As I say, this kind of coding is absolutely fine, but it makes things harder
> to read and doesn't really save much space.  I wouldn't recommend using this
> kind of style yourself, at least until you're more familiar with programming
> in Python.

Does Python make any guarantee that int(True) == 1 and int(False) == 0 will 
always hold, or are their values an implementation detail?

Thanks
Philip


> On 29 September 2010 11:42, Tracubik  wrote:
> 
>> Hi all,
>> I'm studying PyGTK tutorial and i've found this strange form:
>> 
>> button = gtk.Button(("False,", "True,")[fill==True])
>> 
>> the label of button is True if fill==True, is False otherwise.
>> 
>> i have googled for this form but i haven't found nothing, so can any of
>> you pass me any reference/link to this particular if/then/else form?
>> 
>> thanks
>> Nico
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>> 
> -- 
> http://mail.python.org/mailman/listinfo/python-list

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: System idle time under Linux

[Hugo Léveillé]

Sorry, I am not a linux guy. Did not know it was a text file


On Wed, 29 Sep 2010 14:48 +, "Grant Edwards"
 wrote:
> On 2010-09-29, Hugo L?veill?  wrote:
> >
> > Thanks, will take a closer look on that
> >
> > But to get me started, how would you get, via python, the info from that?
> 
> Good grief.  They're text files.  You open them, you read them,
> you parse the contents for the stuff you want.
> 
> -- 
> Grant Edwards   grant.b.edwardsYow! Did something bad
>   at   happen or am I in a
>   gmail.comdrive-in movie??
> -- 
> http://mail.python.org/mailman/listinfo/python-list
> 


-- 
  Hugo Léveillé
  hu...@fastmail.net

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: System idle time under Linux

[Thomas Jollans]

On Wednesday 29 September 2010, it occurred to Hugo Léveillé to exclaim:
> Thanks, will take a closer look on that
> 
> But to get me started, how would you get, via python, the info from that
> ?

Parse the files. They may be very special files, but they are just files.

> 
> Thanks alot
> 
> 
> On Thu, 30 Sep 2010 02:01 +1300, "Lawrence D'Oliveiro"
> 
>  wrote:
> > /proc/stat or /proc/uptime, depending. See the proc(5) man page.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: System idle time under Linux

[Grant Edwards]

On 2010-09-29, Hugo L?veill?  wrote:
>
> Thanks, will take a closer look on that
>
> But to get me started, how would you get, via python, the info from that?

Good grief.  They're text files.  You open them, you read them,
you parse the contents for the stuff you want.

-- 
Grant Edwards   grant.b.edwardsYow! Did something bad
  at   happen or am I in a
  gmail.comdrive-in movie??
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re: Re: Upload files with wsgi

[hidura]

That is what i get: FieldStorage(None, None, [])

On Sep 29, 2010 8:39am, hid...@gmail.com wrote:

Python3k give me an error doing that.



On Sep 29, 2010 3:55am, Richard Thomas chards...@gmail.com> wrote:
> On Sep 28, 11:31 pm, Hidura hid...@gmail.com> wrote:
>
> > Hello, i have a project on Python3k, and i have a very big problem i
>
> > don' t find how take an upload file i am using the wsgiref lib, and or
>
> > theres any way to connect to the client in order to get the file by
>
> > myself?
>
> >
>
> > Thank you
>
> > Diego Hidalgo.
>
> >
>
> > --
>
> > Enviado desde mi dispositivo móvil
>
> >
>
> > Diego I. Hidalgo D.
>
>
>
> 'wsgiref' doesn't do that part of request handling. You want to use
>
> the 'cgi' module to parse the POST data:  
http://docs.python.org/library/cgi.html

>
>
>
> Remember to set the enctype on your tags to multipart/form-
>
> data.
>
>
>
> Chard.
>
> --
>
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

R: embedding python in macOS 10.6

[tinau...@libero.it]

sorry, my error; in order to achieve what written before, i had to link to the 
libpython2.6.a that i find downloading the surce code.
instead, if I link to the one of the distributed version, i get the following 
error:
missing required architecture x86_64 in file.
i tried to build with the -m32 option,but then to that message, another is 
added for the object file
file was built for i386 which is not the architecture being linked (x86_64)

>Messaggio originale
>Da: tinau...@libero.it
>Data: 29/09/2010 16.06
>A: 
>Ogg: embedding python in macOS 10.6
>
>hi there,
>
>i'm trying to embed python in a c++ code.i'm starting with the example in 
the 
>tutorial.i've problem with setting up the enveiroment.
>I've installed python with the distributed version (i.e., i did not, as a 
>start, build it myself); i added the library where both python.h and 
pyconfig 
>are stored and i linked to libpython2.6.a (which is, in the distributed 
>version, an alias).
>the program builds and links correctely, but if I try to run it, i get the 
>following error:
>
>Could not find platform independent libraries 
>Could not find platform dependent libraries 
>Consider setting $PYTHONHOME to [:]
>'import site' failed; use -v for traceback
>Traceback (most recent call last):
>  File "", line 1, in 
>ImportError: No module named time
>
>what is the problem?
>
>in my .profile i have set PATH: /Library/Frameworks/Python.
>framework/Versions/2.6/bin


-- 
http://mail.python.org/mailman/listinfo/python-list

Python becoming orphaned over ssh

[David]

Hi there, I have a strange situation.

If I do this:

1. Make a script /tmp/test.py on a remote server, with this contents:

#!/usr/bin/python
from subprocess import check_call
check_call(['ping', 'www.google.com'])

2. Call the script like this over SSH:

ssh r...@testbox /tmp/test.py

3. Interrupt the script with Ctrl+C.

Then what happens:

The SSH session terminates, as expected.

However:

On the testing box, the Python script is still running, and so is the
ping session.

However, if I make an equivalent shell script, /tmp/test.sh, with this contents:

#!/bin/bash
ping www.google.com

And then run it over ssh like this:

ssh r...@testbox /tmp/test.sh

And then hit Ctrl+C, then the shell script and ping are both
interrupted remotely, as expected.

Here is how 'pstree -p' looks for the python script on the test box,
before Ctrl+C:


├─sshd(1158)─┬─sshd(19756)───test.py(19797)───ping(19798)
│└─sshd(20233)───bash(20269)───pstree(19875)

And after Ctrl+C:


├─sshd(1158)───sshd(20233)───bash(20269)───pstree(20218)
├─test.py(19797)───ping(19798)

Basically, the server-side sshd sub-process has disconnected, but the
Python script (and it's ping subprocess) have become orphaned, and now
belong to the init process.

Note, this only seems to happen if Python is executing a subprocess,
and only while Python is being run through a non-interactive ssh
session.

How can I make Python behave better? I want it to close down itself
and it's subprocess, and not orphan itself when I hit ctrl+C

PS:

The Python version on the testing box: 2.6.4, and the box itself is
running Ubuntu Karmic. Also, it's not just ping, but other utilities,
eg wget.

PPS:

I did also try adding logic to the python script, to keep an eye on
all the ppids (parent, grandparent, etc), and then to interrupt itself
and kill it's subprocess, but that doesn't seem to work: For whatever
reason, Python seems to be unable to kill it's subprocess in this
situation. The Python process closes, and ping becomes a child of
init. But I can then kill ping manually, from a separate ssh session.
-- 
http://mail.python.org/mailman/listinfo/python-list

embedding python in macOS 10.6

[tinau...@libero.it]

hi there,

i'm trying to embed python in a c++ code.i'm starting with the example in the 
tutorial.i've problem with setting up the enveiroment.
I've installed python with the distributed version (i.e., i did not, as a 
start, build it myself); i added the library where both python.h and pyconfig 
are stored and i linked to libpython2.6.a (which is, in the distributed 
version, an alias).
the program builds and links correctely, but if I try to run it, i get the 
following error:

Could not find platform independent libraries 
Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named time

what is the problem?

in my .profile i have set PATH: /Library/Frameworks/Python.
framework/Versions/2.6/bin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: toy list processing problem: collect similar terms

[w_a_x_man]

On Sep 26, 9:24 am, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> Xah Lee  writes:
> > here's a interesting toy list processing problem.
>
> > I have a list of lists, where each sublist is labelled by
> > a number. I need to collect together the contents of all sublists
> > sharing
> > the same label. So if I have the list
>
> > ((0 a b) (1 c d) (2 e f) (3 g h) (1 i j) (2 k l) (4 m n) (2 o p) (4 q
> > r) (5 s t))
>
> > where the first element of each sublist is the label, I need to
> > produce:
>
> > output:
> > ((a b) (c d i j) (e f k l o p) (g h) (m n q r) (s t))
>
> > a Mathematica solution is here:
> >http://xahlee.org/UnixResource_dir/writ/notations_mma.html
>
> > R5RS Scheme lisp solution:
> >http://xahlee.org/UnixResource_dir/writ/Sourav_Mukherjee_sourav.work_...
> > by Sourav Mukherjee
>
> > also, a Common Lisp solution can be found here:
> >http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/5d1de...
>
> It's too complex. Just write:
>
> (let ((list '((0 a b) (1 c d) (2 e f) (3 g h) (1 i j) (2 k l) (4 m n)
>               (2 o p) (4 q r) (5 s t
>
>   (mapcar (lambda (class) (reduce (function append) class :key (function 
> rest)))
>            (com.informatimago.common-lisp.list:equivalence-classes list :key 
> (function first)))
>
>    )
>
> --> ((S T) (Q R M N) (G H) (O P K L E F) (I J C D) (A B))
>
> --
> __Pascal Bourguignon__                    http://www.informatimago.com/

Ruby:

[[0, 'a', 'b'], [1, 'c', 'd'], [2, 'e', 'f'], [3, 'g', 'h'], [1,
'i', 'j'], [2, 'k', 'l'], [4, 'm', 'n'], [2, 'o', 'p'], [4, 'q', 'r'],
[5, 's', 't']].
group_by{|x| x.first}.values.map{|x| x.map{|y| y[1..-1]}.flatten}

==>[["s", "t"], ["a", "b"], ["c", "d", "i", "j"],
 ["e", "f", "k", "l", "o", "p"],
 ["g", "h"], ["m", "n", "q", "r"]]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Keith Thompson]

Erik Max Francis  writes:
> Keith Thompson wrote:
>> Erik Max Francis  writes:
>> [...]
>>>  >>> print c # floating point accuracy aside
>>> 299792458.0 m/s
>> 
>> Actually, the speed of light is exactly 299792458.0 m/s by
>> definition.  (The meter and the second are defined in terms of the
>> same wavelength of light; this was changed relatively recently.)
>
> I know.  Hence why I wrote the comment "floating point accuracy aside" 
> when printing it.

Ok.  I took the comment to be an indication that the figure was
subject to floating point accuracy concerns; in fact you meant just
the opposite.

-- 
Keith Thompson (The_Other_Keith) ks...@mib.org  
Nokia
"We must do something.  This is something.  Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Reoedering indexes in list of list

[Andreas Waldenburger]

On Tue, 28 Sep 2010 11:55:18 -0700 (PDT) Toto 
wrote:

> Hello,
> 
> I have a list of list
> assume myList[x][y] is integer
> I would like to create an alias to that list which I could call this
> way:
> alias[y][x] returns myList[x][y]
> 
> how can I do that ? (python 2.6)
> 
> (I have a feeling I should use 'property' ;)
> 
The zip thing certainly seems nice. But I can never get my head around
zip quick enough to not be confused by it. So my initial idea would
have been a function:

def reverse_indices(lst, x, y):
return lst[y][x]

(or, possibly, a subclass of list with this as an additional method.)

Granted, the invocation is different from what you want, but I don't
know enough about your problem to judge whether this is an issue.

/W

-- 
INVALID? DE!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: System idle time under Linux

[Hugo Léveillé]

Thanks, will take a closer look on that

But to get me started, how would you get, via python, the info from that
?

Thanks alot


On Thu, 30 Sep 2010 02:01 +1300, "Lawrence D'Oliveiro"
 wrote:
> /proc/stat or /proc/uptime, depending. See the proc(5) man page.
> -- 
> http://mail.python.org/mailman/listinfo/python-list
> 


-- 
  Hugo Léveillé
  hu...@fastmail.net

-- 
http://mail.python.org/mailman/listinfo/python-list

Supplementing the std lib (Was: partial sums problem)

[kj]

In  Terry Reedy 
 writes:

>Do not try to do a reduction with a comprehension. Just write clear, 
>straightforward code that obviously works.

>s=[1,2,3,4,5,6]
>def cusum(s):
>   t = 0
>   for i in s:
>   t += i
>   yield t

>print(list(cusum(s)))
> >>>
>[1, 3, 6, 10, 15, 21]


Actually, this is just fine.  Thank you!

But it brings up a new question, of an entirely different nature.

It's a recurrent conundrum, actually, and I have not found a good
solution.

Your cusum function is one that I would like to see somewhere in
the standard library (in itertools maybe?).  Maybe some future
version of the standard library will have it, or something like it
(I'm thinking of a generalized form which, like reduce, takes a
function and an initial value as arguments).

But in the immediate term, cusum is not part of the standard library.

Where would you put it if you wanted to reuse it?  Do you create
a module just for it?  Or do you create a general stdlib2 module
with all those workhorse functions that have not made it to the
standard library?  Or something else entirely?

(I'm not expecting to get *the* solution from anyone reply; rather,
I'm interested in reading people's take on the question and their
way of dealing with those functions they consider worthy of the
standard library.)

kj

-- 
http://mail.python.org/mailman/listinfo/python-list

PyCObject & malloc creating memory leak

[Tom Conneely]

I'm attempting to write a library for reading data via USB from a
device and processing the data to display graphs. I have already
implemented parts of this code as pure python, as a proof of concept
but I have now moved on to implementing the functions in a C
extension.

My original plan was to have the data processing and data acquisition
functions running in separate processes, with a multiprocessing.Queue
for passing the raw data packets. The raw data is read in as a char*,
with a non constant length, hence I have allocated memory using
PyMem_Malloc and I am returning from the acquisition function a
PyCObject containing a pointer to this char* buffer, along with a
destructor. The following code shows a simple test function I've
written (with some module/class boilerplate removed) to demonstrate
this.

static void p_destruct(void *p) {
PyMem_Free((void*)p);
}

static PyObject *malloc_buffer(MyClass *k1) {

PyObject *cobj;
char *foo = PyMem_Malloc(1024 * sizeof(char));

if (foo == NULL) {
return NULL;
}

foo = "foo";
cobj = PyCObject_FromVoidPtr(foo, p_destruct);

return cobj;
}

static PyObject *retrieve_buffer(MyClass *k1, PyObject *args) {
char *foo2;
PyObject cobj2;

char *kwlist[] = {"foo1", NULL};

if (!PyArg_ParseTuple(args, "O", &cobj2)) {
return NULL;
}

foo2 = PyCObject_AsVoidPtr(cobj2);

//Do something
PySys_WriteStdout(foo2);

Py_RETURN_NONE;
}

So if I call these functions in a loop, e.g. The following will
generate ~10GB of data

x = MyClass()
for i in xrange(0, 10 * 2**20):
c = x.malloc_buffer()
x.retrieve_buffer(c)

All my memory disapears, until python crashes with a MemoryError. By
placing a print in the destructor function I know it's being called,
however it's not actually freeing the memory. So in short, what am I
doing wrong?

This is the first time I've written a non-trivial python C extension,
and I'm still getting my head round the whole Py_INC/DECREF and the
correct way to manage memory, so I spent a while playing around with
incref/decref but I left these out of my above example to keep what
I'm trying to achieve clearer.

Also, I'm aware PyCObject is deprecated in >=2.7 but I'm targeting
Python 2.6 at the moment, and I will move on to using capsules once
I've made the big jump with some other libraries. So if there is
anything that could be hugely different using capsules could you point
this out.

I'm developing using:
Python - 2.6.5
Windows XP (although linux is a future target platform)
msvc compiler

Cheers, any help would be greatly appreciated.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Introducing Kids to Programming: 2 or 3?

[Emeka]

Marco,


This is a great news coming out of Africa. I would very much like to see
this your success story replicate across the continent. I would like to
participate and to have your programs for my country, Nigeria.

>From what you asked for, I would say that those kids should be part of the
future and not the past. So, go for Python 3. Being new to programming, what
matters most is learning programming and not the minor syntactical
differences. Get them to understand the real thing and they would build up
from there.


Regards ,
Emeka

On Mon, Sep 27, 2010 at 4:48 PM, Marco Gallotta wrote:

> Hi there
>
> I'm sure you get a lot of "2 or 3" questions, but here's another.
> Umonya [1] uses Python to introduce school kids to programming. The
> initiative is only 15 months old and up till now we've been using
> existing notes and exercises and thus Python 2. But we're at the stage
> where we can either stick with 2 for the next few years, or go to 3
> now.
>
> We received a grant from Google to reach 1,000 kids in South Africa
> with our course in 2011. People have also shown interest in running
> the course in Croatia, Poland and Egypt. We're also eyeing developing
> African countries in the long-term. As such, we're taking the time now
> to write our very own specialised course notes and exercises, and we
> this is why we need to decide *now* which path to take: 2 or 3? As we
> will be translating the notes we'll probably stick with out choice for
> the next few years.
>
> Since these are kids, we feel the nice changes in 3 such as removing
> integer division will help in teaching. It will also remove confusion
> when they go to download Python and grab the latest version. Since
> they're just starting, chances are almost none will be hit by the
> limited library support for at least a year or two. They will,
> however, be hit by the confusion of seeing Python 2 code all over the
> web.
>
> We're tending towards 3, but I am a little cautious myself.
>
> Marco
>
> [1] http://umonya.co.za
>
> --
> Marco Gallotta
> MSc Student
> Department of Computer Science, University of Cape Town
> people.cs.uct.ac.za/~mgallott  |
> marco-za.blogspot.com
> marco AT gallotta DOT co DOT za | 073 170  | 021 552 2731
> --
> http://mail.python.org/mailman/listinfo/python-list
>



-- 
*Satajanus  Nig. Ltd


*
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scheduler or infinite loop

[harryos]

thanks Frank
>
> Here is a technique that allows the loop to run in the background, in its
> own thread, leaving the main program to do other processing -
>
> import threading
>
> class DataGetter(threading.Thread):
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: sequence multiplied by -1

[Lawrence D'Oliveiro]

In message , Seebs wrote:

> Helps, perhaps, that I got exposed to group theory early enough to be used
> to redefining + and * to be any two operations which have interesting
> properties ...

But groups only have one such operation; it’s rings and fields (and number 
systems) that have two.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: scheduler or infinite loop

[Frank Millman]

harryos wrote:


hi
I am trying to write a program to read data from a site url.
The program must read the data from site every 5 minutes.

def get_data_from_site(pageurlstr):
   h=urllib.urlopen(pageurlstr)
   data=h.read()
   process_data(data)

At first, I thought of using the sched module ,but then it doesn't
look right adding so many scheduler.enter() statements.The program is
supposed to execute the above function every
5 minutes  until the application is shut down by the user.

I created an infinite loop
while True:
   print time.asctime()
   get_data_from_site('http://somesite.com/')
   time.sleep(300)

Is there a better way to do this?Any suggestions ,pointers most
welcome
thanks
harry


Here is a technique that allows the loop to run in the background, in its 
own thread, leaving the main program to do other processing -


import threading

class DataGetter(threading.Thread):

   def __init__(self):
   threading.Thread.__init__(self)
   self.event = threading.Event()

   def run(self):
   event = self.event  # make local
   while not event.is_set():
   print time.asctime()
   # either call the function from here,
   #   or put the body of the function here
   get_data_from_site('http://somesite.com/')
   event.wait(300)

   def stop(self):
   self.event.set()

In the startup of the main program, insert the following -

   data_getter = DataGetter()
   data_getter.start()

At the end of the program, terminate the loop like this -
   data_getter.stop()

HTH

Frank Millman


--
http://mail.python.org/mailman/listinfo/python-list

Re: if the else short form

[Alex Willmer]

On Sep 29, 12:38 pm, Hrvoje Niksic  wrote:
> Tracubik  writes:
> > Hi all,
> > I'm studying PyGTK tutorial and i've found this strange form:
>
> > button = gtk.Button(("False,", "True,")[fill==True])
>
> > the label of button is True if fill==True, is False otherwise.
>
> The tutorial likely predates if/else expression syntax introduced in
> 2.5, which would be spelled as:
>
> button = gtk.Button("True" if fill else "False")
>
> BTW adding "==True" to a boolean value is redundant and can even break
> for logically true values that don't compare equal to True (such as the
> number 10 or the string "foo").

Totally agreed with one nit. If one chooses to fake

x = true_val if expr else false_val

prior to Python 2.5, with

x = (false_val, true_val)[expr]

then one should ensure that expr evaluates to either 0, 1 or a bool.
If expr evaluates to "fred" or 42 a TypeError or IndexError will
occur. So better to use (in original line)

 button = gtk.Button(("False,", "True,")[bool(fill)])

but still best for readability, to use a full if-else block
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: if the else short form

[bruno.desthuilli...@gmail.com]

On 29 sep, 13:38, Hrvoje Niksic  wrote:
> Tracubik  writes:
>
> > button = gtk.Button(("False,", "True,")[fill==True])

(snip)

> BTW adding "==True" to a boolean value is redundant and can even break
> for logically true values that don't compare equal to True (such as the
> number 10 or the string "foo").

Note that if fill is actually an int outside the (0, 1) domain, it
will break too. The correct test would be:

 ("False,", "True,")[bool(fill)])


>>> ['a', 'b'][bool(10)]
'b'
>>> ['a', 'b'][bool('')]
'a'
>>> ['a', 'b'][bool("yes")]
'b'
>>> ['a', 'b'][bool([])]
'a'
>>> ['a', 'b'][bool([42, 24])]
'b'
>>> ['a', 'b'][bool(None)]
'a'
>>>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: "Strong typing vs. strong testing"

[Paul Wallich]

On 9/29/10 6:40 AM, Pascal J. Bourguignon wrote:

George Neuner  writes:


On Tue, 28 Sep 2010 12:15:07 -0700, Keith Thompson
wrote:


George Neuner  writes:

On 28 Sep 2010 12:42:40 GMT, Albert van der Horst
  wrote:

I would say the dimensional checking is underrated. It must be
complemented with a hard and fast rule about only using standard
(SI) units internally.

Oil output internal : m^3/sec
Oil output printed:  kbarrels/day


"barrel" is not an SI unit.


He didn't say it was.  Internal calculations are done in SI units (in
this case, m^3/sec); on output, the internal units can be converted to
whatever is convenient.


That's true.  But it is a situation where the conversion to SI units
loses precision and therefore probably shouldn't be done.




  And when speaking about oil there isn't
even a simple conversion.

   42 US gallons  ?  34.9723 imp gal  ?  158.9873 L

[In case those marks don't render, they are meant to be the
double-tilda sign meaning "approximately equal".]


There are multiple different kinds of "barrels", but "barrels of oil"
are (consistently, as far as I know) defined as 42 US liquid gallons.
A US liquid gallon is, by definition, 231 cubic inches; an inch
is, by definition, 0.0254 meter.  So a barrel of oil is *exactly*
0.158987294928 m^3, and 1 m^3/sec is exactly 13.7365022817792
kbarrels/day.  (Please feel free to check my math.)  That's
admittedly a lot of digits, but there's no need for approximations
(unless they're imposed by the numeric representation you're using).


I don't care to check it ... the fact that the SI unit involves 12
decimal places whereas the imperial unit involves 3 tells me the
conversion probably shouldn't be done in a program that wants
accuracy.

[...]


Now perhaps it all depends on whether you buy your oil from Total or
from Texaco, but in my opinion, you're forgetting something: the last
drop.  You never get exactly 42 gallons of oil, there's always a little
drop more or less, so what you get is perhaps 158.987 liter or
41.221 US gallons, or even 158.98 liter = 41.9980729 US gallons,
where you need more significant digits.


And even that pales in comparison to the expansion and contraction of 
petroleum products with temperature. Compensation to standard temp is 
required in some jurisdictions but not in others...


--
http://mail.python.org/mailman/listinfo/python-list