Re: Flexible string representation, unicode, typography, ...

[wxjmfauth]

Le dimanche 26 août 2012 00:26:56 UTC+2, Ian a écrit :
> On Sat, Aug 25, 2012 at 9:47 AM,   wrote:
> 
> > For those you do not know, the go language has introduced
> 
> > the rune type. As far as I know, nobody is complaining, I
> 
> > have not even seen a discussion related to this subject.
> 
> 
> 
> Python has that also.  We call it "int".
> 
> 
> 
> More seriously, strings in Go are not sequences of runes.  They're
> 
> actually arrays of UTF-8 bytes.  That means that they're quite
> 
> efficient for ASCII strings, at the expense of other characters, like
> 
> Chinese (wait, this sounds familiar for some reason).  It also means
> 
> that you have to bend over backwards if you want to work with actual
> 
> runes instead of bytes.  Want to know how many characters are in your
> 
> string?  Don't call len() on it -- that will only tell you how many
> 
> bytes are in it.  Don't try to index or slice it either -- that will
> 
> (accidentally) work for ASCII strings, but for other strings your
> 
> indexes will be wrong.  If you're unlucky you might even split up the
> 
> string in the middle of a character, and now your string has invalid
> 
> characters in it.  The right way to do it looks something like this:
> 
> 
> 
> len([]rune("白鵬翔"))  // get the length of the string in characters
> 
> string([]rune("白鵬翔")[0:2])  // get the substring containing the first
> 
> two characters
> 
> 
> 
> It reminds me of working in Python 2.X, except that instead of an
> 
> actual unicode type you just have arrays of ints.


Sorry, you do not get it.

The rune is an alias for int32. A sequence of runes is a
sequence of int32's. Go do not spend its time in using a
machinery to work with, to differentiate, to keep in memory
this sequence according to the *characers* composing this
"array of code points".

The message is even stronger. Use runes to work comfortably [*]
with unicode:
rune -> int32 -> utf32 -> unicode (the perfect scheme, cann't be
better)

[*] Beyond my skill and my kwowloge and if I understood correctly,
this rune is even technically optimized to ensure it it always
an int32.

len() or slices() have nothing to do here.

My experience with go is equal to uero + epsilon.

jmf


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

Re: Segfault when setting an instance property on 2.7.3

[Vincent Pelletier]

Le samedi 25 août 2012 11:38:47, Vincent Pelletier a écrit :
> Any idea of ways to debug this problem further ?

Trying with pypy ("just to see"), I got even more reproductible segfaults - 
even with valgrind.

Turns out, I was not keeping strong references to ctypes buffers, which get 
very quickly collected with pypy and memory reused for something else, leading 
to a quick crash.

Now, I don't get yet why cpython was not crashing more often, even if I forced 
gc.collect() . Less memory recycling maybe ?

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

VPS For Python

[coldfire]

I will really appreciate if someone type the address of any of the following 
for use with python 
1>Webhost 
2>Shell Account 
3>VPS 
I am really new to all this Got web server and shell account but unable to 
figure out how to use it or deploy the Code, 
My problem is that I m using lot of third party Library which are mostly not 
supported or I don't know How to make it RUN over Internet 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Built-in open() with buffering > 1

[Hans Mulder]

On 24/08/12 06:35:27, Marco wrote:
> Please, can anyone explain me the meaning of the
> "buffering > 1" in the built-in open()?
> The doc says: "...and an integer > 1 to indicate the size
> of a fixed-size chunk buffer."
> So I thought this size was the number of bytes or chars, but
> it is not

The algorithm is explained at
http://docs.python.org/library/io.html#io.DEFAULT_BUFFER_SIZE

>> io.DEFAULT_BUFFER_SIZE
>>
>> An int containing the default buffer size used by the
>> module’s buffered I/O classes. open() uses the file’s
>> blksize (as obtained by os.stat()) if possible.

In other words: open() tries to find a suitable size by
calling os.stat(your_file).st_blksize and if that fails,
it uses io.DEFAULT_BUFFER_SIZE, which is 8192 on my box.

Whether you call open with buffering=2 or any larger
number, does not matter: the buffer size will be the
outcome of this algorithm.


Hope this helps,

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

Re: help with simple print statement!

[Hans Mulder]

On 24/08/12 21:59:12, Prasad, Ramit wrote:
> Also, print doesn't work inside a class.

It works for me:


> python3
Python 3.3.0a1 (v3.3.0a1:f1a9a6505731, Mar  4 2012, 12:26:12)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class spam(object):
... print("Hello there!")
...
Hello there!
>>>

I'm not sure why you'd want to call the print function in a
class definition, though.  The print function is more usually
called from within a method definition, not at the class level.


What, exactly are you doing?

Are you trying python2 syntax in a python3 interpreter, or vice versa?

Can you copy a complete session and paste it into a follow-up message?


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

Re: Computing win/loss records in Python

[Hans Mulder]

On 26/08/12 04:42:59, Steven W. Orr wrote:
> On 8/25/2012 10:20 PM, Christopher McComas wrote:
>> Greetings,
>>
>> I have code that I run via Django that grabs the results from various
>> sports from formatted text files. The script iterates over every line
>> in the formatted text files, finds the team in the Postgres database
>> updates their w/l record depending on the outcome on that line, saves
>> the team's row in the db, and then moves on to the next line in the file.
>>
>> I'm trying to get away from Django for this project, I want to run the
>> files, get the W/L results and output a formatted text file with the
>> teams and their W/L records. What's confusing me I guess how to store
>> the data/results as the wins and losses tally up. We're talking
>> hundreds of teams, thousands of games, but a quick example would be:
>>
>> Marshall
>> Ohio State
>> Kentucky
>> Indiana
>>
>> Marshall,24,Ohio State,48,
>> Kentucky,14,Indiana,10,
>> Marshall,10,Indiana,7,
>> Ohio State,28,Kentucky,10
>>
>> That's just a quick example, I can handle seperating the data in the
>> lines, figuring it all out, I just am unsure of how to keep a running
>> total of a team's record. I would do "for line in file:" then on the
>> first line I see that Marshall lost so they would have 1, Ohio State
>> won so they'd have 1 win. It'd go to the next line Kentucky 1 win,
>> Indiana 1 loss, then on the 3rd line, Marshall got a win so they'd
>> have 1 win, but it would have to remember that loss from line 1...
>>
>> Does this make sense?
>>
>> Thanks,
> 
> win_count = defaultdict(int)
> loss_count = defaultdict(int)
> 
> items = line.split(',')
> if items[1] > items[3]:
> windex = 0
> lossdex = 2
> else:
> windex = 2
> lossdex = 0
> win_count[windex] += 1
> loss_count[lossdex] += 1

I think you meant:

win_count[items[windex]] += 1
loss_count[items[windex]] += 1


I think it would be more readable to do:

from collections import defaultdict

win_count = defaultdict(int)
loss_count = defaultdict(int)

items = line.split(',')
if int(items[1]) > int(items[3]):
winner = items[0]
loser = items[2]
else:
winner = items[2]
loser = items[0]
win_count[winner] += 1
loss_count[loser] += 1

It looks like you're afraid of wasting RAM by needlessly
copying strings.  However, this fear is unfounded: Python
doesn't copy strings, unless you tell it to do so explictly.
An assignment like "winner = items[0]" doesn't copy the string;
it merely creates a new reference to the existing string.


Hope this helps,

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

Re: Flexible string representation, unicode, typography, ...

[Steven D'Aprano]

On Sat, 25 Aug 2012 23:59:34 -0700, wxjmfauth wrote:

> Le dimanche 26 août 2012 00:26:56 UTC+2, Ian a écrit :

>> More seriously, strings in Go are not sequences of runes.  They're
>> actually arrays of UTF-8 bytes.

Actually, it's worse that that. Strings in Go aren't even proper UTF-8. 
They are arbitrary bytes, which means you can create strings which are 
invalid Unicode.

Go looks like an interesting language, but it seems to me that they have 
totally screwed up strings. At least Python had the excuse that it is 20 
years old and carrying the old ASCII baggage. Nobody used Unicode in 1992 
when Python was invented. What is Google's excuse for getting Unicode 
wrong?

In Go, strings are UTF-8 encoded sequences of bytes, except when they're 
not, in which case they're arbitrary bytes. You can't tell if a string is 
valid UTF-8 unless you carefully inspect every single character and 
decide for yourself if it is valid. Don't know the rules for valid UTF-8? 
Too bad.

This also means that basic string operations like slicing are both *slow* 
and *wrong* -- they are slow, because you have to track character 
boundaries yourself. And they are wrong, because most people won't 
bother, they'll just assume each character is one byte.

See here for more information:

http://comments.gmane.org/gmane.comp.lang.go.general/56245

Some useful quotes:

-  "Strings are *not* required to be UTF-8."

- "If the string must always be valid UTF-8 then relatively expensive
   validation is required for many operations. Plus making those
   operations able to fail complicates the interface."

- "In almost all cases strings are just byte arrays."

- "Go simply doesn't have 8-bit Unicode strings"

- "Python3 can afford the luxury of storing strings in UCS-2/UCS-4, 
  Go can't."

I don't question that Go needs a type for arbitrary bytes. But that 
should be "bytes", not "string", and it should be there for the advanced 
programmers who *need* to worry about bytes. Programmers who want to 
include strings in their applications (i.e. all of them) shouldn't need 
to care that "$" is one byte, "¢" is two, "€" is three, and "𤭢" 
(U+24B62) is four. With Python 3.3, it *just works*. With Go, it doesn't.

In my not-so-humble opinion, Go has made a silly design error. Go 
programmers will be paying for this mistake for at least a decade. What 
they should have done is create two data types:

1) Strings which are guaranteed to be valid Unicode. That could be UTF-32 
or a PEP 393 approach, depending on how much memory you want to use, or 
even UTF-16 if you don't mind the complication of surrogate pairs.

