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
-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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
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.)
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
[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.
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
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
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
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
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
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
Python-Dev@python.org
- 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 ;).
-
-
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?
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
-
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
-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
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
37 matches
Mail list logo
