Re: [Python-Dev] Deprecation policy

[Petri Lehtinen]

Michael Foord wrote:
> We tend to see 3.2 -> 3.3 as a "major version" increment, but that's
> just Python's terminology.

Even though (in the documentation) Python's version number components
are called major, minor, micro, releaselevel and serial, in this
order? So when the minor version component is increased it's a major
version increment? :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Long term development external named branches and periodic merges from python

[Petri Lehtinen]

Nick Coghlan wrote:
> > So, in this context, if the tracker "create patch" diff from BASE, it
> > is not "safe" to merge changes from mainline to the branch, because if
> > so "create patch" would include code not related to my work.
> 
> No, "Create Patch" is smarter than that. What it does (or tries to do)
> is walk back through your branch history, trying to find the last
> point where you merged in a changeset that it recognises as coming
> from the main CPython repo. It then uses that revision of the CPython
> repo as the basis for the diff.
> 
> So if you're just working on a feature branch, periodically pulling
> from hg.python.org/cpython and merging from default, then it should
> all work fine.
> 
> Branches-of-branches (i.e. where you've merged from CPython via
> another named branch in your local repo) seems to confuse it though -
> I plan to change my workflow for those cases to merge each branch from
> the same version of default before merging from the other branch.

The ancestor() revset could help for the confusion:

http://stackoverflow.com/a/6744163/639276

In this case, the user would have to be able to tell the branch
against which he wants the diff.

Petri
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecation policy

[Antoine Pitrou]

On Tue, 29 Nov 2011 14:46:06 +0200
Petri Lehtinen  wrote:
> Michael Foord wrote:
> > We tend to see 3.2 -> 3.3 as a "major version" increment, but that's
> > just Python's terminology.
> 
> Even though (in the documentation) Python's version number components
> are called major, minor, micro, releaselevel and serial, in this
> order? So when the minor version component is increased it's a major
> version increment? :)

Well, that's why I think the version number components are not
correctly named. I don't think any of the 2.x or 3.x releases can be
called "minor" by any stretch of the word. A quick glance at
http://docs.python.org/dev/whatsnew/index.html should be enough.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecation policy

[Oleg Broytman]

On Tue, Nov 29, 2011 at 02:46:06PM +0200, Petri Lehtinen wrote:
> Michael Foord wrote:
> > We tend to see 3.2 -> 3.3 as a "major version" increment, but that's
> > just Python's terminology.
> 
> Even though (in the documentation) Python's version number components
> are called major, minor, micro, releaselevel and serial, in this
> order? So when the minor version component is increased it's a major
> version increment? :)

   When the major version component is increased it's a World Shattering
Change, isn't it?! ;-)

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecation policy

[Barry Warsaw]

On Nov 29, 2011, at 01:59 PM, Antoine Pitrou wrote:

>Well, that's why I think the version number components are not
>correctly named. I don't think any of the 2.x or 3.x releases can be
>called "minor" by any stretch of the word. A quick glance at
>http://docs.python.org/dev/whatsnew/index.html should be enough.

Agreed, but it's too late to change it.  I look at it as the attributes of the
namedtuple being evocative of the traditional names for the digit positions,
not the assignment of those positions to Python's semantics.

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecation policy

[Georg Brandl]

Am 29.11.2011 13:46, schrieb Petri Lehtinen:
> Michael Foord wrote:
>> We tend to see 3.2 -> 3.3 as a "major version" increment, but that's
>> just Python's terminology.
> 
> Even though (in the documentation) Python's version number components
> are called major, minor, micro, releaselevel and serial, in this
> order? So when the minor version component is increased it's a major
> version increment? :)

Yes.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] LZMA support has landed

[Nadeem Vawda]

Hey folks,

I'm pleased to announce that as of changeset 74d182cf0187, the
standard library now includes support for the LZMA compression
algorithm (as well as the associated .xz and .lzma file formats). The
new lzma module has a very similar API to the existing bz2 module; it
should serve as a drop-in replacement for most use cases.

If anyone has any feedback or any suggestions for improvement, please
let me know.

I'd like to ask the owners of (non-Windows) buildbots to install the
XZ Utils development headers so that they can build the new module.
For Debian-derived Linux distros, the relevant package is named
"liblzma-dev"; on Fedora I believe the correct package is "xz-devel".
Binaries for OS X are available from the project's homepage at
.

Finally, a big thanks to everyone who contributed feedback during this
module's development!

Cheers,
Nadeem
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Issue #6715: Add module for compression using the LZMA algorithm.

[Antoine Pitrou]