2) Bytes which are not guaranteed to be valid Unicode but let the 
programmer work with arbitrary bytes.

(If this sounds familiar, it should -- it is exactly what Python 3 does. 
We have a string type that guarantees to be valid Unicode, and a bytes 
type that doesn't.)

As given, *every single programmer* who wants to use Unicode in Go is now 
responsible for doing all the hard work of validating UTF-8, converting 
from bytes to strings, etc. Sure, eventually Go will have libraries to do 
that, but not yet, and even when it does, many people will not use them 
and their code will fail to handle Unicode correctly.

Right now, every Go programmer who wants Unicode has to pay the cost of 
the freedom to have arbitrary byte sequences, whether they need those 
arbitrary bytes or not. The consequence is that instead of Go making 
Unicode as trivial and easy to use as it should be, it will be hard to 
get right, annoying, slow and painful. Another generation of programmers 
will grow up thinking that Unicode is all too difficult and we should 
stick to just plain ASCII.

Since Go doesn't have Unicode strings, you can never trust that a string 
is valid UTF-8, you can't slice it efficiently, you can't get the length 
in characters, you can't write it to a file and have other applications 
to be able to read it. Sure, sometimes it will work, and then somebody 
will input a Euro sign into your application, and it will blow up.

Why am I not surprised that JMF misunderstands both Go byte-strings and 
Python Unicode strings?


> Sorry, you do not get it.
> 
> The rune is an alias for int32. A sequence of runes is a sequence of
> int32's.

It certainly is not. Runes are variable-width. Here, for example, are a 
number of Go functions which return a single rune and its width in bytes:

http://golang.org/pkg/unicode/utf8/


> Go do not spend its time in using a machinery to work with, to
> differentiate, to keep in memory this sequence according to the
> *characers* composing this "array of code points".
> 
> The message is even stronger. Use runes to work comfortably [*] with
> unicode:
> rune -> int32 -> utf32 -> unicode (the perfect scheme, cann't be better)

Runes are not int32, and int32 is not UTF-32.

Whether UTF-32 is the "perfect scheme" for Unicode is a matter of opinion.



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

Re: Objects in Python

[Steven D'Aprano]

On Sun, 26 Aug 2012 16:22:05 +1000, Chris Angelico wrote:

> On Sun, Aug 26, 2012 at 3:45 PM, Evan Driscoll 
> wrote:
>> Third, and more wackily, you could technically create a C
>> implementation that works like Python, where it stores variables (whose
>> addresses aren't taken) in a dict keyed by name, and generates code
>> that on a variable access looks up the value by accessing that dict
>> using the name of the variable.
> 
> That would be a reasonable way to build a C interactive interpreter.

No it wouldn't. Without fixed addresses, the language wouldn't be able to 
implement pointers. C without pointers isn't C, it is something else. 
Possibly called Python :)

I suppose you could get pointers in Namespace-C if you somehow mapped 
names to addresses, and vice versa, but why would you do that? You end up 
with a hybrid system that doesn't give you any advantage over C but has a 
much more complicated implementation (and therefore many more new and 
exciting bugs).

But if you want me to agree that you could implement C using name 
binding, plus some weird scheme to track memory addresses, then yes, I 
suppose you could. Then the parts of C that don't rely on fixed memory 
addresses could use the name bindings (with the corresponding loss of 
performance), and the parts of C which do require them could continue to 
do so, and we'll have one more language with a confusing, unclear and 
unclean execution model. Everybody wins! For some definition of win.



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

Re: psphere: how to make thread safe

[jonathan . kinred]

On Wednesday, 22 August 2012 22:03:48 UTC+10, sajuptpm  wrote:
> Hi,
> 
> 
> 
> psphere: Python interface for the VMware vSphere Web Services SDK
> 
> 
> 
> I already developed an app using https://bitbucket.org/jkinred/psphere. But 
> getting lot of errors since psphere is not thread safe (I think). So i wrote 
> couple of scripts to test it (See attached files) and found that caching 
> mechanism used by psphere is not thread safe. Could someone please give me 
> some suggestion to make it thread safe.
> 
> 
> 
> 
> 
> ===Test Code 
> 
> 
> 
> import psphere
> 
> from psphere.client import Client
> 
> from psphere.managedobjects import HostSystem, VirtualMachine, ComputeResource
> 
> client = Client("192.168.0.114", "root", "vmware1") ##vCenter
> 
> print "\nSucessfully connected to vCenter.\n"
> 
> 
> 
> from threading import Thread
> 
> 
> 
> def myfunc(i):
> 
>   host1 = HostSystem.get(client, name="192.168.0.134")
> 
>   host2 = HostSystem.get(client, name="192.168.0.113")
> 
>   print "i--",i
> 
>   while True:
> 
>   #host1.update(properties=["config", "vm"])
> 
>   #host2.update(properties=["config", "vm"])
> 
>   c = type(host1.config.network)
> 
>   v = type(host2.config.network)
> 
>   for vm in host1.vm:
> 
>   k = vm.config.template
> 
>   for vm in host2.vm:
> 
>   p = vm.config.template
> 
> 
> 
> 
> 
> for i in range(10):   
> 
> t = Thread(target=myfunc, args=(i,))
> 
> t.start()
> 
> 
> 
> 
> 
> """
> 
> OUTPUT 
> 
> ===
> 
> Sucessfully connected to vCenter.
> 
> 
> 
> i-- 1
> 
> i-- 3
> 
> i-- 5
> 
> i-- 0
> 
>  i-- 4
> 
> i-- 2i-- 7
> 
> i-- 
> 
> 9
> 
> i-- 6
> 
> i-- 8
> 
> Exception in thread Thread-4:
> 
> Traceback (most recent call last):
> 
>   File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
> 
> self.run()
> 
>   File "/usr/lib/python2.7/threading.py", line 504, in run
> 
> self.__target(*self.__args, **self.__kwargs)
> 
>   File "vcenter_test1.py", line 19, in myfunc
> 
> k = vm.config.template
> 
>   File "/home/saju/cvt/trunk/src/cvt/web/cvt/psphere/__init__.py", line 79, 
> in __get__
> 
> value = self.fget(inst)
> 
>   File "/home/saju/cvt/trunk/src/cvt/web/cvt/psphere/managedobjects.py", line 
> 1236, in config
> 
> return self._get_dataobject("config", False)
> 
>   File "/home/saju/cvt/trunk/src/cvt/web/cvt/psphere/__init__.py", line 116, 
> in _get_dataobject
> 
> return self._cache[name][0]
> 
> KeyError: 'config'
> 
> 
> 
> Exception in thread Thread-6:
> 
> Traceback (most recent call last):
> 
>   File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
> 
> self.run()
> 
>   File "/usr/lib/python2.7/threading.py", line 504, in run
> 
> self.__target(*self.__args, **self.__kwargs)
> 
>   File "vcenter_test1.py", line 17, in myfunc
> 
> v = type(host2.config.network)
> 
> AttributeError: VirtualMachineConfigInfo instance has no attribute 'network'
> 
> 
> 
> 
> 
> 
> 
> """

I'm the author of psphere. I'd be really interested to get some experienced 
insight into this as I really don't know the first thing about thread safety.

psphere does use a cache, but I'm confused as to how the cache would be thread 
unsafe as the cache is just a property of an object.

What I'm suspecting (and this only came to me while writing this post) is that 
I have a "client" object which is passed into each object and used to retrieve 
data from the server. See this gist:
https://gist.github.com/3478641

When used in a threaded scenario could the client be used by multiple objects 
simultaneously and the replies would come in out of order?

A couple of years ago I started psphere to learn Python and I always hoped that 
I would have an experienced developer join me. I did learn Python but I never 
got that experienced developer so when it comes to issues like this I'm 
definitely out of my depth! Please if someone could spend the time with me I 
would really appreciate it!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: issue with struct.unpack

[Alexander Blinne]

On 26.08.2012 01:31, Dennis Lee Bieber wrote:
> The struct module relies upon the user knowing the format of the data.
> If your problem is that you have some null-terminated string data in a
> variable width field, you will have to locate the position of the null
> FIRST, and specify the appropriate "count" for the s format.

This gave me the idea of an Enhancement of the Struct class with an
additional format character (perhaps 'n') which corresponds to a
null-terminated string:

-
# -*- coding: utf-8 -*-

import struct

class Nstr(object):
def __init__(self, ncount):
self.ncount = ncount

def unpack(self, s):
s = s.split('\0')
return s[:self.ncount], '\0'.join(s[self.ncount:])

def pack(self, *s):
if len(s)!=self.ncount:
raise ValueError
for st in s:
if '\0' in st:
raise ValueError
return '\0'.join(s)+'\0'

def __repr__(self):
return 'Nstr('+repr(self.ncount)+')'

class NStruct(object):
def __init__(self, format):
self.format = format
if format[0] in '!=<>@':
self.endianness = format[0]
format = format[1:]
else:
self.endianness = ''
self.chunks = []
while len(format)>0:
j = format.find('n')
if j > -1:
k = j-1
while format[k].isdigit():
k-=1
chunkformat, ncount, format = format[:k+1],\
format[k+1:j], format[j+1:]
ncount = 1 if len(ncount)==0 else int(ncount)
else:
chunkformat, ncount, format = format, '', ''
ncount = 0
stru = struct.Struct(self.endianness+chunkformat)
l = len(stru.unpack("0"*stru.size))
self.chunks.append((stru, l))
if ncount > 0:
self.chunks.append((Nstr(ncount), ncount))

def unpack(self, data):
res = []
for sth, n in self.chunks:
if isinstance(sth, struct.Struct):
chunk, data = data[:sth.size], data[sth.size:]
res.extend(sth.unpack(chunk))
elif isinstance(sth, Nstr):
chunk, data = sth.unpack(data)
res.extend(chunk)
return res

def pack(self, *data):
res = []
for sth, n in self.chunks:
chunk, data = data[:n], data[n:]
res.append(sth.pack(*chunk))
return ''.join(res)

def __repr__(self):
return 'NStruct('+repr(self.format)+')'

if __name__=="__main__":
a = NStruct('h b 2n 2h')
print repr(a)
d = 'asdblah blah\0haha\0asdf'
r = a.unpack(d)
assert r == [29537, 100, 'blah blah', 'haha', 29537, 26212]
print repr(d), repr(r)
dd = a.pack(*r)
print r, repr(dd)
assert dd == d

-

beware of bugs in the above code, i haven't testet it much yet.

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

Re: psphere: how to make thread safe

[jonathan . kinred]

On Sunday, 26 August 2012 22:45:25 UTC+10, jonatha...@gmail.com  wrote:
> On Wednesday, 22 August 2012 22:03:48 UTC+10, sajuptpm  wrote:
> 
> > Hi,
> 
> > 
> 
> > 
> 
> > 
> 
> > psphere: Python interface for the VMware vSphere Web Services SDK
> 
> > 
> 
> > 
> 
> > 
> 
> > I already developed an app using https://bitbucket.org/jkinred/psphere. But 
> > getting lot of errors since psphere is not thread safe (I think). So i 
> > wrote couple of scripts to test it (See attached files) and found that 
> > caching mechanism used by psphere is not thread safe. Could someone please 
> > give me some suggestion to make it thread safe.
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > ===Test Code 
> 
> > 
> 
> > 
> 
> > 
> 
> > import psphere
> 
> > 
> 
> > from psphere.client import Client
> 
> > 
> 
> > from psphere.managedobjects import HostSystem, VirtualMachine, 
> > ComputeResource
> 
> > 
> 
> > client = Client("192.168.0.114", "root", "vmware1") ##vCenter
> 
> > 
> 
> > print "\nSucessfully connected to vCenter.\n"
> 
> > 
> 
> > 
> 
> > 
> 
> > from threading import Thread
> 
> > 
> 
> > 
> 
> > 
> 
> > def myfunc(i):
> 
> > 
> 
> > host1 = HostSystem.get(client, name="192.168.0.134")
> 
> > 
> 
> > host2 = HostSystem.get(client, name="192.168.0.113")
> 
> > 
> 
> > print "i--",i
> 
> > 
> 
> > while True:
> 
> > 
> 
> > #host1.update(properties=["config", "vm"])
> 
> > 
> 
> > #host2.update(properties=["config", "vm"])
> 
> > 
> 
> > c = type(host1.config.network)
> 
> > 
> 
> > v = type(host2.config.network)
> 
> > 
> 
> > for vm in host1.vm:
> 
> > 
> 
> > k = vm.config.template
> 
> > 
> 
> > for vm in host2.vm:
> 
> > 
> 
> > p = vm.config.template
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > for i in range(10): 
> 
> > 
> 
> > t = Thread(target=myfunc, args=(i,))
> 
> > 
> 
> > t.start()
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > """
> 
> > 
> 
> > OUTPUT 
> 
> > 
> 
> > ===
> 
> > 
> 
> > Sucessfully connected to vCenter.
> 
> > 
> 
> > 
> 
> > 
> 
> > i-- 1
> 
> > 
> 
> > i-- 3
> 
> > 
> 
> > i-- 5
> 
> > 
> 
> > i-- 0
> 
> > 
> 
> >  i-- 4
> 
> > 
> 
> > i-- 2i-- 7
> 
> > 
> 
> > i-- 
> 
> > 
> 
> > 9
> 
> > 
> 
> > i-- 6
> 
> > 
> 
> > i-- 8
> 
> > 
> 
> > Exception in thread Thread-4:
> 
> > 
> 
> > Traceback (most recent call last):
> 
> > 
> 
> >   File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
> 
> > 
> 
> > self.run()
> 
> > 
> 
> >   File "/usr/lib/python2.7/threading.py", line 504, in run
> 
> > 
> 
> > self.__target(*self.__args, **self.__kwargs)
> 
> > 
> 
> >   File "vcenter_test1.py", line 19, in myfunc
> 
> > 
> 
> > k = vm.config.template
> 
> > 
> 
> >   File "/home/saju/cvt/trunk/src/cvt/web/cvt/psphere/__init__.py", line 79, 
> > in __get__
> 
> > 
> 
> > value = self.fget(inst)
> 
> > 
> 
> >   File "/home/saju/cvt/trunk/src/cvt/web/cvt/psphere/managedobjects.py", 
> > line 1236, in config
> 
> > 
> 
> > return self._get_dataobject("config", False)
> 
> > 
> 
> >   File "/home/saju/cvt/trunk/src/cvt/web/cvt/psphere/__init__.py", line 
> > 116, in _get_dataobject
> 
> > 
> 
> > return self._cache[name][0]
> 
> > 
> 
> > KeyError: 'config'
> 
> > 
> 
> > 
> 
> > 
> 
> > Exception in thread Thread-6:
> 
> > 
> 
> > Traceback (most recent call last):
> 
> > 
> 
> >   File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
> 
> > 
> 
> > self.run()
> 
> > 
> 
> >   File "/usr/lib/python2.7/threading.py", line 504, in run
> 
> > 
> 
> > self.__target(*self.__args, **self.__kwargs)
> 
> > 
> 
> >   File "vcenter_test1.py", line 17, in myfunc
> 
> > 
> 
> > v = type(host2.config.network)
> 
> > 
> 
> > AttributeError: VirtualMachineConfigInfo instance has no attribute 'network'
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > 
> 
> > """
> 
> 
> 
> I'm the author of psphere. I'd be really interested to get some experienced 
> insight into this as I really don't know the first thing about thread safety.
> 
> 
> 
> psphere does use a cache, but I'm confused as to how the cache would be 
> thread unsafe as the cache is just a property of an object.
> 
> 
> 
> What I'm suspecting (and this only came to me while writing this post) is 
> that I have a "client" object which is passed into each object and used to 
> retrieve data from the server. See this gist:
> 
> https://gist.github.com/3478641
> 
> 
> 
> When used in a threaded scenario could the client be used by multiple objects 
> simultaneously and the replies would come in out of order?
> 
> 
> 
> A couple of years ago I started psphere to learn Python and I always hoped 
> that I would have an experienced developer join me. I did learn Python but I 
> never got that experienced developer so when it comes to issues 

Re: Objects in Python

[Chris Angelico]

On Sun, Aug 26, 2012 at 10:02 PM, Steven D'Aprano
 wrote:
> On Sun, 26 Aug 2012 16:22:05 +1000, Chris Angelico wrote:
>
>> On Sun, Aug 26, 2012 at 3:45 PM, Evan Driscoll 
>> wrote:
>>> Third, and more wackily, you could technically create a C
>>> implementation that works like Python, where it stores variables (whose
>>> addresses aren't taken) in a dict keyed by name, and generates code
>>> that on a variable access looks up the value by accessing that dict
>>> using the name of the variable.
>>
>> That would be a reasonable way to build a C interactive interpreter.
>
> No it wouldn't. Without fixed addresses, the language wouldn't be able to
> implement pointers. C without pointers isn't C, it is something else.
> Possibly called Python :)

The insertion of a single rule will do it. Let it stand that &x is the
string "x" and there you are, out of your difficulty at once!

Okay, that may be a bit of a fairy tale ending and completely illogical.

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

Re: Objects in Python

[Roy Smith]

In article ,
 Chris Angelico  wrote:

> On Sun, Aug 26, 2012 at 3:45 PM, Evan Driscoll  wrote:
> > Third, and more wackily, you could technically create a C implementation
> > that works like Python, where it stores variables (whose addresses aren't
> > taken) in a dict keyed by name, and generates code that on a variable access
> > looks up the value by accessing that dict using the name of the variable.
> 
> That would be a reasonable way to build a C interactive interpreter.

Except that lots of C and C++ programs assume they know how data 
structures are laid out and can index forward and backward over them in 
ways which the language does not promise work (but are, none the less, 
useful).  Say, the sort of thinks you might use python's struct module 
for.

On the other hand, there is certainly a big subset of C that you could 
implement that way.  But it would only be useful as a simple 
instructional tool.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Objects in Python

[Steven D'Aprano]

On Sun, 26 Aug 2012 00:45:55 -0500, Evan Driscoll wrote:

> On 08/24/2012 05:00 AM, Steven D'Aprano wrote:
>> No. The compiler remembers the address of 'a' by keeping notes about it
>> somewhere in memory during the compilation process. When you run the
>> compiled program, there is no longer any reference to the name 'a'.
>>
>> ...
>>
>> The mapping of name:address is part of the *compilation* process -- the
>> compiler knows that variable 'x' corresponds to location 12345678, but
>> the compiled code has no concept of anything called 'x'. It only knows
>> about locations. The source code 'x = 42' is compiled into something
>> like 'store 42 into location 12345678'. (Locations may be absolute or
>> relative.)
>>
>> In languages with name bindings, the compiler doesn't need to track
>> name:address pairs. The compiled application knows about names, but not
>> about addresses. The source code 'x = 42' is compiled into something
>> like 'store 42 into the namespace using key "x"'.
>
> What you describe is sorta correct, but it's also not... you're
> describing implementations rather than the language. And while the
> language semantics certainly impose restrictions on the implementation,

I accept that languages may choose to leave the variable-model 
unspecified. I don't think they can define behaviour without implying one 
model or the other. Or at least not easily - far too much language 
behaviour is tied to the implementation to let us say "it's only 
implementation".

For example, the reason that locals() is not writable inside Python 
functions is because CPython moves away from the name binding model 
inside functions as an optimization. This function prints 1 under both 
CPython and Jython (but not IronPython):

def spam():
x = 1
locals()['x'] = 2
print(x)

Binding to the local namespace does not work, because functions don't 
*actually* use a namespace, they use something closer to the C model. So 
the two models are not interchangable and hence they aren't *just* 
implementation details, they actually do affect the semantics of the 
language.

I suppose you could arrange for locals() to return a proxy dictionary 
which knew about the locations of variables. But what happens if you 
returned that proxy to the caller, which then assigned to it later after 
the function variables no longer existed?

Similarly, there are operations which are no longer allowed simply 
because of the difference between name binding and locational variables:


py> def ham():
... from math import *
...
  File "", line 1
SyntaxError: import * only allowed at module level


(In some older versions of Python, wildcard imports are allowed, and the 
function then falls back on a namespace instead of fixed locations. That 
is no longer the case in Python 3.2 at least.)


> I think in this case the situation is closer than you acknowledge:
> 
>  From the Python side, I suspect that for most functions, you'd be able
> to create a Python implementation that behaves more like C, and
> allocates locals in a more traditional fashion.

As I discuss above, CPython and Jython actually do something like that 
inside functions. And there are observable differences in behaviour (not 
just performance) between function scope and global scope.

So an implementation of Python which used fixed memory addresses 
everywhere, not just in functions, would be detectably different in 
behaviour than CPython. Whether those differences would be enough to 
disqualify it from being called "Python" is a matter of opinion.

(Probably Guido's opinion is the only one that matters.)


[...]
> On the C side, imagine a function with locals x, y, and z which never
> takes the address of any of them. (You said later that "Just because the
> public interface of the language doesn't give you any way to view the
> fixed locations of variables, doesn't mean that variables cease to have
> fixed locations.")
> 
> First, C variables may not even have a memory address. They can
> disappear completely during compilation, or live in a register for their
> entire life.

Variables that don't exist at runtime don't have an address at all -- in 
a way, they aren't even a variable any more. They have a name in the 
source code, but that's all.

As for registers, they are memory addresses, of a sort. (I didn't mean to 
imply that they must live in main motherboard memory.) I call any of 
these an address:

 - in the heap at address 12345678
 - in the GPU's video memory at address 45678
 - 12th entry from the top of the stack
 - register 4


> Second, it's possible that those variables *don't* occupy a fixed
> location. If you never explicitly take an address of a variable (&x),
> then I can't think of any way that the address can be observed without
> invoking undefined behavior -- and this means the C compiler is free to
> transform it to anything that is equivalent under the C semantics.

I may have been too emphatic about the "fixed" part. A sufficiently 
cle

Re: Objects in Python

[Chris Angelico]

On Sun, Aug 26, 2012 at 11:43 PM, Steven D'Aprano
 wrote:
> It gets worse: Python has multiple namespaces that are searched.
>
> "Go to the Excelsior Hotel and ask the concierge for Mr Smith. If Mr
> Smith isn't staying there, go across the road to the Windsor Hotel and
> ask there. If he's not there, try the Waldorf Astoria, and if he's not
> there, try the Hyperion."

Does it? I thought the difference between function-scope and
module-scope was compiled in, and everything else boils down to one of
those. Explicit dot notation is different ("ask for Mr Smith, then ask
him where his packages box is, and put this in the box").

Hmm, okay, there's something slightly different with closures. But
it's still unambiguous at compile time.

>>> x=1
>>> def foo(y):
return lambda z: x+y+z

>>> foo(2)(3)
6
>>> import dis
>>> dis.dis(foo(2))
  2   0 LOAD_GLOBAL  0 (x)
  3 LOAD_DEREF   0 (y)
  6 BINARY_ADD
  7 LOAD_FAST0 (z)
 10 BINARY_ADD
 11 RETURN_VALUE

What multiple namespaces are you talking about, where things have to
get looked up at run time?

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

Re: Objects in Python

[Mark Lawrence]

On 26/08/2012 14:34, Chris Angelico wrote:


Okay, that may be a bit of a fairy tale ending and completely illogical.

ChrisA



Then stick to the thread about flexible string representation, unicode 
and typography :)


--
Cheers.

Mark Lawrence.

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

Re: Objects in Python

[Roy Smith]

In article <503a2804$0$6574$c3e8da3$54964...@news.astraweb.com>,
 Steven D'Aprano  wrote:

>>> The mapping of name:address is part of the *compilation* process -- 
>>> the compiler knows that variable 'x' corresponds to location 
>>> 12345678

Just to pick a nit, the compiler probably doesn't know that, but the 
linker does (or maybe even the run-time loader).  However, we can think 
of all of those as just part of the compilation tool chain, and then 
we're good.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Objects in Python

[Chris Angelico]

On Mon, Aug 27, 2012 at 12:02 AM, Mark Lawrence  wrote:
> On 26/08/2012 14:34, Chris Angelico wrote:
>>
>> Okay, that may be a bit of a fairy tale ending and completely illogical.
>>
>> ChrisA
>
> Then stick to the thread about flexible string representation, unicode and
> typography :)

Hehe. Probably nobody on this list will recognize what I said, but
it's a near-quote from "Iolanthe", an opera about fairies. It's the
great denoumont, the solution to everyone's problems. And in the same
way, redefining the "take-address-of" operator could be a perfect
solution... and, just like in Iolanthe, is a rather fundamental
change, and one that would break a lot of things.

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

Re: Objects in Python

[Chris Angelico]

On Mon, Aug 27, 2012 at 12:02 AM, Roy Smith  wrote:
> In article <503a2804$0$6574$c3e8da3$54964...@news.astraweb.com>,
>  Steven D'Aprano  wrote:
>
 The mapping of name:address is part of the *compilation* process --
 the compiler knows that variable 'x' corresponds to location
 12345678
>
> Just to pick a nit, the compiler probably doesn't know that, but the
> linker does (or maybe even the run-time loader).  However, we can think
> of all of those as just part of the compilation tool chain, and then
> we're good.

Hrm. Back when I first started C programming, it was MS-DOS 16-bit
work - segmented addressing (one of the most fascinating insanities
ever to be perpetrated on unsuspecting consumers - why, oh why, if you
want 20-bit addressing, should you invent a system that uses 32 bits
of data in such a non-expandable way?). My program would be loaded
into whatever segment the loader chose, but offsets within that could
be compiled in.

With modern x86 systems there are several more layers of complication,
but in many cases, you can still hard-code offsets within a logical
segment of memory. Set CS to your one code segment and do your jumps
and calls at fixed locations. Set [DEFG]S to your single data segment
and all your data can be at fixed locations too. (Obviously your stack
is referenced relative to SP/BP.)

I'm not familiar with other architectures, but it seems likely that
there's something similar. The segment / base location may change, but
variable 'x' still corresponds to 12345678 within that.

Nits can be fun to pick :)

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

Re: Objects in Python

[Steven D'Aprano]

On Sun, 26 Aug 2012 23:58:31 +1000, Chris Angelico wrote:

> On Sun, Aug 26, 2012 at 11:43 PM, Steven D'Aprano
>  wrote:
>> It gets worse: Python has multiple namespaces that are searched.
>>
>> "Go to the Excelsior Hotel and ask the concierge for Mr Smith. If Mr
>> Smith isn't staying there, go across the road to the Windsor Hotel and
>> ask there. If he's not there, try the Waldorf Astoria, and if he's not
>> there, try the Hyperion."
> 
> Does it? I thought the difference between function-scope and
> module-scope was compiled in,

It is. But local and global scope are not the only two scopes. Python has 
nested scopes. Try these:

x = y = -99
def test():
def inner():
x = 23
def even_more_inner():
print "x is", x
print "y is", y
even_more_inner()
x = 1000
y = 42
inner()

Also, built-ins require a name lookup too. As you point out, locals are 
special, but Python will search an arbitrarily deep set of nested 
nonlocal scopes, then globals, then builtins.

See the introduction of nested-scopes:

http://www.python.org/dev/peps/pep-0227/

and non-locals:

http://www.python.org/dev/peps/pep-3104/


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

Re: Objects in Python

[Chris Angelico]

On Mon, Aug 27, 2012 at 12:18 AM, Steven D'Aprano
 wrote:
> Also, built-ins require a name lookup too. As you point out, locals are
> special, but Python will search an arbitrarily deep set of nested
> nonlocal scopes, then globals, then builtins.

Ah, builtins, forgot that. So yes, global scope involves potentially
two name lookups. But nonlocals aren't searched at run time.

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

argparse localization support

[Kwpolska]

I am using argparse in my project.  I want to localize it, but it
seems to be impossible to change some things.  See this, for example:

usage: trash [-h] [-V] [-e] [-l] [-r] [-v] [-w] [PLIK [PLIK ...]]

Trashman — menedżer śmietnika XDG w Pythonie.

positional arguments:
  PLIK  pliki do wyrzucenia

optional arguments:
  -h, --helpshow this help message and exit
  -V, --version show program's version number and exit

(a snippet of help for Trashman, a Python trash manager, with
LANG='pl_PL.UTF-8'; https://github.com/Kwpolska/trashman )

Anyways, you can see that -h and -V (added semi-automatically by
argparse), “usage:” and “positional/optional arguments:” are still in
English.  It doesn’t look very professional.  Also, I want to use
fancy UTF-8 characters.  Is there a way to fix that?
-- 
Kwpolska 
stop html mail  | always bottom-post
www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
GPG KEY: 5EAAEA16
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: VPS For Python

[python]

> I will really appreciate if someone type the address of any of the following 
> for use with python 
> 1>Webhost 
> 2>Shell Account 
> 3>VPS 

Check out webfaction.com - they provide great support for Python.

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

Re: Flexible string representation, unicode, typography, ...

[Ian Kelly]

On Sun, Aug 26, 2012 at 5:49 AM, Steven D'Aprano
 wrote:
>> Sorry, you do not get it.
>>
>> The rune is an alias for int32. A sequence of runes is a sequence of
>> int32's.
>
> It certainly is not. Runes are variable-width. Here, for example, are a
> number of Go functions which return a single rune and its width in bytes:
>
> http://golang.org/pkg/unicode/utf8/

I think the documentation for those functions is simply badly worded.
The "width in bytes" it returns is not the width of the rune (which as
jmf notes is simply an alias for int32 that stores a single code
point).  It means the UTF-8 width of the character, i.e. the number of
UTF-8 bytes the function "consumed", presumably so that the caller can
then reslice the data with that many bytes fewer.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Flexible string representation, unicode, typography, ...

[Ian Kelly]

On Sun, Aug 26, 2012 at 12:59 AM,   wrote:
> Sorry, you do not get it.
>
> The rune is an alias for int32. A sequence of runes is a
> sequence of int32's. Go do not spend its time in using a
> machinery to work with, to differentiate, to keep in memory
> this sequence according to the *characers* composing this
> "array of code points".
>
> The message is even stronger. Use runes to work comfortably [*]
> with unicode:
> rune -> int32 -> utf32 -> unicode (the perfect scheme, cann't be
> better)

I understand what rune is.  I think you've missed my complaint, which
is that although rune is the basic building block of Unicode strings
-- representing a single Unicode character -- strings in Go are not
built from runes but from bytes.  If you want to do any actual work
with Unicode strings, then you have to first convert them to runes or
arrays of runes.  The conceptual cost of this is that the object
you're working with is no longer a string.

You call this the "perfect scheme" for working with Unicode.  Why does
the "perfect scheme" for Unicode make it *easier* to write buggy code
that only works for ASCII than to write correct code that works for
all characters?  This is IMO where Python 3 gets it right.  When you
want to work with Unicode strings, you just work with Unicode strings
-- none of this nonsense of first explicitly converting the string to
an array of ints that looks nothing like a string at a high level.
The only place Python 3 makes you worry about converting strings is at
the boundaries of your program, where decoding from bytes to strings
and back is necessary.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: VPS For Python

[Littlefield, Tyler]

On 8/26/2012 1:41 AM, coldfire wrote:

I will really appreciate if someone type the address of any of the following 
for use with python
1>Webhost
2>Shell Account
3>VPS


I love Linode, it's amazing and you get decent resources for a decent 
price. If you sign up, I'd really appreciate it if you used my code. 
They also have a realloygood library at linode.com/library to show you 
how to set a lot of stuff up.

http://www.linode.com/?r=7858d151c1ea11c0ce9a1398865b1cc7ad28c19f


I am really new to all this Got web server and shell account but unable to 
figure out how to use it or deploy the Code,
My problem is that I m using lot of third party Library which are mostly not 
supported or I don't know How to make it RUN over Internet



--
Take care,
Ty
http://tds-solutions.net
The aspen project: a barebones light-weight mud engine:
http://code.google.com/p/aspenmud
He that will not reason is a bigot; he that cannot reason is a fool; he that 
dares not reason is a slave.

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

Re: modeling complex data with sqlalchemy

[Littlefield, Tyler]

Hello:
Thanks for the info. IT doesn't really model the data I wanted. The 
contents was easy enough, I'm just going to set up a 1:n relationship on 
the Entity to the actual player. But for components, it's a bit different.
Each component inherits the actual Component class, and has a number of 
attributes on it. I can't just put it in it's own. So I was going to set 
up a table per component and then just store an id and another id for 
what holds it. But my problem is modeling it. I also need the inherited 
data from Component. Would there be a way to do this? I could have:

id, name, component_id
and then SA could use the name as the table's name, and the id as the id 
of the component in the other table.

How would I set this up with SA? Is it a good idea to go this route?

On 8/25/2012 5:53 PM, Dennis Lee Bieber wrote:

On Sat, 25 Aug 2012 14:47:35 -0600, "Littlefield, Tyler"
 declaimed the following in
gmane.comp.python.general:


Hello all:
I had a quick question.
In my game, I have an is-a setup, where all objects contain data like an
id for sqlalchemy, a name, a description and a list of contents.

Well, a "list of contents" comes down to a table of items with a
foreign key to the item "containing" them...

create table objects
(
ID  integer auto-increment primary key,
namevarchar(?),
description varchar(?)
)

1, Wulfraed, something or other
2, Bag of Holding, whatever
3, Sword, some cutting comments
4, Treasure Chest, everyone wants one

create table holdings
(
ID  integer auto-increment primary key,
holder  integer foreign key objects(ID),
holding integer foreign key objects(ID)
)

1, 1, 2
2, 1, 3
3, 2, 4


In order to add functionality to an object, you add components. So for
example, a player would have the Player and Living component associated

create table attribute_types
(
ID  integer auto-increment primary key,
namevarchar(?),
typechar(?),#or an enumeration if supported by the RDBM
#and SQLAlchemy
)

1, Player, Boolean
2, Living, Boolean
3, EdgeWeapon, Boolean
4, Damage, DieRoll
5, ContainerSize, Integer
6, Class, Text

create table attributes
(
ID  integer auto-increment primary key,
describes   integer foreign key objects(ID),
attribute   integer foreign key attribute_types(ID),
value BLOB(?)
)

1, 1, 1, blob(True)
2, 1, 2, blob(True)
3, 3, 3, blob(True)
4, 3, 4, blob("1D8 + 4")
5, 2, 5, blob(-1)   #-1 being unlimited, bag of holding
6, 4, 5, blob(6)#treasure chest holds 6 units of objects
7, 1, 6, blob("Ranger")


Now, you could add another layer of indirection -- a table of
pre-defined object /types/ (different types of containers, swords, other
weapons), and have each instance (the ones shown in "objects") refer to
the object type table, and the object type table is what the object
attributes refers to.





--
Take care,
Ty
http://tds-solutions.net
The aspen project: a barebones light-weight mud engine:
http://code.google.com/p/aspenmud
He that will not reason is a bigot; he that cannot reason is a fool; he that 
dares not reason is a slave.

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

Re: argparse localization support

[Peter Otten]

Kwpolska wrote:

> I am using argparse in my project.  I want to localize it, but it
> seems to be impossible to change some things.  See this, for example:
> 
> usage: trash [-h] [-V] [-e] [-l] [-r] [-v] [-w] [PLIK [PLIK ...]]
> 
> Trashman — menedżer śmietnika XDG w Pythonie.
> 
> positional arguments:
>   PLIK  pliki do wyrzucenia
> 
> optional arguments:
>   -h, --helpshow this help message and exit
>   -V, --version show program's version number and exit
> 
> (a snippet of help for Trashman, a Python trash manager, with
> LANG='pl_PL.UTF-8'; https://github.com/Kwpolska/trashman )
> 
> Anyways, you can see that -h and -V (added semi-automatically by
> argparse), “usage:” and “positional/optional arguments:” are still in
> English.  It doesn’t look very professional.  Also, I want to use
> fancy UTF-8 characters.  Is there a way to fix that?

I don't know much about gettext, but the following suggests that most 
strings in argparse are properly wrapped:

$ cat localize_argparse.py
import gettext

def my_gettext(s):
return s.upper()
gettext.gettext = my_gettext

import argparse

if __name__ == "__main__":
parser = argparse.ArgumentParser()
parser.add_argument("-V", action="version")
args = parser.parse_args()
$ python localize_argparse.py -h
USAGE: localize_argparse.py [-h] [-V]

OPTIONAL ARGUMENTS:
  -h, --help  SHOW THIS HELP MESSAGE AND EXIT
  -V  show program's version number and exit

The workaround for the "-V" option would be to add the help message 
explicitly

parser.add_argument("-V", ..., help=_("show..."))

You still have to provide all translations yourself.

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

Re: Unittest - testing for filenames and filesize

[Tigerstyle]

Thanks Rob,

I'v modified the test_3 like this:


def test_3(self):
f = open("test.dat", "wb")
filesize = (b'b'*100)
f.write(filesize)
f.close()
statinfo = os.stat("test.dat")
self.assertEqual(statinfo.st_size, filesize)

I'm still getting AssertionError and the error says: 100 !=b'

Help appreciated.

T 

kl. 21:04:54 UTC+2 fredag 24. august 2012 skrev Robert Day følgende:
> On Fri, 2012-08-24 at 09:20 -0700, Tigerstyle wrote:
> 
> 
> 
> > def test_3(self):
> 
> > f = open("test.dat", "wb")
> 
> > filesize = b"0"*100
> 
> > f.write(filesize)
> 
> > f.close()
> 
> > self.assertEqual(os.stat, filesize)
> 
> 
> 
> > The test_3 is to test if the created binary file har the size of 1 million 
> > bytes. Somehow it is not working. Any suggestions?
> 
> >  
> 
> 
> 
> rob@rivertam:~$ python
> 
> Python 2.7.3 (default, Jul 24 2012, 10:05:38) 
> 
> [GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2
> 
> Type "help", "copyright", "credits" or "license" for more information.
> 
> >>> import os
> 
> >>> os.stat
> 
> 
> 
> >>> 
> 
> 
> 
> So that's what 'os.stat' is. Why are you testing whether that's equal to
> 
> b"0"*100?
> 
> 
> 
> (You may find the documentation on os.stat at
> 
> http://docs.python.org/library/os.html#os.stat helpful; it's a function
> 
> which takes a path as its argument, and returns an object with some
> 
> relevant attributes.)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Unittest - testing for filenames and filesize

[Rob Day]

On Sun, 2012-08-26 at 10:36 -0700, Tigerstyle wrote:
> self.assertEqual(statinfo.st_size, filesize)
> 
> I'm still getting AssertionError and the error says: 100 !=b'
> 
> 

filesize is the character 'b' repeated one million times (the contents
of the file, in other words). statinfo.st_size is the number of bytes in
the file, i.e. 1,000,000. So when your assertEqual code checks if those
two values are equal, what do you think happens?

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

Re: Unittest - testing for filenames and filesize

[Tigerstyle]

Ahh,

thank you very much Rob.

Fixed now.

Have a great day.

T

kl. 19:51:54 UTC+2 søndag 26. august 2012 skrev Rob Day følgende:
> On Sun, 2012-08-26 at 10:36 -0700, Tigerstyle wrote:
> 
> > self.assertEqual(statinfo.st_size, filesize)
> 
> > 
> 
> > I'm still getting AssertionError and the error says: 100 !=b'
> 
> > 
> 
> > 
> 
> 
> 
> filesize is the character 'b' repeated one million times (the contents
> 
> of the file, in other words). statinfo.st_size is the number of bytes in
> 
> the file, i.e. 1,000,000. So when your assertEqual code checks if those
> 
> two values are equal, what do you think happens?

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

sys.path in python3.3

[Nicholas Cole]

Dear List,

In all previous versions of python, I've been able to install packages
into the path:

~/Library/Python/$py_version_short/site-packages

but in the rc builds of python 3.3 this is no longer part of sys.path.

Before I go hacking the install, is there a reason that this path was
removed?  Is there a recommended way to get it back, or is this a
gentle way of pushing us all to use virtualenv rather than installing
user-specific packages?

Best wishes,

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

Re: sys.path in python3.3

[Ned Deily]

In article 
,
 Nicholas Cole  wrote:
> In all previous versions of python, I've been able to install packages
> into the path:
> 
> ~/Library/Python/$py_version_short/site-packages
> 
> but in the rc builds of python 3.3 this is no longer part of sys.path.
> 
> Before I go hacking the install, is there a reason that this path was
> removed?  Is there a recommended way to get it back, or is this a
> gentle way of pushing us all to use virtualenv rather than installing
> user-specific packages?

It should be working if you are using an OS X framework build.  What is 
the value of sys.path?

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

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

Re: sys.path in python3.3

[Hans Mulder]

On 26/08/12 21:21:15, Ned Deily wrote:
> In article 
> ,
>  Nicholas Cole  wrote:
>> In all previous versions of python, I've been able to install packages
>> into the path:
>>
>> ~/Library/Python/$py_version_short/site-packages
>>
>> but in the rc builds of python 3.3 this is no longer part of sys.path.
>>
>> Before I go hacking the install, is there a reason that this path was
>> removed?  Is there a recommended way to get it back, or is this a
>> gentle way of pushing us all to use virtualenv rather than installing
>> user-specific packages?
> 
> It should be working if you are using an OS X framework build.  What is 
> the value of sys.path?

Python 3.3.0rc1 (v3.3.0rc1:8bb5c7bc46ba, Aug 25 2012, 09:42:40)
[GCC 4.2.1 (Apple Inc. build 5577)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> for d in sys.path:
... print(d)
...

/Library/Frameworks/Python.framework/Versions/3.3/lib/python33.zip
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/plat-darwin
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages


This is using the Python 3.3 for MacOS binary from python.org.


-- HansM



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

Re: sys.path in python3.3

[Nicholas Cole]

On Sun, Aug 26, 2012 at 8:21 PM, Ned Deily  wrote:
> In article
> ,
>  Nicholas Cole  wrote:
>> In all previous versions of python, I've been able to install packages
>> into the path:
>>
>> ~/Library/Python/$py_version_short/site-packages
>>
>> but in the rc builds of python 3.3 this is no longer part of sys.path.
>>
>> Before I go hacking the install, is there a reason that this path was
>> removed?  Is there a recommended way to get it back, or is this a
>> gentle way of pushing us all to use virtualenv rather than installing
>> user-specific packages?
>
> It should be working if you are using an OS X framework build.  What is
> the value of sys.path?

I'm using the compiled version supplied by python.org.


Python 3.3.0rc1 (v3.3.0rc1:8bb5c7bc46ba, Aug 25 2012, 10:09:29)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/Library/Frameworks/Python.framework/Versions/3.3/lib/python33.zip',
'/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3',
'/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/plat-darwin',
'/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload',
'/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages']
>>>

This contrasts with (for python3.1)

Python 3.1.1 (r311:74543, Aug 24 2009, 18:44:04)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/Library/Frameworks/Python.framework/Versions/3.1/lib/python31.zip',
'/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1',
'/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/plat-darwin',
'/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/lib-dynload',
'/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/site-packages',
'/Users/nicholas/Library/Python/3.1/site-packages']


Best wishes,

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

Re: Flexible string representation, unicode, typography, ...

[Steven D'Aprano]

On Sun, 26 Aug 2012 09:40:13 -0600, Ian Kelly wrote:

> I think the documentation for those functions is simply badly worded.
> The "width in bytes" it returns is not the width of the rune (which as
> jmf notes is simply an alias for int32 that stores a single code point).

Is this documented somewhere?

I can't tell you how long I spent unsuccessfully googling for variations 
on "go language runes", which unsurprisingly mostly came back with pages 
about Germanic runes and elf runes but not Go runes. I read the golang 
FAQs, which mentioned Unicode *once* and runes not at all. Obviously Go 
language programmers don't care much about Unicode.


>  It means the UTF-8 width of the character, i.e. the number of UTF-8
> bytes the function "consumed", presumably so that the caller can then
> reslice the data with that many bytes fewer.

That makes sense, given the lousy string implementation and API they're 
working with.

I note that not all 32-bit ints are valid code points. I suppose I can 
see sense in having rune be a 32-bit integer value limited to those valid 
code points. (But, dammit, why not call it a code point?) But if rune is 
merely an alias for int32, why not just call it int32?


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

Re: Flexible string representation, unicode, typography, ...

[Dan Sommers]

On 2012-08-26 at 20:13:21 +,
Steven D'Aprano  wrote:

> I note that not all 32-bit ints are valid code points. I suppose I can
> see sense in having rune be a 32-bit integer value limited to those
> valid code points. (But, dammit, why not call it a code point?) But if
> rune is merely an alias for int32, why not just call it int32?

Having a "code point" type is a good idea.  If nothing else, human code
readers can tell that you're doing something with characters rather than
something with integers.  If your language provides any sort of type
safety, then you get that, too.

Calling your code points int32 is a bad idea for the same reason that it
turned out to be a bad idea to call all my old ASCII characters int8.
Or all my pointers int (or unsigned int), for n in 16, 20, 24, 32,
36, 48, or 64 (or I'm sure other values of n that I never had the pain
or pleasure of using).

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

Re: sys.path in python3.3

[Ned Deily]

In article 
,
 Nicholas Cole  wrote:

> On Sun, Aug 26, 2012 at 8:21 PM, Ned Deily  wrote:
> > In article
> > ,
> >  Nicholas Cole  wrote:
> >> In all previous versions of python, I've been able to install packages
> >> into the path:
> >>
> >> ~/Library/Python/$py_version_short/site-packages
> >>
> >> but in the rc builds of python 3.3 this is no longer part of sys.path.
> >>
> >> Before I go hacking the install, is there a reason that this path was
> >> removed?  Is there a recommended way to get it back, or is this a
> >> gentle way of pushing us all to use virtualenv rather than installing
> >> user-specific packages?
> >
> > It should be working if you are using an OS X framework build.  What is
> > the value of sys.path?
> 
> I'm using the compiled version supplied by python.org.

The directory needs to exist otherwise the path is not included (see 
site.py).

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

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

Re: Flexible string representation, unicode, typography, ...

[Ian Kelly]

On Sun, Aug 26, 2012 at 2:13 PM, Steven D'Aprano
 wrote:
> On Sun, 26 Aug 2012 09:40:13 -0600, Ian Kelly wrote:
>
>> I think the documentation for those functions is simply badly worded.
>> The "width in bytes" it returns is not the width of the rune (which as
>> jmf notes is simply an alias for int32 that stores a single code point).
>
> Is this documented somewhere?

http://golang.org/ref/spec#Numeric_types
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Objects in Python

[Steven D'Aprano]

On Mon, 27 Aug 2012 00:54:05 +1000, Chris Angelico wrote:

> On Mon, Aug 27, 2012 at 12:18 AM, Steven D'Aprano
>  wrote:
>> Also, built-ins require a name lookup too. As you point out, locals are
>> special, but Python will search an arbitrarily deep set of nested
>> nonlocal scopes, then globals, then builtins.
> 
> Ah, builtins, forgot that. So yes, global scope involves potentially two
> name lookups. But nonlocals aren't searched at run time.

Well, whaddyaknow. You're right.

x = 'globals'
def test(switch):
def a():
if switch == 1:
x = 'a'
def b():
if switch == 2:
x = 'b'
def c():
print "x found in", x
c()
b()
a()


Tried that in Jython, IronPython and Python 2.7, and I get the same 
result: only test(2) succeeds.

I even tried it in Python 2.2, which does the same thing.

(2.1 and older don't have nested scopes, so there's no point in going 
back further.)


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

Re: sys.path in python3.3

[Nicholas Cole]

On Sun, Aug 26, 2012 at 10:23 PM, Ned Deily  wrote:
> In article
> ,
>  Nicholas Cole  wrote:
>
>> On Sun, Aug 26, 2012 at 8:21 PM, Ned Deily  wrote:
>> > In article
>> > ,
>> >  Nicholas Cole  wrote:
>> >> In all previous versions of python, I've been able to install packages
>> >> into the path:
>> >>
>> >> ~/Library/Python/$py_version_short/site-packages
>> >>
>> >> but in the rc builds of python 3.3 this is no longer part of sys.path.
>> >>
>> >> Before I go hacking the install, is there a reason that this path was
>> >> removed?  Is there a recommended way to get it back, or is this a
>> >> gentle way of pushing us all to use virtualenv rather than installing
>> >> user-specific packages?
>> >
>> > It should be working if you are using an OS X framework build.  What is
>> > the value of sys.path?
>>
>> I'm using the compiled version supplied by python.org.
>
> The directory needs to exist otherwise the path is not included (see
> site.py).

It certainly does exist. Distutils will happily put packages into it,
but import won't find them.

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

Re: sys.path in python3.3

[Ned Deily]

In article 
,
 Nicholas Cole  wrote:
> It certainly does exist. Distutils will happily put packages into it,
> but import won't find them.

That's odd!  It works for me on 10.8 and it worked for me yesterday on 
10.7 which I tested just after completing the python.org installer 
builds.  Perhaps there is some permission issue.  Or the path name isn't 
quite correct.  Or you have some PYTHON* environment variable set, like 
PYTHONNOUSERSITE?

Here's a simple case I just tried installing Distribute using --user:

$ ls -ld Library/
drwx--@ 59 nad  staff  2074 Aug 26 15:03 Library//
$ ls -ld Library/Python/
drwxr-x---  5 nad  staff  170 Aug 25 14:37 Library/Python//
$ ls -ld Library/Python/3.3
drwx--  4 nad  staff  136 Aug 25 14:37 Library/Python/3.3/
$ ls -ld Library/Python/3.3/lib/
drwx--  3 nad  staff  102 Aug 25 14:37 Library/Python/3.3/lib//
$ ls -ld Library/Python/3.3/lib/python/
drwx--  3 nad  staff  102 Aug 25 14:37 
Library/Python/3.3/lib/python//
$ ls -ld Library/Python/3.3/lib/python/site-packages/
drwx--  6 nad  staff  374 Aug 25 14:37 
Library/Python/3.3/lib/python/site-packages//
$ mv Library/Python/ Library/PythonDis
$ /usr/local/bin/python3.3
Python 3.3.0rc1 (v3.3.0rc1:8bb5c7bc46ba, Aug 25 2012, 10:09:29) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> pp(sys.path)
['',
 '/Library/Frameworks/Python.framework/Versions/3.3/lib/python33.zip',
 '/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3',
 
'/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/plat-dar
win',
 
'/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynl
oad',
 
'/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-pac
kages']
>>> ^D
$ curl -O http://python-distribute.org/distribute_setup.py
  % Total% Received % Xferd  Average Speed   TimeTime Time  
Current
 Dload  Upload   Total   SpentLeft  
Speed
100 16295  100 162950 0  18199  0 --:--:-- --:--:-- --:--:-- 
31518
$ /usr/local/bin/python3.3 distribute_setup.py --user
Downloading 
http://pypi.python.org/packages/source/d/distribute/distribute-0.6.28.tar
.gz
Extracting in /var/folders/fm/9wjgctqx61n796zt88qmmnxcgn/T/tmp25bmgw
Now working in 
/var/folders/fm/9wjgctqx61n796zt88qmmnxcgn/T/tmp25bmgw/distribute-0.6
.28
Installing Distribute
[...]
creating dist
creating 'dist/distribute-0.6.28-py3.3.egg' and adding 
'build/bdist.macosx-10.6-intel/egg' to it
removing 'build/bdist.macosx-10.6-intel/egg' (and everything under it)
Processing distribute-0.6.28-py3.3.egg
creating 
/Users/nad/Library/Python/3.3/lib/python/site-packages/distribute-0.6.28-
py3.3.egg
Extracting distribute-0.6.28-py3.3.egg to 
/Users/nad/Library/Python/3.3/lib/python/site-packages
Adding distribute 0.6.28 to easy-install.pth file
Installing easy_install-3.3 script to /Users/nad/Library/Python/3.3/bin
Installing easy_install script to /Users/nad/Library/Python/3.3/bin

Installed 
/Users/nad/Library/Python/3.3/lib/python/site-packages/distribute-0.6.28-
py3.3.egg
Processing dependencies for distribute==0.6.28
Finished processing dependencies for distribute==0.6.28
After install bootstrap.
Don't have permissions to write 
/Users/nad/Library/Python/3.3/lib/python/site-packages/setuptools-0.6c11-
py3.3.egg-info, skipping
Creating 
/Users/nad/Library/Python/3.3/lib/python/site-packages/setuptools-0.6c11-
py3.3.egg-info
Creating 
/Users/nad/Library/Python/3.3/lib/python/site-packages/setuptools.pth
$ ls Library/Py
Python/PythonDis/ 
$ ls Library/Python/3.3/
bin/ lib/ 
$ ls Library/Python/3.3/lib/python/site-packages/
distribute-0.6.28-py3.3.egg/  setuptools-0.6c11-py3.3.egg-info
easy-install.pth  setuptools.pth
$ ls Library/Python/3.3/lib/python/site-packages/
distribute-0.6.28-py3.3.egg/  setuptools-0.6c11-py3.3.egg-info
easy-install.pth  setuptools.pth
$ /usr/local/bin/python3.3
Python 3.3.0rc1 (v3.3.0rc1:8bb5c7bc46ba, Aug 25 2012, 10:09:29) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> pp(sys.path)
['',
 
'/Users/nad/Library/Python/3.3/lib/python/site-packages/distribute-0.6.28
-py3.3.egg',
 '/Library/Frameworks/Python.framework/Versions/3.3/lib/python33.zip',
 '/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3',
 
'/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/plat-dar
win',
 
'/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynl
oad',
 '/Users/nad/Library/Python/3.3/lib/python/site-packages',
 
'/Users/nad/Library/Python/3.3/lib/python/site-packages/setuptools-0.6c11
-py3.3.egg-info',
 
'/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-pac
kages']
>>> import setuptools
>>> setuptools.__file__
'/Users/nad/Library/Python/3.3/lib/python/site-packages/distribute-0.6.

Re: Objects in Python

[Steven D'Aprano]

On Sun, 26 Aug 2012 16:12:40 -0400, Dennis Lee Bieber wrote:

> On 26 Aug 2012 13:43:33 GMT, Steven D'Aprano
>  declaimed the following in
> gmane.comp.python.general:
> 
> 
> 
>> (In some older versions of Python, wildcard imports are allowed, and
>> the function then falls back on a namespace instead of fixed locations.
>> That is no longer the case in Python 3.2 at least.)
>>
>   Must be really old:

Not really. You get a SyntaxWarning back to at least 2.2, but the 
fallback namespace behaviour does work through to 2.7:

py> assert 'pi' not in globals()
py> def test():
... from math import *
... print pi
... 
:1: SyntaxWarning: import * only allowed at module level
py> test()
3.14159265359

What I didn't realise until just now is that it's a bit more complicated 
than that. Using import * in a function you can end up with two distinct 
sets of locals, those using numbered memory slots (effectively address-
based), and those using a dict namespace.

If you assign to a name in the function, it still gets turned into a 
memory slot rather than being in a dict. Decompiling the function shows 
that such local are still accessed using LOAD_FAST and STORE_FAST op-
codes. (That's the case all the way back to Python 1.5 at least.)

But if you *don't* assign to the name, Python uses LOAD_NAME instead, 
which searches namespace. In this case pi is not found in the global or 
built-in namespaces, so there must be a local, dict-based namespace in 
addition to the usual LOAD_FAST slots. Hence, two distinct sets of locals.


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

Re: Flexible string representation, unicode, typography, ...

[Steven D'Aprano]

On Sun, 26 Aug 2012 15:42:00 -0600, Ian Kelly wrote:

> On Sun, Aug 26, 2012 at 2:13 PM, Steven D'Aprano
>  wrote:
>> On Sun, 26 Aug 2012 09:40:13 -0600, Ian Kelly wrote:
>>
>>> I think the documentation for those functions is simply badly worded.
>>> The "width in bytes" it returns is not the width of the rune (which as
>>> jmf notes is simply an alias for int32 that stores a single code
>>> point).
>>
>> Is this documented somewhere?
> 
> http://golang.org/ref/spec#Numeric_types

Thanks.

Well that's just plain nuts.


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

Re: Flexible string representation, unicode, typography, ...

[Paul Rubin]

Steven D'Aprano  writes:
>> http://golang.org/ref/spec#Numeric_types
> Thanks.
> Well that's just plain nuts.

I'm not sure how Rust handles Unicode, but overall I think it is more
clueful than Go while having sort of comparable goals.  See:
http://rust-lang.org .
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: calling loaded DLL function expecting POINT * argument

[Tim Roberts]

Tim Williams  wrote:

>Hello all,
>
>I'm trying to use the ctypes module to call functions in a DLL. I've
>figured out how to modify my path so the library is found, and I can 
>call LoadLibrary on it, but one of the functions expects an array of
> POINTS. Here is the prototype from the .h file:
>
>
>TRACKER_API HRESULT InitializeMask(HANDLE pHandle, int nWidth, int nHeight, 
>POINT* ptMasks, int nNumPoints);

How is TRACKER_API defined?  You're using ctypes.oledll, which uses the
__stdcall calling convention.  It's possible your DLL is defined as
__cdecl.  Try cdll.LoadLibrary instead of oledll.LoadLibrary.
-- 
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
-- 
http://mail.python.org/mailman/listinfo/python-list

Python 2.6 and Sqlite3 - Slow

[bruceg113355]

My program uses Python 2.6 and Sqlite3 and connects to a network database 100 
miles away. 
My program reads approx 60 records (4000 bytes) from a Sqlite database in less 
than a second. 
Each time the user requests data, my program can continuously read 60 records 
in less than a second. 
However, if I access the network drive  (e.g.  DOS command DIR /S)  while my 
program is running, my program takes 20 seconds to read the same 60 records. If 
I restart my program, my program once again takes less than a second to read 60 
records.

Any ideas?

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

Python list archives double-gzipped?

[Tim Chase]

Playing around with the mbox module, I reached into the archives[1]
to grab some real-world data files[2].  To successfully unpack the
contents to an mbox file, I had to do the following:

  bash$ gunzip 2012-July.txt.gz
  bash$ mv 2012-July.txt 2012-July.txt.gz
  bash$ gunzip 2012-July.txt.gz

So it looks like some python-list@ archiving process is double
gzip'ing the archives.  Can anybody else confirm this and get the
info the right people?

-tkc

[1]
http://mail.python.org/pipermail/python-list/

[2]
http://mail.python.org/pipermail/python-list/2012-July.txt.gz


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

Make error when installing Python 1.5

[Steven D'Aprano]

Yes, you read the subject line right -- Python 1.5. Yes, I am nuts ;)

(I like having old versions of Python around for testing historical 
behaviour.)

On Debian squeeze, when I try to build Python 1.5, I get this error:

fileobject.c:590: error: conflicting types for ‘getline’
/usr/include/stdio.h:651: note: previous declaration of ‘getline’ was here
make[1]: *** [fileobject.o] Error 1
make[1]: Leaving directory `/home/steve/personal/python/Python-1.5.2/
Objects'
make: *** [Objects] Error 2


But when I do the same on Centos 5, it builds successfully and I can then 
run "sudo make altinstall" to install it. What's going on here and what 
do I need to do to fix this?

Grepping stdio.h gives the same content on both Centos and Debian:

$ grep getline /usr/include/stdio.h
extern _IO_ssize_t getline (char **__restrict __lineptr,


For those wanting to play around with it:

wget http://www.python.org/ftp/python/src/py152.tgz
tar xzf py152.tgz
cd Python-1.5.2/
./configure
make
sudo make altinstall




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

Re: Make error when installing Python 1.5

[Cameron Simpson]

On 27Aug2012 01:54, Steven D'Aprano  
wrote:
| Yes, you read the subject line right -- Python 1.5. Yes, I am nuts ;)
| 
| (I like having old versions of Python around for testing historical 
| behaviour.)
| 
| On Debian squeeze, when I try to build Python 1.5, I get this error:
| 
| fileobject.c:590: error: conflicting types for ‘getline’
| /usr/include/stdio.h:651: note: previous declaration of ‘getline’ was here
| make[1]: *** [fileobject.o] Error 1
| make[1]: Leaving directory `/home/steve/personal/python/Python-1.5.2/
| Objects'
| make: *** [Objects] Error 2
[...]

I would take the compile line for fileobject.c and supposing it to look
like this:

  gcc -c -blah fileobject.c

run it by hand as:

  gcc -E -blah fileobject.c >fileobject.cpp

and examine the preprocessor output (initially with grep, then with
vi/emacs).

I would expect the lines for getline to be different, with some macro
definition occuring between the first and second occurence.

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

Calling External (Perl)Script in Python

[Pervez Mulla]

Hi,

I am trying to call perl script in my python view.py and store that data in 
logfile 

On shell I am able to display data. I wanna call that data on logfile , How can 
i do this ...?

I wanna call perl objects in python ... So , How can I pass all that stuff in 
python(firstname, lastname, username)

Please help
Pervez
-- 
http://mail.python.org/mailman/listinfo/python-list