Re: Python detection

[Stephan Witt]

Am 13.04.2013 um 03:09 schrieb Pavel Sanda sa...@lyx.org:

 José Matos wrote:
 So these are the facts. The question then is how do we want to proceed?
 
 I thought we want to be 3.0 compatible and ditch 2.x series completely(?).
 Otherwise it looks like just maintenace burden without profit.
 
 What's the status of python 3 on fedora/debian/suse?

On my Mac (latest version Mac OS X 10.8.3) the default is 2.7.2.

Stephan

stephan$ python -V
Python 2.7.2
stephan$ which python
/usr/bin/python
stephan$ 

Re: Python detection

[Cor Blom]

Op 13-04-13 03:09, Pavel Sanda schreef:

José Matos wrote:

So these are the facts. The question then is how do we want to proceed?


I thought we want to be 3.0 compatible and ditch 2.x series completely(?).
Otherwise it looks like just maintenace burden without profit.

What's the status of python 3 on fedora/debian/suse?

Pavel



on openSUSE 12.3 python 2 (2.7.3) is still default, but version 3 
(3.3.0) is available. Unknown when default will change.


Cor

Re: Python detection

[Pavel Sanda]

Stephan Witt wrote:
  What's the status of python 3 on fedora/debian/suse?
 
 On my Mac (latest version Mac OS X 10.8.3) the default is 2.7.2.

Default is not so important, important is 3.x availability, we have
mostly working selection mechanism thanks to Enrico.

Pavel

Re: Python detection

[Georg Baum]

Pavel Sanda wrote:

 Stephan Witt wrote:
  What's the status of python 3 on fedora/debian/suse?
 
 On my Mac (latest version Mac OS X 10.8.3) the default is 2.7.2.
 
 Default is not so important, important is 3.x availability, we have
 mostly working selection mechanism thanks to Enrico.

3.2.1 is available in debian squeeze (the current stable version). Since 
debian is usually the most outdated linux distro it should not be a problem 
to require python 3 if it is avialable on OS X as well. If we stay with 
python 2 I'd say that 2.6 is a safe minimum requirement. This could be 
raised to 2.7 as soon as RHEL 7 and debian wheezy are released.

BTW I don't see any maintenance burden if we stay with version 2 for another 
year or so, as long as we don't support both versions at the same time.


Georg

Re: Python detection

[Georg Baum]

Georg Baum wrote:

 3.2.1 is available in debian squeeze (the current stable version).

Wrong, it is 3.1.3, but does not matter.


Georg

Re: Python detection

[Guenter Milde]

On 2013-04-13, Georg Baum wrote:
 Pavel Sanda wrote:
 Stephan Witt wrote:
  What's the status of python 3 on fedora/debian/suse?

 On my Mac (latest version Mac OS X 10.8.3) the default is 2.7.2.

 Default is not so important, important is 3.x availability, we have
 mostly working selection mechanism thanks to Enrico.

 3.2.1 is available in debian squeeze (the current stable version). Since 
 debian is usually the most outdated linux distro it should not be a problem 
 to require python 3 if it is avialable on OS X as well. If we stay with 
 python 2 I'd say that 2.6 is a safe minimum requirement. This could be 
 raised to 2.7 as soon as RHEL 7 and debian wheezy are released.

 BTW I don't see any maintenance burden if we stay with version 2 for another 
 year or so, as long as we don't support both versions at the same time.

I propose to keep supporting 2.x until:

* the minimum requirement is 2.7 (i.e. 2.7 is available in Debian/stable),
  
  AND
  
* the majority of Python installations defaults to Python 3.


I suppose, there is no need to raise the minimum requirement to 2.7 unless
we start supporting 3.x.

Günter

Re: Re: Re: Re: Python detection

[José Matos]

On Friday 12 April 2013 18:09:02 Pavel Sanda wrote:
 I thought we want to be 3.0 compatible and ditch 2.x series completely(?).
 Otherwise it looks like just maintenace burden without profit.
 
 What's the status of python 3 on fedora/debian/suse?
 
 Pavel

In the mean time it is possible to use the features of python 2.7 that allow an 
easy update to python 3.3.

