On Mon, Jan 11, 2010 at 06:27, Neil Schemenauer wrote:
> I think we have got to the heart of our disagreement. Assume that
> some superhuman takes all the backwards compatible goodies from 3.x
> and merges them into 2.x.
The superhumans of core developers pretty much already have. That's
pretty m
On Sun, Jan 10, 2010 at 21:27, Neil Schemenauer wrote:
> On Sun, Jan 10, 2010 at 09:06:15PM -0800, Brett Cannon wrote:
> > If people start taking the carrots we have added to 3.x and
> > backporting them to keep the 2.x series alive you are essentially
> > making the 3.x DOA by negating its benef
On Sun, Jan 10, 2010 at 09:06:15PM -0800, Brett Cannon wrote:
> If people start taking the carrots we have added to 3.x and
> backporting them to keep the 2.x series alive you are essentially
> making the 3.x DOA by negating its benefits which I personally
> don't agree with.
I think we have got t
On Sun, Jan 10, 2010 at 20:05, Neil Schemenauer wrote:
> On Sun, Jan 10, 2010 at 07:46:04PM -0800, Brett Cannon wrote:
> > On Sun, Jan 10, 2010 at 17:44, Neil Schemenauer wrote:
> > > After the Python 2.7 release, the focus of Python development
> > > will be on Python 3. There will con
On Mon, Jan 11, 2010 at 12:02:01AM +0100, "Martin v. Löwis" wrote:
> [...] would it still be ok if I closed a 2.x feature request as
> "won't fix", or only committed the new feature to the 3.x branch?
Yes. Non-bugfix development on 2.x would optional (i.e. done by
people who want to spend the tim
On Sun, Jan 10, 2010 at 07:46:04PM -0800, Brett Cannon wrote:
> On Sun, Jan 10, 2010 at 17:44, Neil Schemenauer wrote:
> > After the Python 2.7 release, the focus of Python development
> > will be on Python 3. There will continue to be maintainance
> > releases of Python 2.x.
>
> No
On Sun, Jan 10, 2010 at 17:44, Neil Schemenauer wrote:
> On Sun, Jan 10, 2010 at 12:09:08PM -0800, Brett Cannon wrote:
> > I don't think ending the 2.x series at 2.7 makes it look bad
> > compared to 3.2; it's simply the end of a development line like
> > any other software project. I suspect 2.7
> Date: Mon, 11 Jan 2010 01:51:09 +0100
> From: "Amaury Forgeot d'Arc"
> To: Benjamin Peterson
> Cc: Python Dev
> Subject: Re: [Python-Dev] Data descriptor doc/implementation
> inconsistency
> Message-ID:
>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> 2010/1/11 Benja
On 1/10/2010 8:44 PM, Neil Schemenauer wrote:
On Sun, Jan 10, 2010 at 12:09:08PM -0800, Brett Cannon wrote:
I don't think ending the 2.x series at 2.7 makes it look bad
compared to 3.2; it's simply the end of a development line like
any other software project. I suspect 2.7 will have a protracte
On Sun, Jan 10, 2010 at 12:09:08PM -0800, Brett Cannon wrote:
> I don't think ending the 2.x series at 2.7 makes it look bad
> compared to 3.2; it's simply the end of a development line like
> any other software project. I suspect 2.7 will have a protracted
> bugfix window because so much code runs
2010/1/10 Amaury Forgeot d'Arc :
> Quoting the documentation:
> """Normally, data descriptors define both __get__() and __set__(),
> while non-data descriptors have just the __get__() method.
> """
> Your example is neither a data descriptor nor a non-data descriptor...
See the footnote: http://do
Hi,
2010/1/11 Benjamin Peterson :
> Consider this program:
>
> class Descr(object):
> def __init__(self, name):
> self.name = name
> def __set__(self, instance, what):
> instance.__dict__[self.name] = what
>
> class X(object):
> attr = Descr("attr")
>
> x = X()
> print(x.att
Consider this program:
class Descr(object):
def __init__(self, name):
self.name = name
def __set__(self, instance, what):
instance.__dict__[self.name] = what
class X(object):
attr = Descr("attr")
x = X()
print(x.attr)
x.attr = 42
print(x.attr)
It gives in output:
<_
> The announcement is precisely to avoid the situation where people commit
> new features to the 2.x main line of development (after the 2.7
> maintenance branch is created) in the expectation that they will be
> released as part of a hypothetical 2.8 release.
>
> Whether that info needs to be in
> I propose that the 2.x branch be treated like 2.x.y branches: as
> long as there is sufficient volunteer labour, it should continue to
> live. In order to avoid wasted development effort, it would be
> prudent to announce that unless a 2.8 release manager steps up,
> whatever is committed to the
On 10/01/2010 21:52, Dirkjan Ochtman wrote:
On Sun, Jan 10, 2010 at 21:25, Brett Cannon wrote:
Michael has given me the hg transition/stdlib time slot at the language
summit this year. In regards to that I plan to lead a discussion on:
* where we are at w/ the Hg transition (Dirkjan should
On Sun, Jan 10, 2010 at 21:25, Brett Cannon wrote:
> Michael has given me the hg transition/stdlib time slot at the language
> summit this year. In regards to that I plan to lead a discussion on:
> * where we are at w/ the Hg transition (Dirkjan should be there and I did a
> blog post on this topi
Michael has given me the hg transition/stdlib time slot at the language
summit this year. In regards to that I plan to lead a discussion on:
* where we are at w/ the Hg transition (Dirkjan should be there and I did a
blog post on this topic recently:
http://sayspy.blogspot.com/2010/01/where-hg-tra
Neil Schemenauer wrote:
> In order to avoid wasted development effort, it would be
> prudent to announce that unless a 2.8 release manager steps up,
> whatever is committed to the 2.x branch after the 2.7 release may
> never get released.
The announcement is precisely to avoid the situation where
On Sun, Jan 10, 2010 at 11:30, Neil Schemenauer wrote:
> Benjamin Peterson wrote:
> > On behalf of the Python development team, I'm gleeful to announce
> > the second alpha release of Python 2.7.
>
> Thanks to everyone who contributed.
>
> > Python 2.7 is scheduled to be the last major version i
Benjamin Peterson wrote:
> On behalf of the Python development team, I'm gleeful to announce
> the second alpha release of Python 2.7.
Thanks to everyone who contributed.
> Python 2.7 is scheduled to be the last major version in the 2.x
> series.
Has this really been decided already? Maybe I mi
2010/1/10 Victor Stinner :
> Hi,
>
> Le dimanche 10 janvier 2010 19:51:26, Brett Cannon a écrit :
>> Nick Coghlan thought I should forward this to python-dev so people are
>> aware of this change and why it occurred (plus it indirectly informs Guido
>> I finally finished the work).
>
> Thanks to
Hi,
Le dimanche 10 janvier 2010 19:51:26, Brett Cannon a écrit :
> Nick Coghlan thought I should forward this to python-dev so people are
> aware of this change and why it occurred (plus it indirectly informs Guido
> I finally finished the work).
Thanks to copy this mail to the python-dev maili
Nick Coghlan thought I should forward this to python-dev so people are aware
of this change and why it occurred (plus it indirectly informs Guido I
finally finished the work).
-- Forwarded message --
From: brett.cannon
Date: Sat, Jan 9, 2010 at 18:56
Subject: [Python-checkins] r77
On Sun, Jan 10, 2010 at 12:10, Henning von Bargen
wrote:
> If Python should support BOM when reading text files,
> it should also be able to *write* such files.
That's what I thought too. Turns out the UTF-16 does write such a
mark. You also have the constants in the codecs module, so you can
wri
If Python should support BOM when reading text files,
it should also be able to *write* such files.
An encoding="BOM" argument wouldn't help here, because
it does not specify which encoding to use actually:
UFT-8, UTF-16-LE or what?
That would be a point against encoding="BOM" and
pro an additio
26 matches
Mail list logo
