Re: [gentoo-dev] Stabilization of Python 3.1

2009-10-08 Thread Arfrever Frehtes Taifersar Arahesis
2009-09-20 20:46:17 Nirbheek Chauhan napisał(a):
 On Sun, Sep 20, 2009 at 11:57 PM, Arfrever Frehtes Taifersar Arahesis
 arfre...@gentoo.org wrote:
  There is a difference between Python scripts and Python modules.
 
 
 Yes, I'm well aware of the difference between them.
 
 [snip]
  Python modules shouldn't have shebang. Python modules are intended to
  be imported from Python scripts or other Python modules. Any shebang
  in a Python module is ignored, when this module is imported using 'import'
  statement.
 
 
 You forget that the search path for both installs is different, and
 hence modules installed for python-3 cannot be found/used by scripts
 using python-2; which results in the dependency hell; which was the
 basis for my whole argument.

When both Python 2 and Python 3 are installed, then Python modules, which
support both Python 2 and Python 3, are automatically installed for both
Python 2 and Python 3.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Petteri Räty
Alex Alexander wrote:
 *On Sat, Sep 19, 2009 at 23:21, Robert Bridge rob...@robbieab.com wrote:
 So the question isn't SHOULD python-3 be stabilised, it's what will break if
 it is surely?
 
 There seems to be a misunderstanding on what will happen if/when
 python 3 gets stabilized.
 
 The short answer is... *drum roll*... nothing :)
 

Every Gentoo system where world or system includes deps like
=dev-lang/python-2.5 will get it installed because in this case Portage
will automatically update to the latest slot at least according to my
quick research. I don't like putting stuff to users systems that they
have no need for.

Regards,
Petteri






signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Richard Freeman

Olivier Crête wrote:


~arch is for testing ebuilds, not the upstream package



I'm pretty sure this isn't the case - at least not as cleanly as you 
suggest.  Certainly testing the ebuilds themselves is part of the reason 
for having ~arch, but upstream readiness is part of it as well.  If a 
package hit ~arch and we got 10 serious bugs that were all upstream 
problems and then somebody filed a STABLEREQ I know that I wouldn't be 
the one to stabilize it.


The whole point of having QA is so that people who don't want to be 
bothered with bleeding-edge packages aren't bothered with them.  Masking 
is for packages with known serious problems, ~arch is for packages that 
we think are fine but don't have much production history with, and 
stable is for packages that are known to be decent with history.


However, I'm not convinced that the 3.1 issues need to be a showstopper 
for going stable.  Others have made some of these suggestions, but let 
me consolidate some ideas that have come up:


1.  A tracking bug should be created to track 3.1 stabilization issues 
(assuming it doesn't already exist).
2.  Portage (and other system packages) deps should be checked to ensure 
it pulls in the current version.  This should be carefully coordinated.
3.  -dev-announce message sent out to check your python deps and fix 
them (logging blockers as needed).  This need not be carefully coordinated.
4.  einfo message about not eselecting the new version of python.  News 
message as well.


As long as the current version doesn't go anywhere and the current 
version can be re-selected at-will, then I don't see how users can get 
themselves into a corner.


The ability to support stuff like this is the reason we have SLOTs in 
the first place.




Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Jesús Guerrero
On Sat, 19 Sep 2009 19:09:38 +0200, Dirkjan Ochtman d...@gentoo.org
wrote:
 On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote:
 What is the point of stabilizing it if users shouldn't use it as main
 interpreter? Just leave it in ~arch until it can be safely used.
 
 Making it easily available so that people can port stuff, so that the
 entire world may be able to use it as their main interpreter sooner?

Ummm, if someone is not able to keywords the ~arch package, I doubt,
highly doubt, that s/he is going to be able to port anything, seriously...

Just eselect set python to 3.1 and see how wonderfully your portage
works...
-- 
Jesús Guerrero



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Jesús Guerrero
On Sat, 19 Sep 2009 20:51:17 +0200, Arfrever Frehtes Taifersar Arahesis
arfrever@gmail.com wrote:
 2009-09-19 20:22:49 Tobias Klausmann napisał(a):
 Hi! 
 
 Aside from the remarks made by others (and speaking as someone
 who maintains Python software), there is one reason for me to not
 switch Python 3 to stable yet: lack of compatibility. Software
 that runs with 3.x will not run with any 2.x version as of today
 
 It's possible (and not too hard) to write code which works with
 Python 3 and 2.6. It might be also possible to support older
 versions, but it would require many ugly exec() calls etc.

Possible doesn't equal to real. Most software won't work with 3.1,
TODAY.
-- 
Jesús Guerrero



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Jesús Guerrero
On Sun, 20 Sep 2009 08:55:00 +1200, Alistair Bush ali_b...@gentoo.org
wrote:
 Stabilization of Python 3.1.* will be requested at the beginning of
  november. There was a suggestion to create a news item which would
  inform
  users that temporarily they shouldn't switch to Python 3 as their main
  interpreter. Python ebuilds don't automatically activate Python 3, so
  I'm
  not sure if the news item is required. What is your opinion about it?
 
 
 Stablise.
 
 And to pacify all the cry babies out there could we update portage tools
 to 
 call /usr/bin/python2.6 directly?


Yes, we could. And *AFTER* that happens, then it will be time to *cry* ;)
for the stabilization of 3.1, not now. Some people don't seem to realize
that most distros are not using 3.1, and even if they were using it, Gentoo
would still be a very special case because python is a core piece in this
OS, and not on any other.


