Re: numpy installation

[David Cournapeau]

Hi Jia,

On Sun, Jul 25, 2010 at 12:01 PM, Jia Hu  wrote:
> Hello:
>
> I tried to install numpy 1.4.1 from source under ubuntu following
> instruction at http://docs.scipy.org/doc/numpy/user/install.html
> I type "" python setup.py build –help-fcompiler ""  and it says gnu95 is
> found. Then I run ""python setup.py build –fcompiler=gnu95"". There is
> error.

Please state the full error. Saying that there is an error is
generally unhelpful.

Also, you are more likely to receive good information on the numpy ML:

http://www.scipy.org/Mailing_Lists

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

Re: Are those features still the same?

[francogrex]

Terry Reedy wrote:
>As other have said, mostly, but I would change the following...

Thanks for all those who replied. I know these are not all the features but 
some of them and again this is not a comparison but a little taste of what 
python offers today, and the replies were very informative. By the way Peter 
Norvig is not biased, he works for Google research and is a supporter of 
programming in any language, especially in Python.




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

Re: Library versions

[Lawrence D'Oliveiro]

In message 
<2cb0c88b-58ea-4704-8578-2ebd766f1...@t10g2000yqg.googlegroups.com>, Peo 
wrote:

> My current plan is to call the library something like 'foo1' and
> import it into scripts like 'import foo1 as foo'. Releases that change the
> API would be installed as 'foo2', 'foo3' and so on. This works fine but it
> will be quite difficult to create new releases (documentation and library
> code are littered with references to 'foo1').

I don’t understand why this is a problem. The references to “foo1” are 
because it is “foo1” that implements those facilities, is it not? When 
“foo2” comes along, you will introduce that name where specifying the 
facilities specific to it, will you not? Where both modules provide the same 
facilities, you will have to mention both names, and only in those cases.

I don’t see how you can possibly short-cut this process and still produce 
correct documentation.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multiple versions of Python coexisting in the same OS

[Gelonida]

Hi Edward,

On 07/25/2010 04:40 AM, Edward Diener wrote:

> I found the solutions too exotic for actual use, and completely
> ineffectual for the cases I originally cited. The people in that thread
> seem to have completely forgotten that Python can be invoked externally
> and internally both through executing 'python(w) xxx' and through
> executing a file with the file extension(s) associated with Python. They
> seem to have forgotten this can be within scripts or any other program
> using Python, both written by themselves and by others, and not just by
> their typing 'python(w) xxx' somewhere. Their solutions seem to believe
> that only they will externally be i9nvoking Python and only for their
> own written scripts, as opposed to the many libraries using Python as
> well as the Python distribution itself.
> 
> The best solution is some program which changes the PATH and the Python
> file type associations depending on which version of Python one wants to
> use on one's own system when more than one Python version must coexist
> with others. I will probably write such a program for myself.
> 
Hi Edward,

changing the path and is perfect for people who use consoles.
(under linux there's virtuelenv for his and it's great)

changing the file association is perfect for people who'd know at which
time they want to use which version of python.

The usecase, that I'm nore aware of however is somethig like having some
scripts / directories, that should use one version of python
and others that shoud use another.
In unix you do this normally with the 'shebang line'
( e.g.  #!/usr/bin/env/python2.6 )

There the windows solution could be something like a small 'pystarter'
program, which would decide depending on the file's location / the
file's first line which python should be started.




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

Re: Socket performance

[Roy Smith]

In article <4c4bd0b1$0$1624$742ec...@news.sonic.net>,
 John Nagle  wrote:

> 1.  When writing to a TCP socket, write everything you have to write
> with one "send" or "write" operation if at all possible.
> Don't write a little at a time.  That results in sending small
> packets, because sockets are "flushed" after each write.

There's nothing that guarantees that a single write won't be split into 
multiple packets, nor that multiple writes won't be coalesced into a 
single packet.  Or any combination of splitting and coalescing that the 
kernel feels like.

That being said, for any sane implementation, what John says is true 
most of the time, and is indeed a reasonable optimization.  Just don't 
depend on it being true all the time.  The most common case where it 
will not be true is if you're trying to send a large amount of data and 
exceed the MTU of the network.  Then you are certain to get 
fragmentation.

Depending on what you're doing, this can be a point of networking 
trivia, or it can be the difference between your application working and 
not working.  If you're just streaming data from one place to another, 
you don't have to worry about it.  But, if you're doing some sort of 
interactive protocol where you send a command, wait for a respond, send 
another command, etc, you really do need to be aware of how this works.

Let's say you're writing something like a HTTP client.  You send a bunch 
of headers, then expect to get back something like "200 OK\r\n", or "404 
Not Found\r\n".  You can't just do a read() on the socket and then 
examine the string to see if the first three characters are "200" or 
"404", because (regardless of how the server sent them), it is legal for 
your read() to return just a single character (i.e. "2"), and then for 
the next read() to get "00 OK\r\n".  You need to do buffering inside 
your application which keeps doing read() until you find the "\r\n" (and 
stops there, even if the read() returned more data beyond that).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multiple versions of Python coexisting in the same OS

[Edward Diener]

On 7/25/2010 6:07 AM, Gelonida wrote:

Hi Edward,

On 07/25/2010 04:40 AM, Edward Diener wrote:


I found the solutions too exotic for actual use, and completely
ineffectual for the cases I originally cited. The people in that thread
seem to have completely forgotten that Python can be invoked externally
and internally both through executing 'python(w) xxx' and through
executing a file with the file extension(s) associated with Python. They
seem to have forgotten this can be within scripts or any other program
using Python, both written by themselves and by others, and not just by
their typing 'python(w) xxx' somewhere. Their solutions seem to believe
that only they will externally be i9nvoking Python and only for their
own written scripts, as opposed to the many libraries using Python as
well as the Python distribution itself.

The best solution is some program which changes the PATH and the Python
file type associations depending on which version of Python one wants to
use on one's own system when more than one Python version must coexist
with others. I will probably write such a program for myself.


Hi Edward,

changing the path and is perfect for people who use consoles.
(under linux there's virtuelenv for his and it's great)

changing the file association is perfect for people who'd know at which
time they want to use which version of python.


The problem with this is that you forget that a script can invoke Python 
internally. So whether one uses the console or file association method 
of invoking Python externally, any already written script can use either 
internally.




The usecase, that I'm nore aware of however is somethig like having some
scripts / directories, that should use one version of python
and others that shoud use another.
In unix you do this normally with the 'shebang line'
( e.g.  #!/usr/bin/env/python2.6 )

There the windows solution could be something like a small 'pystarter'
program, which would decide depending on the file's location / the
file's first line which python should be started.


This does not work when Python is invoked internally via a file 
association. That was the point of my saying that the simple solutions 
do not work.

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

Re: Light-weight/very-simple version control under Windows using Python?

[Anssi Saari]

pyt...@bdurham.com writes:

> 1. Use an existing version control utility. There are lots of options
> here(!), any recommendations on a light weight, open source one that
> xcopy installs under Windows with lots of command line options?

Personally, I like RCS. It seems fulfil your requirements. You can get
it for Windows from http://www.cs.purdue.edu/homes/trinkle/RCS/.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multiple versions of Python coexisting in the same OS

[Edward Diener]

On 7/25/2010 2:20 AM, Steven D'Aprano wrote:

On Sat, 24 Jul 2010 22:03:48 -0700, Chris Rebert wrote:


Are the .py and .pyc extensions the only ones which are associated with
Python or are there others, for a normal Python installation in Windows
?


There's also .pyw


Also .pyo

.py = Python source code, usually associated with command line Python
.pyc = Python byte code
.pyo = Python optimized byte code
.pyw = is Windows only, and shouldn't open a console window.


Thanks ! I had forgotten about .pyo and .pyw under Windows.


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

Re: Socket performance

[Navkirat Singh]

On 25-Jul-2010, at 5:52 PM, Roy Smith wrote:

> In article <4c4bd0b1$0$1624$742ec...@news.sonic.net>,
> John Nagle  wrote:
> 
>>1.  When writing to a TCP socket, write everything you have to write
>>with one "send" or "write" operation if at all possible.
>>Don't write a little at a time.  That results in sending small
>>packets, because sockets are "flushed" after each write.
> 
> There's nothing that guarantees that a single write won't be split into 
> multiple packets, nor that multiple writes won't be coalesced into a 
> single packet.  Or any combination of splitting and coalescing that the 
> kernel feels like.
> 
> That being said, for any sane implementation, what John says is true 
> most of the time, and is indeed a reasonable optimization.  Just don't 
> depend on it being true all the time.  The most common case where it 
> will not be true is if you're trying to send a large amount of data and 
> exceed the MTU of the network.  Then you are certain to get 
> fragmentation.
> 
> Depending on what you're doing, this can be a point of networking 
> trivia, or it can be the difference between your application working and 
> not working.  If you're just streaming data from one place to another, 
> you don't have to worry about it.  But, if you're doing some sort of 
> interactive protocol where you send a command, wait for a respond, send 
> another command, etc, you really do need to be aware of how this works.
> 
> Let's say you're writing something like a HTTP client.  You send a bunch 
> of headers, then expect to get back something like "200 OK\r\n", or "404 
> Not Found\r\n".  You can't just do a read() on the socket and then 
> examine the string to see if the first three characters are "200" or 
> "404", because (regardless of how the server sent them), it is legal for 
> your read() to return just a single character (i.e. "2"), and then for 
> the next read() to get "00 OK\r\n".  You need to do buffering inside 
> your application which keeps doing read() until you find the "\r\n" (and 
> stops there, even if the read() returned more data beyond that).
> -- 
> http://mail.python.org/mailman/listinfo/python-list

Thanks John, Roy. I really appreciate your valuable input. I have made a note 
of what you have said and will implement keeping the same in mind : )

Nav

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

Re: Unicode error

[Nobody]

On Fri, 23 Jul 2010 18:27:50 -0400, Terry Reedy wrote:

> But in the 
> meanwhile, once you get an error, you know what it is. You can 
> intentionally feed code bad data and see what you get. And then maybe 
> add a test to make sure your code traps such errors.

That doesn't really help with exceptions which are triggered by external
factors rather than explicit inputs.

Also, if you're writing libraries (rather than self-contained programs),
you have no control over the arguments. Coupled with the fact that
duck typing is quite widely advocated in Python circles, you're stuck with
the possibility that any method call on any argument can raise any
exception. This is even true for calls to standard library functions or
methods of standard classes if you're passing caller-supplied objects as
arguments.

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

Re: Multiple versions of Python coexisting in the same OS

[Thomas Jollans]

On 07/25/2010 02:46 PM, Edward Diener wrote:
> The problem with this is that you forget that a script can invoke Python
> internally. So whether one uses the console or file association method
> of invoking Python externally, any already written script can use either
> internally.

Maybe it's just me, but I think that a script that does this is quite
simply badly written: it *will* break on systems that have multiple
Python versions.

If you let .py scripts specify which interpreter they'd like to be run
with in the first line, with some sort of pystarter script that you map
to the file extensions (or by using UNIX), this should work equally well
no matter if the script being run by a script or by a user.

If you invoke the Python interpreter directly, you should NEVER EVER
assume that the interpreter is in a certain place, or on the PATH. It's
a stupid idea: what if it's not? Instead, if you really must, invoke
sys.executable instead of guessing.

Obviously, Windows doesn't have fork(), but still, I don't see any
reason to leave the comfort of your own running interpreter: you can use
runpy to run python scripts. If you want them to run in the background,
you can use threads, or, if you require (or want) separate processes,
use multiprocessing.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multiple versions of Python coexisting in the same OS

[News123]

On 07/25/2010 02:46 PM, Edward Diener wrote:
> On 7/25/2010 6:07 AM, Gelonida wrote:

>> There the windows solution could be something like a small 'pystarter'
>> program, which would decide depending on the file's location / the
>> file's first line which python should be started.
> 
> This does not work when Python is invoked internally via a file
> association. That was the point of my saying that the simple solutions
> do not work.

I'm not sure I understand. The ida is of course, that the file
association would point to the pystarter and that pystarter would
depending on directory / first line of the script
identify the correct executable to be started with.



Perhaps you could once more explain, what your intended solution would be.

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

Re: Multiple versions of Python coexisting in the same OS

[Gelonida]

On 07/25/2010 02:46 PM, Edward Diener wrote:
> On 7/25/2010 6:07 AM, Gelonida wrote:
>> Hi Edward,
>>
>> There the windows solution could be something like a small 'pystarter'
>> program, which would decide depending on the file's location / the
>> file's first line which python should be started.
> 
> This does not work when Python is invoked internally via a file
> association. That was the point of my saying that the simple solutions
> do not work.

What do you mean with invoking python internally?

call another python script? from a python script.

You could start it again via a pystarter.
or just with python (assuming the starter adapts the path)


The problem, that I currently encounter are some scripts, which want to
use python UNO (open office delivers ther own version of python)
and others which want to use libraries of my 'normal' python.

having the file association point to a python starter and let the python
starter choose could be an option.

However I never tried so far.

the fast and easy option is to just have specific file suffixes for the
open office python scripts (like e.g ) .oopy

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

Re: Unicode error

[Steven D'Aprano]

On Sun, 25 Jul 2010 13:52:33 +0100, Nobody wrote:

> On Fri, 23 Jul 2010 18:27:50 -0400, Terry Reedy wrote:
> 
>> But in the
>> meanwhile, once you get an error, you know what it is. You can
>> intentionally feed code bad data and see what you get. And then maybe
>> add a test to make sure your code traps such errors.
> 
> That doesn't really help with exceptions which are triggered by external
> factors rather than explicit inputs.

Huh? What do you mean by "external factors"? Do you mean like power 
supply fluctuations, cosmic rays flipping bits in memory, bad hardware? 
You can't defend against that, not without specialist fault-tolerant 
hardware, so just don't worry about it.

If you mean external factors like "the network goes down" or "the disk is 
full", you can still test for those with appropriate test doubles (think 
"stunt doubles", only for testing) such as stubs or mocks. It's a little 
bit more work (sometimes a lot more work), but it can be done.

Or don't worry about it. Release early, release often, and take lots of 
logs. You'll soon learn what exceptions can happen and what can't. Your 
software is still useful even when it's not perfect, and there's always 
time for another bug fix release.


> Also, if you're writing libraries (rather than self-contained programs),
> you have no control over the arguments. 

You can't control what the caller passes to you, but once you have it, 
you have total control over it. You can reject it with an exception, 
stick it inside a wrapper object, convert it to something else, deal with 
it as best you can, or just ignore it.


> Coupled with the fact that duck
> typing is quite widely advocated in Python circles, you're stuck with
> the possibility that any method call on any argument can raise any
> exception. This is even true for calls to standard library functions or
> methods of standard classes if you're passing caller-supplied objects as
> arguments.

That's a gross exaggeration. It's true that some methods could in theory 
raise any exception, but in practice most exceptions are vanishingly 
rare. And it isn't even remotely correct that "any" method could raise 
anything. If you can get something other than NameError, ValueError or 
TypeError by calling "spam".index(arg), I'd like to see it.

Frankly, it sounds to me that you're over-analysing all the things that 
"could" go wrong rather than focusing on the things that actually do go 
wrong. That's your prerogative, of course, but I don't think you'll get 
much support for it here.



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

Compare two nested dictionaries

[targetsmart]

Hi,
I am trying to compare two nested dictionaries, I want to know what is
the exact difference between them. I tried this solution

...
s1 = set(result1)
s2 = set(result2)
print s1 - s2

but it doesn't seem show any difference, but

assert result1 == result2
fails

could someone help me to find out the difference the two nested
dictionaries.

Any help is greatly appreciated.

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

Constructor call in the same class?

[Karsten Wutzke]

What's wrong with:

class Enum(RootFragment):
__jpaTypes = {
# complete!
'CascadeType': Enum("javax.persistence.CascadeType"),
'DiscriminatorType':
Enum("javax.persistence.DiscriminatorType"),
'EnumType': Enum("javax.persistence.EnumType"),
'FetchType': Enum("javax.persistence.FetchType"),
'FlushModeType': Enum("javax.persistence.FlushModeType"),
'GenerationType': Enum("javax.persistence.GenerationType"),
'InheritanceType': Enum("javax.persistence.InheritanceType"),
'LockModeType': Enum("javax.persistence.LockModeType"),
'PersistenceContextType':
Enum("javax.persistence.PersistenceContextType"),
'TemporalType': Enum("javax.persistence.TemporalType"),
}

# constructor
def __init__(self, package, modifiers, name, superInterfaces = [],
 annotations = [], innerClasses = [], properties = [],
methods = []):
RootFragment.__init__(self, packageName, modifiers, "enum",
name, superInterfaces, annotations, innerClasses, properties, methods)


?

I get

'CascadeType': Enum("javax.persistence.CascadeType"),

NameError: name 'Enum' is not defined

What's wrong with calling a constructor in a dict initializer? How do
I solve this?

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

Re: Constructor call in the same class?

[Thomas Jollans]

On 07/25/2010 05:41 PM, Karsten Wutzke wrote:
> What's wrong with:
> 
> class Enum(RootFragment):
> __jpaTypes = {
> # complete!
> 'CascadeType': Enum("javax.persistence.CascadeType"),
> 'DiscriminatorType':
> Enum("javax.persistence.DiscriminatorType"),
> 'EnumType': Enum("javax.persistence.EnumType"),
> 'FetchType': Enum("javax.persistence.FetchType"),
> 'FlushModeType': Enum("javax.persistence.FlushModeType"),
> 'GenerationType': Enum("javax.persistence.GenerationType"),
> 'InheritanceType': Enum("javax.persistence.InheritanceType"),
> 'LockModeType': Enum("javax.persistence.LockModeType"),
> 'PersistenceContextType':
> Enum("javax.persistence.PersistenceContextType"),
> 'TemporalType': Enum("javax.persistence.TemporalType"),
> }
> 
> # constructor
> def __init__(self, package, modifiers, name, superInterfaces = [],
>  annotations = [], innerClasses = [], properties = [],
> methods = []):
> RootFragment.__init__(self, packageName, modifiers, "enum",
> name, superInterfaces, annotations, innerClasses, properties, methods)
> 
> 
> ?
> 
> I get
> 
> 'CascadeType': Enum("javax.persistence.CascadeType"),
> 
> NameError: name 'Enum' is not defined

well, within the class statement, it's not defined. So you can't call
Enum yet.

You have to create your dict somewhere else. You can either set it from
outside:

class Enum(RootFragment):
...

Enum._jpaTypes = { ... }


Or, do exactly the same thing, but within a class method:

class Enum(bla):
@classmethod
def contruct_jpatypes(cls):
cls.__jpaTypes = { ... }

Enum.construct_jpatypes()

> 
> What's wrong with calling a constructor in a dict initializer? How do
> I solve this?
> 
> Karsten

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

Re: Compare two nested dictionaries

[Steven D'Aprano]

On Sun, 25 Jul 2010 08:03:06 -0700, targetsmart wrote:

> Hi,
> I am trying to compare two nested dictionaries, I want to know what is
> the exact difference between them. I tried this solution
> 
> ...
> s1 = set(result1)
> s2 = set(result2)
> print s1 - s2
> 
> but it doesn't seem show any difference, but
> 
> assert result1 == result2
> fails
> 
> could someone help me to find out the difference the two nested
> dictionaries.

Have you tried printing them and just looking for the differences?

Calling set() on a dictionary will create a set from the keys only:

>>> d1 = {"a": 1, "b": 2}
>>> d2 = {"a": 1, "b": 999}
>>> set(d1) == set(d2)
True
>>> d1 == d2
False

If you want to know the difference between two dictionaries, you have to 
consider:

(1) Keys that are in the first dict, but not the second;

(2) Keys that are in the second dict, but not the first; and

(3) Keys which are in both dicts, but have different values.


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

Re: Compare two nested dictionaries

[News123]

Hi,

On 07/25/2010 06:21 PM, Steven D'Aprano wrote:
> On Sun, 25 Jul 2010 08:03:06 -0700, targetsmart wrote:
> 
>> Hi,
>> I am trying to compare two nested dictionaries, I want to know what is
>> the exact difference between them. I tried this solution
>>
>> ...
>> s1 = set(result1)
>> s2 = set(result2)
>> print s1 - s2
>>

I think you want to have the symmetric difference:
try s1 ^ s2

>> but it doesn't seem show any difference, but
>>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Constructor call in the same class?

[Karsten Wutzke]

>
> You have to create your dict somewhere else. You can either set it from
> outside:
>
> class Enum(RootFragment):
>     ...
>
> Enum._jpaTypes = { ... }
>

THANKS for the quick help.

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

Re: Builtn super() function. How to use it with multiple inheritance? And why should I use it at all?

[Raymond Hettinger]

On Jul 24, 3:56 am, Lacrima  wrote:
> Thank you for your answer.

You're welcome.

> Some things are still not clear. Your example works great. But if I
> remove "super(SuperClass1, self).__init__(**kwds)" from SuperClass1's
> __init__, the example stops working. That is when I instantiate
> SubClass only __init__ of SuperClass1 is called and __init__ of
> SuperClass2 is omitted, i.e. only 'Python' is printed. Why is it so?
>
> So as I understand every parent should necessarily call super() at the
> end of its __init__ method in order for things to work properly.

Yes.  That's correct.  Python's super() was designed to support
cooperative multiple inheritance.  The "cooperative" part means that
every class implementing the target method (such as __init__ in your
example) needs to call super() in order to trigger the next method in
the sequence (the method resolution order or MRO).


> But what if SuperClass1 is from third party library?
  . . .
> How to deal with that?

Then, the odds are that that class isn't "cooperating".  You can
either wrap the third-party library to add a super() call or you can
switch to an alternate design using composition instead of
inheritance.


Raymond


P.S.  Outside of the simple case of single inheritance, the one key to
understanding super() is to forget about the concept of parent
classes.  Instead, super() is all about the MRO which is computed
dynamically (unknowable at the time a class is written).  Every class
in the MRO implementing the target method *must* call super() to give
the next class in the MRO a chance to run.

IOW, using super() means "I'm in the MRO and I got a chance to run;
now the next class in the MRO gets its chance."   Since the MRO is
only knowable at runtime, the sole job of super() is to figure out
which is "the next class in the MRO".
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compare two nested dictionaries

[Raymond Hettinger]

[targetsmart]
> > I am trying to compare two nested dictionaries, I want to know what is
> > the exact difference between them. I tried this solution

[Steven D'Aprano]
> If you want to know the difference between two dictionaries, you have to
> consider:
>
> (1) Keys that are in the first dict, but not the second;
>
> (2) Keys that are in the second dict, but not the first; and
>
> (3) Keys which are in both dicts, but have different values.

Steven, thanks for the excellent specification.  Here's the code:

s1 = set(d1)
s2 = set(d2)
first_not_second = s1 - s2
second_not_first = s2 - s1
difference_values = set(k for k in s1 & s2 if d1[k] != d2[k])

If the values are hashable, an alternate approach is:

s1 = set(d1.items())
s2 = set(d2.items())
first_not_second = s1 - s2
second_not_first = s2 - s1


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

Re: Multiple versions of Python coexisting in the same OS

[Joel Goldstick]

Edward Diener wrote:
Are there any documents about multiple versionsof Python coexisting in 
the same OS ( Windows in my case ) and what pitfalls to look out for ? I 
have already run into a number of them. I installed Python 2.7 and 3.1.2 
into completely folders, but immediately ran into serious problems 
executing a Python script.


The first problem is that just invoking Python will start whichever 
version is first in the PATH, and this is true from the command line or 
internally in a Python script.


The second problem is that invoking a script ( some xxx.py ) will start 
whichever version of Python is associated with the .py extension.


The third problem is if some software expects its scripts, which it puts 
in some Python subdirectory to be in the PATH.


There may be other considerations but overall having to versions 
coexisting has turned out to be a big headache involving both changes in 
the PATH and in the .py association.


Does anybody know of other things to look out for ?


There is this:
http://pypi.python.org/pypi/virtualenv

We have a good group in NYC for python and django.  That's where I 
learned about virtualevn.  I admit I'm not fully up to speed on it, but 
it lets you set up multiple 'virtual environments' for python to do 
exactly what I think you are asking about


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

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

[Zooko O'Whielacronx]

On Wed, Jul 7, 2010 at 3:32 AM, Jonathan Hartley  wrote:
>
> I presume this problem would go away if future versions of Python
> itself were compiled on Windows with something like MinGW gcc.

You might want to track issue3871. Roumen Petrov has done a lot of
work to make CPython compilable with mingw on Windows, as well as to
make it possible to compile CPython on a different operating system
and produce a CPython executable for Windows (cross-compile).

And by the way, I've usually had success building my native extension
modules with mingw. I understand (vaguely) that if a native extension
module needs to pass FILE*'s or C++ iostreams back and forth to
different extension modules or the the core CPython interpreter then
this could lead to segfaults, but none of my extension modules need to
do that.

I would suggest that people try to build their native extension
modules with mingw, and if it doesn't work report a bug (to mingw
project and to the Python project) so that we can track more precisely
what the issues are.

Regards,

Zooko

http://bugs.python.org/issue3871# cross and native build of python for
mingw32 with distutils
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Light-weight/very-simple version control under Windows using Python?

[Günther Dietrich]

pyt...@bdurham.com wrote:

>I have some very simple use cases[1] for adding some version control
>capabilities to a product I'm working on. My product uses simple, text
>(UTF-8) based scripts that are independent of one another. I would like
>to "version control" these scripts on behalf of my users. By version
>control, I mean *very-simple* version control with no branching or
>merging - just the ability to store, list and restore a specific version
>of a file. The data store should be a local file with the ability to
>upsize to a multi-user database in the future.
>
>I'm looking for recommendations on possible solutions:
>
>1. Use an existing version control utility. There are lots of options
>here(!), any recommendations on a light weight, open source one that
>xcopy installs under Windows with lots of command line options?
>
>2. Interface to a hosted version control system (SaaS) that provides a
>RESTful API. Any recommendations here?
>
>3. Build this capability myself using Python and Python's DBI layer to
>store files in a local SQLite database at first (but with the ability to
>upsize to a real client server database in the future). Seems like a fun
>project to work on, but also smells like I'd be re-inventing the wheel
>with very little value added other than simpler deployment?
>
>Any suggestions appreciated.

Use Mercurial (). It is written in python, 
can be extended by python modules/packages and can be used by python 
programs directly.


>1. Check a file in with optional comment and username; ideally
>get a version number that can be used to reference this specific
>check-in in the future.

That's a basic task in mercurial (as probably in every version control 
system).


>2. Get a history listing of all checkins for a specific file
>(version number, timestamp, file size, user, comment)

Also avalilable. I am not sure about file size and comment, but if you 
have the list of version numbers, you can extract this info from the 
repository easily.


>3. Check out a specific version of a file by version number.

See point 1.


>4. Delete checked-in versions by version number, date range,
>and/or username.

I've never tried it with mercurial. There are a remove and a forget 
command. Maybe, one could use the rebase extension.

But deleting changesets from a repository usually is a bad idea.


>5. (Optional) Diff 2 versions of a file by version number and
>return diff in richly formatted format that visually shows
>changes via color and font effects (strikethru) (I'm thinking
>of using BeyondCompare for this if not present in a simple
>version control tool)

Also available.



Regards,

Günther
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multiple versions of Python coexisting in the same OS

[Edward Diener]

On 7/25/2010 1:51 PM, Joel Goldstick wrote:

Edward Diener wrote:

Are there any documents about multiple versionsof Python coexisting in
the same OS ( Windows in my case ) and what pitfalls to look out for ?
I have already run into a number of them. I installed Python 2.7 and
3.1.2 into completely folders, but immediately ran into serious
problems executing a Python script.

The first problem is that just invoking Python will start whichever
version is first in the PATH, and this is true from the command line
or internally in a Python script.

The second problem is that invoking a script ( some xxx.py ) will
start whichever version of Python is associated with the .py extension.

The third problem is if some software expects its scripts, which it
puts in some Python subdirectory to be in the PATH.

There may be other considerations but overall having to versions
coexisting has turned out to be a big headache involving both changes
in the PATH and in the .py association.

Does anybody know of other things to look out for ?


There is this:
http://pypi.python.org/pypi/virtualenv


It appears to be only for Linux.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Multiple versions of Python coexisting in the same OS

[Edward Diener]

On 7/25/2010 10:03 AM, Thomas Jollans wrote:

On 07/25/2010 02:46 PM, Edward Diener wrote:

The problem with this is that you forget that a script can invoke Python
internally. So whether one uses the console or file association method
of invoking Python externally, any already written script can use either
internally.


Maybe it's just me, but I think that a script that does this is quite
simply badly written: it *will* break on systems that have multiple
Python versions.


Whether it is badly written or not in your opinion it is legal and 
happens all the time. Are you going to refuse to use any script, no 
matter for what library or for what purpose, that internally invokes 
Python either through a 'python' command or through a file with a Python 
extension ? And how would you find out if a script did this or not ? Are 
going to search every script in every distribution and library to 
determine if it does this ? And when you find out a script does this, 
what will you do ?


Be real. saying you do not like scripts that internally invoke Python 
does not solve anything if you have multiple coexisting versions of 
Python installed.

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

Re: Multiple versions of Python coexisting in the same OS

[Thomas Jollans]

On 07/25/2010 09:12 PM, Edward Diener wrote:
> On 7/25/2010 1:51 PM, Joel Goldstick wrote:
>> There is this:
>> http://pypi.python.org/pypi/virtualenv
> 
> It appears to be only for Linux.

I don't know where you get that impression from. I don't know how well
it works on which platforms, but the fact that there is a "Note for
Windows:" does suggest that it does work on windows.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multiple versions of Python coexisting in the same OS

[Thomas Jollans]

On 07/25/2010 09:19 PM, Edward Diener wrote:
> On 7/25/2010 10:03 AM, Thomas Jollans wrote:
>> On 07/25/2010 02:46 PM, Edward Diener wrote:
>>> The problem with this is that you forget that a script can invoke Python
>>> internally. So whether one uses the console or file association method
>>> of invoking Python externally, any already written script can use either
>>> internally.
>>
>> Maybe it's just me, but I think that a script that does this is quite
>> simply badly written: it *will* break on systems that have multiple
>> Python versions.
> 
> Whether it is badly written or not in your opinion it is legal and
> happens all the time. Are you going to refuse to use any script, no
> matter for what library or for what purpose, that internally invokes
> Python either through a 'python' command or through a file with a Python
> extension ? And how would you find out if a script did this or not ? Are
> going to search every script in every distribution and library to
> determine if it does this ? And when you find out a script does this,
> what will you do ?
> 
> Be real. saying you do not like scripts that internally invoke Python
> does not solve anything if you have multiple coexisting versions of
> Python installed.

I doubt many scripts do it. The fact of the matter is: many systems have
multiple Python versions installed in parallel, and it probably will
break somewhere, which will get noticed, and probably fixed.

If a script uses sys.executable instead of "python", there is no
problem, at all.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multiple versions of Python coexisting in the same OS

[Edward Diener]

On 7/25/2010 10:31 AM, News123 wrote:

On 07/25/2010 02:46 PM, Edward Diener wrote:

On 7/25/2010 6:07 AM, Gelonida wrote:



There the windows solution could be something like a small 'pystarter'
program, which would decide depending on the file's location / the
file's first line which python should be started.


This does not work when Python is invoked internally via a file
association. That was the point of my saying that the simple solutions
do not work.


I'm not sure I understand. The ida is of course, that the file
association would point to the pystarter and that pystarter would
depending on directory / first line of the script
identify the correct executable to be started with.



Perhaps you could once more explain, what your intended solution would be.


How does a 'pystarter' program know where the file's location is which 
is being invoked ? As to the first file line this is completely 
unrealistic. What are you going to do, alter the first file line of 
every script in a Python distribution and every script in every library 
installed in a Python distribution ? Sorry, but a less intrusive 
solution is much better and much less of a headache to say the least.


My intended solution would be a simple program which understands where 
each co-existing Python distribution is installed on a system and what 
the "name" of that distribution is. Then you tell the program which 
Python distribution should be the current one by its "name", the current 
one meaning the distribution which you want to be invoked at any given 
time. The program then changes the PATH so that any references to the 
Python directory and its subdirectories point to the "name" Python 
directory tree, and changes the file associations so that the "name" 
Python executables handle the Python associations.


This does have the weakness that I can not use more than one Python 
distribution while Python is executing scripts. But I can personally 
live with that since I have never encountered a situation where I must 
use more than one Python distribution at the same time.



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

Re: Multiple versions of Python coexisting in the same OS

[Christian Heimes]

Am 25.07.2010 21:32, schrieb Thomas Jollans:
> If a script uses sys.executable instead of "python", there is no
> problem, at all.

It's true that sys.executable is the best way if you have to start a new
Python interpreter. However sys.executable may not be set for NT
services. So there may be a problem after all.

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

Re: Multiple versions of Python coexisting in the same OS

[Thomas Jollans]

On 07/25/2010 09:39 PM, Christian Heimes wrote:
> Am 25.07.2010 21:32, schrieb Thomas Jollans:
>> If a script uses sys.executable instead of "python", there is no
>> problem, at all.
> 
> It's true that sys.executable is the best way if you have to start a new
> Python interpreter. However sys.executable may not be set for NT
> services. So there may be a problem after all.

Interesting. Does the multiprocessing module still work in that scenario?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multiple versions of Python coexisting in the same OS

[News123]

sOn 07/25/2010 09:39 PM, Christian Heimes wrote:
> Am 25.07.2010 21:32, schrieb Thomas Jollans:
>> If a script uses sys.executable instead of "python", there is no
>> problem, at all.


sys.executable will  not work  with scripts converted with py2exe,
as sys.executable will not be the executable of the python interpreter,
but with the main executable's name.





> 
> It's true that sys.executable is the best way if you have to start a new
> Python interpreter. However sys.executable may not be set for NT
> services. So there may be a problem after all.
> 

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

Re: Multiple versions of Python coexisting in the same OS

[Thomas Jollans]

On 07/25/2010 10:04 PM, News123 wrote:
> sOn 07/25/2010 09:39 PM, Christian Heimes wrote:
>> Am 25.07.2010 21:32, schrieb Thomas Jollans:
>>> If a script uses sys.executable instead of "python", there is no
>>> problem, at all.
> 
> 
> sys.executable will  not work  with scripts converted with py2exe,
> as sys.executable will not be the executable of the python interpreter,
> but with the main executable's name.

Well, but a script converted with py2exe can't really ever assume that
there is a Python interpreter, at all.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multiple versions of Python coexisting in the same OS

[News123]

On 07/25/2010 09:33 PM, Edward Diener wrote:
> On 7/25/2010 10:31 AM, News123 wrote:
>> On 07/25/2010 02:46 PM, Edward Diener wrote:
>>> On 7/25/2010 6:07 AM, Gelonida wrote:

> 
> How does a 'pystarter' program know where the file's location is which
> is being invoked ? 
the file's location would be somewhere in sys.argv
probably in sys.argv[1].
converting it to  an abs path would return a directory which the python
file belongs to.


> As to the first file line this is completely
> unrealistic. What are you going to do, alter the first file line of
> every script in a Python distribution and every script in every library
> installed in a Python distribution ? Sorry, but a less intrusive
> solution is much better and much less of a headache to say the least.
> 
Well I would at least do it for all of my self written scripts.

It could allow a soft transition from 2.6 to 2.7 to 3.0 without having
to upgrade all scripts at the same time.

> My intended solution would be a simple program which understands where
> each co-existing Python distribution is installed on a system and what
> the "name" of that distribution is. Then you tell the program which
> Python distribution should be the current one by its "name", the current
> one meaning the distribution which you want to be invoked at any given
> time. The program then changes the PATH so that any references to the
> Python directory and its subdirectories point to the "name" Python
> directory tree, and changes the file associations so that the "name"
> Python executables handle the Python associations.


> 
> This does have the weakness that I can not use more than one Python
> distribution while Python is executing scripts. But I can personally
> live with that since I have never encountered a situation where I must
> use more than one Python distribution at the same time.
> 

I guess it's rather difficult to find a solution which suits all.

The above minor weakness, that you mention would be a killer for me.

Currently I'm looking for solutions, where I can start python scripts
requireing different python versions at the same time.

Currently I'm staring the scripts manually from two different cmd line
windows with a different path name and an explicit python call,

Thus my idea of having a pystarter with a config file
mentioning which directories (tools) should use which python executable





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

Re: Multiple versions of Python coexisting in the same OS

[News123]

On 07/25/2010 10:18 PM, Thomas Jollans wrote:
> On 07/25/2010 10:04 PM, News123 wrote:
>> sOn 07/25/2010 09:39 PM, Christian Heimes wrote:
>>> Am 25.07.2010 21:32, schrieb Thomas Jollans:
 If a script uses sys.executable instead of "python", there is no
 problem, at all.
>>
>>
>> sys.executable will  not work  with scripts converted with py2exe,
>> as sys.executable will not be the executable of the python interpreter,
>> but with the main executable's name.
> 
> Well, but a script converted with py2exe can't really ever assume that
> there is a Python interpreter, at all.

true :-)


However, why I thought about this is, that
I write sometimes python code, which tries to call other python files.

later on for distribution I use py2exe.

Therefore I use wrapper functions, which will work in either case.

The wrapper could use sys.executable in 'python mode'
and had to call the exe file in 'py2exe mode'

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

Re: Multiple versions of Python coexisting in the same OS

[MRAB]

News123 wrote:

On 07/25/2010 09:33 PM, Edward Diener wrote:

On 7/25/2010 10:31 AM, News123 wrote:

On 07/25/2010 02:46 PM, Edward Diener wrote:

On 7/25/2010 6:07 AM, Gelonida wrote:



How does a 'pystarter' program know where the file's location is which
is being invoked ? 

the file's location would be somewhere in sys.argv
probably in sys.argv[1].
converting it to  an abs path would return a directory which the python
file belongs to.



As to the first file line this is completely
unrealistic. What are you going to do, alter the first file line of
every script in a Python distribution and every script in every library
installed in a Python distribution ? Sorry, but a less intrusive
solution is much better and much less of a headache to say the least.


Well I would at least do it for all of my self written scripts.

It could allow a soft transition from 2.6 to 2.7 to 3.0 without having
to upgrade all scripts at the same time.


My intended solution would be a simple program which understands where
each co-existing Python distribution is installed on a system and what
the "name" of that distribution is. Then you tell the program which
Python distribution should be the current one by its "name", the current
one meaning the distribution which you want to be invoked at any given
time. The program then changes the PATH so that any references to the
Python directory and its subdirectories point to the "name" Python
directory tree, and changes the file associations so that the "name"
Python executables handle the Python associations.




This does have the weakness that I can not use more than one Python
distribution while Python is executing scripts. But I can personally
live with that since I have never encountered a situation where I must
use more than one Python distribution at the same time.



I guess it's rather difficult to find a solution which suits all.

The above minor weakness, that you mention would be a killer for me.

Currently I'm looking for solutions, where I can start python scripts
requireing different python versions at the same time.

Currently I'm staring the scripts manually from two different cmd line
windows with a different path name and an explicit python call,

Thus my idea of having a pystarter with a config file
mentioning which directories (tools) should use which python executable


I think that's the wrong way round. A pystarter should ask the _tool_
which version of Python it needs.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Multiple versions of Python coexisting in the same OS

[Edward Diener]

On 7/25/2010 3:32 PM, Thomas Jollans wrote:

On 07/25/2010 09:19 PM, Edward Diener wrote:

On 7/25/2010 10:03 AM, Thomas Jollans wrote:

On 07/25/2010 02:46 PM, Edward Diener wrote:

The problem with this is that you forget that a script can invoke Python
internally. So whether one uses the console or file association method
of invoking Python externally, any already written script can use either
internally.


Maybe it's just me, but I think that a script that does this is quite
simply badly written: it *will* break on systems that have multiple
Python versions.


Whether it is badly written or not in your opinion it is legal and
happens all the time. Are you going to refuse to use any script, no
matter for what library or for what purpose, that internally invokes
Python either through a 'python' command or through a file with a Python
extension ? And how would you find out if a script did this or not ? Are
going to search every script in every distribution and library to
determine if it does this ? And when you find out a script does this,
what will you do ?

Be real. saying you do not like scripts that internally invoke Python
does not solve anything if you have multiple coexisting versions of
Python installed.


I doubt many scripts do it. The fact of the matter is: many systems have
multiple Python versions installed in parallel, and it probably will
break somewhere, which will get noticed, and probably fixed.

If a script uses sys.executable instead of "python", there is no
problem, at all.


What a script uses to internally invoke Python I can not control. My 
solution seeks to be non-intrusive and lets me run a particular version 
of Python, among the co-existing versions installed, at any given time. 
I believe that is the best I can do. I neither can control, nor do I 
want to control, all of the Python scripts installed on my system, nor 
can I worry how they may internally invoke Python. But I do want to be 
able to say, at any given time, that when I run Python a particular 
version, amidst the co-existing ones on my system, needs to be executed 
and therafter all internally executed modules use that version.


Trying to make rules for scripts, such as telling scripts they must use 
sys.executable, is pursuing an imaginary solution that can not work 
unless one is theoretically willing to manually inspect and change all 
Python scripts in some way. To me any intrusive changes to actual 
scripts is no solution at all.

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

Re: Multiple versions of Python coexisting in the same OS

[Edward Diener]

On 7/25/2010 3:39 PM, Christian Heimes wrote:

Am 25.07.2010 21:32, schrieb Thomas Jollans:

If a script uses sys.executable instead of "python", there is no
problem, at all.


It's true that sys.executable is the best way if you have to start a new
Python interpreter. However sys.executable may not be set for NT
services. So there may be a problem after all.



Once you start instrusively changing scripts to find a solution to 
multiple versions of Python co-existing in one system, you are heading 
down a path of endless problems.

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

Re: Multiple versions of Python coexisting in the same OS

[Edward Diener]

On 7/25/2010 4:22 PM, News123 wrote:

On 07/25/2010 09:33 PM, Edward Diener wrote:

On 7/25/2010 10:31 AM, News123 wrote:

On 07/25/2010 02:46 PM, Edward Diener wrote:

On 7/25/2010 6:07 AM, Gelonida wrote:




How does a 'pystarter' program know where the file's location is which
is being invoked ?

the file's location would be somewhere in sys.argv
probably in sys.argv[1].
converting it to  an abs path would return a directory which the python
file belongs to.



As to the first file line this is completely
unrealistic. What are you going to do, alter the first file line of
every script in a Python distribution and every script in every library
installed in a Python distribution ? Sorry, but a less intrusive
solution is much better and much less of a headache to say the least.


Well I would at least do it for all of my self written scripts.

It could allow a soft transition from 2.6 to 2.7 to 3.0 without having
to upgrade all scripts at the same time.


Intrusively changing scripts is a path to Python hell.




My intended solution would be a simple program which understands where
each co-existing Python distribution is installed on a system and what
the "name" of that distribution is. Then you tell the program which
Python distribution should be the current one by its "name", the current
one meaning the distribution which you want to be invoked at any given
time. The program then changes the PATH so that any references to the
Python directory and its subdirectories point to the "name" Python
directory tree, and changes the file associations so that the "name"
Python executables handle the Python associations.





This does have the weakness that I can not use more than one Python
distribution while Python is executing scripts. But I can personally
live with that since I have never encountered a situation where I must
use more than one Python distribution at the same time.



I guess it's rather difficult to find a solution which suits all.

The above minor weakness, that you mention would be a killer for me.

Currently I'm looking for solutions, where I can start python scripts
requireing different python versions at the same time.


If you need that, then of course my intended solution would not work.



Currently I'm staring the scripts manually from two different cmd line
windows with a different path name and an explicit python call,


If you start scripts and point to a specific version of Python, this 
works in my solution also. But if an internal call to Python exists 
thwre is always a problem.




Thus my idea of having a pystarter with a config file
mentioning which directories (tools) should use which python executable


Well, good luck ! I don;t know how this is resolved for you when some 
scripts executes 'python xxx yyy' or 'someScript.py yyy'.

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

Re: Multiple versions of Python coexisting in the same OS

[Edward Diener]

On 7/25/2010 4:26 PM, News123 wrote:

On 07/25/2010 10:18 PM, Thomas Jollans wrote:

On 07/25/2010 10:04 PM, News123 wrote:

sOn 07/25/2010 09:39 PM, Christian Heimes wrote:

Am 25.07.2010 21:32, schrieb Thomas Jollans:

If a script uses sys.executable instead of "python", there is no
problem, at all.



sys.executable will  not work  with scripts converted with py2exe,
as sys.executable will not be the executable of the python interpreter,
but with the main executable's name.


Well, but a script converted with py2exe can't really ever assume that
there is a Python interpreter, at all.


true :-)


However, why I thought about this is, that
I write sometimes python code, which tries to call other python files.

later on for distribution I use py2exe.

Therefore I use wrapper functions, which will work in either case.

The wrapper could use sys.executable in 'python mode'
and had to call the exe file in 'py2exe mode'



You can control what you do but how are you going to control what any 
givemn script does ?


Attempting to intrusively change potentially every script in a 
distribution in any way is a path to Python hell IMO.

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

Re: Multiple versions of Python coexisting in the same OS

[Thomas Jollans]

On 07/25/2010 11:10 PM, Edward Diener wrote:
> On 7/25/2010 3:39 PM, Christian Heimes wrote:
>> Am 25.07.2010 21:32, schrieb Thomas Jollans:
>>> If a script uses sys.executable instead of "python", there is no
>>> problem, at all.
>>
>> It's true that sys.executable is the best way if you have to start a new
>> Python interpreter. However sys.executable may not be set for NT
>> services. So there may be a problem after all.
>>
> 
> Once you start instrusively changing scripts to find a solution to
> multiple versions of Python co-existing in one system, you are heading
> down a path of endless problems.

What exactly is it that you're afraid to change?

The standard library? There's certainly no need to change that in any way!

Your own code? That'd just be nonsense.

Someone else's then. Is there any problem at all when you start it with
a specific Python interpreter? I expect that there probably isn't. If
there is, if the code makes ANY assumptions about where to find a Python
interpreter on your system, I would consider that a serious bug that
should be reported. If it's only one or two affected lines of code, why
not change them? There's nothing intrusive or wrong about fixing
something on your own computer!
If it turns out that you'd have to change a lot of code to make it work,
THAT's the time to think about a complex workaround, like writing a
batch file that sets up an environment in which it works, for that
program. Otherwise, I don't think it's worth the effort.

I'm on a Linux system with multiple Python interpreters. (Almost) all
installed Python programs work with the system default interpreter
(CPython 2.6). Those that don't have been fitted with shebang lines like
"#!/usr/bin/python2.5". This tells the OS to use a different
interpreter, like the pystarter script solution proposed in this very
thread.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

[David Cournapeau]

On Mon, Jul 26, 2010 at 3:07 AM, Zooko O'Whielacronx  wrote:

>
> I would suggest that people try to build their native extension
> modules with mingw, and if it doesn't work report a bug (to mingw
> project and to the Python project) so that we can track more precisely
> what the issues are.