Note that even if we go python 3 we should set a minimum version, like say 
python 3.2 or even python 3.3 if we are feeling lucky. :-)

In case of Fedora it has the most recent versions python 2.7.4 and python 3.3.1 
(they are in the testing stage because it has been released this/last week). 
The distribution default is yet python 2 and it will be at least for another 
year.

Note that personally I have no problem going the python 3 route and if we 
decide to go that way I will support it.

-- 
José Abílio

Re: Re: Re: Re: Python detection

[Pavel Sanda]

José Matos wrote:
 In the mean time it is possible to use the features of python 2.7 that allow 
 an easy update to python 3.3.

I hope we already at least support python 2.7, cause what I see in changelogs, 
Uwe already ships it in Win version :)

 Note that even if we go python 3 we should set a minimum version, like say 
 python 3.2 or even python 3.3 if we are feeling lucky. :-)

You mean that backward compatibility issues are even within 3.x series?

 Note that personally I have no problem going the python 3 route and if we 
 decide to go that way I will support it.

I don't feel any hurry for bumping, just tried to catch you while your are 
active, otherwise I'm not sure who wants to do that...

Pavel

Re: Python detection

[Richard Heck]

On 04/13/2013 02:09 PM, José Matos wrote:

On Friday 12 April 2013 18:09:02 Pavel Sanda wrote:

I thought we want to be 3.0 compatible and ditch 2.x series completely(?).
Otherwise it looks like just maintenace burden without profit.

What's the status of python 3 on fedora/debian/suse?

Pavel

In the mean time it is possible to use the features of python 2.7 that allow an 
easy update to python 3.3.

Note that even if we go python 3 we should set a minimum version, like say 
python 3.2 or even python 3.3 if we are feeling lucky. :-)

In case of Fedora it has the most recent versions python 2.7.4 and python 3.3.1 
(they are in the testing stage because it has been released this/last week). 
The distribution default is yet python 2 and it will be at least for another 
year.

Note that personally I have no problem going the python 3 route and if we 
decide to go that way I will support it.


Isn't there some import __future__ thing we can use to make this easy? 
Or is that what is only in 2.7?


Richard

Re: Re: Re: Re: Re: Python detection

[José Matos]

On Saturday 13 April 2013 11:36:18 Pavel Sanda wrote:
 José Matos wrote:
  In the mean time it is possible to use the features of python 2.7 that 
  allow an easy update to python 3.3.
 
 I hope we already at least support python 2.7, cause what I see in 
 changelogs, Uwe already ships it in Win version :)

Sure, lyx works with python 2.7 but it does not make any use of the new 
features that are present in python-2.7 but are not present in python-2.4. That 
is the point of forward compatible. :-)

When I say that we should support python-2.7 I mean, in this context, that we 
should make python-2.7 the minimum supported version in order to simplify a 
transition to python 3 later.

  Note that even if we go python 3 we should set a minimum version, like say 
  python 3.2 or even python 3.3 if we are feeling lucky. :-)
 
 You mean that backward compatibility issues are even within 3.x series?

No. Not with that alarming tone. :-)

I mean that it is easy to go from python-2.7 to python-3.3 (or 3.2) that it is 
to go from python-2.7 to python-3.0 or python-3.1.

Take as an example the python 3.3 release:
http://www.python.org/getit/releases/3.3.0/

Notice the third paragraph:
Python 3.3 includes a range of improvements of the 3.x series, as well as 
*easier porting* between 2.x and 3.x.

In the development of python 3.3 there was a moratorium in the development of 
new language features in order to improve both the standard library and the 
porting of the code from 2.x.

  Note that personally I have no problem going the python 3 route and if we 
  decide to go that way I will support it.
 
 I don't feel any hurry for bumping, just tried to catch you while your are 
 active, otherwise I'm not sure who wants to do that...
 
 Pavel

Note that I am proposing this change after lyx-2.1 is released so in a sense 
this discussion is premature.

Oh, BTW and then if we go with python 3.x we can call the next version lyx 3.0. 
:-D
Or we can already adopt the firefox convention and go with lyx-3.0 for new 
release. :-)

FWIW on a more serious note that are lots of very competent python programmers 
in this list so I am not worried. :-)

Regards,
-- 
José Abílio