-- 
Jesús Guerrero



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Dale
Richard Freeman wrote:
 Olivier Crête wrote:

 ~arch is for testing ebuilds, not the upstream package


 I'm pretty sure this isn't the case - at least not as cleanly as you
 suggest.  Certainly testing the ebuilds themselves is part of the
 reason for having ~arch, but upstream readiness is part of it as
 well.  If a package hit ~arch and we got 10 serious bugs that were all
 upstream problems and then somebody filed a STABLEREQ I know that I
 wouldn't be the one to stabilize it.

 The whole point of having QA is so that people who don't want to be
 bothered with bleeding-edge packages aren't bothered with them. 
 Masking is for packages with known serious problems, ~arch is for
 packages that we think are fine but don't have much production history
 with, and stable is for packages that are known to be decent with
 history.

 However, I'm not convinced that the 3.1 issues need to be a
 showstopper for going stable.  Others have made some of these
 suggestions, but let me consolidate some ideas that have come up:

 1.  A tracking bug should be created to track 3.1 stabilization issues
 (assuming it doesn't already exist).
 2.  Portage (and other system packages) deps should be checked to
 ensure it pulls in the current version.  This should be carefully
 coordinated.
 3.  -dev-announce message sent out to check your python deps and fix
 them (logging blockers as needed).  This need not be carefully
 coordinated.
 4.  einfo message about not eselecting the new version of python. 
 News message as well.

 As long as the current version doesn't go anywhere and the current
 version can be re-selected at-will, then I don't see how users can get
 themselves into a corner.

 The ability to support stuff like this is the reason we have SLOTs in
 the first place.



Thanks for explaining that better than I could. 

Dale

:-)  :-) 



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Jesús Guerrero
On Sun, 20 Sep 2009 00:41:32 +0200, Dawid Węgliński c...@gentoo.org
wrote:
 On Sunday 20 of September 2009 00:32:28 Dale wrote:
 
  ~arch is for testing ebuilds, not the upstream package

 So it would be OK to mark something stable even tho portage itself
 doesn't work with it?  Sorry, this makes no sense to me.  I run stable
 for the most part and having a package that portage depends on that is
 not stable just sounds a little like putting the cart before the horse.

 See some of the other replies as to why this is a not so good idea.

 Dale

 :-)  :-)
 
 You mix it up. Portage works with python 3.1. If an user switches to
 python 
 3.1 as the main interpreter, it's possible that his own scripts won't
 work. 

Yes?

# eselect python set 2
# emerge -s foo
  File /usr/bin/emerge, line 41
except PermissionDenied, e:
   ^
SyntaxError: invalid syntax


Ummm, yes, it works *beautifully*, you see. Nothing else to add.

 Marking it stable sometine in november give's some time to ebuilds 
 maintainers to fix their python based apps just like it's done with gcc 
 stabilization.

That's not the usual case. In Gentoo we have a serious policy of not
marking as stable things until it has passed one month without any serious
bug report about it. And you are proposing to break this rule for a core
piece of the OS, right, wonderful. 

Instead I say, first fix the stuff, and then we can start planning the
switch to 3.1

-- 
Jesús Guerrero



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Dale
Jesús Guerrero wrote:
 On Sun, 20 Sep 2009 00:41:32 +0200, Dawid Węgliński c...@gentoo.org
 wrote:
   
 On Sunday 20 of September 2009 00:32:28 Dale wrote:
 
 ~arch is for testing ebuilds, not the upstream package
 
 So it would be OK to mark something stable even tho portage itself
 doesn't work with it?  Sorry, this makes no sense to me.  I run stable
 for the most part and having a package that portage depends on that is
 not stable just sounds a little like putting the cart before the horse.

 See some of the other replies as to why this is a not so good idea.

 Dale

 :-)  :-)
   
 You mix it up. Portage works with python 3.1. If an user switches to
 python 
 3.1 as the main interpreter, it's possible that his own scripts won't
 work. 
 

 Yes?

 # eselect python set 2
 # emerge -s foo
   File /usr/bin/emerge, line 41
 except PermissionDenied, e:
^
 SyntaxError: invalid syntax


 Ummm, yes, it works *beautifully*, you see. Nothing else to add.

   
 Marking it stable sometine in november give's some time to ebuilds 
 maintainers to fix their python based apps just like it's done with gcc 
 stabilization.
 

 That's not the usual case. In Gentoo we have a serious policy of not
 marking as stable things until it has passed one month without any serious
 bug report about it. And you are proposing to break this rule for a core
 piece of the OS, right, wonderful. 

 Instead I say, first fix the stuff, and then we can start planning the
 switch to 3.1

   

My point exactly.  No package, especially a core package that portage
depends on, should just be thrown into the tree and just assume that it
will work for everyone else. 

Dale

:-)  :-) 



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Arfrever Frehtes Taifersar Arahesis
2009-09-20 16:53:37 Jesús Guerrero napisał(a):
 On Sun, 20 Sep 2009 00:41:32 +0200, Dawid Węgliński c...@gentoo.org
 wrote:
  On Sunday 20 of September 2009 00:32:28 Dale wrote:
  
   ~arch is for testing ebuilds, not the upstream package
 
  So it would be OK to mark something stable even tho portage itself
  doesn't work with it?  Sorry, this makes no sense to me.  I run stable
  for the most part and having a package that portage depends on that is
  not stable just sounds a little like putting the cart before the horse.
 
  See some of the other replies as to why this is a not so good idea.
 
  Dale
 
  :-)  :-)
  
  You mix it up. Portage works with python 3.1. If an user switches to
  python 
  3.1 as the main interpreter, it's possible that his own scripts won't
  work. 
 
 Yes?
 
 # eselect python set 2
 # emerge -s foo
   File /usr/bin/emerge, line 41
 except PermissionDenied, e:
^
 SyntaxError: invalid syntax
 
 
 Ummm, yes, it works *beautifully*, you see. Nothing else to add.

I have fixed it today :) .
http://sources.gentoo.org/viewcvs.py/portage?rev=14289view=rev

  Marking it stable sometine in november give's some time to ebuilds 
  maintainers to fix their python based apps just like it's done with gcc 
  stabilization.
 
 That's not the usual case. In Gentoo we have a serious policy of not
 marking as stable things until it has passed one month without any serious
 bug report about it.

There wasn't any serious bug report about Python 3.1.
IIRC the only problem was a (already fixed) build failure caused by non-UTF-8
characters in header of Berkeley DB.
Stabilization of Python 3.1.1-r1 is planned over 1 month after its addition to
the tree and about 3 months after addition of 3.1 slot to the tree.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Jesús Guerrero
On Sun, 20 Sep 2009 17:24:53 +0200, Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org wrote:
 2009-09-20 16:53:37 Jesús Guerrero napisał(a):
 On Sun, 20 Sep 2009 00:41:32 +0200, Dawid Węgliński c...@gentoo.org
 wrote:
  On Sunday 20 of September 2009 00:32:28 Dale wrote:
  
   ~arch is for testing ebuilds, not the upstream package
 
  So it would be OK to mark something stable even tho portage itself
  doesn't work with it?  Sorry, this makes no sense to me.  I run
stable
  for the most part and having a package that portage depends on that
