On 03/14/2011 10:02 PM, James Mills wrote:
On Tue, Mar 15, 2011 at 11:50 AM, Terry Reedytjre...@udel.edu wrote:
How would that work if you had a field named replace? I think
Raymond's current design is as good as it's going to get.
'as_dict' is an unlikely fieldname. 're_place' is too, but
On Tue, Mar 15, 2011 at 10:27 AM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
Maybe this will be the killer app for the or enhancement
to the import statement. :-)
Except that won't help, since even if it were added right now, pre-3.3
compatible code couldn't use it :)
Cheers,
Nick.
--
On Tue, Mar 15, 2011 at 6:20 PM, Eric Smith e...@trueblade.com wrote:
The field names are not always under direct control of the developer, such
as when they are database column names. Not that using _replace completely
gets rid of this problem, but I agree with Raymond's decision that a field
In fact, since the deprecation in the Python 2 line happened in 2.7,
the deprecation period of this API in practice was between July 3rd
2010 and February 20 2011. That is a deprecation period of somewhat
longer than seven months. Nobody obviously though 2.6 was out of
practical use by now,
Would you please post this to bugs.python.org so that it doesn't get lost?
thanks!
-gps
On Mon, Mar 14, 2011 at 8:51 PM, Bill Green b...@supposedly.org wrote:
Hi all,
I ran across this issue several months ago and filed a bug report (#9667).
It just came up again, and it doesn't look like
On Tue, Mar 15, 2011 at 7:50 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Mar 15, 2011 at 10:27 AM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
Maybe this will be the killer app for the or enhancement
to the import statement. :-)
Except that won't help, since even if it were added
On 15/03/2011 07:59, Nick Coghlan wrote:
On Tue, Mar 15, 2011 at 6:20 PM, Eric Smithe...@trueblade.com wrote:
The field names are not always under direct control of the developer, such
as when they are database column names. Not that using _replace completely
gets rid of this problem, but I
On Tue, 15 Mar 2011 15:29:59 +0100
brian.curtin python-check...@python.org wrote:
+
+def test_gz_ext(self):
[...]
+
+def test_bz2_ext(self):
[...]
+
+def test_Gz_ext(self):
+self.do_test_use_builtin_open(abcd.Gz, 6)
+
+def test_Bz2_ext(self):
+
On Tue, Mar 15, 2011 at 10:44, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 15 Mar 2011 15:29:59 +0100
brian.curtin python-check...@python.org wrote:
+
+def test_gz_ext(self):
[...]
+
+def test_bz2_ext(self):
[...]
+
+def test_Gz_ext(self):
+
On Tue, Mar 15, 2011 at 09:20, Martin v. Löwis mar...@v.loewis.de wrote:
In fact, since the deprecation in the Python 2 line happened in 2.7,
the deprecation period of this API in practice was between July 3rd
2010 and February 20 2011. That is a deprecation period of somewhat
longer than
On Mon, Mar 14, 2011 at 19:22, Reid Kleckner reid.kleck...@gmail.com wrote:
I don't know how your code works, but handling either type from C
seems very straightforward to me. You can simply use #ifdef
Py_COBJECT_H to see if the cobject.h header was pulled into Python.h.
Similarly for
On Tue, Mar 15, 2011 at 9:42 AM, Tim Lesher tles...@gmail.com wrote:
2. Add a new class attribute that uses the same mechanism, with a
different name (e.g., __api__).
Pro: fairly easy to explain; because it doesn't share a name with
__all__ its semantics can be tweaked without confusing
On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 15/03/2011 07:59, Nick Coghlan wrote:
While I actually think the current API design is a decent compromise,
another option to consider would be to move the underscore to the
*end* (as_dict_, replace_, make_) as
On Tue, Mar 15, 2011 at 9:48 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
or if you backport it, we could add a new fallback ;)
try:
from __future__ import or_importer
except ImportError:
XXX -- previous proposal
else:
or based proposal
Alas, the fallback trick doesn't work for
On Tue, 15 Mar 2011 11:17:18 -0400
Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 15/03/2011 07:59, Nick Coghlan wrote:
While I actually think the current API design is a decent compromise,
another option to
On Tue, Mar 15, 2011 at 10:52 AM, Brian Curtin brian.cur...@gmail.com wrote:
Agreed. I'll rename them to be more expressive.
Don't forget NEWS and ACKS updates as well.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
I think you guys are forgetting about FOR_ITER, listcomps, and the like.
That is, IIRC, the reason loops use the block stack is because they put
things on the regular stack, that need to be cleared off the stack when the
loop is exited (whether normally or via an exception).
Good point.
On Tue, Mar 15, 2011 at 11:28, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Mar 15, 2011 at 10:52 AM, Brian Curtin brian.cur...@gmail.com
wrote:
Agreed. I'll rename them to be more expressive.
Don't forget NEWS and ACKS updates as well.
Got the news update in 9448691fe084. Had him in
Python 2.6's API wasn't removed in 2.7. It remains available.
But not in 3.2. And the new API appeared in 2.7.
No, it didn't. It first appeared in 3.1.
That is a deprecation period of seven and a half months.
Not true. It's a deprecation period of 19 months and two
releases (3.1 and
Hi, Sorry, it was just laughingly pointed out to me that I responded to your
complaint about a bug being ignored by asking you to file a bug. :) Thats
what I get for reading things late at night.
regardless, any time you have a patch for something, please attach it to the
issue, things on the
On Tue, Mar 15, 2011 at 11:24, Antoine Pitrou solip...@pitrou.net wrote:
Wouldn't a decorator be adequate?
@pydoc.public_api
def _asdict(self):
some docstring
...
That was my first attempt. Unfortunately, it didn't work well with
classmethods or immutable data members,
On Tue, Mar 15, 2011 at 11:15, Nick Coghlan ncogh...@gmail.com wrote:
The challenge here is how it would interact with inheritance. pydoc
couldn't use normal attribute lookup, it would have to walk the MRO
manually, only applying __api__ to the specific class that defined it.
Great catch. I
On 3/14/11 5:30 PM, Lennart Regebro wrote:
Many projects, not only the Zope Toolkit needs to support a lot of
versions. The Zope component architecture currently supports 2.4, 2.5
and 2.6 and is expected to work on 2.7. I don't know if 2.4 or 2.5 can
be dropped, but it definitely will be
On Tue, 15 Mar 2011 04:19:24 +0100
ezio.melotti python-check...@python.org wrote:
Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c
Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c
libffi is a third-party library and you should probably not introduce
gratuitous changes in these files. It
On Tue, Mar 15, 2011 at 12:27 PM, Tim Lesher tles...@gmail.com wrote:
Overall, this is becoming more interesting than I'd thought at first.
Is this something that should require a PEP?
Yeah, just to thrash out the semantics and give some visibility into
the design decisions.
Cheers,
Nick.
--
One of simplest and least invasive ways to get help()
to show the underscore methods and attributes is to
make pydoc aware of named tuples by checking for the
presence of _fields.
* That leaves the named tuple code as simple as possible
(which is important because the self-documenting code
is
On Tue, Mar 15, 2011 at 12:02, Martin v. Löwis mar...@v.loewis.de wrote:
If you actually had been supporting 2.x and 3.x in parallel for the last two
years, you would have had a deprecation period of 19 months
and two releases. It's only if you are now migrating from 2 to 3
that you notice the
I noticed the API change now because it's gone from 3.2. That's how
most API changes gets noticed: Things stop working. And that's OK.
Deprecation periods are there to help you support multiple versions at
the same time.
That may be the source of misunderstanding. In my understanding, that's
On 3/15/2011 11:17 AM, Nick Coghlan wrote:
On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 15/03/2011 07:59, Nick Coghlan wrote:
While I actually think the current API design is a decent compromise,
another option to consider would be to move the underscore
Traditionally I could see who was the committer who push change to the
buildbots. This info seems not to be (easily) available.
I have now restored that information in the buildbot. However, only
includes the committer, not the pusher. Traditionally, they were the
same thing, but they are not
On 3/15/2011 11:57 AM, Brian Curtin wrote:
On Tue, Mar 15, 2011 at 11:28, Nick Coghlan ncogh...@gmail.com
mailto:ncogh...@gmail.com wrote:
On Tue, Mar 15, 2011 at 10:52 AM, Brian Curtin
brian.cur...@gmail.com mailto:brian.cur...@gmail.com wrote:
Agreed. I'll rename them to be more
On 3/15/2011 1:00 PM, Antoine Pitrou wrote:
On Tue, 15 Mar 2011 04:19:24 +0100
ezio.melottipython-check...@python.org wrote:
Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c
Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c
libffi is a third-party library and you should probably not
2011/3/15 Terry Reedy tjre...@udel.edu:
On 3/15/2011 1:00 PM, Antoine Pitrou wrote:
On Tue, 15 Mar 2011 04:19:24 +0100
ezio.melottipython-check...@python.org wrote:
Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c
Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c
libffi is a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15/03/11 21:14, Martin v. Löwis wrote:
Traditionally I could see who was the committer who push change to the
buildbots. This info seems not to be (easily) available.
I have now restored that information in the buildbot. However, only
Hey all,
I realise that we're still getting used to the workflows, but there are
currently unmerged changesets (in test_peepholer and friends) on the 3.2
branch that seem to have been applied *separately* to 3.3. This causes
problems for anyone else who wants to merge changes from 3.2 to 3.3
On Tue, Mar 15, 2011 at 15:39, Martin v. Löwis mar...@v.loewis.de wrote:
Of course you could have. You could have added a version of your code
that uses capsules (just as you are probably doing now).
No I'm not.
Right - and that's why the deprecation period is not about supporting
multiple
On Tue, Mar 15, 2011 at 6:46 PM, Lennart Regebro rege...@gmail.com wrote:
On Tue, Mar 15, 2011 at 15:39, Martin v. Löwis mar...@v.loewis.de wrote:
Of course you could have. You could have added a version of your code
that uses capsules (just as you are probably doing now).
No I'm not.
The
For years, urlparse (and subsequently urlib.parse) has opted to
implement the semantics from the older URL processing RFCs, rather
than updating to the new semantics as the RFCs are superseded.
With RFC 3986 passing its 6th birthday, and with it being well past
its 7th by the time 3.3 comes out,
On Tue, Mar 15, 2011 at 18:56, Nick Coghlan ncogh...@gmail.com wrote:
why not just consider this another
instance of the 2.x/3.x incompatibility? That's what it is after all.
Apparently not, as the code already ran under Python 3.1.
//Lennart
___
On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan ncogh...@gmail.com wrote:
With RFC 3986 passing its 6th birthday, and with it being well past
its 7th by the time 3.3 comes out, can we finally switch to supporting
the current semantics rather than the obsolete behaviour?
We do infact, support RFC
On Tue, 15 Mar 2011 18:46:37 -0400
Lennart Regebro rege...@gmail.com wrote:
Right - and that's why the deprecation period is not about supporting
multiple versions, but to reduce the need for people to adjust their
code on a quick notice.
I think we need to adjust PEP 5 then. We can't
Martin v. Löwis wrote:
There must be at least a one-year transition period between the
release of the transitional version of Python and the release
of the backwards incompatible version.
I still think this is going to result in rude shocks to
people switching from 2 to 3 and jumping several
Tarek Ziadé wrote:
try:
from __future__ import or_importer
except ImportError:
XXX -- previous proposal
else:
or based proposal
This could easily be fixed if we allowed run-time access
to the time machine:
from __future__ import temporal_mechanics, or_importer
import
Nick Coghlan wrote:
The challenge here is how it would interact with inheritance. pydoc
couldn't use normal attribute lookup, it would have to walk the MRO
manually,
This is an instance of a pattern that I've encountered a
few times in things that I've done: you have a class
attribute
As PEP 3101 http://www.python.org/dev/peps/pep-3101/ says (and current
Python does) user can specify conversions like {0!s}.
In custom formatters (derived from string.Formatter) he can override
convert_field method to add custom conversions.
I experimented with that last month and found it very
On 03/15/2011 08:07 PM, Andrew Svetlov wrote:
As PEP 3101 http://www.python.org/dev/peps/pep-3101/ says (and current
Python does) user can specify conversions like {0!s}.
In custom formatters (derived from string.Formatter) he can override
convert_field method to add custom conversions.
I
Tim Lesher wrote:
Any test cases should definitely throw some diamond-pattern or even
more degenerate cases at the implementation. What *is* the worst case
for MRO complexity?
I don't think that's an issue -- the MRO gets flattened into
a list at class creation time, so code that walks it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As far as I remember, python-dev decided that each branch should have a
single head. We probably have even a push hook to avoid mistakes. Or we
should :).
But we don't explain what is suppose to be done when a developer is
working in a feature, she
On Wed, 16 Mar 2011 02:00:42 +0100
Jesus Cea j...@jcea.es wrote:
The standard approach in mercurial is for her to pull the changes and to
do a merge before trying to push again (and hope nobody else raced her
again, this time).
This is indeed the standard approach, so I'm not sure what the
On Tue, Mar 15, 2011 at 19:14, Antoine Pitrou solip...@pitrou.net wrote:
Beside, if you need long-term support, there is a well-known solution:
turn to a company that provides such support. That company can be called
Redhat, Canonical, ActiveState or even Apple. The community of
volunteers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16/03/11 02:15, Antoine Pitrou wrote:
On Wed, 16 Mar 2011 02:00:42 +0100
Jesus Cea j...@jcea.es wrote:
The standard approach in mercurial is for her to pull the changes and to
do a merge before trying to push again (and hope nobody else raced
2011/3/15 Jesus Cea j...@jcea.es:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16/03/11 02:15, Antoine Pitrou wrote:
On Wed, 16 Mar 2011 02:00:42 +0100
Jesus Cea j...@jcea.es wrote:
The standard approach in mercurial is for her to pull the changes and to
do a merge before trying to
On Wed, 16 Mar 2011 02:37:21 +0100
Jesus Cea j...@jcea.es wrote:
Maybe a simple try to keep the history lineal, as possible and feel
free to merge heads in the standard mercurial way.
Well, can you propose a patch to add or improve wording?
For instance, merging between branches (in which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16/03/11 02:42, Benjamin Peterson wrote:
For instance, merging between branches (in which direction) is
established here, but not in the devguide.
What are you talking about?
http://docs.python.org/devguide/committing.html#forward-porting
I
On Tue, 15 Mar 2011 21:16:58 -0400
Lennart Regebro rege...@gmail.com wrote:
On Tue, Mar 15, 2011 at 19:14, Antoine Pitrou solip...@pitrou.net wrote:
Beside, if you need long-term support, there is a well-known solution:
turn to a company that provides such support. That company can be called
On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou solip...@pitrou.net wrote:
I don't know what other core devs, but I don't think this discussion is
going anywhere. If porting the ZTK is a burden for you, perhaps you
should try to find some financial support for it (or let other people
do it for
On Tue, Mar 15, 2011 at 10:14:12PM -0400, Lennart Regebro wrote:
Up until the reactions from the core Python developers on these real
world problems, it was hard work, but also fun.
It is still. The majority of the responses were informative on
backwards compatibility and release process. And
On Tue, Mar 15, 2011 at 7:14 PM, Lennart Regebro rege...@gmail.com wrote:
On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou solip...@pitrou.net wrote:
I don't know what other core devs, but I don't think this discussion is
going anywhere. If porting the ZTK is a burden for you, perhaps you
should
On Mar 15, 2011, at 10:14 PM, Lennart Regebro wrote:
On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou solip...@pitrou.net wrote:
I don't know what other core devs, but I don't think this discussion is
going anywhere. If porting the ZTK is a burden for you, perhaps you
should try to find some
On Tue, Mar 15, 2011 at 7:14 PM, Senthil Kumaran orsent...@gmail.com wrote:
On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan ncogh...@gmail.com wrote:
With RFC 3986 passing its 6th birthday, and with it being well past
its 7th by the time 3.3 comes out, can we finally switch to supporting
the
On Tue, Mar 15, 2011 at 22:42, Guido van Rossum gu...@python.org wrote:
Fortunately there may not be any more such cases since no new major
versions of Python 2 will be released. So I'm not sure what an update
of PEP 5 will buy us.
That is a good point. But at least making sure no more API's
On Tue, Mar 15, 2011 at 9:15 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 16 Mar 2011 02:00:42 +0100
Jesus Cea j...@jcea.es wrote:
The standard approach in mercurial is for her to pull the changes and to
do a merge before trying to push again (and hope nobody else raced her
again,
On Tue, Mar 15, 2011 at 22:58, Lennart Regebro rege...@gmail.com wrote:
That is a good point. But at least making sure no more API's get
deprecated in 3.3 (and preferably 3.4)
I meant removed.
___
Python-Dev mailing list
Python-Dev@python.org
On 3/15/2011 10:58 PM, Lennart Regebro wrote:
On Tue, Mar 15, 2011 at 22:42, Guido van Rossumgu...@python.org wrote:
Fortunately there may not be any more such cases since no new major
versions of Python 2 will be released. So I'm not sure what an update
of PEP 5 will buy us.
That is a good
On Tue, Mar 15, 2011 at 7:58 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Mar 15, 2011 at 7:14 PM, Senthil Kumaran orsent...@gmail.com wrote:
On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan ncogh...@gmail.com wrote:
With RFC 3986 passing its 6th birthday, and with it being well past
its
Nick Coghlan wrote:
Backwards compatible with *what* though?
I meant the parsing 'behavior'.
For the decimal module, we treat deviations from spec as bug fixes and
update accordingly, even if this changes behaviour.
For URL parsing, the spec has changed (6 years ago!), but we still
On Wed, Mar 16, 2011 at 12:03 AM, Senthil Kumaran orsent...@gmail.com wrote:
A new function, which can given this behavior is also a good idea.
I'm strongly in favor of this approach. I know we've been bitten by
changes made in the past, and have had to introduce Python-version
specific
67 matches
Mail list logo