Re: Re: Re: Re: Re: Python detection

[Pavel Sanda]

José Matos wrote:
 Oh, BTW and then if we go with python 3.x we can call the next version lyx 
 3.0. :-D
 Or we can already adopt the firefox convention and go with lyx-3.0 for new 
 release. :-)

195.113.26.193/~sanda/facepalm.jpg :D

Re: Re: Python detection

[José Matos]

On Saturday 13 April 2013 16:53:42 Richard Heck wrote:
 Isn't there some import __future__ thing we can use to make this easy? 
 Or is that what is only in 2.7?
 
 Richard

python 2.7 supports both from future import  as well as new features that 
were backported from python 3 (specifically from 3.1) such as python 2.6 as 
incorporated features from python 3.0

That why I said that it possible to write code that is compatible between 
python 2.7 and python 3, if necessary using 2to3 as Günter referred before.

FWIW http://docs.python.org/dev/whatsnew/ (with a list of what has changed 
between each version) is a nice read.

One example that illustrates my point, in lib/scripts/lyxpak.py we use sets 
(data structures, basically dictionaries where we only care about keys).

In python 3 a set can be declared as

{1,2,3,4,5}

and so can you using python 2.7.


In a sense this is a bad example because the previous syntax would still work 
set([1,2,3,4,5]) but I hope you get the point. :-)

-- 
José Abílio

Re: Re: Re: Re: Re: Re: Python detection

[José Matos]

On Saturday 13 April 2013 16:37:55 Pavel Sanda wrote:
 facepalm.jpg 

By using a polar bear instead of a cat you have spoken to my heart. ;-)

Cheers,
-- 
José Abílio

Re: Python detection

[Stephan Witt]

Am 13.04.2013 um 03:09 schrieb Pavel Sanda :

> José Matos wrote:
>> So these are the facts. The question then is how do we want to proceed?
> 
> I thought we want to be >3.0 compatible and ditch 2.x series completely(?).
> Otherwise it looks like just maintenace burden without profit.
> 
> What's the status of python 3 on fedora/debian/suse?

On my Mac (latest version Mac OS X 10.8.3) the default is 2.7.2.

Stephan

stephan$ python -V
Python 2.7.2
stephan$ which python
/usr/bin/python
stephan$ 

Re: Python detection

[Cor Blom]

Op 13-04-13 03:09, Pavel Sanda schreef:

José Matos wrote:

So these are the facts. The question then is how do we want to proceed?


I thought we want to be >3.0 compatible and ditch 2.x series completely(?).
Otherwise it looks like just maintenace burden without profit.

What's the status of python 3 on fedora/debian/suse?

Pavel



on openSUSE 12.3 python 2 (2.7.3) is still default, but version 3 
(3.3.0) is available. Unknown when default will change.


Cor

Re: Python detection

[Pavel Sanda]

Stephan Witt wrote:
> > What's the status of python 3 on fedora/debian/suse?
> 
> On my Mac (latest version Mac OS X 10.8.3) the default is 2.7.2.

Default is not so important, important is 3.x availability, we have
mostly working selection mechanism thanks to Enrico.

Pavel

Re: Python detection

[Georg Baum]

Pavel Sanda wrote:

> Stephan Witt wrote:
>> > What's the status of python 3 on fedora/debian/suse?
>> 
>> On my Mac (latest version Mac OS X 10.8.3) the default is 2.7.2.
> 
> Default is not so important, important is 3.x availability, we have
> mostly working selection mechanism thanks to Enrico.

3.2.1 is available in debian squeeze (the current stable version). Since 
debian is usually the most outdated linux distro it should not be a problem 
to require python 3 if it is avialable on OS X as well. If we stay with 
python 2 I'd say that 2.6 is a safe minimum requirement. This could be 
raised to 2.7 as soon as RHEL 7 and debian wheezy are released.

BTW I don't see any maintenance burden if we stay with version 2 for another 
year or so, as long as we don't support both versions at the same time.


Georg

Re: Python detection

[Georg Baum]

Georg Baum wrote:

> 3.2.1 is available in debian squeeze (the current stable version).

Wrong, it is 3.1.3, but does not matter.


Georg

