PyCon, and the Python Language Summit, is nearly upon us. We have a good number of people confirmed to attend. If you are intending to come to the language summit but haven't let me know please do so.
The agenda of topics for discussion so far includes the following:
* A report on pypy status - Maciej and Armin
* Jython and IronPython status reports - Dino / Frank
* Packaging (Doug Hellmann and Monty Taylor at least)
* Cleaning up interpreter initialisation (both in hopes of finding areas
to rationalise and hence speed things up, as well as making things
more embedding friendly). Nick Coghlan
* Adding new async capabilities to the standard library (Guido)
* cffi and the standard library - Maciej
* flufl.enum and the standard library - Barry Warsaw
* The argument clinic - Larry Hastings
If you have other items you'd like to discuss please let me know and I can add them to the agenda.
All the best,
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing
On Thu, Feb 28, 2013 at 1:30 AM, Antoine Pitrou <solipsis(a)pitrou.net> wrote:
> Le Wed, 27 Feb 2013 11:33:30 -0800,
> "fwierzbicki(a)gmail.com" <fwierzbicki(a)gmail.com> a écrit :
>> There are a couple of spots that might be more controversial. For
>> example, Jython has a file Lib/zlib.py that implements zlib in terms
>> of the existing Java support for zlib. I do wonder if such a file is
>> acceptable in CPython's Lib since its 195 lines of code would be
>> entirely skipped by CPython.
> That's a bit annoying. How will we know that the code still works, even
> though our buildbots don't exercise it?
> Also, what happens if the code doesn't work anymore?
Agreed on those problems. Would it be possible to use a design
pattern in these cases so the Jython-only code wouldn't need to be
part of the CPython repo? A naive example would be refactoring zlib
to allow subclassing in the way that Jython needs, and then Jython
could subclass in its own repo. CPython could have tests to check the
subclass "contract" that Jython needs.
I know this is a hard topic, but python-dev is already incredibly
high-volume and dragging discussion off-topic is making following
important stuff (while ignoring unimportant stuff) very hard.
For example in a recent topic "cffi in stdlib" I find a mail that says
"we have to find a sufficiently silly species of snake". It's even
funny, but it definitely makes it very hard to follow for those of us
who don't read python-dev 24/7. Would it be reasonable for python-dev
to generally try to stay on topic (for example if the thread is called
"silly species of snakes", I absolutely don't mind people posting
there whatever they feel like as long as I'm not expected to read
every single message).
Following up on a conversation on python-dev from last December:
I'm pleased to announced PEP 436, proposing Argument Clinic for adoption
into the CPython source tree.
Argument Clinic itself hasn't changed much in the intervening three
months; I did add a prototype extension mechanism for adding user types
at runtime, and I allow writing the generated code to a separate file.
The PEP is adopted out of the "clinic.txt" included with the prototype,
updated and with a new rationale.
For what it's worth, the bug tracker issue is here:
I'm guessing python-dev is the right place for the ten-thousand-foot
view topics: the merits of the specific proposed DSL syntax, the
possible runtime extension API, and the approach as a whole. So for now
let's just use the bug tracker issue for code reviews and the like.
The prototype implementation is checked in here:
as well as being posted to the above issue on the tracker in patch form.
I look forward to your comments,
Open archives. As the header says this is for the discussion of CLA/other issues. If specific legal questions or alterations to Python/the PSF trademarks, CLA/etc are requested those *must* be sent to psf(a)python.org for board oversight and approval. This is an open discussion list, and is not official legal stance of the foundation, trademarks, etc.
eli.bendersky <python-checkins(a)python.org> wrote:
> +Ordered comparisons between enumeration values are *not* supported. Enums are
> +not integers!
Hmm. I think this limits interoperation with C libraries and prototyping
Actually all I want from a Python enum is to be like a C enum with symbolic
representations for the values.
On Feb 25, 2013, at 05:40 PM, brett.cannon wrote:
>user: Brett Cannon <brett(a)python.org>
>date: Mon Feb 25 11:39:56 2013 -0500
> Add PEP 445: The Argument Clinic DSL
I beat you with PEP 436. :)
I downloaded Python 3.3 source, opened up the solution in VS2012 Express for Desktop and built the "python" subproject using "Release" and "x64" configurations. I now have a "python.exe" in the PCBuild/amd64 subfolder that appears to be working as far as i can see.
I have a few questions:
a) Is there a test suite that I can run to verify that the build is working fine?
b) I now intend to build some extensions (such as NumPy). Not sure if this is the right list, but would I need to modify something in distutils to get it working with VS2012?