Lennart Regebro, 16.03.2011 00:04:
On Tue, Mar 15, 2011 at 18:56, Nick Coghlan 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.
Personally, I would expect that breaking ba
On Wed, Mar 16, 2011 at 12:03 AM, Senthil Kumaran 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 handling. (I don't have t
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 Tue, Mar 15, 2011 at 7:58 PM, Nick Coghlan wrote:
> On Tue, Mar 15, 2011 at 7:14 PM, Senthil Kumaran wrote:
>> On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan 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 swi
On 3/15/2011 10:58 PM, Lennart Regebro wrote:
On Tue, Mar 15, 2011 at 22:42, Guido van Rossum 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 lea
On Tue, Mar 15, 2011 at 22:58, Lennart Regebro 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
http://mail.python.org/m
On Tue, Mar 15, 2011 at 9:15 PM, Antoine Pitrou wrote:
> On Wed, 16 Mar 2011 02:00:42 +0100
> Jesus Cea 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
On Tue, Mar 15, 2011 at 22:42, Guido van Rossum 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 get
deprecated
On Tue, Mar 15, 2011 at 7:14 PM, Senthil Kumaran wrote:
> On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan 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
On Mar 15, 2011, at 10:14 PM, Lennart Regebro wrote:
> On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou 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 suppo
On Tue, Mar 15, 2011 at 7:14 PM, Lennart Regebro wrote:
> On Tue, Mar 15, 2011 at 21:54, Antoine Pitrou 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 sup
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 21:54, Antoine Pitrou 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 you), rather than
On Tue, 15 Mar 2011 21:16:58 -0400
Lennart Regebro wrote:
> On Tue, Mar 15, 2011 at 19:14, Antoine Pitrou 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, ActiveSta
-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-porti
On Wed, 16 Mar 2011 02:37:21 +0100
Jesus Cea 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 direct
2011/3/15 Jesus Cea :
> -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 wrote:
>>>
>>> The standard approach in mercurial is for her to pull the changes and to
>>> do a merge before trying to push again
-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 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
On Tue, Mar 15, 2011 at 19:14, Antoine Pitrou 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 called python-dev i
On Wed, 16 Mar 2011 02:00:42 +0100
Jesus Cea 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 point of
-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 up
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 nev
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 expe
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
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 containi
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 timemac
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
On Tue, 15 Mar 2011 18:46:37 -0400
Lennart Regebro 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 keep on br
On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan 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 3986, expect fo
On Tue, Mar 15, 2011 at 18:56, Nick Coghlan 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
___
Python-Dev mailing l
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, c
On Tue, Mar 15, 2011 at 6:46 PM, Lennart Regebro wrote:
> On Tue, Mar 15, 2011 at 15:39, "Martin v. Löwis" 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 numpy folks have shown it is
On Tue, Mar 15, 2011 at 15:39, "Martin v. Löwis" 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 versions, but
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 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
>
2011/3/15 Terry Reedy :
> On 3/15/2011 1:00 PM, Antoine Pitrou wrote:
>>
>> On Tue, 15 Mar 2011 04:19:24 +0100
>> ezio.melotti 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 sh
On 3/15/2011 1:00 PM, Antoine Pitrou wrote:
On Tue, 15 Mar 2011 04:19:24 +0100
ezio.melotti 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
On 3/15/2011 11:57 AM, Brian Curtin wrote:
On Tue, Mar 15, 2011 at 11:28, Nick Coghlan mailto:ncogh...@gmail.com>> wrote:
On Tue, Mar 15, 2011 at 10:52 AM, Brian Curtin
mailto:brian.cur...@gmail.com>> wrote:
> Agreed. I'll rename them to be more expressive.
Don't forget NEWS an
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:17 AM, Nick Coghlan wrote:
On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord
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_, r
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
*no
On Tue, Mar 15, 2011 at 12:02, "Martin v. Löwis" 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 breakage for
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 e
On Tue, Mar 15, 2011 at 12:27 PM, Tim Lesher 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.
--
Nick Coghlan
On Tue, 15 Mar 2011 04:19:24 +0100
ezio.melotti 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 will make tracking changes
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 *years*
On Tue, Mar 15, 2011 at 11:15, 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, only applying __api__ to the specific class that defined it.
Great catch. I know pydoc already
On Tue, Mar 15, 2011 at 11:24, Antoine Pitrou 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, and forci
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 m
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 2.7)
On Tue, Mar 15, 2011 at 11:28, Nick Coghlan wrote:
> On Tue, Mar 15, 2011 at 10:52 AM, Brian Curtin
> 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 acks from another patch last
night. T
> 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 10:52 AM, Brian Curtin 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
___
Python-Dev mailin
On Tue, 15 Mar 2011 11:17:18 -0400
Nick Coghlan wrote:
> On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord
> 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
On Tue, Mar 15, 2011 at 9:48 AM, Tarek Ziadé 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 the from __fu
On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord
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 is sometimes done
On Tue, Mar 15, 2011 at 9:42 AM, Tim Lesher 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 people.
> Con: sligh
On Mon, Mar 14, 2011 at 19:22, Reid Kleckner 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 Py_CAPSULE_H. All you lose
On Tue, Mar 15, 2011 at 09:20, "Martin v. Löwis" 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 seven months.
On Tue, Mar 15, 2011 at 10:44, Antoine Pitrou wrote:
> On Tue, 15 Mar 2011 15:29:59 +0100
> brian.curtin wrote:
> > +
> > +def test_gz_ext(self):
> [...]
> > +
> > +def test_bz2_ext(self):
> [...]
> > +
> > +def test_Gz_ext(self):
> > +self.do_test_use_builtin_open("abcd.Gz",
On Tue, 15 Mar 2011 15:29:59 +0100
brian.curtin 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):
> +self.do_test_use_builtin_op
On 15/03/2011 07:59, Nick Coghlan wrote:
On Tue, Mar 15, 2011 at 6:20 PM, Eric Smith 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
On Tue, Mar 15, 2011 at 7:50 AM, Nick Coghlan wrote:
> On Tue, Mar 15, 2011 at 10:27 AM, Greg Ewing
> 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 c
On Mon, Mar 14, 2011 at 08:28, Tim Lesher wrote:
> On Mon, Mar 14, 2011 at 05:45, Nick Coghlan wrote:
>> There are two relatively simple ways forward I can see:
>>
>> A. Add a __public__ attribute that pydoc (and import *) understand.
>> This would overrride the default "this is private" detectio
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 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 anything's been
> 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 n
On Tue, Mar 15, 2011 at 6:20 PM, Eric Smith 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
> name can be an
On Tue, Mar 15, 2011 at 10:27 AM, Greg Ewing
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.
--
Nick Coghlan | ncogh...
On 03/14/2011 10:02 PM, James Mills wrote:
On Tue, Mar 15, 2011 at 11:50 AM, Terry Reedy 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 that just shift
69 matches
Mail list logo