Re: Python detection

[Guenter Milde]

On 2013-04-13, Georg Baum wrote:
> Pavel Sanda wrote:
>> Stephan Witt wrote:
>>> > What's the status of python 3 on fedora/debian/suse?

>>> On my Mac (latest version Mac OS X 10.8.3) the default is 2.7.2.

>> Default is not so important, important is 3.x availability, we have
>> mostly working selection mechanism thanks to Enrico.

> 3.2.1 is available in debian squeeze (the current stable version). Since 
> debian is usually the most outdated linux distro it should not be a problem 
> to require python 3 if it is avialable on OS X as well. If we stay with 
> python 2 I'd say that 2.6 is a safe minimum requirement. This could be 
> raised to 2.7 as soon as RHEL 7 and debian wheezy are released.

> BTW I don't see any maintenance burden if we stay with version 2 for another 
> year or so, as long as we don't support both versions at the same time.

I propose to keep supporting 2.x until:

* the minimum requirement is 2.7 (i.e. 2.7 is available in Debian/stable),
  
  AND
  
* the majority of Python installations defaults to Python 3.


I suppose, there is no need to raise the minimum requirement to 2.7 unless
we start supporting 3.x.

Günter

Re: Re: Re: Re: Python detection

[José Matos]

On Friday 12 April 2013 18:09:02 Pavel Sanda wrote:
> I thought we want to be >3.0 compatible and ditch 2.x series completely(?).
> Otherwise it looks like just maintenace burden without profit.
> 
> What's the status of python 3 on fedora/debian/suse?
> 
> Pavel

In the mean time it is possible to use the features of python 2.7 that allow an 
easy update to python 3.3.

Note that even if we go python 3 we should set a minimum version, like say 
python 3.2 or even python 3.3 if we are feeling lucky. :-)

In case of Fedora it has the most recent versions python 2.7.4 and python 3.3.1 
(they are in the testing stage because it has been released this/last week). 
The distribution default is yet python 2 and it will be at least for another 
year.

Note that personally I have no problem going the python 3 route and if we 
decide to go that way I will support it.

-- 
José Abílio

Re: Re: Re: Re: Python detection

[Pavel Sanda]

José Matos wrote:
> In the mean time it is possible to use the features of python 2.7 that allow 
> an easy update to python 3.3.

I hope we already at least support python 2.7, cause what I see in changelogs, 
Uwe already ships it in Win version :)

> Note that even if we go python 3 we should set a minimum version, like say 
> python 3.2 or even python 3.3 if we are feeling lucky. :-)

You mean that backward compatibility issues are even within 3.x series?

> Note that personally I have no problem going the python 3 route and if we 
> decide to go that way I will support it.

I don't feel any hurry for bumping, just tried to catch you while your are 
active, otherwise I'm not sure who wants to do that...

Pavel

Re: Python detection

[Richard Heck]

On 04/13/2013 02:09 PM, José Matos wrote:

On Friday 12 April 2013 18:09:02 Pavel Sanda wrote:

I thought we want to be >3.0 compatible and ditch 2.x series completely(?).
Otherwise it looks like just maintenace burden without profit.

What's the status of python 3 on fedora/debian/suse?

Pavel

In the mean time it is possible to use the features of python 2.7 that allow an 
easy update to python 3.3.

Note that even if we go python 3 we should set a minimum version, like say 
python 3.2 or even python 3.3 if we are feeling lucky. :-)

In case of Fedora it has the most recent versions python 2.7.4 and python 3.3.1 
(they are in the testing stage because it has been released this/last week). 
The distribution default is yet python 2 and it will be at least for another 
year.

Note that personally I have no problem going the python 3 route and if we 
decide to go that way I will support it.


Isn't there some "import __future__" thing we can use to make this easy? 
Or is that what is only in 2.7?


Richard

Re: Re: Re: Re: Re: Python detection

[José Matos]

On Saturday 13 April 2013 11:36:18 Pavel Sanda wrote:
> José Matos wrote:
> > In the mean time it is possible to use the features of python 2.7 that 
> > allow an easy update to python 3.3.
> 
> I hope we already at least support python 2.7, cause what I see in 
> changelogs, Uwe already ships it in Win version :)