is
  not stable just sounds a little like putting the cart before the
  horse.
 
  See some of the other replies as to why this is a not so good idea.
 
  Dale
 
  :-)  :-)
  
  You mix it up. Portage works with python 3.1. If an user switches to
  python 
  3.1 as the main interpreter, it's possible that his own scripts won't
  work. 
 
 Yes?
 
 # eselect python set 2
 # emerge -s foo
   File /usr/bin/emerge, line 41
 except PermissionDenied, e:
^
 SyntaxError: invalid syntax
 
 
 Ummm, yes, it works *beautifully*, you see. Nothing else to add.
 
 I have fixed it today :) .
 http://sources.gentoo.org/viewcvs.py/portage?rev=14289view=rev
 
  Marking it stable sometine in november give's some time to ebuilds 
  maintainers to fix their python based apps just like it's done with
  gcc
  stabilization.
 
 That's not the usual case. In Gentoo we have a serious policy of not
 marking as stable things until it has passed one month without any
 serious
 bug report about it.
 
 There wasn't any serious bug report about Python 3.1.
 IIRC the only problem was a (already fixed) build failure caused by
 non-UTF-8
 characters in header of Berkeley DB.
 Stabilization of Python 3.1.1-r1 is planned over 1 month after its
 addition to
 the tree and about 3 months after addition of 3.1 slot to the tree.

That sounds better. :)

All users want is something that works out of the box. As long as that's
true I don't have a problem with the change. I myself live in ~arch for my
desktop machine, I am just concerned about the average user.

-- 
Jesús Guerrero



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Nirbheek Chauhan
On Sun, Sep 20, 2009 at 9:16 PM, Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org wrote:
 Some packages (whose older versions might be stable) might soon start 
 requiring
 Python 3. Stabilization of these packages cannot be delayed due to the fact
 that some other packages don't work with Python 3.


Are you seriously suggesting that you would knowingly break existing
packages in the tree?

-- 
~Nirbheek Chauhan

GNOME+Mozilla Team, Gentoo



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Arfrever Frehtes Taifersar Arahesis
2009-09-20 17:56:46 Nirbheek Chauhan napisał(a):
 On Sun, Sep 20, 2009 at 9:16 PM, Arfrever Frehtes Taifersar Arahesis
 arfre...@gentoo.org wrote:
  Some packages (whose older versions might be stable) might soon start 
  requiring
  Python 3. Stabilization of these packages cannot be delayed due to the fact
  that some other packages don't work with Python 3.
 
 
 Are you seriously suggesting that you would knowingly break existing
 packages in the tree?

Please stop spreading untrue information. Stabilization of Python 3 (and 
packages
which depend on Python 3) wouldn't break any packages and wouldn't require
to switch main Python interpreter to Python 3.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Robert Buchholz
On Sunday 20 September 2009, Arfrever Frehtes Taifersar Arahesis wrote:
 Some packages (whose older versions might be stable) might soon start
 requiring Python 3. Stabilization of these packages cannot be delayed
 due to the fact that some other packages don't work with Python 3.

Of course they can. That is exactly the reason I am using a distribution 
(instead of LFS), because I expect maintainers of packages to 
coordinate and define a working set of packages for me to use. This 
includes holding back updates, fast-tracking updates, forward- and 
backward-porting. Automatisms in updates and blindly following upstream 
removes that extra value we are there to provide.



Robert


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Petteri Räty
Arfrever Frehtes Taifersar Arahesis wrote:
 2009-09-20 16:44:09 Jesús Guerrero napisał(a):
 On Sat, 19 Sep 2009 19:09:38 +0200, Dirkjan Ochtman d...@gentoo.org
 wrote:
 On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote:
 What is the point of stabilizing it if users shouldn't use it as main
 interpreter? Just leave it in ~arch until it can be safely used.
 Making it easily available so that people can port stuff, so that the
 entire world may be able to use it as their main interpreter sooner?
 Ummm, if someone is not able to keywords the ~arch package, I doubt,
 highly doubt, that s/he is going to be able to port anything, seriously...
 
 Some packages (whose older versions might be stable) might soon start 
 requiring
 Python 3. Stabilization of these packages cannot be delayed due to the fact
 that some other packages don't work with Python 3.
 

Yes indeed and when you have enough apps needing Python 3, it's much
easier to sell python 3 to the developer base as there's actually
benefit to users.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Arfrever Frehtes Taifersar Arahesis
2009-09-20 18:51:53 Robert Buchholz napisał(a):
 On Sunday 20 September 2009, Arfrever Frehtes Taifersar Arahesis wrote:
  Some packages (whose older versions might be stable) might soon start
  requiring Python 3. Stabilization of these packages cannot be delayed
  due to the fact that some other packages don't work with Python 3.
 
 Of course they can. That is exactly the reason I am using a distribution 
 (instead of LFS), because I expect maintainers of packages to 
 coordinate and define a working set of packages for me to use. This 
 includes holding back updates, fast-tracking updates, forward- and 
 backward-porting. Automatisms in updates and blindly following upstream 
 removes that extra value we are there to provide.

I agree. But Python 3.1 doesn't have more issues than Python 2.6, so
the stabilization is reasonable.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Nirbheek Chauhan
On Sun, Sep 20, 2009 at 9:37 PM, Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org wrote:
 which depend on Python 3) wouldn't break any packages and wouldn't require
 to switch main Python interpreter to Python 3.


Package X (stable) requires python-2
Package Y (stable) requires python-3

= User can't use both at the same time.

You're just introducing another form of dependency hell for the users.
They now have to figure out one of the following:

a) Find version of Package X that works with python-3
b) Find which old version of Y still works with python-2
c) Force X/Y to use python-2/3 by patching the interpreter called
d) Give up and install Ubuntu where somehow magically both work at the same time

-- 
~Nirbheek Chauhan

GNOME+Mozilla Team, Gentoo



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Nirbheek Chauhan
On Sun, Sep 20, 2009 at 8:54 PM, Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org wrote:
 2009-09-20 16:53:37 Jesús Guerrero napisał(a):
 # eselect python set 2
 # emerge -s foo
   File /usr/bin/emerge, line 41
     except PermissionDenied, e:
                            ^
 SyntaxError: invalid syntax


 Ummm, yes, it works *beautifully*, you see. Nothing else to add.

 I have fixed it today :) .
 http://sources.gentoo.org/viewcvs.py/portage?rev=14289view=rev


