I was the guy at the back taking pictures. I also took notes! :)
Language Summit --------------- Intros ~~~~~~ Everyone starts by doing a 15 second intro. People are good and keep it short, and we make it through all ~40 people. People start introduce themselves saying "module X is my fault". Guido just says, "It's my fault." Release Management ~~~~~~~~~~~~~~~~~~ Larry Hastings talks about release versioning! How to use branches for the 3.5 RC process. When RCs start, should default be locked down, should it become 3.5.1, or should it become 3.6? Or something else? After a bit of discussion, people asked to move the decision to email. PyPy ~~~~ PyPy update: 7 iterations of stm! (compared to "The JIT took 5?") STM is 25-50% slower on a single-threaded workload, but shows nearly linear speedups with more cores on non-conflicting workloads. Brett Cannon: "So it's only HOW much faster than CPython?" It's not sure if there will be multiple PyPy releases or everyone takes the hit and STM is default. STM fundraiser II is active now. PyPy oving to 2.7.6 stdlib soon. A bunch of effort has gone to supporting CFFI porting in the community which aids porting of packages to PyPy. Something about Python 3 support that I didn't quite catch. Alex Gaynor says that most people who look to PyPy are looking for Python 2 right now. IronPython ~~~~~~~~~~ IronPython is active again! New contributors! Python 3 support! What can the PSF do to help IronPython? IronPython should ask for support if it would help. Jython ~~~~~~ Nobody from the team was present, but they sent a report which Michael Foord talked through with the group. Jython moving to Java 7 minimum runtime. Added buffer protocol (memoryview etc), required for Python 3 support. PyPA tooling? CFFI backend is coming! EuroPython sprint in July. Looking forward to Python 3 because of string types vs JVM. But it's slow (work?). Packaging ~~~~~~~~~ pip will suddenly need to become more user-friendly, now that it's bundled with 3.4. Instead of being used by people who need it, it's going to be presented to people who don't know what it is. Nick Coghlan: "PyPI's security model: it didn't have one." Richard Jones says the new PyPI code is nearly ready. It has some rough bits (OAuth, OpenID) but they're rough anyway. Replacing old crufty code with nice code; then moving forward with shiny new features. Oh, and wheels! Want to be at the point where Windows and OSX users can download the binary distro from python.org, and ``pip install django`` and have it work. Numpy is apparently still a sore point; conda would still be a better way for most people. Largely two kinds of packages: those that are self-contained (may include c-extensions though), and those that depend on system libraries (e.g. link to libmysql). Packaging has to make both of those work, and if it's made easier to make distro packages (i.e. RedHat packages, Debian packages, etc), it should be easier to build conda packages. Nick doesn't want to cross the line where python packaging (PyPI) does the distro side of things. Currently, "we do c extensions, but not linking to C libraries". Also, "metadata 2" has been put off by ~12 months, but is becoming the last thing standing before dropping setup.py and having wheels for all? Bits of metdata 2 have been pushed out as extensions or "decide later" bits, which has been instructive in terms of "how far can we get". Build chain in stdlib: bad idea, release schedules are different. Need a build system that supports all the verisons in the wild. Setuptools is now version-independent distutils. Oh, and Apple screwed up python, building it with a compiler that's not in xcode. ``pkg_resources`` has a dependency on ``setuptools`` which is WRONG, needs to be the other way around. But ``pkg_resources`` does what it does very well. Technically pip itself doesn't ship with 3.4, but rather ensurepip. This is so that new versions of pip can be brought in in point releases, and for security updates. Windows and OSX installers run ensurepip. ``virtualenv`` installs pip by default at this point, too. Someone asks, "Can we do that for SSL?" Everyone laughs. Disussion about packaging continues. Glyph asks if the PSF could fund a usability study on installing Python. People generally seem to think it's a good idea. Go to `packaging.python.org <http://packaging.python.org/en/latest/>`__! Documentation! Quite a few sections are already filled in: please contribute! There is no "one installer" that has everything you need for 2.7 right now. Nick: "C development is stupidly complicated." Nature of the old guard of Python programmers: you were already a C developer, and just wanted Python to help make some things easier. Nick got into Python for DSP testing. The demographics have changed. How do we change the docs and ecosystem to avoid the assumption that Python programmers already know how to program in C? "We have the wrong people maintaining the docs." "A distro is a pre-packaged group of binaries." Linux distros do it for Linux; On OSX you have macports, fink, and homebrew (OSX isn't itself a distro, except that it is because they do ship with *some* libraries, which are often broken); and on Windows there's Enthought, Activestate, and cygwin. Need SEO to get Windows users searching for "installers" to find "packages". Want to turn PyPI into "write metadata, upload source, PyPI does the rest", i.e. building c-extensions. Compiling c-extensions is particularly painful on Windows becuase Python 2.7 is build with Visual Studio 2008. OSX has similar issues where the system Python isn't compiled with what's in XCode. Ways to get the python.org Python packages to include the required bits: 2.7 is missing pip, 3.4 ships with it. If you want a GUI…then maybe you should just get Enthought or ActiveState? Python(x,y) is another option on Windows. Lunch ~~~~~ There was food! Pyston ~~~~~~ Pyston: Python on LLVM, coming out of Dropbox. Rebuilding a complete VM targetted for Python. Pro: optimize for Python, most custom you can get. Drawback: most work you can do. A different kind of JIT from PyPy: method-at-a-time. "Directly" from Python to machine code. Generate a fastpath for the types that you're seeing to avoid dynamic overheads. `speed.pypy.org <speed.pypy.org>`__ and `speed.python.org <speed.python.org>`__: suggested for pyston to help move it along. Benchmarks aren't just to show how good you are, they're a guide to where you can improve. Unladen Swallow did great work compiling a list of less synthetic benchmarks. Pyston memory usage is higher (includes jit etc), object size is smaller (inferred slots), function calls are bigger (than CPython). There's an LLVM IR interpreter for pre-JIT execution. Looking to add a "quick, IR to machine code" skipping the expensive bits. [Taavi: sounds like Firefox's `collection of OdinMonkey, IonMonkey, etc <https://blog.mozilla.org/javascript/2014/01/23/the-monkeys-in-2013/>`__, where JS is JITted very quickly to not-particularly-efficient machine code, and re-JITted more expensively as the hot codepaths are found.] Optional static type checking ----------------------------- Presentation by Jukka Lehtosalo on Mypy's static type checking, making use of type annotations in Python 3: - Faster than unit tests - Compatible with existing VMs (no runtime checks, just compilation checks; errors are warnings at runtime) - Documentation - Tools (IDEs) - Mypy: import typing; then you get static type checks! All valid programs, using Python 3 type annotations. - Can always fall back: from typing import Dict, Any; d = Dict[str, Any]; d[x] = 'y'; d[x] += 2 - `www.mypy-lang.org <http://www.mypy-lang.org>`__ - See also `https://github.com/google/pytypedecl <www.mypy-lang.org>`__ Michael Foord: mock and autospec; having function return annotations would be nice so an autospec'd mock can return more autospec'd mocks PEP8 said "don't use annotations", but that was only intended for stdlib (so that people were free to play with annotations in their own code). It was said that stdlib ought to be a good example of how to write Python code. But it isn't (right now, at least). Education --------- No docs on python.org for teachers (links). Mostly just "teach yourself" tutorials. Want things more like lesson plans. Having a new doc section for "absolute beginners" (Jessica McKellar volunteers to write it!) would be helpful; beginners often download the other python (2/3) from the tutorial they're trying to do. AP exams are starting to allow Python, but it's 10% of the AP CS exams. Jessica's working on making it Real. People on the APCS board already want it, just need the numbers to show that it's the right choice to teach to students. "The packaging and install programs, oh god." New users are good at contributing to docs. StackOverflow gets refd'd in bug tickets "see this StackOverflow post for why this is a problem/confusing". Selena Deckelmann talked about having a list of mitigations for teachers to help students using Windows and OSX. Lots of non-obvious "gotchas". Lots of outreach things. Women In Tech Linux kernel thing received 144 patches before selecting anyone (because applicants had to submit a patch to apply in the first place), and ended up adding an extra 1-2 people beyhond their planned 7 acceptees. Read the docs website! "Write the docs" conference! Yay! Learning to use the tooling currently required for contribution is a high bar. Being able to submit doc changes without a pull request might help. `bugs.python.org <http://bugs.python.org>`__: Selena filed one for a doc bug. But there is no "docs" type tag. Is a dead (404) link an "enhancement"? "Bug"? Should github issues be used for python.org website bugs? We have too many bug trackers? One for bugs.pycon.org, for pypi, for website, and a bugtracker for the bugtracker… Richard Jones is no longer working on Roundup, and reduced pypi from 3 bug trackers to 2?!? Too many places to report problems, and it's not clear how to even find them all. Terminology and vocabulary: if there are no words that seem to have anything to do with their problem, new bug sumitters will walk away. Being able to report a doc bug without specifying a type (because they're more worried about using the wrong type) might help. Jessica suggesting ("OPW"s: outreach programmes?) to talk about how to fill the pipeline. India and UK have re-done syllabi to include programming. India has put Python in explicitly, but there's pushback from parents and teachers because they don't know what this "strange language" is. In the UK, there's no language mandate, but children 7 and over are to be taught programming. The biggest problem is that the teachers are used to teaching spreadsheets and word processing, not programming. Raspberry PIs are common, £25 version includes minecraft. Kids usually start with Scratch and move to Python. Selena says that some American parents are worried because they don't know if their kids could get jobs [Taavi: loud surprise from audience]. Our industry knows the demand, but apparently it's not "common knowledge". Bringing parents and kids together in workshops, meeting people who have tech jobs and businesspeople who want to hire for tech jobs could help educate parents who don't realise there really are jobs… Pain points; why Mercurial isn't on Python 3 -------------------------------------------- Currently supports 2.4, 2.5, 2.6, 2.7. 2.4 sucks, but there's nothing much extra in 2.5 to make dropping 2.4 worth it. Mercurial will stop supporting 2.7 when RHEL7 is end-of-life. "We'll all be dead, I'll be on a differnet project." -- Matt Mackall Mercurial is bytestrings everywhere (intentionally), which isn't nearly as nice in Python 3 at this time. Most important benchmark: startup time. "hello world" in 2.7: 0.017s. In 3.4, 0.043s. git is 10x faster (Perl. Or bash.). Estimate of 1 person full time for 1.5 years to get mercurial running on Python 3, at half the speed of Python 2. It's not a pressing issue for anyone (that Matt knows of). People ask about Python 3 support once every few months. Matt's asking for 2.8. "I want a path forward that's not end-of-life." Looking for new features, bugfixes? Guido: "We can keep 2.7 alive for longer. … It's reasonable. 2.8 is [a can of worms]." 3/4 of pypi downloads are for 2.7 (biased sample, but of millions a month) Glyph: 2.8 would give an opportunity to be more aggressive, e.g. raise warnings on implicit string coercion. Guido disagrees (people will stay away from loud warnings that break their code). Nick: there are missing warnings for "-3", but they could be added in 2.7. Guido: What's going to be in 2.8? Tres: All the backports from pypi. Guido: Can we prevent people from adding new features along with the backports? The biggest difference for 2 =< 3 is str/bytes. Guido: There is not going to be a 2.8. Another good reason for a 2.8: Windows. 2.7 on Windows is compiled with Visual Studio 2008, and changing compiler is (apparently) a real problem. The total amount of churn any 2.8 release would cause is too much. (packaging, porting, etc) Even if it's a no-op from 2.7.6 to 2.8.0. 3.5 --- Kevin Modzelewski: Don't do 3.5, call it 4.0, then you can tell 2.x people they're TWO major versions behind! :) Guido: Can we get the PSF to issue a press release that 2.7 support will continue? (Matt wants to know that support is not ending.) Bring up a list of things that would be useful in a 2.8, so we can see what to do in 3.5. Glyph might start the list. Someone should also look through existing PEPs, because stuff might already be done. Guido asked about 2.4ish =< 2.7-single-source. "modernize" was mentioned, but it's abandoned. [Taavi: modernize and one other library were mentioned at the Python 3 panel discussion at the Montréal Python meetup on April 14th. Video will probably show up `on YouTube <https://www.youtube.com/user/MontrealPython/playlists>`__ as MP-45 in a few weeks?] Talk of the PSF paying experienced contractors to do certain bits of work. OpenStack is looking to do single-source Python 2/3. Other helpful things: instead of saying "print: invalid syntax", say something like "you need parentheses in Python 3". Adding AI to error messaging so that it can provide helpful messages would be great! Tooling to help port 2.x to 2.7+3-single-source would be great. Action items ------------ - Update pep to declare that 2.7 is not dead, and getting new maintenance updates. - Glyph will tell us what to do in 3.5. -- taa /*eof*/
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
