[Python-Dev] Language Summit notes

Senthil Kumaran senthil at uthcode.com
Thu Apr 10 04:30:56 CEST 2014


Here are my notes that I jotted down from the back row. Forgive me for any
mistakes. (As I shared in the intro, I am trying to get back and keep up.
:))


Python Release Process:
  * Larry Hastings goes for vote for shortend release process. But Guido
does not seem to be excited about it.
     Would go for go for email based voting.

 PyPy:
   * Alex Gaynor mentioned about the 7th iteration of STM - Software
Transactional Memory that is being worked on.
   * PyPy is targetting go from 2.7.3 to 2.7.6  and Brett teases about STM
enabled CPython interpreter?

 Iron Python:
   * Dino gave an updated on IronPython, 2.7.5 is under development, 3.x is
under development (/will be under development soon)
   * Contributions from community has grown recently. MaL encouraged them
to submit for a funding proposal.

  Jython:
  * Support for Buffer Protocol, For Python 3 support. cffi backend for
Python is coming up.

  Discussion about splitting the standard library:
   * IronPython, Pypy say that it is not a priority request for them.

 Packaging:
   * Nick Coghlan shares his experience on how difficult is get the packing
right. Every agrees and kind of recognize that recent efforts are in the
right direction. Mentioned about https://pypi-preview.a.ssl.fastly.net/ and
wheels packaging format.
   * Well maintained docs at http://packaging.python.org/en/latest/ -
Python packaging user guide.
   * The focus/goal is not get new users easy to understand python
ecosystem and use python packages.

Pyston:
  * Kevin shared his ideas and updates on Pyston. Folks suggested about
using the speed.pypy.org benchmarks to measure the effort.

 MyPy:
  * The optional static typing using functional annotations demonstrated by
MyPy interested a number of developers.  Few felt that it would be a nice
to have feature in Python 3.5 It basically means identify what's lacking in
current function annotations and work on enhancing it.
  * Thomos Wouters suggested to Larry Hastings that Argument clinic could
be enhanced to support such a feature.
  * Interested parties should get together on a python type checking
mailing list.

 Features we care about 3.5:
   ☐ bytes formatting redux
   ☐ Binary mode cleanup
   ☐ Type Annotations.
   ☐ Improved tooling AI based tooling to convert 2.x code to 3.x and
provide better error messages. (Sounds exciting!)




On Wed, Apr 9, 2014 at 9:08 PM, Guido van Rossum <guido at python.org> wrote:

> To anyone who took notes at the language summit at PyCon today, even if
> you took them just for yourself, would you mind posting them here? It would
> be good to have some kind of (informal!) as soon as possible, before we
> collectively forget. You won't be held responsible for correctness.
>
> Here are some of my own recollections (I didn't take notes but I have a
> decent memory):
>
> - Packaging sucks, but we're improving, and we're actually doing better
> than other dynamic languages.
>
> - Kevin Modzelewski answered questions about Pyston, a new (very early
> stage) Python VM based on the new LLVM JIT engine (which is much different
> from what defeated Unladen Swallow). Alex Gaynor seemed unconcerned. :-)
>
> - Jukka Lehtosalo gave a talk and answered questions about mypy, his
> design and implementation of pragmatic type annotations (no new syntax
> required, uses Python 3 function annotations). See mypy-lang.org. In
> response, Greg P Smith pointed people to a similar project from Google,
> https://github.com/google/pytypedecl, which has annotations in a separate
> file (hence amenable to Python 2). Larry Hastings brought up that Argument
> Clinic (a new way of specifying signatures for C extensions), released as
> part of 3.4) encodes similar information in the docstring of C functions.
>
> - Maybe this is should be the year when we start getting agreement on a
> standard use of function annotations to specify argument and return types,
> now that we seem to have a somewhat critical mass of experience with
> annotations.
>
> - We should make an effort to publicize that we're NOT sunsetting Python
> 2.7 just yet; support will continue (hopefully with ample support from
> distro vendors), and someone should update PEP 373. (Unclear what the new
> EOL is but we should definitely rescind the currently published schedule.)
>
> - We (I) still don't want to do a 2.8 release, and I don't want to
> accelerate 3.5, but I do think we should make things better for people who
> have to straddle Python 2 and 3 in a single codebase, by developing more
> tools, and by security and possibly installer updates to 2.7 (PEP 466).
>
> - Some suggestions that were made: PSF financial support for tool
> development and/or porting, add more "-3" warnings to a future Python 2.7
> release, additional 2to3 fixers to help convert Python-2-only code to
> Python-2-and-3-single-source code, a separate linter, a sumo 2.7
> distribution that includes all known backported-from-Python-3-stdlib
> packages, adding ensure_pip to the 2.7.7 stdlib, and several more I forgot.
> IIRC Glyph and Alex Gaynor are going to compile a list of pain points for
> people. (I can't honestly say that I convinced Glyph and Alex and a few
> others not to pine for 2.8, but I also honestly don't believe it will have
> the effect that they expect. Nor do I believe any new feature we add to 3.5
> can serve as a big enough carrot.)
>
> - The recommended and least painful way to develop for Python 2 and 3 is
> definitely to use a single source that runs under both without translation;
> we no longer recommend auto-generating Python 3 compatible source code
> using 2to3, for a variety of reasons. Several people attested that
> single-source has worked well for them; Mercurial is using the 2to3
> approach but they're not too happy with it.
>
> - An argument for releasing something labeled 2.8 was made based on the
> unavailability (current or future?) of Visual Studio 2008; the
> uncomfortable alternative would be to switch to a newer compiler at some
> 2.7.x bugfix release, which would break extension modules compiled with for
> 2.7.0-2.7.6, and that would confuse and upset people.
>
> - Apparently no restaurant in downtown Montreal takes reservations for a
> group of 30 people to show up in one hour.
>
> --
> --Guido van Rossum (python.org/~guido)
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/senthil%40uthcode.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140409/1f947102/attachment-0001.html>


More information about the Python-Dev mailing list