This is silly. portage itself was broken with python-3.1 and you want
to stabilize it? Why do you want to make it trivial for people to chop
off their feet by mistake (in panic or frustration)?

Actually, how did you make portage work with both 2.x and 3.x at the
same time? I would be very interested to know this since afaik no
useful program can work with both python-3 and python-2 with the same
code.

-- 
~Nirbheek Chauhan

GNOME+Mozilla Team, Gentoo



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Arfrever Frehtes Taifersar Arahesis
2009-09-20 19:25:55 Nirbheek Chauhan napisał(a):
 On Sun, Sep 20, 2009 at 9:37 PM, Arfrever Frehtes Taifersar Arahesis
 arfre...@gentoo.org wrote:
  which depend on Python 3) wouldn't break any packages and wouldn't require
  to switch main Python interpreter to Python 3.
 
 
 Package X (stable) requires python-2
 Package Y (stable) requires python-3
 
 = User can't use both at the same time.

Distribute/Setuptools will ensure that appropriate shebang is present in Python
scripts. In other cases, we can easily modify shebangs in installed scripts.
(A new function in python.eclass could be created for this purpose, but until
now it isn't needed.)

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Nirbheek Chauhan
On Sun, Sep 20, 2009 at 11:05 PM, Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org wrote:
 Package X (stable) requires python-2
 Package Y (stable) requires python-3

 = User can't use both at the same time.

 Distribute/Setuptools will ensure that appropriate shebang is present in 
 Python
 scripts. In other cases, we can easily modify shebangs in installed scripts.
 (A new function in python.eclass could be created for this purpose, but until
 now it isn't needed.)


Oooh, this will lead to more phun!

Package A (module, stable) requires python-3

However, A is a dependency of *both* X and Y

Now what? Slotting? Install to both/all python prefixes? Or some other
ugly solution?

Seriously, if you *really* *really* want python-3 stable, it should:

1) NOT show up in `eselect python` to set as the default interpreter
2) NOT be a dependency of any package in stable
3) Be accessibly ONLY via the name python-3 (or similar)

Which means, that for stable users, it will be for personal projects
only. In which case, I don't see much point in stabilizing it.

-- 
~Nirbheek Chauhan

GNOME+Mozilla Team, Gentoo



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Arfrever Frehtes Taifersar Arahesis
2009-09-20 19:30:54 Nirbheek Chauhan napisał(a):
 On Sun, Sep 20, 2009 at 8:54 PM, Arfrever Frehtes Taifersar Arahesis
 arfre...@gentoo.org wrote:
  2009-09-20 16:53:37 Jesús Guerrero napisał(a):
  # eselect python set 2
  # emerge -s foo
File /usr/bin/emerge, line 41
  except PermissionDenied, e:
 ^
  SyntaxError: invalid syntax
 
 
  Ummm, yes, it works *beautifully*, you see. Nothing else to add.
 
  I have fixed it today :) .
  http://sources.gentoo.org/viewcvs.py/portage?rev=14289view=rev
 
 This is silly. portage itself was broken with python-3.1 and you want
 to stabilize it?

You should distinguish between Python version used by Portage and
Python version used by packages which can be installed by Portage.

 Actually, how did you make portage work with both 2.x and 3.x at the
 same time?

Portage doesn't yet work with Python 3, but it hopefully change soon.

 I would be very interested to know this since afaik no useful program
 can work with both python-3 and python-2 with the same code.

It isn't hard to write code which works with both Python 2.6 and 3.*.

Example:

$ cat get_protocol.py
#!/usr/bin/env python

# It allows to use print() function in 2.6.
from __future__ import print_function

import sys

try:
  # Python 3
  from urllib.parse import urlparse as urllib_parse_urlparse
except ImportError:
  # Python 2
  from urlparse import urlparse as urllib_parse_urlparse

if len(sys.argv) != 2:
  sys.stderr.write(This script requires 1 argument: URL\n)

def get_protocol(url):
  return urllib_parse_urlparse(url)[0]

print(Protocol:, get_protocol(sys.argv[1]))
$ ./get_protocol.py http://www.example.com
Protocol: http

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Arfrever Frehtes Taifersar Arahesis
2009-09-20 19:47:28 Nirbheek Chauhan napisał(a):
 On Sun, Sep 20, 2009 at 11:05 PM, Arfrever Frehtes Taifersar Arahesis
 arfre...@gentoo.org wrote:
  Package X (stable) requires python-2
  Package Y (stable) requires python-3
 
  = User can't use both at the same time.
 
  Distribute/Setuptools will ensure that appropriate shebang is present in 
  Python
  scripts. In other cases, we can easily modify shebangs in installed scripts.
  (A new function in python.eclass could be created for this purpose, but 
  until
  now it isn't needed.)
 
 
 Oooh, this will lead to more phun!
 
 Package A (module, stable) requires python-3
 
 However, A is a dependency of *both* X and Y
 
 Now what? Slotting? Install to both/all python prefixes? Or some other
 ugly solution?

There is a difference between Python scripts and Python modules.

Python scripts should have shebang and this shebang is used to decide
which interpreter should be used when './script.py' is called. But it
is possible to call Python scripts using 'pythonX.Y script.py' which
will enforce using of pythonX.Y instead of interpreter specified in
shebang in this script. When one Python script executes another Python
script (using e.g. subprocess.Popen()) then both scripts will work
correctly even when they have different shebangs.

Python modules shouldn't have shebang. Python modules are intended to
be imported from Python scripts or other Python modules. Any shebang
in a Python module is ignored, when this module is imported using 'import'
statement.

The chance that well known and often used Python modules start
unconditionally require Python 3 in the near future is small, but
Python scripts can safely do it.

For example PyQt4 supports both Python 2 and 3, but a useful script, which
uses PyQt4, might require Python 3.

 Seriously, if you *really* *really* want python-3 stable, it should:
 
 1) NOT show up in `eselect python` to set as the default interpreter

When a user wants to work for an hour with a script requiring Python 3,
and doesn't want to use e.g. Portage during this time, then it is
reasonable to run 'eselect python set python3.1' once and be able
to just use './script.py' instead of having to type 'python3.1 script.py'
every time. Next this user can switch active Python back to 2.6.

 2) NOT be a dependency of any package in stable

