[Python-Dev] Packaging in Python 2 anyone ?

2011-08-14 Thread Tarek Ziadé 
Hi all,

I am lacking of time right now to finish an important task before 3.2
final is out: we need to release "packaging" as a standalone release
under Python 2.x and Python 3.1, to gather as much feedback as we can
from more people.

Doing an automated conversion turned out to be a nightmare, and I was
about to go ahead and maintain a fork of the packaging package, with
the few modules that are needed (sysconfig, etc) within a standalone
release.

I am looking for someone that has some free time and that is willing
to lead this work.

3.2 can go out without this work of course, but it would be *much*
better to have that feedback

If you are interested, please let me know.

Cheers
Tarek

-- 
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python 3.2.2rc1

2011-08-14 Thread Martin v. Löwis 
On behalf of the Python development team, I'm happy to announce the
first release candidate of the Python 3.2.2 maintenance release (3.2.2rc1).

Python 3.2.2 fixes `a regression `_ in the
``urllib.request`` module that prevented opening many HTTP resources
correctly
with Python 3.2.1.

Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line.  Since the final release of Python 2.7, the 2.x line
will only receive bugfixes, and new features are developed for 3.x only.

Since PEP 3003, the Moratorium on Language Changes, is in effect, there
are no changes in Python's syntax and built-in types in Python 3.2.
Development efforts concentrated on the standard library and support for
porting code to Python 3.  Highlights are:

* numerous improvements to the unittest module
* PEP 3147, support for .pyc repository directories
* PEP 3149, support for version tagged dynamic libraries
* PEP 3148, a new futures library for concurrent programming
* PEP 384, a stable ABI for extension modules
* PEP 391, dictionary-based logging configuration
* an overhauled GIL implementation that reduces contention
* an extended email package that handles bytes messages
* a much improved ssl module with support for SSL contexts and certificate
  hostname matching
* a sysconfig module to access configuration information
* additions to the shutil module, among them archive file support
* many enhancements to configparser, among them mapping protocol support
* improvements to pdb, the Python debugger
* countless fixes regarding bytes/string issues; among them full support
  for a bytes environment (filenames, environment variables)
* many consistency and behavior fixes for numeric operations

For a more extensive list of changes in 3.2, see

http://docs.python.org/3.2/whatsnew/3.2.html

To download Python 3.2 visit:

http://www.python.org/download/releases/3.2/

Please consider trying Python 3.2 with your code and reporting any bugs
you may notice to:

http://bugs.python.org/


Enjoy!