To be clear, building extensions with mingw for the official python
works well. Numpy and scipy official binaries have been built with
mingw for years. There are problems for 64 bits binaries, though

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

Python acting weird

[Westly Ward]

x = {"type":"folder", "name":"sonicbot", "data":[{"type":"folder",
"name":"SonicMail", "data":[{"type":"file", "name":"bbcode.py",
"compressed":False, "contents":"blahblahfilecontents"}]}]}
print x
def setindict(dictionary, keys, value) :
if len(keys) == 1 :
if keys[0].isdigit() and int(keys[0]) == len(dictionary)  :
dictionary.append(keys[0])
else :
dictionary[keys[0]] = value
else :
dictionary[keys[0]] = setindict(dictionary[keys[0]], keys[1:], value)
return dictionary
a = x.copy()

print id(a), id(x)
y = setindict(a, ["data", 0, "data", 0, "compressed"], True)
if y == x :
print True

else :
print False
print x
print a

How are x and a are ending up the same?  I would think .copy() would
make it completely seperate.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Builtn super() function. How to use it with multiple inheritance? And why should I use it at all?

[Gregory Ewing]

Raymond Hettinger wrote:

Every class
in the MRO implementing the target method *must* call super() to give
the next class in the MRO a chance to run.


EXCEPT for the last one, which must NOT call super!