Sure, lyx works with python 2.7 but it does not make any use of the new 
features that are present in python-2.7 but are not present in python-2.4. That 
is the point of forward compatible. :-)

When I say that we should support python-2.7 I mean, in this context, that we 
should make python-2.7 the minimum supported version in order to simplify a 
transition to python 3 later.

> > Note that even if we go python 3 we should set a minimum version, like say 
> > python 3.2 or even python 3.3 if we are feeling lucky. :-)
> 
> You mean that backward compatibility issues are even within 3.x series?

No. Not with that alarming tone. :-)

I mean that it is easy to go from python-2.7 to python-3.3 (or 3.2) that it is 
to go from python-2.7 to python-3.0 or python-3.1.

Take as an example the python 3.3 release:
http://www.python.org/getit/releases/3.3.0/

Notice the third paragraph:
"Python 3.3 includes a range of improvements of the 3.x series, as well as 
*easier porting* between 2.x and 3.x."

In the development of python 3.3 there was a moratorium in the development of 
new language features in order to improve both the standard library and the 
porting of the code from 2.x.

> > Note that personally I have no problem going the python 3 route and if we 
> > decide to go that way I will support it.
> 
> I don't feel any hurry for bumping, just tried to catch you while your are 
> active, otherwise I'm not sure who wants to do that...
> 
> Pavel

Note that I am proposing this change after lyx-2.1 is released so in a sense 
this discussion is premature.

Oh, BTW and then if we go with python 3.x we can call the next version lyx 3.0. 
:-D
Or we can already adopt the firefox convention and go with lyx-3.0 for new 
release. :-)

FWIW on a more serious note that are lots of very competent python programmers 
in this list so I am not worried. :-)

Regards,
-- 
José Abílio

Re: Re: Re: Re: Re: Python detection

[Pavel Sanda]

José Matos wrote:
> Oh, BTW and then if we go with python 3.x we can call the next version lyx 
> 3.0. :-D
> Or we can already adopt the firefox convention and go with lyx-3.0 for new 
> release. :-)

195.113.26.193/~sanda/facepalm.jpg :D

Re: Re: Python detection

[José Matos]

On Saturday 13 April 2013 16:53:42 Richard Heck wrote:
> Isn't there some "import __future__" thing we can use to make this easy? 
> Or is that what is only in 2.7?
> 
> Richard

python 2.7 supports both "from future import " as well as new features that 
were backported from python 3 (specifically from 3.1) such as python 2.6 as 
incorporated features from python 3.0

That why I said that it possible to write code that is compatible between 
python 2.7 and python 3, if necessary using 2to3 as Günter referred before.

FWIW http://docs.python.org/dev/whatsnew/ (with a list of what has changed 
between each version) is a nice read.

One example that illustrates my point, in lib/scripts/lyxpak.py we use sets 
(data structures, basically dictionaries where we only care about keys).

In python 3 a set can be declared as

{1,2,3,4,5}

and so can you using python 2.7.


In a sense this is a bad example because the previous syntax would still work 
set([1,2,3,4,5]) but I hope you get the point. :-)

-- 
José Abílio

Re: Re: Re: Re: Re: Re: Python detection

[José Matos]

On Saturday 13 April 2013 16:37:55 Pavel Sanda wrote:
> facepalm.jpg 

By using a polar bear instead of a cat you have spoken to my heart. ;-)

Cheers,
-- 
José Abílio

Re: Re: Python detection

[José Matos]

On Thursday 11 April 2013 10:59:47 Pavel Sanda wrote:
 I think that long term solution was rather to switch to Python 3.
 But all such talk is cheap, we need patches 
 Pavel

The first step is to raise the supported python to version 2.7 and then the 
transition will be easy. That was the whole point of version 2.7 (after version 
2.6) was to ease the transition to python 3. That is realistic and an easy task.

Are we there at that point?

Should that be one of the goals of lyx-2.2-devel?

That is what we can decide now.

-- 
José Abílio

Re: Re: Python detection

[Pavel Sanda]

José Matos wrote:
 Are we there at that point?

You are the pythonist here :)
P

Re: Re: Re: Python detection

[José Matos]