It isn't implementable without having to change dependencies in hundreds
of packages. There is nothing wrong in having Python 3 installed which
would use small amount of disk space.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Nirbheek Chauhan
On Sun, Sep 20, 2009 at 11:57 PM, Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org wrote:
 There is a difference between Python scripts and Python modules.


Yes, I'm well aware of the difference between them.

[snip]
 Python modules shouldn't have shebang. Python modules are intended to
 be imported from Python scripts or other Python modules. Any shebang
 in a Python module is ignored, when this module is imported using 'import'
 statement.


You forget that the search path for both installs is different, and
hence modules installed for python-3 cannot be found/used by scripts
using python-2; which results in the dependency hell; which was the
basis for my whole argument.


 Seriously, if you *really* *really* want python-3 stable, it should:

 1) NOT show up in `eselect python` to set as the default interpreter

 When a user wants to work for an hour with a script requiring Python 3,
 and doesn't want to use e.g. Portage during this time, then it is
 reasonable to run 'eselect python set python3.1' once and be able
 to just use './script.py' instead of having to type 'python3.1 script.py'
 every time. Next this user can switch active Python back to 2.6.


The user would rather just edit the shebang for an hour rather than
become root, eselect and get back. Only us weird system-fudgers always
have a root shell running, most people rarely do.

 2) NOT be a dependency of any package in stable

 It isn't implementable without having to change dependencies in hundreds
 of packages. There is nothing wrong in having Python 3 installed which
 would use small amount of disk space.


You're twisting what I mean. You know what I mean -- packages
*needing* python-3.

-- 
~Nirbheek Chauhan

GNOME+Mozilla Team, Gentoo



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Arfrever Frehtes Taifersar Arahesis
2009-09-20 20:46:17 Nirbheek Chauhan napisał(a):
 On Sun, Sep 20, 2009 at 11:57 PM, Arfrever Frehtes Taifersar Arahesis
 arfre...@gentoo.org wrote:
  There is a difference between Python scripts and Python modules.
 
 
 Yes, I'm well aware of the difference between them.
 
 [snip]
  Python modules shouldn't have shebang. Python modules are intended to
  be imported from Python scripts or other Python modules. Any shebang
  in a Python module is ignored, when this module is imported using 'import'
  statement.
 
 
 You forget that the search path for both installs is different, and
 hence modules installed for python-3 cannot be found/used by scripts
 using python-2;

These modules can be installed for both Python 2 and 3 simultaneously.

  Seriously, if you *really* *really* want python-3 stable, it should:
 ...
  2) NOT be a dependency of any package in stable
 
  It isn't implementable without having to change dependencies in hundreds
  of packages. There is nothing wrong in having Python 3 installed which
  would use small amount of disk space.
 
 
 You're twisting what I mean. You know what I mean -- packages
 *needing* python-3.

So Seriously, if you *really* *really* want python-3 stable, it should:
...
2) NOT be a dependency of any package in stable is already met, because
no stable package unconditionally needs Python 3. If it was otherwise,
then the dependency tree of these stable packages would be broken.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Zac Medico
Petteri Räty wrote:
 Every Gentoo system where world or system includes deps like
 =dev-lang/python-2.5 will get it installed because in this case Portage
 will automatically update to the latest slot at least according to my
 quick research. I don't like putting stuff to users systems that they
 have no need for.

For portage-2.1.7 I'm planning to add version range detection, so
ebuilds like that can use dev-lang/python-3.0 in order to prevent
incompatible new versions of python from being pulled in
unnecessarily. See this bug:

 http://bugs.gentoo.org/show_bug.cgi?id=285767
-- 
Thanks,
Zac



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Mark Loeser
Dawid Węgliński c...@gentoo.org said:
 You mix it up. Portage works with python 3.1. If an user switches to python 
 3.1 as the main interpreter, it's possible that his own scripts won't work. 
 Marking it stable sometine in november give's some time to ebuilds 
 maintainers to fix their python based apps just like it's done with gcc 
 stabilization.

And you are mixing that up.  We never mark GCC stable before we fix
everything we have identified as a problem, or pretty close to
everything.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpW6pMGhwBsH.pgp
Description: PGP signature


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Mark Loeser
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said:
 I agree. But Python 3.1 doesn't have more issues than Python 2.6, so
 the stabilization is reasonable.

And how about all of the packages in the tree that use python?  You are
missing that huge part.  That's like saying libfoo works absolutely
great, but every single application that links to libfoo now breaks with
the new release of libfoo-2.0.  The things that use your package are
just as important when looking to stablize something or to move it out
of package.mask.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpuYjSfPlpRR.pgp
Description: PGP signature


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Dale
Mark Loeser wrote:
 Dawid Węgliński c...@gentoo.org said:
   
 You mix it up. Portage works with python 3.1. If an user switches to python 
 3.1 as the main interpreter, it's possible that his own scripts won't work. 
 Marking it stable sometine in november give's some time to ebuilds 
 maintainers to fix their python based apps just like it's done with gcc 
 stabilization.
 

 And you are mixing that up.  We never mark GCC stable before we fix
 everything we have identified as a problem, or pretty close to
 everything.

   

That will be the next thing he wants to stabilize without testing.  I
been using Gentoo for more than 5 years and this is the first time I
ever recall someone wanting to mark something stable that has not been
tested for quite some time and in the normal way.  Add in that this is
something that portage itself depends on, this just sounds like a really
bad idea.  I hope someone puts a hold on this.

Dale

:-)  :-) 



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-20 Thread Brian Harring
On Sun, Sep 20, 2009 at 06:20:41PM -0400, Mark Loeser wrote:
 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said:
  I agree. But Python 3.1 doesn't have more issues than Python 2.6, so
  the stabilization is reasonable.
 
 And how about all of the packages in the tree that use python?  You are
 missing that huge part.  That's like saying libfoo works absolutely
 great, but every single application that links to libfoo now breaks with
 the new release of libfoo-2.0.  The things that use your package are
 just as important when looking to stablize something or to move it out
 of package.mask.

Mark pretty much nailed it on the head.  Before even looking at 
stabilizing py3k it probably would be a good idea to identify what 
libs/frameworks actually *work* with it out of the box.