The posted example happens to work because object has
a default __init__ method that does nothing. But this
is not generally true of other methods, which means you
need a "terminating" class at the end of the MRO whose
methods don't call super.

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

Re: Python acting weird

[Chris Rebert]

On Sun, Jul 25, 2010 at 5:08 PM, Westly Ward  wrote:
> x = {"type":"folder", "name":"sonicbot", "data":[{"type":"folder",
> "name":"SonicMail", "data":[{"type":"file", "name":"bbcode.py",
> "compressed":False, "contents":"blahblahfilecontents"}]}]}
> print x
> def setindict(dictionary, keys, value) :
>    if len(keys) == 1 :
>        if keys[0].isdigit() and int(keys[0]) == len(dictionary)  :
>            dictionary.append(keys[0])
>        else :
>            dictionary[keys[0]] = value
>    else :
>        dictionary[keys[0]] = setindict(dictionary[keys[0]], keys[1:], value)
>    return dictionary
> a = x.copy()
>
> print id(a), id(x)
> y = setindict(a, ["data", 0, "data", 0, "compressed"], True)
> if y == x :
>    print True
>
> else :
>    print False
> print x
> print a
>
> How are x and a are ending up the same?  I would think .copy() would
> make it completely seperate.

Nope, .copy() only makes a "shallow" copy of the outermost dict, not a
recursive "deep" copy; the 2 dictionaries initially point to the
*exact* same objects for their keys and values.