On Friday 12 April 2013 12:35:57 Pavel Sanda wrote:
 You are the pythonist here 
 P

:-)

The issue is what is the minimum version of python that we want to support. If 
we decide to stay with python 2 as the default version the question then 
becomes what is the minimum version we want to support.

According to http://en.wikipedia.org/wiki/History_of_Python

the minimum version of python that we are using now has been released more than 
8 years ago.

 *  Python 2.0 - October 16, 2000 
 *  Python 2.1 - April 17, 2001
 *  Python 2.2 - December 21, 2001
 *  Python 2.3 - July 29, 2003
 *  Python 2.4 - November 30, 2004
 *  Python 2.5 - September 19, 2006
 *  Python 2.6 - October 1, 2008
 *  Python 2.7 - July 3, 2010

The main differences between 2.6 and 2.7 is that 2.7 simplifies more the 
transition process to python 3.

The political decision that we need to make is what is the minimum standard we 
want to set for the python version. For example python 2.7 is only available 
for wheezy that will be debian 7.0 as well for RHEL 7 that we will be out soon. 
Both the most up to date current stable versions of these two distributions, 
that we have used as reference in the past, only carry currently python 2.6.

I would expect that they will only switch to python3 by default in 5 years or 
so (a forecast done with my usual optimism).

So these are the facts. The question then is how do we want to proceed?

-- 
José Abílio

Re: Re: Re: Python detection

[Pavel Sanda]

José Matos wrote:
 So these are the facts. The question then is how do we want to proceed?

I thought we want to be 3.0 compatible and ditch 2.x series completely(?).
Otherwise it looks like just maintenace burden without profit.

What's the status of python 3 on fedora/debian/suse?

Pavel

Re: Re: Python detection

[José Matos]

On Thursday 11 April 2013 10:59:47 Pavel Sanda wrote:
> I think that long term solution was rather to switch to Python 3.
> But all such talk is cheap, we need patches 
> Pavel

The first step is to raise the supported python to version 2.7 and then the 
transition will be easy. That was the whole point of version 2.7 (after version 
2.6) was to ease the transition to python 3. That is realistic and an easy task.

Are we there at that point?

Should that be one of the goals of lyx-2.2-devel?

That is what we can decide now.

-- 
José Abílio

Re: Re: Python detection

[Pavel Sanda]

José Matos wrote:
> Are we there at that point?

You are the pythonist here :)
P

Re: Re: Re: Python detection

[José Matos]

On Friday 12 April 2013 12:35:57 Pavel Sanda wrote:
> You are the pythonist here 
> P

:-)

The issue is what is the minimum version of python that we want to support. If 
we decide to stay with python 2 as the default version the question then 
becomes what is the minimum version we want to support.

According to http://en.wikipedia.org/wiki/History_of_Python

the minimum version of python that we are using now has been released more than 
8 years ago.

 *  Python 2.0 - October 16, 2000 
 *  Python 2.1 - April 17, 2001
 *  Python 2.2 - December 21, 2001
 *  Python 2.3 - July 29, 2003
 *  Python 2.4 - November 30, 2004
 *  Python 2.5 - September 19, 2006
 *  Python 2.6 - October 1, 2008
 *  Python 2.7 - July 3, 2010

The main differences between 2.6 and 2.7 is that 2.7 simplifies more the 
transition process to python 3.

The political decision that we need to make is what is the minimum standard we 
want to set for the python version. For example python 2.7 is only available 
for wheezy that will be debian 7.0 as well for RHEL 7 that we will be out soon. 
Both the most up to date current stable versions of these two distributions, 
that we have used as reference in the past, only carry currently python 2.6.

I would expect that they will only switch to python3 by default in 5 years or 
so (a forecast done with my usual optimism).

So these are the facts. The question then is how do we want to proceed?

-- 
José Abílio

Re: Re: Re: Python detection

[Pavel Sanda]

José Matos wrote:
> So these are the facts. The question then is how do we want to proceed?

I thought we want to be >3.0 compatible and ditch 2.x series completely(?).
Otherwise it looks like just maintenace burden without profit.

What's the status of python 3 on fedora/debian/suse?

Pavel

Re: Python detection

[Guenter Milde]