Keep in mind that gentoo pkging of python ebuilds isn't slotted on 
python version- meaning you wind up with either setuptools for 2.5 or 
for 2.6.  Then you take a look at the larger frameworks like 
numpy and twisted to see if they actually support 3k w/ existing 
releases.  Not a huge number do, at least for actual releases (random 
branches don't count here).

If the big boys don't support 3k yet, it doesn't much matter if the 
small fry do, thus the gain from having py3k stabilized is way less 
and the cost in terms of user annoyance is way larger.

Regardless of the potential portage issue, I honestly don't think the 
state of python libs is at the point that running purely py3k w/ 
single slotting of python pkgs is viable.

Basically what gain is there?  Stabilizing it at this point 
comes off as whee, we have py3k stabilized!  Now go mask it on all 
of your boxes since not a lot of the useful things play nice with 
it right now!

My 2 cents.
~harring


pgpaf2ifqTp0S.pgp
Description: PGP signature


[gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Arfrever Frehtes Taifersar Arahesis
Stabilization of Python 3.1.* will be requested at the beginning of november.
There was a suggestion to create a news item which would inform users that
temporarily they shouldn't switch to Python 3 as their main interpreter.
Python ebuilds don't automatically activate Python 3, so I'm not sure if
the news item is required. What is your opinion about it?

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Dirkjan Ochtman
On Sat, Sep 19, 2009 at 18:48, Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org wrote:
 Stabilization of Python 3.1.* will be requested at the beginning of november.
 There was a suggestion to create a news item which would inform users that
 temporarily they shouldn't switch to Python 3 as their main interpreter.
 Python ebuilds don't automatically activate Python 3, so I'm not sure if
 the news item is required. What is your opinion about it?

I think a news item is probably a good idea, if only because it gives
us something to point at.

Cheers,

Dirkjan



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Alex Legler
On Sat, 19 Sep 2009 18:48:27 +0200, Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org wrote:

 Stabilization of Python 3.1.* will be requested at the beginning of
 november. There was a suggestion to create a news item which would
 inform users that temporarily they shouldn't switch to Python 3 as
 their main interpreter. 

What is the point of stabilizing it if users shouldn't use it as main
interpreter? Just leave it in ~arch until it can be safely used.

Alex


signature.asc
Description: PGP signature


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Dirkjan Ochtman
On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote:
 What is the point of stabilizing it if users shouldn't use it as main
 interpreter? Just leave it in ~arch until it can be safely used.

Making it easily available so that people can port stuff, so that the
entire world may be able to use it as their main interpreter sooner?

Seriously, it's out there, there's no reason to keep it from stable.
Just prevent people from making python invoke 3.x and everything will
be fine.

Cheers,

Dirkjan



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Dale
Dirkjan Ochtman wrote:
 On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote:
   
 What is the point of stabilizing it if users shouldn't use it as main
 interpreter? Just leave it in ~arch until it can be safely used.
 

 Making it easily available so that people can port stuff, so that the
 entire world may be able to use it as their main interpreter sooner?

 Seriously, it's out there, there's no reason to keep it from stable.
 Just prevent people from making python invoke 3.x and everything will
 be fine.

 Cheers,

 Dirkjan


   

Isn't ~arch supposed to be for testing?  Isn't that the point of having
~arch?

Dale

:-)  :-) 



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Alex Legler
On Sat, 19 Sep 2009 19:09:38 +0200, Dirkjan Ochtman d...@gentoo.org
wrote:

 On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote:
  What is the point of stabilizing it if users shouldn't use it as
  main interpreter? Just leave it in ~arch until it can be safely
  used.
 
 Making it easily available so that people can port stuff, so that the
 entire world may be able to use it as their main interpreter sooner?
 

Don't you think that ~arch makes it easily available enough for people
who *want* to port stuff? 
If I run stable Gentoo, I'm interested in a /stable/ system(tm) and not
the latest Python version that people are still fiddling with.
Especially since the Gentoo core system extensively uses Python. By the
way, does Portage work with Python 3 yet?

 Seriously, it's out there, there's no reason to keep it from stable.
 Just prevent people from making python invoke 3.x and everything will
 be fine.
 

Yeah, right, let's install it on all those stable machines, but then
not use it.

Way to go!
Alex


signature.asc
Description: PGP signature


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Olivier Crête
On Sat, 2009-09-19 at 12:21 -0500, Dale wrote:
 Dirkjan Ochtman wrote:
  On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote:

  What is the point of stabilizing it if users shouldn't use it as main
  interpreter? Just leave it in ~arch until it can be safely used.
  
 
  Making it easily available so that people can port stuff, so that the
  entire world may be able to use it as their main interpreter sooner?
 
  Seriously, it's out there, there's no reason to keep it from stable.
  Just prevent people from making python invoke 3.x and everything will
  be fine.

 Isn't ~arch supposed to be for testing?  Isn't that the point of having
 ~arch?

~arch is for testing ebuilds, not the upstream package

-- 
Olivier Crête
tes...@gentoo.org
Gentoo Developer


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread AllenJB
Dirkjan Ochtman wrote:
 On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote:
 What is the point of stabilizing it if users shouldn't use it as main
 interpreter? Just leave it in ~arch until it can be safely used.
 
 Making it easily available so that people can port stuff, so that the
 entire world may be able to use it as their main interpreter sooner?
 
 Seriously, it's out there, there's no reason to keep it from stable.
 Just prevent people from making python invoke 3.x and everything will
 be fine.
 
 Cheers,
 
 Dirkjan
 

Yes, there is a very good reason: The sanity of the users and those who
support them.

As a user who has spent a lot of time on IRC and the forums supporting
other users, I think I can safely say that stabilizing a version of
python which is not supported by portage will end up in a nightmare
scenario. At the very least portage, python-updater and eselect, if not
the majority of the commonly used tools (whichever of gentoolkit,
portage-utils, eix, etc use python), should support python 3.1 before it
goes stable.

Everything would be fine if all the users read news items, forums,
mailing lists and web pages - but they don't. It will get missed by many
many users - too many for something that breaks portage, in my opinion.

I would suggest the developers keep python 3.1 out of stable until it is
supported by portage, puthon-updater and eselect at minimum (ie. you can
easily revert to 2.6).