a = x.copy()
assert x is not a # wouldn't be much of a copy otherwise
assert x["data"] is a["data"] # no recursive copying though
# separate dicts, so rebinding the items of one doesn't affect the other
x[42] = 12
assert 42 not in a
# mutating the items in one does affect the other however
x["data"].append(7)
assert a["data"].pop() == 7
# remember that x[y] = z === x.__setitem__(y, z)
# so we can write a similar example thusly:
x["data"][0] = 8
assert a["data"][0] == 8
# again, rebinding at the outermost level is independent
x["data"] = 99
assert a["data"] != x["data"]

For a deep copy, use copy.deepcopy() in the std lib:
http://docs.python.org/library/copy.html#copy.deepcopy

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

Re: Multiple versions of Python coexisting in the same OS

[Edward Diener]

On 7/25/2010 5:57 PM, Thomas Jollans wrote:

On 07/25/2010 11:10 PM, Edward Diener wrote:

On 7/25/2010 3:39 PM, Christian Heimes wrote:

Am 25.07.2010 21:32, schrieb Thomas Jollans:

If a script uses sys.executable instead of "python", there is no
problem, at all.


It's true that sys.executable is the best way if you have to start a new
Python interpreter. However sys.executable may not be set for NT
services. So there may be a problem after all.



