Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
> Consistency and compatibility with > 3.0 suggest that they should return long for every new type we add > them to. What does the list think? I think Py2.6 and Py2.5 should be treated with more respect. Will backporting this change can only cause relief or create headaches?. By definition, the Py3.0 release was supposed to be the one big incompatible set of changes. Backporting with a goal of "consistency and compatibility with 3.0" suggests that the backporters may have lost their compass. FWIW, Py2.6 hasn't been released yet and no one *has* to upgrade to it. So, if it is to have any chance of success, it needs to be a better Python than 2.5. IMO, jamming 3.0 junk into 2.x just provides an incentive to skip the upgrade altogether. In the press release for 2.6, we need to be able to say something stronger than: filled with deprecations, two ways to do everything, dozens of tiny incompatibilities all done in the name of 3.0, and runs slower. I think there ought to be a much more agressive standard for 3.0 backports:, "does the proposed backport make 2.6 more attractive?" Remember, for large code bases, upgrading is a PITA (I think Google is still running tons of code on 2.2, 2.3, and 2.4). There needs to be a good incentive for upgrading; otherwise, Py2.6 *will* fail. The specific change suggested here is possibly (and perhaps probably) harmless; however, it is part of a larger trend that is not healthy for the 2.x series. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax suggestion for imports
-On [20080103 08:53], Raymond Hettinger ([EMAIL PROTECTED]) wrote:
>Thanks. I'm more curious about the content of those lines. Does the
>proposed syntax help, does the need go away in Py3.0, what is the typical
>pattern?
These are some of the examples, I've tried to reduce them to specific use
patterns:
To determine if some feature is available:
try:
pygments = __import__('pygments', {}, {}, [])
have_pygments = True
except ImportError:
have_pygments = False
try:
from docutils import nodes
from docutils.core import publish_parts
from docutils.parsers import rst
from docutils import __version__
except ImportError:
raise TracError(_('Docutils not found'))
if StrictVersion(__version__) < StrictVersion('0.3.9'):
raise TracError(_('Docutils version >= %(version)s required, '
'%(found)s found', version='0.3.9', found=__version__))
To specify which specific version we have of a given module:
try:
import pysqlite2.dbapi2 as sqlite
have_pysqlite = 2
except ImportError:
try:
import sqlite3 as sqlite
have_pysqlite = 2
except ImportError:
try:
import sqlite
have_pysqlite = 1
except ImportError:
have_pysqlite = 0
This gets repeated a lot in order to see if we have threading:
try:
import threading
except ImportError:
import dummy_threading as threading
threading._get_ident = lambda: 0
Functions we do use and need, fall-back to support code if not present:
try:
from operator import attrgetter, itemgetter
except ImportError:
def attrgetter(name):
def _getattr(obj):
return getattr(obj, name)
return _getattr
def itemgetter(name):
def _getitem(obj):
return obj[name]
return _getitem
Masking functions if a particular function is not found:
try:
from base64 import b64decode
except ImportError:
from base64 import decodestring as b64decode
--
Jeroen Ruigrok van der Werven / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
Only I can change my life. No one can do it for me...
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
2008/1/3, Raymond Hettinger <[EMAIL PROTECTED]>: > I think Py2.6 and Py2.5 should be treated with more respect. Will > backporting this change can only cause relief or create > headaches?. By definition, the Py3.0 release was supposed to be the one big > incompatible set of changes. Backporting with a goal Well, as issue 1689 states, the backporting was commited by Jeffrey on rev 5967 [2], so this is the time to understand if we want this or not. Personally, I'm -0. I was involved in this because of Decimal, but I can grow some __methods__ in it that can be in the trunk, unused, and when ported to 3k fit ok in the new infrastructure. Regards, [1] http://bugs.python.org/issue1689 [2] http://svn.python.org/view?rev=59671&view=rev -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax suggestion for imports
Raymond Hettinger wrote: > How about a new, simpler syntax: > > * import threading or dummy_threading as threading > > * import xml.etree.CElementTree or cElementTree or elementree.ElementTree as > ET > > * from cStringIO or StringIO import StringIO > > * import readline or emptymodule The syntax idea has a nice ring to it, except for the last idea. As others have already said, the name emptymodule is too magic. The readline example becomes more readable when you change the import to import readline or None as readline In my opinion the import or as syntax definition is easy to understand if you force the user to always have an "as" statement. The None name is optional but must be the last name: import name[, or name2[, or name3 ...] [, or None] as target This translates into: try: import name as target except ImportError: try: import name2 as target except ImportError: target = None from name[, or name2 ...] [, or None] import target translates into try: from name import target except ImportError: try: from name2 import target except ImportError: target = None Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax suggestion for imports
On 3 jan 2008, at 02.19, Raymond Hettinger wrote:
> How about a new, simpler syntax:
>
> * import threading or dummy_threading as threading
>
> * import xml.etree.CElementTree or cElementTree or
> elementree.ElementTree as ET
>
> * from cStringIO or StringIO import StringIO
>
> * import readline or emptymodule
Wouldn't a (stdlib) function suffice in the cases where this is needed?
ET = import_with_alternative("xml.etree.CElementTree", "cElementTree",
"elementtree.ElementTree")
It's not as elegant, but it's easier than status quo.
//Simon
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax suggestion for imports
Raymond Hettinger wrote: > The standard library, my personal code, third-party packages, and my > employer's code base are filled with examples of the following pattern: > > try: >import threading > except ImportError: >import dummy_threading as threading > > try: > import xml.etree.cElementTree as ET > except ImportError: > try: > import cElementTree as ET > except ImportError: > import elementtree.ElementTree as ET > > try: > from cStringIO import StringIO > except ImportError: > from StringIO import StringIO > > try: > import readline > except ImportError: > pass > > > How about a new, simpler syntax: > > * import threading or dummy_threading as threading > > * import xml.etree.CElementTree or cElementTree or elementree.ElementTree as > ET > > * from cStringIO or StringIO import StringIO > > * import readline or emptymodule I don't think it's as visually clear, but that may be I'm just not used to it. An alternative possibility might be, rather than "or", reuse "else" before import. import threading else import dummy_threading as threading import xml.etree.CElementTree as ET else import cElementTree as ET else import elementtree.ElementTree as ET The readline example above should be in a try except as it allows a failure to pass. For example if you wanted to allow the above elementtree example to pass instead of raising an exception you would write.. try: import xml.etree.CElementTree as ET else import cElementTree as ET else import elementtree.ElementTree as ET except ImportError: pass # or handle failed import. This still improves readability and flattens out the multiple nested structure which I believe is what makes the current way unappealing. I think multiple possible imports in "from - import"s statements should not be allowed. When you consider multiple imports from possibly multiple sources, it seems like that could get a bit messy when debugging. Regards, Ron ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax suggestion for imports
On Wed, Jan 02, 2008, Raymond Hettinger wrote: > > Before posting, I ran some scans of our code base at work and found > plenty of examples (mostly third-party cmodules vs python equivalents > and a few that searched for similar functionality in different > packages). It might be helpful if others were to also search their > own code bases and post their findings: > > find . -name "*py" | xargs grep -C2 ImportError *py Most of my company's examples fall into cases like this: try: klass = load_class(foo) except ImportError: klass = NullClass -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
> I think there ought to be a much more agressive standard for 3.0 backports:, > "does the proposed backport make 2.6 more attractive?" > Remember, for large code bases, upgrading is a PITA (I think Google is still > running tons of code on 2.2, 2.3, and 2.4). There > needs to be a good incentive for upgrading; otherwise, Py2.6 *will* fail. Very well put, Raymond. I wonder, though, whether the appearance of a viable 3.0 will essentially kill the demand for 2.6? Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 3, 2008 12:33 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > Consistency and compatibility with
> > 3.0 suggest that they should return long for every new type we add
> > them to. What does the list think?
>
> I think Py2.6 and Py2.5 should be treated with more respect. Will
> backporting this change can only cause relief or create
> headaches?. By definition, the Py3.0 release was supposed to be the one big
> incompatible set of changes. Backporting with a goal
> of "consistency and compatibility with 3.0" suggests that the backporters may
> have lost their compass.
Whoa. Jeffrey is mostly backporting new stuff (such as numbers.py)
which doesn't introduce incompatibilities. The backporting is intended
to make 2.6 more attractive by allowing developers to do some of the
painful work of porting to 3.0 while staying on 2.6.
> FWIW, Py2.6 hasn't been released yet and no one *has* to upgrade to it. So,
> if it is to have any chance of success, it needs to be
> a better Python than 2.5. IMO, jamming 3.0 junk into 2.x just provides an
> incentive to skip the upgrade altogether. In the press
> release for 2.6, we need to be able to say something stronger than: filled
> with deprecations, two ways to do everything, dozens of
> tiny incompatibilities all done in the name of 3.0, and runs slower.
Watch your words, Raymond. I don't mind personally, but you run the
risk of discouraging contributors by slamming down on them with with
words like "jamming 3.0 junk into 2.x", and that's the last thing we
want to happen. We're thin on contributors as it is (have you noticed
how few people are submitting anything at all lately?).
2.6 should be extremely compatible with 2.5 by default. Its main
attraction should be that it is an important stepping stone in the
upgrade path from 2.{2,3,4,5} to 3.0 -- going straight from 2.5 to 3.0
will be much harder than going from 2.5 to 2.6, doing a bunch of work
while on 2.6, and then going to 3.0. The initial step from 2.5 to 2.6
should be very simple and painless.
There will still be plenty of good stuff in 2.6 to encourage folks to
upgrade who have no need for 3.0 (yet) -- this is the backported 3.0
stuff that doesn't create incompatibilities (like abc.py and
numbers.py).
> I think there ought to be a much more agressive standard for 3.0 backports:,
> "does the proposed backport make 2.6 more attractive?"
> Remember, for large code bases, upgrading is a PITA (I think Google is still
> running tons of code on 2.2, 2.3, and 2.4). There
> needs to be a good incentive for upgrading; otherwise, Py2.6 *will* fail.
The incentive for upgrading will be "you can reach 3.0 easier via 2.6"
and perhaps "the latest version of 3rd party software X runs best on
2.6".
> The specific change suggested here is possibly (and perhaps probably)
> harmless; however, it is part of a larger trend that is not
> healthy for the 2.x series.
Where do you see evidence for a larger trend? I agree that a trend
towards making 2.6 less compatible with 2.5 would be a mistake, but I
don't think I see it happening.
Also, Facundo wrote:
> Well, as issue 1689 states, the backporting was commited by Jeffrey on
> rev 5967 [2], so this is the time to understand if we want this or
> not.
This is a problem. Right now, in the trunk, math.float(1) returns 1,
where it should return 1.0 for compatibility with 2.5. Jeffrey, can
you fix this and similar incompatibilities you introduced?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Contributing to Python
Guido, -On [20080103 19:38], Guido van Rossum ([EMAIL PROTECTED]) wrote: >We're thin on contributors as it is (have you noticed how few people are >submitting anything at all lately?). When you say this are you talking about code or contributions all over the project, e.g. documentation? Is there a reason that it thinned out? I'm asking since I never really dove into the Python project much aside from using Python here and there, but I seem to get a career using Python almost full-time so perhaps there are things I, and I am sure others, can step up to help out. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ A frightened mental vortex we will be, a Sun we seek, a Sun we flee... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax suggestion for imports
2008/1/2, Raymond Hettinger <[EMAIL PROTECTED]>: > How about a new, simpler syntax: > > * import threading or dummy_threading as threading > > * import xml.etree.CElementTree or cElementTree or elementree.ElementTree as > ET > > * from cStringIO or StringIO import StringIO > > * import readline or emptymodule With the minor modification of changing emptymodule by a None in the last line, I'm +0 on it. I don't use this that much, but I find this syntax clear and understable. It does not bring additional complexity when not used, and is very helpful when needed. Don't know how much effort for the parser it is, though. Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax suggestion for imports
At 3:20 PM +0100 1/3/08, Christian Heimes wrote:
>Raymond Hettinger wrote:
>> How about a new, simpler syntax:
...
>> * import readline or emptymodule
>
>The syntax idea has a nice ring to it, except for the last idea. As
>others have already said, the name emptymodule is too magic.
>
>The readline example becomes more readable when you change the import to
>
>import readline or None as readline
>
>
>In my opinion the import or as syntax definition is easy to understand
>if you force the user to always have an "as" statement. The None name is
>optional but must be the last name:
>
>import name[, or name2[, or name3 ...] [, or None] as target
...
At 11:48 AM -0600 1/3/08, Ron Adam wrote:
...
>An alternative possibility might be, rather than "or", reuse "else" before
>import.
...
I prefer "else" to "or" but with the original single-statement syntax.
If the last clause could be an expression as well as a module name, what
I've done (used with and copied from BeautifulSoup):
try:
from htmlentitydefs import name2codepoint
except ImportError:
name2codepoint = {}
could become:
from htmlentitydefs else ({}) import name2codepoint as name2codepoint
Also:
import foo or (None) as foo
--
TonyN.:'
'
Re: [Python-Dev] Contributing to Python
We're getting a fair number of doc contributions, especially since the docs were converted from Latex to ReST, and especially since the start of the GHOP project. My main gripe is with code contributions to Py3k and 2.6; Py3k is mostly done by a handful of people, and almost nobody is working much on 2.6. --Guido On Jan 3, 2008 11:05 AM, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: > Guido, > > -On [20080103 19:38], Guido van Rossum ([EMAIL PROTECTED]) wrote: > >We're thin on contributors as it is (have you noticed how few people are > >submitting anything at all lately?). > > When you say this are you talking about code or contributions all over the > project, e.g. documentation? > > Is there a reason that it thinned out? > > I'm asking since I never really dove into the Python project much aside from > using Python here and there, but I seem to get a career using Python almost > full-time so perhaps there are things I, and I am sure others, can step up to > help out. > > -- > Jeroen Ruigrok van der Werven / asmodai > イェルーン ラウフロック ヴァン デル ウェルヴェン > http://www.in-nomine.org/ | http://www.rangaku.org/ > A frightened mental vortex we will be, a Sun we seek, a Sun we flee... > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
On Thu, Jan 03, 2008 at 11:15:04AM -0800, Guido van Rossum wrote: -> We're getting a fair number of doc contributions, especially since the -> docs were converted from Latex to ReST, and especially since the start -> of the GHOP project. -> -> My main gripe is with code contributions to Py3k and 2.6; Py3k is -> mostly done by a handful of people, and almost nobody is working much -> on 2.6. What needs to be done with 2.6? I'm happy to review patches, although even were commit access on offer I'm too scatterbrained to do a good job of it. Incidentally, I'm planning to set up an SVK repos containing the GHOP doc patches; that way they can stay sync'ed with 2.6 work. I'd be happy to do the same thing with reviewed-and-probably-OK patches, although I don't know if repository proliferation is a generally good idea ;). --titus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
On Jan 3, 2008, at 2:15 PM, Guido van Rossum wrote: > My main gripe is with code contributions to Py3k and 2.6; Py3k is > mostly done by a handful of people, and almost nobody is working much > on 2.6. For those of us still using Python 2.4 and earlier, it's hard to be motivated to worry about Python 3.0, no matter how wonderful it looks. (It doesn't help that my own available time appears to decrease daily with the kids and all.) Python 2.6 seems to be entirely targeted at people who really want to be on Python 3, but have code that will need to be ported. I certainly don't view it as interesting in it's own right. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
On Thu, Jan 03, 2008 at 05:48:25PM -0200, Facundo Batista wrote: -> 2008/1/3, Titus Brown <[EMAIL PROTECTED]>: -> -> > What needs to be done with 2.6? I'm happy to review patches, although -> > even were commit access on offer I'm too scatterbrained to do a good job -> > of it. -> -> We have 109 patches open for 2.5 [1], and 118 patches open for 2.6 [2]. The question is, is reviewing patches a good place to contribute? Also, if I (and others) could have a "core mentor" with commit access, that might streamline things. As it is, I am worried that patch reviews will pass through the ether without leaving a visible trace; that's OK and understandable, but it's demotivating. (I've had a very good experience with Georg and documentation commits for GHOP.) cheers, --titus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
On Thu, Jan 03, 2008 at 02:49:27PM -0500, Fred Drake wrote: -> On Jan 3, 2008, at 2:15 PM, Guido van Rossum wrote: -> > My main gripe is with code contributions to Py3k and 2.6; Py3k is -> > mostly done by a handful of people, and almost nobody is working much -> > on 2.6. -> -> For those of us still using Python 2.4 and earlier, it's hard to be -> motivated to worry about Python 3.0, no matter how wonderful it -> looks. (It doesn't help that my own available time appears to -> decrease daily with the kids and all.) -> -> Python 2.6 seems to be entirely targeted at people who really want to -> be on Python 3, but have code that will need to be ported. I -> certainly don't view it as interesting in it's own right. 3k and 26 are, however, the only place where we can propose new features -- which makes it the place for cleanup and additional testing, as well as backwards-incompatible bug fixes... --titus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
2008/1/3, Titus Brown <[EMAIL PROTECTED]>: > What needs to be done with 2.6? I'm happy to review patches, although > even were commit access on offer I'm too scatterbrained to do a good job > of it. We have 109 patches open for 2.5 [1], and 118 patches open for 2.6 [2]. Note that the added number is less than the sum, as some patchs are marked for both versions, and even some are marked as 3.0 also. And of course I'm not counting bugs, here, just issues marked as patch. I deliberately work only on the trunk (except for some issues regarding Decimal), because of the balance Guido talked about. Regards, [1] http://www.taniquetil.com.ar/cgi-bin/pytickets.py?nropag=0&priority=0&severity=0&component=0&version=2&keyword=2 [2] http://www.taniquetil.com.ar/cgi-bin/pytickets.py?nropag=0&priority=0&severity=0&component=0&version=1&keyword=2 -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
-On [20080103 20:39], Guido van Rossum ([EMAIL PROTECTED]) wrote: >My main gripe is with code contributions to Py3k and 2.6; Py3k is >mostly done by a handful of people, and almost nobody is working much >on 2.6. You don't put the bar high for newbies on the Python project eh? :) I am assumign that most of those contributions code-wise need a fair amount of knowledge of Python's internals? -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Mayoi nagara demo ii aruki dashite... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
> My main gripe is with code contributions to Py3k and 2.6; Py3k is > mostly done by a handful of people, and almost nobody is working much > on 2.6. There's a great Duke Ellington quote: ``Without a deadline, baby, I wouldn't do nothing.'' The SSL code in 2.6 is out-of-date (buggy) compared to the code in the 3.x branch, for instance. I just haven't prioritized backporting the 3.x fixes, because there's no schedule for 2.6. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
Titus, Having a "core mentor" would be great but do they really have time for that? I've been lucky at finding people in #python / #python-dev) that can answer development inquiries (or at least verify something is or is not a bug). With respects to the bug tracker, when I select Search and Python 2.6, I retrieved 208 open bugs. At a quick glance, I found two that were windows, but not tagged appropriately. If it's worthwhile, I can spend some time this evening browsing the list of current 2.6 bugs to see if there are any duplicates, collisions, etc. Joseph Armbruster On Jan 3, 2008 2:53 PM, Titus Brown <[EMAIL PROTECTED]> wrote: > On Thu, Jan 03, 2008 at 02:49:27PM -0500, Fred Drake wrote: > -> On Jan 3, 2008, at 2:15 PM, Guido van Rossum wrote: > -> > My main gripe is with code contributions to Py3k and 2.6; Py3k is > -> > mostly done by a handful of people, and almost nobody is working much > -> > on 2.6. > -> > -> For those of us still using Python 2.4 and earlier, it's hard to be > -> motivated to worry about Python 3.0, no matter how wonderful it > -> looks. (It doesn't help that my own available time appears to > -> decrease daily with the kids and all.) > -> > -> Python 2.6 seems to be entirely targeted at people who really want to > -> be on Python 3, but have code that will need to be ported. I > -> certainly don't view it as interesting in it's own right. > > 3k and 26 are, however, the only place where we can propose new features > -- which makes it the place for cleanup and additional testing, as well > as backwards-incompatible bug fixes... > > --titus > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/josepharmbruster%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
Jeroen Ruigrok van der Werven wrote: > You don't put the bar high for newbies on the Python project eh? :) > > I am assumign that most of those contributions code-wise need a fair amount of > knowledge of Python's internals? It's neither impossible nor too hard to get involved. I got from "haven't done serious C coding in years" to "Python core developer with full svn access" in less than 9 months. OK, I've more than 5 years of Python experience but you don't need it to contribute. You can start by updating or enhancing the existing documentation, writing new docs and tutorials or updating the unit test suite. New tests need to be written and existing test should be ported to the new unit test module. Large parts of Python are written *in* Python. You don't need to be a C coder to contribute. For example you can give a C coder a hand by writing documentation and unit tests for the C coder. This way the C coder can concentrate on the C code and you can enhance your unit testing Fu. :) Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
On Thu, Jan 03, 2008 at 02:49:27PM -0500, Fred Drake wrote: > Python 2.6 seems to be entirely targeted at people who really want to > be on Python 3, but have code that will need to be ported. I > certainly don't view it as interesting in its own right. The bulk of the *language* changes in 2.6 are driven by 3.0, but the abstract base class support is fairly significant even if you don't plan on going to 3.0. There are a fair number of new features in the library: Bill's new SSL code, collections.namedtuple, the signal handling/event loop fix, the new floating point features dealing with infinities and NaNs. None are earth-shattering to me personally, but for the right audience they might be very compelling. So far I view 2.6 as a relatively cautious release, like 2.3. (That assessment may change once I research the numeric changes that just went in.) Most of the action has been in the surrounding tools, like the new documentation format and the adoption of Roundup. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
Joseph Armbruster wrote: > With respects to the bug tracker, when I select Search and Python 2.6, I > retrieved 208 open bugs. At a quick glance, I found two that were windows, > but not tagged appropriately. If it's worthwhile, I can spend some time > this evening browsing the list of current 2.6 bugs to see if there are any > duplicates, collisions, etc. The bug tracker is an issue and in my opinion a development hindrance, too. It contains almost 1,400 bugs, about 450 w/o a target version and about 400 more bugs with a target version <= 2.4. The bug tracker was discussed two threads "Bug tracker: meaning of resolution keywords" and "1324 bugs in the tracker" lately. I don't want to repeat the arguments here but Brett's answer http://permalink.gmane.org/gmane.comp.python.devel/90137 is worth reading. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
On Jan 3, 2008 11:49 AM, Fred Drake <[EMAIL PROTECTED]> wrote: > For those of us still using Python 2.4 and earlier, it's hard to be > motivated to worry about Python 3.0, no matter how wonderful it > looks. (It doesn't help that my own available time appears to > decrease daily with the kids and all.) Oh, just get rid of the kids. :-) > Python 2.6 seems to be entirely targeted at people who really want to > be on Python 3, but have code that will need to be ported. I > certainly don't view it as interesting in it's own right. It will be though -- it will have genuine new features -- yes, backported from 3.0, but new features nevertheless, and in a compatible fashion. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
> The question is, is reviewing patches a good place to contribute? Also, > if I (and others) could have a "core mentor" with commit access, that > might streamline things. As it is, I am worried that patch reviews will > pass through the ether without leaving a visible trace; that's OK and > understandable, but it's demotivating. Keep posting to this list, if you think a patch can be accepted. If you think a patch should be rejected, it would probably be easiest if you just close it. > (I've had a very good experience with Georg and documentation commits > for GHOP.) You can only find out what feedback you get on code reviews when you actually start reviewing :-) I would like to promise guaranteed responses to you, but I feel that recently, I found that I cannot keep up with such promises. But I would hope that some of the active committers will "quickly" commit patches when they find that your review leaves nothing to be added. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
[GvR] > We're thin on contributors as it is (have you noticed > how few people are submitting anything at all lately?). The people who are contributing are doing a nice job. Also, it was nice that the change was discussed on the list. > 2.6 should be extremely compatible with 2.5 by default. Good to hear that is still a primary goal. Along the way, I worried that that sentiment had been lost and that little incompatibilities were sneaking in (iirc, the proposed transition plan for leading zeroes was headed down this path). > The incentive for upgrading will be "you can reach 3.0 > easier via 2.6" and perhaps "the latest version of 3rd > party software X runs best on 2.6". Does the 2to3 tool work from 2.5 or from 2.6 or does it make difference? If it works from 2.5, I'm thinking my company will make the jump all at once (after the 3.x series stabilizes, gets optimized, and key third-party packages have been migrated). I'm also expecting that some chuck of users will be left in the 2.x world and that they would like highest version to be as clean as possible (with migration features going into the category of things that don't provide them any benefit). > Right now, in the trunk, math.float(1) returns 1, > where it should return 1.0 for compatibility with 2.5. > Jeffrey, can you fix this and similar incompatibilities > you introduced? Thanks for zapping this. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
Raymond Hettinger wrote: > Does the 2to3 tool work from 2.5 or from 2.6 or does it make difference? If > it works from 2.5, I'm thinking my company will make the jump all at once > (after the 3.x series stabilizes, gets optimized, and key third-party > packages have been migrated). It's not guaranteed that it will work from 2.5. The transition plan for 2to3 is: * Get your code working under python2.6 -3 without Python 3.0 deprecation warnings * Use 2to3 to migrate the code from 2.6 to 3.0 Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Return type of round, floor, and ceil in 2.6
On Jan 3, 2008 1:13 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [GvR] > > We're thin on contributors as it is (have you noticed > > how few people are submitting anything at all lately?). > > The people who are contributing are doing a nice job. Also, it was nice that > the change was discussed on the list. We can always use more contributors! (See separate thread.) > > 2.6 should be extremely compatible with 2.5 by default. > > Good to hear that is still a primary goal. Along the way, I worried that > that sentiment had been lost and that little incompatibilities were sneaking > in (iirc, the proposed transition plan for leading zeroes was headed down > this path). I don't recall vetting (or even seeing) that plan! Without the "-3" option, 2.6 should accept the same syntax (or a superset) as 2.5. With the "-3" flag, however, you may get warnings about stuff that changes in 3.0. I don't like that "-3" would change the accepted syntax; for that, we should use "from __future__ import ...". A hypothetical example for octal numbers: I propose that bare 2.6 accepts either 0777 and 0o777 as octal literals. If you use "python -3", you might get a warning about using 0777, although this is borderline useless since 2to3 will take care of it just fine. If people think it's worth it (I doubt it for this example) we could add "from __future__ import octal_literals" which would prohibit 0777 altogether. > > The incentive for upgrading will be "you can reach 3.0 > > easier via 2.6" and perhaps "the latest version of 3rd > > party software X runs best on 2.6". > > Does the 2to3 tool work from 2.5 or from 2.6 or does it make difference? If > it works from 2.5, I'm thinking my company will make the jump all at once > (after the 3.x series stabilizes, gets optimized, and key third-party > packages have been migrated). The 2to3 tool works from either baseline, but there is lots of stuff it can't deal with (basically because 2to3 doesn't do type inference, and it's unlikely that it ever will). In 2.6, the "-3" warnings will help you find stuff that you should transform yourself. (Usually there is a transformation that will do the right thing in 2.6 and which will, after conversion by 2to3, continue to do the right thing in 3.0.) > I'm also expecting that some chuck of users will be left in the 2.x world and > that they would like highest version to be as clean as possible (with > migration features going into the category of things that don't provide them > any benefit). They could either stick with 2.5 (or at least insist on compatibility with 2.5) or use 2.6 without the "-3" flag. They might benefit from the migration features 5 years from now, and until then they shouldn't hurt. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
On Jan 3, 2008 12:17 PM, Bill Janssen <[EMAIL PROTECTED]> wrote: > > My main gripe is with code contributions to Py3k and 2.6; Py3k is > > mostly done by a handful of people, and almost nobody is working much > > on 2.6. > > There's a great Duke Ellington quote: ``Without a deadline, baby, I > wouldn't do nothing.'' > > The SSL code in 2.6 is out-of-date (buggy) compared to the code in the > 3.x branch, for instance. I just haven't prioritized backporting the > 3.x fixes, because there's no schedule for 2.6. Eh? PEP 3000 has a schedule that includes 2.6: * August 2007: release 3.0a1. * December 2007: release 3.0a2. * Early 2007 (pre-PyCon): release 2.6a1. * May 2008 (post-PyCon): full feature freeze for 3.0 and 2.6. * July 2008: release 2.6 (final). * August 2008: release 3.0 (final). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
On Jan 3, 2008 11:40 AM, Titus Brown <[EMAIL PROTECTED]> wrote: > On Thu, Jan 03, 2008 at 11:15:04AM -0800, Guido van Rossum wrote: > -> We're getting a fair number of doc contributions, especially since the > -> docs were converted from Latex to ReST, and especially since the start > -> of the GHOP project. > -> > -> My main gripe is with code contributions to Py3k and 2.6; Py3k is > -> mostly done by a handful of people, and almost nobody is working much > -> on 2.6. > > What needs to be done with 2.6? I'm happy to review patches, although > even were commit access on offer I'm too scatterbrained to do a good job > of it. IMO the main issue with 2.6 is not handling bugs and patches but backporting 3.0 stuff. There's a spreadsheet somewhere that shows there's a huge amount of work to be done: http://spreadsheets.google.com/ccc?key=pCKY4oaXnT81FrGo3ShGHGg (if you can't access it, try the published version: http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGg ) > Incidentally, I'm planning to set up an SVK repos containing the GHOP > doc patches; that way they can stay sync'ed with 2.6 work. I'd be happy > to do the same thing with reviewed-and-probably-OK patches, although I > don't know if repository proliferation is a generally good idea ;). IMO patches should just be applied to the trunk ASAP. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
On Jan 3, 2008 12:17 PM, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: > -On [20080103 20:39], Guido van Rossum ([EMAIL PROTECTED]) wrote: > >My main gripe is with code contributions to Py3k and 2.6; Py3k is > >mostly done by a handful of people, and almost nobody is working much > >on 2.6. > > You don't put the bar high for newbies on the Python project eh? :) > > I am assuming that most of those contributions code-wise need a fair amount of > knowledge of Python's internals? Actually, it goes all over the place. Some things (like doing "-3" warnings for uses of .keys() that assume the result is a list) required wizard level knowledge; other things are fairly simple. For example, abc.py and _abcoll.py were backported successfully by someone who was learning on the job. Backporting pure Python code often isn't that hard. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
> > 3.x fixes, because there's no schedule for 2.6. > > Eh? PEP 3000 has a schedule that includes 2.6: OK, no schedule that I knew about :-). I'll get back to work on it. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
-> > Incidentally, I'm planning to set up an SVK repos containing the GHOP -> > doc patches; that way they can stay sync'ed with 2.6 work. I'd be happy -> > to do the same thing with reviewed-and-probably-OK patches, although I -> > don't know if repository proliferation is a generally good idea ;). -> -> IMO patches should just be applied to the trunk ASAP. (We're waiting on contributor forms for the GHOP students. That's on my TODO list, too.) --titus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
On Thu, Jan 03, 2008 at 09:55:44PM +0100, Christian Heimes wrote: -> Jeroen Ruigrok van der Werven wrote: -> > You don't put the bar high for newbies on the Python project eh? :) -> > -> > I am assumign that most of those contributions code-wise need a fair amount of -> > knowledge of Python's internals? -> -> It's neither impossible nor too hard to get involved. I got from -> "haven't done serious C coding in years" to "Python core developer with -> full svn access" in less than 9 months. OK, I've more than 5 years of -> Python experience but you don't need it to contribute. -> -> You can start by updating or enhancing the existing documentation, -> writing new docs and tutorials or updating the unit test suite. New -> tests need to be written and existing test should be ported to the new -> unit test module. As far as I am aware, we/GHOP have patches for all of the tests in 2.6 => unittest or doctest. They have not all been applied yet, but that will come soon. Speaking as someone with a few years experience in Python and quite a bit of C knowledge, it is not at all easy to come up with a way to dive into the core code. For GHOP, it was a bit of a struggle to come up with tasks; I ended up with three main sources of tasks: - a blog post asking people about their favorite poorly documented module; - the 3.0 spreadsheet and some grepping, to figure out which tests still needed to be ported over to unittest/doctest; - a test coverage analysis to figure out which modules were largely untested; A parent of a GHOP student asked us if we could somehow come up with a suggested task list for new contributors (not just GHOP students). While this could be a lot of work, I think the contributions from GHOP to core in the areas of test coverage, test porting, and module documentation indicate that this kind of outreach may be very effective. If you have ideas on how to keep such a task list fresh and up-to-date as well as populated with good, simple tasks, I'm interested in hearing from you! cheers, --titus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Contributing to Python
On Thu, Jan 03, 2008 at 03:24:16PM -0500, Joseph Armbruster wrote: -> Having a "core mentor" would be great but do they really have time for -> that? I've been lucky at finding people in #python / #python-dev) that can -> answer development inquiries (or at least verify something is or is not a -> bug). Again, IMO as someone on the lunatic fringe of core development (i.e. I'm a happy spectator, but I'm too busy to actually get much done): Mentoring coders may not be a traditional route for hard-core OSS developers, but it sure can be effective, as I've found with GHOP. For example, many core Python developers can save an outsider hours of effort by simply and quickly outlining the issues involved in a particular patch or coding effort. Having actual committers involved is especially good, because they can evaluate whether or not a patch is likely to be accepted, potentially cutting out more hours of effort; and they can directly commit patches, leading to the very important gratification of an actual commit. >From another angle, there are a lot of "easy" fixes/patches/updates to be done to Python, but I'll be damned if I can figure out which ones are easy meat, or complex, or likely to touch a nerve. Having someone experienced to quickly give an opinion is invaluable. (I'm an overconfident loudmouth, so I don't mind posting to this list, but I think python-dev is pretty intimidating for people new to the hurly burly of OSS development.) As I've said in other responses in this thread, I'm not sure how to make it happen, but I'm leaning towards asking the active GHOP mentors to try to extend the GHOP mentoring effort into a general python-love effort. We've got a good group of experienced people, and it's been a pretty friendly list IMO. cheers, --titus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Backport threading.py fix to 2.5.2?
See http://bugs.python.org/issue1731. Should we consider it safe to backport r57216 to 2.5.2? This is Thomas Wouters's code to disable spurious tracebacks when daemon threads die. We're running some 2.4 apps with (a variant of) this at Google that get many 1000s of invocations a day, so I'm pretty confident that it works. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backport threading.py fix to 2.5.2?
-On [20080104 02:46], Guido van Rossum ([EMAIL PROTECTED]) wrote: >See http://bugs.python.org/issue1731. Should we consider it safe to >backport r57216 to 2.5.2? This is Thomas Wouters's code to disable >spurious tracebacks when daemon threads die. We're running some 2.4 >apps with (a variant of) this at Google that get many 1000s of >invocations a day, so I'm pretty confident that it works. If it fixes a bunch of unnecessary tracebacks which only add confusion whether or not something is working I'm +1 on it. Being on the grunt-side of handling bug reports anything that gets rid of unnecessary bug reports is a good change to backport in my opinion. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Light-in-Darkness, lift me up from here... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Syntax suggestion for imports
Simon Percivall wrote:
> Wouldn't a (stdlib) function suffice in the cases where this is needed?
>
> ET = import_with_alternative("xml.etree.CElementTree", "cElementTree",
> "elementtree.ElementTree")
>
> It's not as elegant, but it's easier than status quo.
>
I like that direction a lot better than the syntax proposals. This isn't
the kind of thing that needs to get composed into bigger expressions,
which is where clever uses of operators really shine. Here, I think the
operators were subtracting clarity and your named function was adding
clarity.
When I saw the OP, I actually wondered why people whose codebases are
"filled" with the same try/except block over and over hadn't just
written their own import_with_alternative function in the first place.
If I wanted half my lines of code to be devoted to control flow and
block structure, I'd write in one of those curly-brace languages :)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