On 2013-04-11, Pavel Sanda wrote:
 Enrico Forestieri wrote:
 On Sat, Apr 06, 2013 at 10:10:48AM -0700, Pavel Sanda wrote:

As a long-term project, I suggest making the Python scripts run with both,
Python 2.x and 3.x (with x some decent choice of not-too-old versions).

For simple modules, this could be achieved by some compatibility definitions
and avoiding incompatible syntax.

For larger modules/packages, I suggest providing:

* two versions of the module/package, where the Py3x version is generated
  from the Py2x version with the 2to3 script that comes with distutils.
  
* a front end script that detects the Python version and imports the
  corresponding module.
  
I have some experience in this field from Docutils development, so I may be
able to help implementing.

Günter  

Re: Python detection

[Pavel Sanda]

Guenter Milde wrote:
 As a long-term project, I suggest making the Python scripts run with both,
 Python 2.x and 3.x (with x some decent choice of not-too-old versions).

I think that long term solution was rather to switch to Python 3.
But all such talk is cheap, we need patches :)
Pavel

Re: Python detection

[Guenter Milde]

On 2013-04-11, Pavel Sanda wrote:
> Enrico Forestieri wrote:
>> On Sat, Apr 06, 2013 at 10:10:48AM -0700, Pavel Sanda wrote:

As a long-term project, I suggest making the Python scripts run with both,
Python 2.x and 3.x (with x some decent choice of not-too-old versions).

For simple modules, this could be achieved by some compatibility definitions
and avoiding incompatible syntax.

For larger modules/packages, I suggest providing:

* two versions of the module/package, where the Py3x version is generated
  from the Py2x version with the 2to3 script that comes with distutils.
  
* a front end script that detects the Python version and imports the
  corresponding module.
  
I have some experience in this field from Docutils development, so I may be
able to help implementing.

Günter  

Re: Python detection

[Pavel Sanda]

Guenter Milde wrote:
> As a long-term project, I suggest making the Python scripts run with both,
> Python 2.x and 3.x (with x some decent choice of not-too-old versions).

I think that long term solution was rather to switch to Python 3.
But all such talk is cheap, we need patches :)
Pavel

Re: Python detection

[Pavel Sanda]

Enrico Forestieri wrote:
 On Sat, Apr 06, 2013 at 10:10:48AM -0700, Pavel Sanda wrote:
 
  Enrico Forestieri wrote:
   2) Every time Systemcall::startscript() is called with a command starting
  exactly as python -tt, the python string is replaced with the name
  of the good python, e.g., python -tt - python2.6.8 -tt.
  
  Yep, but there are parts of code like preview machinery which run
  ForkedCall::startScript() and then no python substitution is called.
  Intended or bug?
 
 Not intended. If this is the case, ForkedCall::startScript() should
 mimic what Systemcall::startscript() does.

Added to bugzilla, #8631.
Pavel

Re: Python detection

[Pavel Sanda]

Enrico Forestieri wrote:
> On Sat, Apr 06, 2013 at 10:10:48AM -0700, Pavel Sanda wrote:
> 
> > Enrico Forestieri wrote:
> > > 2) Every time Systemcall::startscript() is called with a command starting
> > >exactly as "python -tt", the "python" string is replaced with the name
> > >of the "good" python, e.g., "python -tt" -> "python2.6.8 -tt".
> > 
> > Yep, but there are parts of code like preview machinery which run
> > ForkedCall::startScript() and then no python substitution is called.
> > Intended or bug?
> 
> Not intended. If this is the case, ForkedCall::startScript() should
> mimic what Systemcall::startscript() does.

Added to bugzilla, #8631.
Pavel

Re: Python detection

[Enrico Forestieri]

On Fri, Apr 05, 2013 at 09:44:49PM -0700, Pavel Sanda wrote:

 Enrico,
 
 what is the status of the python 2 detection you committed some time ago?
 Is it just supposed to be fallback in order to avoid worst things or
 is lyx supposed to work on systems with both 2.6  3.x pythons?

It is supposed to automatically use any python version 2.
If I remember correctly, it should work like this:
1) At startup, all commands in $PATH whose name starts with python
   are checked and the first of them that declares to be version 2.x
   is taken to be a good python version.