Once you start instrusively changing scripts to find a solution to
multiple versions of Python co-existing in one system, you are heading
down a path of endless problems.


What exactly is it that you're afraid to change?


I do not want to intrusively change any script that has been installed 
as part of Python. I shouldn't even have to know about the code in these 
scripts other than what good documentation tells me in how to use them.


That's not to say having source is worthless. I am just not going to 
change source to get a version of Python to work properly when I have 2 
or more versions installed in their own separate folders.




The standard library? There's certainly no need to change that in any way!


So if a standard library module ( or distributed library ) executes a 
call internally to 'python xxx yyy' or executes a call internally to 
'someScript.py yyy', you're fine with multiple co-existing versions of 
Python on your system ?


Because under Windows the first call will look for the python.exe first 
found in the PATH while the second call will find the python.exe 
associated with the .py extension. And it does not matter in either case 
what version of the multiple installed versions of Python which are on 
my system is currently executing that script.


And please don't say that there is some sort of guarantee that no 
library or installation would invoke Python in such a way as opposed to 
the normal 'import AScript.py' method of using functionality in Python 
scripts.

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

Re: Multiple versions of Python coexisting in the same OS

[Steven D'Aprano]

On Sun, 25 Jul 2010 15:19:53 -0400, Edward Diener wrote:

> On 7/25/2010 10:03 AM, Thomas Jollans wrote:
>> On 07/25/2010 02:46 PM, Edward Diener wrote:
>>> The problem with this is that you forget that a script can invoke
>>> Python internally. So whether one uses the console or file association
>>> method of invoking Python externally, any already written script can
>>> use either internally.
>>
>> Maybe it's just me, but I think that a script that does this is quite
>> simply badly written: it *will* break on systems that have multiple
>> Python versions.
> 
> Whether it is badly written or not in your opinion it is legal and
> happens all the time.

Yes, people write poorly written, buggy scripts all the time. Just 
because code is legal syntax doesn't mean it does what is intended, or 
that what is intended is sensible.

If you have multiple versions of Python installed, and you call "python 
somescript.py" without knowing *which* Python will be called, it is 
neither sensible nor does it do what you intend. End of story.

This is no different from calling any other application without knowing 
what version you will get, then relying on features that are only 
available in some versions. It is just buggy code.


> Are you going to refuse to use any script, no
> matter for what library or for what purpose, that internally invokes
> Python either through a 'python' command or through a file with a Python
> extension ? And how would you find out if a script did this or not ? Are
> going to search every script in every distribution and library to
> determine if it does this ? And when you find out a script does this,
> what will you do ?

Treat it like any script with a bug: fix the bug, stop using the script, 
or determine a work-around that masks the bug. All three are acceptable, 
the third being the least acceptable because it just leaves a bug waiting 
to bite you again in the future.


> Be real. saying you do not like scripts that internally invoke Python
> does not solve anything if you have multiple coexisting versions of
> Python installed.

No, it solves it completely. Treat it as a bug, and fix it. 

If you're not willing to treat it as a bug, then uninstall all but one of 
the Python versions, and the problem goes away. You might have a 
different problem, namely that some scripts stop working, but now the 
solution is obvious and straight-forward: fix the scripts that aren't 
working.

Or rename the Python applications, so that scripts can easily call the 
right version without getting confused.

Trying to make some brittle, Do-What-I-Mean solution for trying to auto-
magically select between Python versions is pursuing a path of endless 
problems. Any solution that doesn't fix the actual problem, namely that 
the scripts are buggy, is at best just a work-around and at worst is no 
solution at all.


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

Re: Light-weight/very-simple version control under Windows using Python?

[Ben Finney]

"Günther Dietrich"  writes:

> pyt...@bdurham.com wrote:
>
> >I have some very simple use cases[1] for adding some version control
> >capabilities to a product I'm working on.
[…]

> >I'm looking for recommendations on possible solutions:
> >
> >1. Use an existing version control utility.
[…]

> Use Mercurial (). It is written in
> python, can be extended by python modules/packages and can be used by
> python programs directly.

Either of Mercurial or Bazaar http://bazaar.canonical.com/> will be
good choices for the requirements specified.

All of Günther's comments (including those I trimmed in this reply)
apply equally to both Mercurial and Bazaar. You might like to ask
questions in each of the support forums for those tools for more
information.

-- 
 \ “To punish me for my contempt of authority, Fate has made me an |
  `\   authority myself.” —Albert Einstein, 1930-09-18 |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multiple versions of Python coexisting in the same OS

[David Robinow]

On Sun, Jul 25, 2010 at 8:40 PM, Edward Diener
 wrote:
> On 7/25/2010 5:57 PM, Thomas Jollans wrote:
> So if a standard library module ( or distributed library ) executes a call
> internally to 'python xxx yyy' or executes a call internally to
> 'someScript.py yyy', you're fine with multiple co-existing versions of
> Python on your system ?
>
> Because under Windows the first call will look for the python.exe first
> found in the PATH while the second call will find the python.exe associated
> with the .py extension. And it does not matter in either case what version
> of the multiple installed versions of Python which are on my system is
> currently executing that script.
>
> And please don't say that there is some sort of guarantee that no library or
> installation would invoke Python in such a way as opposed to the normal
> 'import AScript.py' method of using functionality in Python scripts.
Edward, I'm having a really hard time understanding your problem.
Could you give an example of some real code that is causing you
difficulty?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Multiple versions of Python coexisting in the same OS

[Edward Diener]

On 7/25/2010 8:41 PM, Steven D'Aprano wrote:

On Sun, 25 Jul 2010 15:19:53 -0400, Edward Diener wrote:


On 7/25/2010 10:03 AM, Thomas Jollans wrote:

On 07/25/2010 02:46 PM, Edward Diener wrote:

The problem with this is that you forget that a script can invoke
Python internally. So whether one uses the console or file association
method of invoking Python externally, any already written script can
use either internally.


Maybe it's just me, but I think that a script that does this is quite
simply badly written: it *will* break on systems that have multiple
Python versions.


Whether it is badly written or not in your opinion it is legal and
happens all the time.


Yes, people write poorly written, buggy scripts all the time. Just
because code is legal syntax doesn't mean it does what is intended, or
that what is intended is sensible.

If you have multiple versions of Python installed, and you call "python
somescript.py" without knowing *which* Python will be called, it is
neither sensible nor does it do what you intend. End of story.


Somebody is supplying you with a Python script and internally invoking 
Python again. But that somebody does not have to be myself.


I am neither buying "End of story" nor that invoking Python internally 
is an error. But if you believe it to be then you can root out all such 
Python code, or correct it as you like. Even with co-existing versions 
of Python installed I have better things to do with my time and 
therefore will pursue a solution that will work for me in the face of 
such code.

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

Re: why is this group being spammed?

[Benjamin Kaplan]

Python-list is comp.lang.python turned into mailing list form. gmane
is python-list turned back into a newsgroup. The reason it gets less
spam is because it's behind the mailing list's spam filters. Both the
mailing list and gmane should see the same amount of spam. which is
way less than the original newsgroup/Google Group sees.

On Sat, Jul 24, 2010 at 12:28 PM, Jia Hu  wrote:
> I subscribe for this mailing list at
> http://mail.python.org/mailman/listinfo/python-list
>
> On Sat, Jul 24, 2010 at 3:22 PM, Jia Hu  wrote:
>>
>> Hi, can I subscribe this by gmail?
>>
>> On Sat, Jul 24, 2010 at 3:16 PM, Mark Lawrence 
>> wrote:
>>>
>>> On 24/07/2010 18:01, Dennis Lee Bieber wrote:

 On Sat, 24 Jul 2010 07:32:30 -0700 (PDT), "be.krul"
 declaimed the following in gmane.comp.python.general:

> But maybe owner of this group do no care in that case we *all* get
> spammed!

        There is NO OWNER of comp.lang.python; and turning a comp.* group
 into moderated takes a fairly long time assuming you can find someone
 willing to be the moderators -- what would likely happen is that
 comp.lang.python.moderated would be created and then take a few months
 to be picked up by the servers, and a few more months for the real users
 to leave comp.lang.python to use it.

        Oh, and also the hassle of the mailing-list<>usenet gateway (does
 it
 pass traffic to both groups, drop the existing one, etc.). And readers
 on Google may still see spam if Google takes posts stuff before it
 passes through the moderation board.
>>>
>>> For the benefit of those who might have missed it, I'll repeat that I'm
>>> reading this from gmane.comp.python.general and see little or no spam.
>>>
>>> Regards.
>>>
>>> Mark Lawrence.
>>>
>>> --
>>> 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: Builtn super() function. How to use it with multiple inheritance? And why should I use it at all?

[Michele Simionato]

Everything you ever wanted to know about super is collected here:
http://micheles.googlecode.com/hg/artima/python/super.pdf

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

obtaining pid of child process

[tazimk]

Hi,

I am using python's multiprocessing module to spawn new process

as follows :

import multiprocessing
import os
d = multiprocessing.Process(target=os.system,args=('iostat 2 >
a.txt',))
d.start()

I want to obtain pid of iostat command or the command executed using
multiprocessing module

When I execute :

 d.pid

it gives me pid of subshell in which this command is running .

Any help will be valuable .

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

Re: obtaining pid of child process

[Chris Rebert]

On Sun, Jul 25, 2010 at 9:02 PM, tazimk  wrote:
> Hi,
>
> I am using python's multiprocessing module to spawn new process
>
> as follows :
>
> import multiprocessing
> import os
> d = multiprocessing.Process(target=os.system,args=('iostat 2 >
> a.txt',))
> d.start()
>
> I want to obtain pid of iostat command or the command executed using
> multiprocessing module

`multiprocessing` isn't the best module for this; use `subprocess` instead:

from subprocess import Popen, PIPE
process = Popen(["iostat"], stderr=open("a.txt", 'w'), stdout=PIPE)
print("the PID is", process.pid)

`multiprocessing` is used for parallelism in Python code, as an
alternative to threads. `subprocess` is used for running external
commands, as a preferred alternative to os.system() among other
things.

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

Re: Unicode error

[Nobody]

On Sun, 25 Jul 2010 14:47:11 +, Steven D'Aprano wrote:

>>> But in the
>>> meanwhile, once you get an error, you know what it is. You can
>>> intentionally feed code bad data and see what you get. And then maybe
>>> add a test to make sure your code traps such errors.
>> 
>> That doesn't really help with exceptions which are triggered by external
>> factors rather than explicit inputs.
> 
> Huh? What do you mean by "external factors"?

I mean this:

> If you mean external factors like "the network goes down" or "the disk is 
> full",

> you can still test for those with appropriate test doubles (think 
> "stunt doubles", only for testing) such as stubs or mocks. It's a little 
> bit more work (sometimes a lot more work), but it can be done.

I'd say "a lot" is more often the case.

>> Also, if you're writing libraries (rather than self-contained programs),
>> you have no control over the arguments. 
> 
> You can't control what the caller passes to you, but once you have it, 
> you have total control over it.

Total control insofar as you can wrap all method calls in semi-bare
excepts (i.e. catch any Exception but not Interrupt).

>> Coupled with the fact that duck
>> typing is quite widely advocated in Python circles, you're stuck with
>> the possibility that any method call on any argument can raise any
>> exception. This is even true for calls to standard library functions or
>> methods of standard classes if you're passing caller-supplied objects as
>> arguments.
> 
> That's a gross exaggeration. It's true that some methods could in theory 
> raise any exception, but in practice most exceptions are vanishingly 
> rare.

Now *that* is a gross exaggeration. Exceptions are by their nature
exceptional, in some sense of the word. But a substantial part of Python
development is playing whac-a-mole with exceptions. Write code, run
code, get traceback, either fix the cause (LBYL) or handle the exception
(EAFP), wash, rinse, repeat.

> And it isn't even remotely correct that "any" method could raise 
> anything. If you can get something other than NameError, ValueError or 
> TypeError by calling "spam".index(arg), I'd like to see it.

How common is it to call methods on a string literal in real-world code?

It's far, far more common to call methods on an argument or expression
whose value could be any "string-like object" (e.g. UserString or a str
subclass).

IOW, it's "almost" correct that any method can raise any exception. The
fact that the number of counter-examples is non-zero doesn't really
change this. Even an isinstance() check won't help, as nothing prohibits a
subclass from raising exceptions which the original doesn't. Even using
"type(x) == sometype" doesn't help if x's methods involve calling methods
of user-supplied values (unless those methods are wrapped in catch-all
excepts).

Java's checked exception mechanism was based on real-world experience of
the pitfalls of abstract types. And that experience was gained in
environments where interface specifications were far more detailed than is
the norm in the Python world.

> Frankly, it sounds to me that you're over-analysing all the things that 
> "could" go wrong rather than focusing on the things that actually do go 
> wrong.

See Murphy's Law.

> That's your prerogative, of course, but I don't think you'll get 
> much support for it here.

Alas, I suspect that you're correct. Which is why I don't advocate using
Python for "serious" software. Neither the language nor its "culture" are
amenable to robustness.

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

Re: Multiple versions of Python coexisting in the same OS

[Edward Diener]

On 7/25/2010 10:42 PM, David Robinow wrote:

On Sun, Jul 25, 2010 at 8:40 PM, Edward Diener
  wrote:

On 7/25/2010 5:57 PM, Thomas Jollans wrote:
So if a standard library module ( or distributed library ) executes a call
internally to 'python xxx yyy' or executes a call internally to
'someScript.py yyy', you're fine with multiple co-existing versions of
Python on your system ?

Because under Windows the first call will look for the python.exe first
found in the PATH while the second call will find the python.exe associated
with the .py extension. And it does not matter in either case what version
of the multiple installed versions of Python which are on my system is
currently executing that script.

And please don't say that there is some sort of guarantee that no library or
installation would invoke Python in such a way as opposed to the normal
'import AScript.py' method of using functionality in Python scripts.

Edward, I'm having a really hard time understanding your problem.
Could you give an example of some real code that is causing you
difficulty?


I start a Python script for version X by going to X's root directory and 
invoking 'python someScript.py' from the command line. Does that not 
sound reasonable ?


In SomeScript.py there is an internal call to 'python someOtherScript.y 
someParameters'. But the call invokes another version of Python because 
it is that version which is in the PATH. Or in SomeScript.py there is an 
internal call to 'someOtherScript.py someParameters'. But the call 
invokes another version of Python because the .py extension is 
associated with a different version.


My solution is that I will write some code which sets a particular 
version of Python as the current version for a particular time, meaning 
that version will be in the PATH and associated with Python extensions. 
The way I do not have to worry when I externally invoke Python from the 
command line that internal calls are going to some other version.

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

Undo-Redo, copy instance, custom events and a problem

[King]

Hi,
I am developing an app using wxPython.
The Undo-Redo implementation is based on storing pre & post state of
an attribute.
You store the instance before changing the value and store the
instance after changing the values.
While undoing or redoing, you copy/replace the current state with
stored once.

For color attribute as soon as you choose a color, here is the code:

# Custom Event
evt = ValueChangeEvent(EVT_COLOR_CHANGED.typeId, self.GetId())
# Store Pre State
evt.SetPreState(copy.copy(self.attribute))
# Change the newly selected color
self.attribute.setValue(R,G,B)
# Store Post State
evt.SetPostState(copy.copy(self.attribute))
# Throw Custom Event
self.GetEventHandler().ProcessEvent(evt)

Both states are copied as new instance with correct values.
The problem is when this event is getting fired.

evt.GetPreState().GetValue() is showing the post color value. Although
GetPreState() & GetPostState()
are showing two different instances but I have no idea why values are
not coming/stored correctly. Some where
in between is messed up and post-state values are copied in pre-state.

On a side note, self.attribute.setValue takes three floating values
for R,G & B colors but stored them
as a text. Similarly self.attribute.getValue() converts text into
float and returns.

Is there anything related to scope or something?

Cheers

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

Re: Multiple versions of Python coexisting in the same OS

[Steven D'Aprano]

On Mon, 26 Jul 2010 00:36:47 -0400, Edward Diener wrote:

> On 7/25/2010 10:42 PM, David Robinow wrote:
[...]
>> Edward, I'm having a really hard time understanding your problem. Could
>> you give an example of some real code that is causing you difficulty?
> 
> I start a Python script for version X by going to X's root directory and
> invoking 'python someScript.py' from the command line. Does that not
> sound reasonable ?

No it doesn't, it's a very unreasonable thing to do.

If you have multiple versions of Python, you should name them 
appropriately so you can launch the appropriate version from any 
directory:

python26 someScript.py  # calls python31 secondScript.py internally
python31 anotherScript.py  # calls python25 thirdScript.py internally

etc.

Or give the full path to the executable:

C:\Programs\python26\python.exe someScript.py  
# calls C:\Programs\python31\python.exe secondScript.py internally


If a script doesn't do this, then the script should be treated as buggy.



> In SomeScript.py there is an internal call to 'python someOtherScript.y
> someParameters'. 

That's a pretty dodgy thing to do in the first place, unless you can 
guarantee that there's only one executable called python. Otherwise, how 
do you know which one will be called? You can't easily predict which one 
will be called, so don't do it unless you want your scripts to call 
arbitrary executables.



> But the call invokes another version of Python because
> it is that version which is in the PATH. Or in SomeScript.py there is an
> internal call to 'someOtherScript.py someParameters'. But the call
> invokes another version of Python because the .py extension is
> associated with a different version.

Exactly. The root of your problem is that there are multiple executables 
called "python" and you don't know which one you will get. So don't do 
that.


> My solution is that I will write some code which sets a particular
> version of Python as the current version for a particular time, meaning
> that version will be in the PATH and associated with Python extensions.

/facepalm


> The way I do not have to worry when I externally invoke Python from the
> command line that internal calls are going to some other version.


Good luck with that.



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