While writing this an alternative solution has occurred to me: Make sure
portage dependencies are correct so that python doesn't get dep-cleaned
(a brief check of the portage 2.1.6.7 ebuild makes it look like this
currently isn't the case - surely this should've been done as soon as it
was known portage didn't support python 3!) and perhaps add a block to
eselect so that python-3.1 can't be selected as the system python
interpreter until portage supports it.

AllenJB



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Tobias Klausmann
Hi! 

Aside from the remarks made by others (and speaking as someone
who maintains Python software), there is one reason for me to not
switch Python 3 to stable yet: lack of compatibility. Software
that runs with 3.x will not run with any 2.x version as of today
(and I doubt there will ever be a 2.x version of Python that can
run 3.x code).

As such, upstream devs will have to maintain two branches of
software for a rather long time. Thing is, some projects just
don't have the manpower to maintain two branches, so they will
stay with 2.x versions for now. Yes, it's a catch-22, but I doubt
that a sufficiently large portion of projects will have a
3.x-compatible branch/version this year (sufficient meaning
over 95%).

On the other hand, we can patch everything that doesn't run with
3.x (i.e. fixing the shebang lines and maybe assorted paths).
The Python team is more suited to evaluate the feasibility of
that.

Regards,
Tobias

PS: As an illustration: just look at how long it took to get a
2.6-compatible version of mailman into the tree...




Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread AllenJB
Alex Legler wrote:
 On Sat, 19 Sep 2009 19:09:38 +0200, Dirkjan Ochtman d...@gentoo.org
 wrote:
 
 Seriously, it's out there, there's no reason to keep it from stable.
 Just prevent people from making python invoke 3.x and everything will
 be fine.

 
 Yeah, right, let's install it on all those stable machines, but then
 not use it.
 
 Way to go!
 Alex

Surely this isn't an issue: If the dependencies on packages are correct,
surely this shouldn't happen?

If the dependencies aren't correct, maybe checking and correcting them
for every package that needs python should be a requirement for
stabilization.

AllenJB



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Nirbheek Chauhan
On Sat, Sep 19, 2009 at 10:18 PM, Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org wrote:
 Stabilization of Python 3.1.* will be requested at the beginning of november.
 There was a suggestion to create a news item which would inform users that
 temporarily they shouldn't switch to Python 3 as their main interpreter.
 Python ebuilds don't automatically activate Python 3, so I'm not sure if
 the news item is required. What is your opinion about it?


Have any other distribution moved to purely using python-3.1? The
reason is pretty simple: Not everything has been ported to use 3.1
yet. Hell, I personally have 3.1 under a local p.mask so I don't have
to bother with breakage due to it. (existing packages as well as
scripts/projects I have).

I do believe it will be very counter-productive to move it to stable
at this point.


-- 
~Nirbheek Chauhan

GNOME+Mozilla Team, Gentoo



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Arfrever Frehtes Taifersar Arahesis
2009-09-19 20:22:49 Tobias Klausmann napisał(a):
 Hi! 
 
 Aside from the remarks made by others (and speaking as someone
 who maintains Python software), there is one reason for me to not
 switch Python 3 to stable yet: lack of compatibility. Software
 that runs with 3.x will not run with any 2.x version as of today

It's possible (and not too hard) to write code which works with
Python 3 and 2.6. It might be also possible to support older
versions, but it would require many ugly exec() calls etc.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Arfrever Frehtes Taifersar Arahesis
2009-09-19 20:45:45 Nirbheek Chauhan napisał(a):
 On Sat, Sep 19, 2009 at 10:18 PM, Arfrever Frehtes Taifersar Arahesis
 arfre...@gentoo.org wrote:
  Stabilization of Python 3.1.* will be requested at the beginning of 
  november.
  There was a suggestion to create a news item which would inform users that
  temporarily they shouldn't switch to Python 3 as their main interpreter.
  Python ebuilds don't automatically activate Python 3, so I'm not sure if
  the news item is required. What is your opinion about it?
 
 
 Have any other distribution moved to purely using python-3.1?

We won't move to purely using Python 3.1. Both Python 2 and 3 will be used.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Arfrever Frehtes Taifersar Arahesis
2009-09-19 20:20:10 AllenJB napisał(a):
 Dirkjan Ochtman wrote:
  On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote:
  What is the point of stabilizing it if users shouldn't use it as main
  interpreter? Just leave it in ~arch until it can be safely used.
  
  Making it easily available so that people can port stuff, so that the
  entire world may be able to use it as their main interpreter sooner?
  
  Seriously, it's out there, there's no reason to keep it from stable.
  Just prevent people from making python invoke 3.x and everything will
  be fine.
  
  Cheers,
  
  Dirkjan
  
 
 Yes, there is a very good reason: The sanity of the users and those who
 support them.
 
 As a user who has spent a lot of time on IRC and the forums supporting
 other users, I think I can safely say that stabilizing a version of
 python which is not supported by portage will end up in a nightmare
 scenario. At the very least portage, python-updater and eselect, if not
 the majority of the commonly used tools (whichever of gentoolkit,
 portage-utils, eix, etc use python), should support python 3.1 before it
 goes stable.

python-updater and eselect are written in bash. portage-utils are written
in C. eix is written in C++.

 perhaps add a block to eselect so that python-3.1 can't be selected as
 the system python interpreter until portage supports it.

Users might want to sometimes temporarily switch to Python 3 to test some
Portage-unrelated code.
Anyway Portage will support Python 3 soon.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Mark Loeser
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said:
 Stabilization of Python 3.1.* will be requested at the beginning of november.
 There was a suggestion to create a news item which would inform users that
 temporarily they shouldn't switch to Python 3 as their main interpreter.
 Python ebuilds don't automatically activate Python 3, so I'm not sure if
 the news item is required. What is your opinion about it?

Please don't do this.  The stable system is meant to Just Work.  We
don't need people switching between python versions and making half of
their system unusuable.  There is absolutely no benefit to moving it to
stable.

-- 
Mark Loeser
email -   halcy0n AT gentoo DOT org
email -   mark AT halcy0n DOT com
web   -   http://www.halcy0n.com


pgpBOqjpyzWlZ.pgp
Description: PGP signature


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Nirbheek Chauhan
On Sun, Sep 20, 2009 at 12:23 AM, Arfrever Frehtes Taifersar Arahesis
arfre...@gentoo.org wrote:
 Have any other distribution moved to purely using python-3.1?

 We won't move to purely using Python 3.1. Both Python 2 and 3 will be used.


Let me modify me question: Has any other distribution moved to using
python-3 by default? Because that is what will happen when you
stabilize python-3.1. You will move to it by default. Everyone who
installs Gentoo will get python-3.1. Everyone who has 2.6 will get 3.1
-- unless they take action to prevent that. That is the _definition_
of default.

For the normal user, no amount of documentation. I repeated BLOODY
*NO* amount of documentation will change the fact that the default is
broken system for a stable install.

Whoever suggested that python-3.1 should go stable immediately needs
his head examined.


Nirbheek,
Extremely Pissed Off At This Idiocy.

-- 
~Nirbheek Chauhan

GNOME+Mozilla Team, Gentoo



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Petteri Räty
Arfrever Frehtes Taifersar Arahesis wrote:
 2009-09-19 20:20:10 AllenJB napisał(a):
 Dirkjan Ochtman wrote:
 On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote:
 What is the point of stabilizing it if users shouldn't use it as main
 interpreter? Just leave it in ~arch until it can be safely used.
 Making it easily available so that people can port stuff, so that the
 entire world may be able to use it as their main interpreter sooner?

 Seriously, it's out there, there's no reason to keep it from stable.
 Just prevent people from making python invoke 3.x and everything will
 be fine.

 Cheers,

 Dirkjan

 Yes, there is a very good reason: The sanity of the users and those who
 support them.

 As a user who has spent a lot of time on IRC and the forums supporting
 other users, I think I can safely say that stabilizing a version of
 python which is not supported by portage will end up in a nightmare
 scenario. At the very least portage, python-updater and eselect, if not
 the majority of the commonly used tools (whichever of gentoolkit,
 portage-utils, eix, etc use python), should support python 3.1 before it
 goes stable.
 
 python-updater and eselect are written in bash. portage-utils are written
 in C. eix is written in C++.
 
 perhaps add a block to eselect so that python-3.1 can't be selected as
 the system python interpreter until portage supports it.
 
 Users might want to sometimes temporarily switch to Python 3 to test some
 Portage-unrelated code.
 Anyway Portage will support Python 3 soon.
 

The users who test code usually have the skills to unmask the things
they need. Stabling 3.x should bring benefit to people who don't write
anything in python because it will be upgraded for all users. If we
don't make 3.x part of system then we can talk about stabilizing it.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Robert Bridge
Speaking as a user, I seem to recall having multiple versions of python
installed in the past, and never really knowing or caring which version was
being used so long as stuff worked. If you want to install python-3.14159 in
the stable tree, than go right ahead, so long as anything that doesn't work
with python-3 can still access python-2 and does so without me knowing, it
doesn't matter.

So the question isn't SHOULD python-3 be stabilised, it's what will break if
it is surely?


Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Alistair Bush
 Stabilization of Python 3.1.* will be requested at the beginning of
  november. There was a suggestion to create a news item which would inform
  users that temporarily they shouldn't switch to Python 3 as their main
  interpreter. Python ebuilds don't automatically activate Python 3, so I'm
  not sure if the news item is required. What is your opinion about it?
 

Stablise.

And to pacify all the cry babies out there could we update portage tools to 
call /usr/bin/python2.6 directly? (yes I realise this will break, but at least 
it is a suggestion)   Or how about we (remove python3.1 from the menu)/(stick 
a big fat warning message)/(do something else) on eselect-python.  Or create a 
system-python link that all gentoo core apps use instead of /usr/bin/python 
(longer term solution?).  [rant]Hell maybe we could even start using those 
slot dep thingy me bobbies to depend only a slot. So ppl don't have python3.1 
unless something depends on it.  Does portage have support for slots in world?
[/rant]

Solutions ppl.  Thats is what we need.  Not oh poor woe is me.

Alistair.



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Dale
Olivier Crête wrote:
 On Sat, 2009-09-19 at 12:21 -0500, Dale wrote:
   
 Dirkjan Ochtman wrote:
 
 On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote:
   
   
 What is the point of stabilizing it if users shouldn't use it as main
 interpreter? Just leave it in ~arch until it can be safely used.
 
 
 Making it easily available so that people can port stuff, so that the
 entire world may be able to use it as their main interpreter sooner?

 Seriously, it's out there, there's no reason to keep it from stable.
 Just prevent people from making python invoke 3.x and everything will
 be fine.
   
 Isn't ~arch supposed to be for testing?  Isn't that the point of having
 ~arch?
 

 ~arch is for testing ebuilds, not the upstream package

   

So it would be OK to mark something stable even tho portage itself
doesn't work with it?  Sorry, this makes no sense to me.  I run stable
for the most part and having a package that portage depends on that is
not stable just sounds a little like putting the cart before the horse.

See some of the other replies as to why this is a not so good idea. 

Dale

:-)  :-) 



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Dawid Węgliński
On Sunday 20 of September 2009 00:32:28 Dale wrote:
 
  ~arch is for testing ebuilds, not the upstream package

 So it would be OK to mark something stable even tho portage itself
 doesn't work with it?  Sorry, this makes no sense to me.  I run stable
 for the most part and having a package that portage depends on that is
 not stable just sounds a little like putting the cart before the horse.

 See some of the other replies as to why this is a not so good idea.

 Dale

 :-)  :-)

You mix it up. Portage works with python 3.1. If an user switches to python 
3.1 as the main interpreter, it's possible that his own scripts won't work. 
Marking it stable sometine in november give's some time to ebuilds 
maintainers to fix their python based apps just like it's done with gcc 
stabilization.

So marking python 3.1 stable and telling users port your own apps/scripts to 
current python sounds good to me.



Re: [gentoo-dev] Stabilization of Python 3.1

2009-09-19 Thread Alex Alexander
*On Sat, Sep 19, 2009 at 23:21, Robert Bridge rob...@robbieab.com wrote:
 So the question isn't SHOULD python-3 be stabilised, it's what will break if
 it is surely?

There seems to be a misunderstanding on what will happen if/when
python 3 gets stabilized.

The short answer is... *drum roll*... nothing :)

I'm guessing that the idea of getting python 3 stable is to allow
people interested in using it to do so easily. We're talking about the
stabilization of python 3, NOT switching portage or your system to it.

Python 2.6 will continue to be the user's default python even after he
installs version 3. In fact, if you're using ~testing you should have
it already and your system is probably still working OK :)

Now.. if a user decides to switch his system *manually* to python 3
without thinking... he's asking for it :)

-- 
Alex || wired
Gentoo Dev
www.linuxized.com