--
Martin v. Löwis
(on behalf of the entire python-dev team and 3.2's contributors)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Packaging in Python 2 anyone ?

2011-08-14 Thread Nick Coghlan 
On Sun, Aug 14, 2011 at 7:41 PM, Tarek Ziadé  wrote:
> Hi all,
>
> I am lacking of time right now to finish an important task before 3.2
> final is out:

If anyone else got at all confused by Tarek's email, s/3.x/3.x+1/ and
it will all make sense (the mentioned release numbers in the 3.x
series are all one lower than they should be - packaging is planned
for 3.3, but a standalone library will allow feedback to be gathered
from 2.x and 3.2 users before the API is 'locked in' for 3.3).

How far has packaging diverged from distutils2, though? Wasn't that
the planned venue for any backports in order to avoid name conflicts?

Cheers,
Nick.

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

Re: [Python-Dev] Python 3.2.2rc1

2011-08-14 Thread Terry Reedy 

On 8/14/2011 12:31 PM, "Martin v. Löwis" wrote:

On behalf of the Python development team, I'm happy to announce the
first release candidate of the Python 3.2.2 maintenance release (3.2.2rc1).

Python 3.2.2 fixes `a regression`_ in the
``urllib.request`` module that prevented opening many HTTP resources
correctly
with Python 3.2.1.


It also has the fix for http://bugs.python.org/issue12540
as requested. Thank you.

--
Terry Jan Reedy


___
Python-Dev mailing list
[email protected]
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: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-14 Thread Brett Cannon 
On Thu, Aug 11, 2011 at 00:02, Antoine Pitrou  wrote:

> Le Thu, 11 Aug 2011 03:34:37 +0200,
> brian.curtin  a écrit :
> > http://hg.python.org/cpython/rev/77a65b078852
> > changeset:   71809:77a65b078852
> > parent:  71803:1b4fae183da3
> > user:Brian Curtin 
> > date:Wed Aug 10 20:05:21 2011 -0500
> > summary:
> >   Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.
>
>
> It would sound more useful to have a generic Py_RETURN() macro rather than
> some specific forms for each and every common object.
>

Since the macro is rather generic, sure, but the name should probably be
better since it doesn't necessarily convene the fact that a INCREF has
occurred. So maybe Py_INCREF_RETURN()?


>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
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: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-14 Thread Benjamin Peterson 
2011/8/14 Brett Cannon :
>
>
> On Thu, Aug 11, 2011 at 00:02, Antoine Pitrou  wrote:
>>
>> Le Thu, 11 Aug 2011 03:34:37 +0200,
>> brian.curtin  a écrit :
>> > http://hg.python.org/cpython/rev/77a65b078852
>> > changeset:   71809:77a65b078852
>> > parent:      71803:1b4fae183da3
>> > user:        Brian Curtin 
>> > date:        Wed Aug 10 20:05:21 2011 -0500
>> > summary:
>> >   Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.
>>
>>
>> It would sound more useful to have a generic Py_RETURN() macro rather than
>> some specific forms for each and every common object.
>
> Since the macro is rather generic, sure, but the name should probably be
> better since it doesn't necessarily convene the fact that a INCREF has
> occurred. So maybe Py_INCREF_RETURN()?

That nearly nullifies the space saving. I think that fact that it's a
macro at all conveys that it does something else aside from "return
x;".


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

Re: [Python-Dev] Backporting howto/pyporting to 2.7

2011-08-14 Thread Brett Cannon 
Probably mostly hassle of maintaining changes between the two versions, but
the doc will probably get more exposure that way. I say if you want to
spearhead the backport, go for it.

On Fri, Aug 12, 2011 at 09:51, Éric Araujo  wrote:

> Hi everyone,
>
> I think it would be useful to have the “Porting Python 2 Code to Python
> 3” HOWTO in the 2.7 docs, as I think that a lot of users consult the 2.7
> docs.  Is there any reason not to do it?
>
> Regards
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
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: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-14 Thread Brett Cannon 
On Sun, Aug 14, 2011 at 19:36, Benjamin Peterson wrote:

> 2011/8/14 Brett Cannon :
> >
> >
> > On Thu, Aug 11, 2011 at 00:02, Antoine Pitrou 
> wrote:
> >>
> >> Le Thu, 11 Aug 2011 03:34:37 +0200,
> >> brian.curtin  a écrit :
> >> > http://hg.python.org/cpython/rev/77a65b078852
> >> > changeset:   71809:77a65b078852
> >> > parent:  71803:1b4fae183da3
> >> > user:Brian Curtin 
> >> > date:Wed Aug 10 20:05:21 2011 -0500
> >> > summary:
> >> >   Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.
> >>
> >>
> >> It would sound more useful to have a generic Py_RETURN() macro rather
> than
> >> some specific forms for each and every common object.
> >
> > Since the macro is rather generic, sure, but the name should probably be
> > better since it doesn't necessarily convene the fact that a INCREF has
> > occurred. So maybe Py_INCREF_RETURN()?
>
> That nearly nullifies the space saving. I think that fact that it's a
> macro at all conveys that it does something else aside from "return
> x;".
>

This is C code; space savings went out the window along with gc a long time
ago.

Yes, being a macro helps differentiate semantics that a longer name is
probably not needed.


>
>
> --
> Regards,
> Benjamin
>
___
Python-Dev mailing list
[email protected]
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: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-14 Thread Benjamin Peterson 
2011/8/14 Brett Cannon :
>
>
> On Sun, Aug 14, 2011 at 19:36, Benjamin Peterson 
> wrote:
>>
>> 2011/8/14 Brett Cannon :
>> >
>> >
>> > On Thu, Aug 11, 2011 at 00:02, Antoine Pitrou 
>> > wrote:
>> >>
>> >> Le Thu, 11 Aug 2011 03:34:37 +0200,
>> >> brian.curtin  a écrit :
>> >> > http://hg.python.org/cpython/rev/77a65b078852
>> >> > changeset:   71809:77a65b078852
>> >> > parent:      71803:1b4fae183da3
>> >> > user:        Brian Curtin 
>> >> > date:        Wed Aug 10 20:05:21 2011 -0500
>> >> > summary:
>> >> >   Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.
>> >>
>> >>
>> >> It would sound more useful to have a generic Py_RETURN() macro rather
>> >> than
>> >> some specific forms for each and every common object.
>> >
>> > Since the macro is rather generic, sure, but the name should probably be
>> > better since it doesn't necessarily convene the fact that a INCREF has
>> > occurred. So maybe Py_INCREF_RETURN()?
>>
>> That nearly nullifies the space saving. I think that fact that it's a
>> macro at all conveys that it does something else aside from "return
>> x;".
>
> This is C code; space savings went out the window along with gc a long time
> ago.

I'm hanging on to it by a hair. :)



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
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: Add Py_RETURN_NOTIMPLEMENTED macro. Fixes #12724.

2011-08-14 Thread Nick Coghlan 
On Mon, Aug 15, 2011 at 12:34 PM, Brett Cannon  wrote:
> On Thu, Aug 11, 2011 at 00:02, Antoine Pitrou  wrote:
>> It would sound more useful to have a generic Py_RETURN() macro rather than
>> some specific forms for each and every common object.
>
> Since the macro is rather generic, sure, but the name should probably be
> better since it doesn't necessarily convene the fact that a INCREF has
> occurred. So maybe Py_INCREF_RETURN()?

Aside from None and NotImplemented, do we really do the straight
incref-and-return all that often?

While I was initially attracted to the idea of a generic macro, the
more I thought about it, the more it seemed like a magnet for
reference leak bugs.

Cheers,
Nick.

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

Re: [Python-Dev] Latest draft of PEP 399 (Pure Python/C Accelerator Module Compatibility Requirements)

2011-08-14 Thread Brett Cannon 
Since the latest draft went four weeks w/o comment or complaint to address
the last round of issues, I am going to consider this PEP accepted (don't
think we need a BDFAP since this is procedural and not a language feature or
stdlib addition, but if people disagree then Guido can assign someone).

On Sun, Jul 17, 2011 at 17:16, Brett Cannon  wrote:

> While at a mini-PyPy sprint w/ Alex Gaynor of PyPy and Phil Jenvey of
> Jython, I decided to finally put the time in to update this PEP yet again.
>
> The biggest changes is that the 100% branch coverage requirement has been
> replaced with "comprehensive" coverage from the tests. I think we are all
> enough grown-ups to not have to specify anything tighter than this. I also
> added a paragraph in the Details section about using the abstract C APIs
> (e.g., PyObject_GetItem) over type-specific ones (e.g., PyList_GetItem) in
> order to be more supportive of duck typing from the Python code. I figure
> the "be API compatible" assumes this, but mentioning it doesn't hurt (and
> should help make Raymond less angry =).
>
>
> PEP: 399
> Title: Pure Python/C Accelerator Module Compatibility Requirements
> Version: $Revision: 88219 $
> Last-Modified: $Date: 2011-01-27 13:47:00 -0800 (Thu, 27 Jan 2011) $
> Author: Brett Cannon 
> Status: Draft
> Type: Informational
> Content-Type: text/x-rst
> Created: 04-Apr-2011
> Python-Version: 3.3
> Post-History: 04-Apr-2011, 12-Apr-2011, 17-Jul-2011
>
> Abstract
> 
>
> The Python standard library under CPython contains various instances
> of modules implemented in both pure Python and C (either entirely or
> partially). This PEP requires that in these instances that the
> C code *must* pass the test suite used for the pure Python code
> so as to act as much as a drop-in replacement as reasonably possible
> (C- and VM-specific tests are exempt). It is also required that new
> C-based modules lacking a pure Python equivalent implementation get
> special permission to be added to the standard library.
>
>
> Rationale
> =
>
> Python has grown beyond the CPython virtual machine (VM). IronPython_,
> Jython_, and PyPy_ are all currently viable alternatives to the
> CPython VM. The VM ecosystem that has sprung up around the Python
> programming language has led to Python being used in many different
> areas where CPython cannot be used, e.g., Jython allowing Python to be
> used in Java applications.
>
> A problem all of the VMs other than CPython face is handling modules
> from the standard library that are implemented (to some extent) in C.
> Since other VMs do not typically support the entire `C API of CPython`_
> they are unable to use the code used to create the module. Often times
> this leads these other VMs to either re-implement the modules in pure
> Python or in the programming language used to implement the VM itself
> (e.g., in C# for IronPython). This duplication of effort between
> CPython, PyPy, Jython, and IronPython is extremely unfortunate as
> implementing a module *at least* in pure Python would help mitigate
> this duplicate effort.
>
> The purpose of this PEP is to minimize this duplicate effort by
> mandating that all new modules added to Python's standard library
> *must* have a pure Python implementation _unless_ special dispensation
> is given. This makes sure that a module in the stdlib is available to
> all VMs and not just to CPython (pre-existing modules that do not meet
> this requirement are exempt, although there is nothing preventing
> someone from adding in a pure Python implementation retroactively).
>
> Re-implementing parts (or all) of a module in C (in the case
> of CPython) is still allowed for performance reasons, but any such
> accelerated code must pass the same test suite (sans VM- or C-specific
> tests) to verify semantics and prevent divergence. To accomplish this,
> the test suite for the module must have comprehensive coverage of the
> pure Python implementation before the acceleration code may be added.
>
>
> Details
> ===
>
> Starting in Python 3.3, any modules added to the standard library must
> have a pure Python implementation. This rule can only be ignored if
> the Python development team grants a special exemption for the module.
> Typically the exemption will be granted only when a module wraps a
> specific C-based library (e.g., sqlite3_). In granting an exemption it
> will be recognized that the module will be considered exclusive to
> CPython and not part of Python's standard library that other VMs are
> expected to support. Usage of ``ctypes`` to provide an
> API for a C library will continue to be frowned upon as ``ctypes``
> lacks compiler guarantees that C code typically relies upon to prevent
> certain errors from occurring (e.g., API changes).
>
> Even though a pure Python implementation is mandated by this PEP, it
> does not preclude the use of a companion acceleration module. If an
> acceleration module is provided it is to be named the same as the
>

Re: [Python-Dev] Latest draft of PEP 399 (Pure Python/C Accelerator Module Compatibility Requirements)

2011-08-14 Thread Benjamin Peterson 
2011/8/14 Brett Cannon :
>> proper `PyList_Check()` is used, but otherwise APIs should work with

To be terribly nitty, what is probably wanted to is PyList_CheckExact.



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