On Tue, 29 Nov 2011 23:36:58 +0100
nadeem.vawda  wrote:
> http://hg.python.org/cpython/rev/74d182cf0187
> changeset:   73794:74d182cf0187
> user:Nadeem Vawda 
> date:Wed Nov 30 00:25:06 2011 +0200
> summary:
>   Issue #6715: Add module for compression using the LZMA algorithm.

Congratulations, Nadeem!

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] LZMA support has landed

[Amaury Forgeot d'Arc]

2011/11/29 Nadeem Vawda 

> I'm pleased to announce that as of changeset 74d182cf0187, the
> standard library now includes support for the LZMA compression
> algorithm


Congratulations!


> I'd like to ask the owners of (non-Windows) buildbots to install the
> XZ Utils development headers so that they can build the new module.
>

And don't worry about Windows builbots, they will automatically download
the XZ prebuilt binaries from the usual place.
(svn export http://svn.python.org/projects/external/xz-5.0.3)

Next step: add support for tar.xz files (issue5689)...

-- 
Amaury Forgeot d'Arc
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecation policy

[Nick Coghlan]

On Wed, Nov 30, 2011 at 1:13 AM, Barry Warsaw  wrote:
> On Nov 29, 2011, at 01:59 PM, Antoine Pitrou wrote:
>
>>Well, that's why I think the version number components are not
>>correctly named. I don't think any of the 2.x or 3.x releases can be
>>called "minor" by any stretch of the word. A quick glance at
>>http://docs.python.org/dev/whatsnew/index.html should be enough.
>
> Agreed, but it's too late to change it.  I look at it as the attributes of the
> namedtuple being evocative of the traditional names for the digit positions,
> not the assignment of those positions to Python's semantics.

Hmm, I wonder about that. Perhaps we could add a second set of names
in parallel with the "major.minor.micro" names:
"series.feature.maint".

That would, after all, reflect what is actually said in practice:
- release series: 2.x, 3.x  (usually used in a form like "In the 3.x
series, X is true. In 2.x, Y is true)
- feature release: 2.7, 3.2, etc
- maintenance release: 2.7.2, 3.2.1, etc

I know I tend to call feature releases major releases and I'm far from
alone in that. The discrepancy in relation to sys.version_info is
confusing, but we can't make 'major' refer to a different field
without breaking existing programs. But we *can* change:

>>> sys.version_info
sys.version_info(major=2, minor=7, micro=2, releaselevel='final', serial=0)

to instead read:

sys.version_info(series=2, feature=7, maint=2, releaselevel='final', serial=0)

while allowing 'major' as an alias of 'series', 'minor' as an alias of
'feature' and 'micro' as an alias of 'maint'. Nothing breaks, and we'd
have started down the path towards coherent terminology for the three
fields in the version numbers (by accepting that 'major' has now
become irredeemably ambiguous in the context of CPython releases).

This idea of renaming all three fields has come up before, but I
believe we got stuck on the question of what to call the first number
(i.e. the one I'm calling the "series" here).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecation policy

[Benjamin Peterson]

2011/11/29 Nick Coghlan :
> On Wed, Nov 30, 2011 at 1:13 AM, Barry Warsaw  wrote:
>> On Nov 29, 2011, at 01:59 PM, Antoine Pitrou wrote:
>>
>>>Well, that's why I think the version number components are not
>>>correctly named. I don't think any of the 2.x or 3.x releases can be
>>>called "minor" by any stretch of the word. A quick glance at
>>>http://docs.python.org/dev/whatsnew/index.html should be enough.
>>
>> Agreed, but it's too late to change it.  I look at it as the attributes of 
>> the
>> namedtuple being evocative of the traditional names for the digit positions,
>> not the assignment of those positions to Python's semantics.
>
> Hmm, I wonder about that. Perhaps we could add a second set of names
> in parallel with the "major.minor.micro" names:
> "series.feature.maint".
>
> That would, after all, reflect what is actually said in practice:
> - release series: 2.x, 3.x  (usually used in a form like "In the 3.x
> series, X is true. In 2.x, Y is true)
> - feature release: 2.7, 3.2, etc
> - maintenance release: 2.7.2, 3.2.1, etc
>
> I know I tend to call feature releases major releases and I'm far from
> alone in that. The discrepancy in relation to sys.version_info is
> confusing, but we can't make 'major' refer to a different field
> without breaking existing programs. But we *can* change:
>
 sys.version_info
> sys.version_info(major=2, minor=7, micro=2, releaselevel='final', serial=0)
>
> to instead read:
>
> sys.version_info(series=2, feature=7, maint=2, releaselevel='final', serial=0)
>
> while allowing 'major' as an alias of 'series', 'minor' as an alias of
> 'feature' and 'micro' as an alias of 'maint'. Nothing breaks, and we'd
> have started down the path towards coherent terminology for the three
> fields in the version numbers (by accepting that 'major' has now
> become irredeemably ambiguous in the context of CPython releases).
>
> This idea of renaming all three fields has come up before, but I
> believe we got stuck on the question of what to call the first number
> (i.e. the one I'm calling the "series" here).

Can we drop this now? Too much effort for very little benefit. We call
releases what we call releases.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecation policy

[Matt Joiner]

I like this article on it:

http://semver.org/

The following snippets being relevant here:

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards
compatible functionality is introduced to the public API. It MUST be
incremented if any public API functionality is marked as deprecated.

Major version X (X.y.z | X > 0) MUST be incremented if any backwards
incompatible changes are introduced to the public API.

With the exception of actually dropping stuff (however this only
occurs in terms of modules, which hardly count in special cases?),
Python already conforms to this standard very well.

On Wed, Nov 30, 2011 at 11:00 AM, Benjamin Peterson  wrote:
> 2011/11/29 Nick Coghlan :
>> On Wed, Nov 30, 2011 at 1:13 AM, Barry Warsaw  wrote:
>>> On Nov 29, 2011, at 01:59 PM, Antoine Pitrou wrote:
>>>
Well, that's why I think the version number components are not
correctly named. I don't think any of the 2.x or 3.x releases can be
called "minor" by any stretch of the word. A quick glance at
http://docs.python.org/dev/whatsnew/index.html should be enough.
>>>
>>> Agreed, but it's too late to change it.  I look at it as the attributes of 
>>> the
>>> namedtuple being evocative of the traditional names for the digit positions,
>>> not the assignment of those positions to Python's semantics.
>>
>> Hmm, I wonder about that. Perhaps we could add a second set of names
>> in parallel with the "major.minor.micro" names:
>> "series.feature.maint".
>>
>> That would, after all, reflect what is actually said in practice:
>> - release series: 2.x, 3.x  (usually used in a form like "In the 3.x
>> series, X is true. In 2.x, Y is true)
>> - feature release: 2.7, 3.2, etc
>> - maintenance release: 2.7.2, 3.2.1, etc
>>
>> I know I tend to call feature releases major releases and I'm far from
>> alone in that. The discrepancy in relation to sys.version_info is
>> confusing, but we can't make 'major' refer to a different field
>> without breaking existing programs. But we *can* change:
>>
> sys.version_info
>> sys.version_info(major=2, minor=7, micro=2, releaselevel='final', serial=0)
>>
>> to instead read:
>>
>> sys.version_info(series=2, feature=7, maint=2, releaselevel='final', 
>> serial=0)
>>
>> while allowing 'major' as an alias of 'series', 'minor' as an alias of
>> 'feature' and 'micro' as an alias of 'maint'. Nothing breaks, and we'd
>> have started down the path towards coherent terminology for the three
>> fields in the version numbers (by accepting that 'major' has now
>> become irredeemably ambiguous in the context of CPython releases).
>>
>> This idea of renaming all three fields has come up before, but I
>> believe we got stuck on the question of what to call the first number
>> (i.e. the one I'm calling the "series" here).
>
> Can we drop this now? Too much effort for very little benefit. We call
> releases what we call releases.
>
>
>
> --
> Regards,
> Benjamin
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] LZMA support has landed

[Matt Joiner]

Congrats, this is an excellent feature.

On Wed, Nov 30, 2011 at 10:34 AM, Amaury Forgeot d'Arc
 wrote:
> 2011/11/29 Nadeem Vawda 
>>
>> I'm pleased to announce that as of changeset 74d182cf0187, the
>> standard library now includes support for the LZMA compression
>> algorithm
>
>
> Congratulations!
>
>>
>> I'd like to ask the owners of (non-Windows) buildbots to install the
>> XZ Utils development headers so that they can build the new module.
>
>
> And don't worry about Windows builbots, they will automatically download
> the XZ prebuilt binaries from the usual place.
> (svn export http://svn.python.org/projects/external/xz-5.0.3)
>
> Next step: add support for tar.xz files (issue5689)...
>
> --
> Amaury Forgeot d'Arc
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] LZMA support has landed

[Meador Inge]

On Tue, Nov 29, 2011 at 4:59 PM, Nadeem Vawda  wrote:

> "liblzma-dev"; on Fedora I believe the correct package is "xz-devel".

"xz-devel" is right.  I just verified a build of the new module on a
fresh F16 system.

-- 
Meador
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com