2) Every time Systemcall::startscript() is called with a command starting
   exactly as python -tt, the python string is replaced with the name
   of the good python, e.g., python -tt - python2.6.8 -tt.
This means that if you call python using an absolute path or with a name
like python3.0, no substitution takes place and that version of python
(whatever it is) is used instead.

 Is see errors like
 
 Found Python 2.6.8
 
   File /lyx/devel/lib/scripts/lyxpreview2bitmap.py, line 293
 except getopt.GetoptError, err:
  ^
 SyntaxError: invalid syntax
 
 when default python links to 3.x.

This means that either you do not invoke python exactly as python -tt
or there is a flaw in the automatic substitution code.

-- 
Enrico

Re: Python detection

[Pavel Sanda]

Enrico Forestieri wrote:
 2) Every time Systemcall::startscript() is called with a command starting
exactly as python -tt, the python string is replaced with the name
of the good python, e.g., python -tt - python2.6.8 -tt.

Yep, but there are parts of code like preview machinery which run
ForkedCall::startScript() and then no python substitution is called.
Intended or bug?

Pavel

Re: Python detection

[Enrico Forestieri]

On Sat, Apr 06, 2013 at 10:10:48AM -0700, Pavel Sanda wrote:

 Enrico Forestieri wrote:
  2) Every time Systemcall::startscript() is called with a command starting
 exactly as python -tt, the python string is replaced with the name
 of the good python, e.g., python -tt - python2.6.8 -tt.
 
 Yep, but there are parts of code like preview machinery which run
 ForkedCall::startScript() and then no python substitution is called.
 Intended or bug?

Not intended. If this is the case, ForkedCall::startScript() should
mimic what Systemcall::startscript() does.

-- 
Enrico

Re: Python detection

[Enrico Forestieri]

On Fri, Apr 05, 2013 at 09:44:49PM -0700, Pavel Sanda wrote:

> Enrico,
> 
> what is the status of the python 2 detection you committed some time ago?
> Is it just supposed to be fallback in order to avoid worst things or
> is lyx supposed to work on systems with both 2.6 & 3.x pythons?

It is supposed to automatically use any python version 2.
If I remember correctly, it should work like this:
1) At startup, all commands in $PATH whose name starts with "python"
   are checked and the first of them that declares to be version 2.x
   is taken to be a "good" python version.
2) Every time Systemcall::startscript() is called with a command starting
   exactly as "python -tt", the "python" string is replaced with the name
   of the "good" python, e.g., "python -tt" -> "python2.6.8 -tt".
This means that if you call python using an absolute path or with a name
like "python3.0", no substitution takes place and that version of python
(whatever it is) is used instead.

> Is see errors like
> 
> Found Python 2.6.8
> 
>   File "/lyx/devel/lib/scripts/lyxpreview2bitmap.py", line 293
> except getopt.GetoptError, err:
>  ^
> SyntaxError: invalid syntax
> 
> when default python links to 3.x.

This means that either you do not invoke python exactly as "python -tt"
or there is a flaw in the automatic substitution code.

-- 
Enrico

Re: Python detection

[Pavel Sanda]

Enrico Forestieri wrote:
> 2) Every time Systemcall::startscript() is called with a command starting
>exactly as "python -tt", the "python" string is replaced with the name
>of the "good" python, e.g., "python -tt" -> "python2.6.8 -tt".

Yep, but there are parts of code like preview machinery which run
ForkedCall::startScript() and then no python substitution is called.
Intended or bug?

Pavel

Re: Python detection

[Enrico Forestieri]

On Sat, Apr 06, 2013 at 10:10:48AM -0700, Pavel Sanda wrote:

> Enrico Forestieri wrote:
> > 2) Every time Systemcall::startscript() is called with a command starting
> >exactly as "python -tt", the "python" string is replaced with the name
> >of the "good" python, e.g., "python -tt" -> "python2.6.8 -tt".
> 
> Yep, but there are parts of code like preview machinery which run
> ForkedCall::startScript() and then no python substitution is called.
> Intended or bug?

Not intended. If this is the case, ForkedCall::startScript() should
mimic what Systemcall::startscript() does.

-- 
Enrico