Re: [Python-Dev] death to 2.7; long live 2.7

2014-04-10 Thread Antoine Pitrou 

Le 10/04/2014 04:09, Senthil Kumaran a écrit :


On Wed, Apr 9, 2014 at 10:02 PM, Benjamin Peterson mailto:[email protected]>> wrote:

I consider the security enhancement/feature question to be in the domain
of PEP 466. If security stuff lands in the 2.7 branch, it will get
released eventually is all I'm saying.


Thanks for the response.


Instead dealing 2.7 will just be completely optional for coredevelopers


I was worried about this part, that if bug-fixes are
optionally back-ported, then we may end up a inconsistent, undesirable
state.


They already are. There are routinely things I (and other developers) 
don't consider for inclusion in 2.x.


Regards

Antoine.


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

Re: [Python-Dev] death to 2.7; long live 2.7

2014-04-10 Thread Christian Heimes 
On 10.04.2014 04:16, Guido van Rossum wrote:
> Yeah, this was mentioned a few times. I quipped to Nick that Red Hat's
> biggest contribution might be to take over the Windows Installer, but
> didn't bite. :-)
> 
> But there's always the PSF. We may try to find some folks we trust with
> relevant expertise to volunteer their time in return for a stipend from
> the PSF.

The Python core dev team has a couple of people that have the necessary
experience and tools to create Windows installers. Martin has done an
great job in automating the build process, too. AFAIK the new person in
charge for Windows 2.7 builds just need the certificate to sign the
installer.

Christian

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

Re: [Python-Dev] A Friendly IDLE

2014-04-10 Thread Tal Einat 
On Thu, Apr 10, 2014 at 12:42 AM, Terry Reedy  wrote:
> On 4/9/2014 12:25 AM, [email protected] wrote:

> Python-list, python-ideas, or idle-dev lists might have been better places to 
> put this, but here are my responses.

I'm adding idle-dev, where this belongs. Further discussion should
take place there rather than on python-dev.

>>  3.
>> In Python Shell Save & Save As menus are enable and using them we
>> can save shell text as python script (.py) that never executes again
>> on IDLE. I recommends to either disable this option or save shell
>> text as plain text. I made a little try to disable this and succeed.
>
>
> We will not disable being able to save the shell window.
> http://bugs.python.org/issue11838 is about saving in runnable form.

If IDLE saves the shell history to a file with a .py extension by
default, that is indeed confusing. It is useful to be able to save the
history to a file, but it shouldn't have a .py extension.

- Tal Einat
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] death to 2.7; long live 2.7

2014-04-10 Thread Paul Moore 
On 10 April 2014 02:58, Benjamin Peterson  wrote:
>> What will a lack of provided installers do to Windows support? It's
>> easy enough on Linux to say "either build it from source, or let your
>> upstream package provider build it for you", but AIUI, most Windows
>> users want to get a ready-made binary.
>
> It's not that I don't think Windows installers are important, but rather
> that Martin has indicated he is (completely reasonably) not interested
> in indefinitely making 2.7 installers.

I would assume that ActiveState, Enthought and Anaconda are the people
we should be expecting to provide Windows binaries once the core team
stop doing so. In all honesty, if none of those 3 companies can see a
business case for providing 2.7.x binaries for Windows, then that
demonstrates pretty effectively that doing so isn't worth the effort.

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

Re: [Python-Dev] Language Summit notes

2014-04-10 Thread Kushal Das 
On Thu, Apr 10, 2014 at 6:38 AM, Guido van Rossum  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.
>

The day started with introductions. Guido introduced himself as its
all his fault.

Release management discussion
==

Larry Hastings started the day with discussion on 3.5 release. 3.4
release was actually in 16 months. He wanted a
feedback on the next release, if we want it in a smaller release cycle
than the usual 18 months. Guido mentioned to
stay with the 18 month cycle.

Larry also asked about opinions on state of the SCM after release
candidate 1, should we create 3.5 branch and if yes
then should we allow people to commit there or not? Default should
point to 3.5.1 or 3.6 at that time? There can be another
scenario where we do not create the 3.5 branch and keep the default as
3.5 release itself. The discussion will continue
in the mailing list.

Next topic in the agenda was reports from different implementations.

PyPy
=

Alex Gaynor gave us the current status of `PyPy `_
project. There will be a second fund raiser on STM.
The next release is targeting 2.7.6, there were a million downloads.
While discussing about Python 3 branch he explained
that it it only 3 bugs away from shipping and it is based on 3.2.


There was a small discussion about state of CFFI for standard library
inclusion. Alex and David Beazley are supposed to
work on cleaning PLY for the same. General opinion was that it will be
hidden as a private part of the standard lib and to
be used by the language only.

Ironpython
===

Dino Viehland talked about the status of `Ironpython
`_ project. Development is going on both 2.7
and 3.x
series. 2.7.4 was released last year. Many new contributors came into
the project which is a good news.

Jython
===

The developers sent a detailed report to Micheal Foord and he will
forward it to the python-dev list. The takeaways from the mail are

* Small number of contributors is a big problem.
* 2.7.beta2 is tagged which used Java7.
* Buffer protocol work is done (foundation to Python3 support).
* They are also working on PyPi tooling.
* There is also hope for releasing CFFI backend for Jython during
Europycon sprints.


No standard library as module
==

When it was asked that if the other implementations want the standard
library as a separate module to be resused, all agreed as 'No'.

Packaging
===

It was the longest discussion which made hungry developers really
hungry :) Jokes aside, Nick Coghlan gave a detailed report on the
advancement of the packaging world. Most of the development/design
discussions are now happening on the distutils sig and in pypi mailing
lists.
He managed to put the use cases a very broader audience now, so we can
except better feedbacks. On the development side, Warehouse is now
implementing all old API(s), you may want to try it out at
`https://warehouse.python.org/ `_.

3.4 has pip included, one usecase was to help people who downloads
binary installers from our site. They can now install Django or other
projects
in wheel format.

Everyone also agreed that having the buildsystem inside the language
is a bad idea. The buildsystem should be able to do cross-version
builds.

Nick also pointed us to `http://packaging.python.org/
`_ which is the documentation
for the whole echosystem.  We all agreed that the Python echosystem is
bigger than the core interpreter.

Glyph wants a PSF fund to a usability study on Python. There were a
few other suggestion on PSF support for tooling development.

Pyston
===

Kevin Modzelewski explained how they are rebuilding a complete vm
which is targeted to Python, this also means too much work but one can
customize. It is targeting Python2.7 as Dropbox runs on it.


At this time of discussion Nick pointed us to
`http://speed.python.org/ `_, he asked if
any of the implementations
wants to maintain it. We need more volunteers for that, target is to
have a common set of tests to benchmark different implementations.

Mypy project
=

Jukka Lehtosalo gave a talk on his `mypy project
`_ which uses Python3 function annotations. Greg
P Smith pointed us to
a similar kind of Google project,
`https://github.com/google/pytypedecl
`_.

Notes from teaching and outreach
=

Selena Deckelmann talked about few pain points from teaching and outreach.

* Website is confusing. (Should I go for Python2 or Python3?)
* Packaging and installer problem
* So many different bug tracking system is also c

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

2014-04-10 Thread Björn Lindqvist 
2014-04-09 17:37 GMT+02:00 Nathaniel Smith :
> On Wed, Apr 9, 2014 at 4:25 PM, Björn Lindqvist  wrote:
>> 2014-04-08 14:52 GMT+02:00 Nathaniel Smith :
>>> On Tue, Apr 8, 2014 at 9:58 AM, Björn Lindqvist  wrote:
 2014-04-07 3:41 GMT+02:00 Nathaniel Smith :
> So, I guess as far as I'm concerned, this is ready to go. Feedback 
> welcome:
>   http://legacy.python.org/dev/peps/pep-0465/

 Couldn't you please have made your motivation example actually runnable?

 import numpy as np
 from numpy.linalg import inv, solve

 # Using dot function:
 S = np.dot((np.dot(H, beta) - r).T,
np.dot(inv(np.dot(np.dot(H, V), H.T)), np.dot(H, beta) - r))

 # Using dot method:
 S = (H.dot(beta) - r).T.dot(inv(H.dot(V).dot(H.T))).dot(H.dot(beta) - r)

 Don't keep your reader hanging! Tell us what the magical variables H,
 beta, r and V are. And why import solve when you aren't using it?
 Curious readers that aren't very good at matrix math, like me, should
 still be able to follow your logic. Even if it is just random data,
 it's better than nothing!
>>>
>>> There's a footnote that explains the math in more detail and links to
>>> the real code this was adapted from. And solve is used further down in
>>> the section. But running it is really what you want, just insert:
>>>
>>> beta = np.random.randn(10)
>>> H = np.random.randn(2, 10)
>>> r = np.random.randn(2)
>>> V = np.random.randn(10, 10)
>>>
>>> Does that help? ;-)
>>
>> Thanks! Yes it does help. Then I can see that this expression:
>>
>>   np.dot(H, beta) - r
>>
>> Evaluates to a vector. And a vector transposed is the vector itself.
>> So the .T part in this expression np.dot(H, beta) - r).T is
>> unnecessary, isn't it?
>
> In univariate regressions r and beta are vectors, and the .T is a
> no-op. The formula also works for multivariate regression, in which
> case r and beta become matrices; in this case the .T becomes
> necessary.

Then what is the shape of those variables supposed to be? The earlier
definitions you gave isn't enough for this general case.


-- 
mvh/best regards Björn Lindqvist
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit notes

2014-04-10 Thread A.M. Kuchling 
On Wed, Apr 09, 2014 at 09:08:04PM -0400, Guido van Rossum 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.

>From a 30-second check, the recordings I made on my laptop are
listenable (though the audio levels in the morning were too low).  We
probably don't want to post them publicly, just because they haven't
been listened to.  I provided them to Kushal Das, who was taking
notes; if other attendees want them for reference, please let me know.

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

[Python-Dev] Windows installers and OpenSSL

2014-04-10 Thread Paul Moore 
Given the OpenSSL vulnerability and the fact that we bundle OpenSSL
with the Windows installers (1.0.1e in Python 3.4.0) should we be
releasing updated installers?

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

Re: [Python-Dev] Language Summit notes

2014-04-10 Thread Antoine Pitrou 

Le 10/04/2014 13:24, Kushal Das a écrit :


At this time of discussion Nick pointed us to
`http://speed.python.org/ `_, he asked if
any of the implementations
wants to maintain it. We need more volunteers for that, target is to
have a common set of tests to benchmark different implementations.


I feel a bit tired to point out that there *is* a common set of 
cross-implementation benchmarks at http://hg.python.org/benchmarks


It is maintained and there is also a mailing-list to discuss it at 
https://mail.python.org/mailman/listinfo/speed


Regards

Antoine.


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

Re: [Python-Dev] Language Summit notes

2014-04-10 Thread Guido van Rossum 
Maybe we don't need a volunteer to maintain it, but we sure need a
volunteer to coordinate and spread the knowledge! :-)


On Thu, Apr 10, 2014 at 10:20 AM, Antoine Pitrou wrote:

> Le 10/04/2014 13:24, Kushal Das a écrit :
>
>
>> At this time of discussion Nick pointed us to
>> `http://speed.python.org/ `_, he asked if
>> any of the implementations
>> wants to maintain it. We need more volunteers for that, target is to
>> have a common set of tests to benchmark different implementations.
>>
>
> I feel a bit tired to point out that there *is* a common set of
> cross-implementation benchmarks at http://hg.python.org/benchmarks
>
> It is maintained and there is also a mailing-list to discuss it at
> https://mail.python.org/mailman/listinfo/speed
>
> Regards
>
> Antoine.
>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Windows installers and OpenSSL

2014-04-10 Thread MRAB 

On 2014-04-10 14:41, Paul Moore wrote:

Given the OpenSSL vulnerability and the fact that we bundle OpenSSL
with the Windows installers (1.0.1e in Python 3.4.0) should we be
releasing updated installers?


I'd say yes, but, then, I wouldn't be doing any of the work...
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit notes

2014-04-10 Thread Kushal Das 
On Thu, Apr 10, 2014 at 7:50 PM, Antoine Pitrou  wrote:
>
>
> I feel a bit tired to point out that there *is* a common set of
> cross-implementation benchmarks at http://hg.python.org/benchmarks
>
> It is maintained and there is also a mailing-list to discuss it at
> https://mail.python.org/mailman/listinfo/speed
>
I think I had the comma in the wrong place for that sentence.

Thanks for information, I am adding them in the blog post.

Kushal
-- 
http://fedoraproject.org
http://kushaldas.in
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit notes

2014-04-10 Thread Thomas Wouters 
On Thu, Apr 10, 2014 at 4:24 AM, Kushal Das  wrote:

> On Thu, Apr 10, 2014 at 6:38 AM, Guido van Rossum 
> 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.
> >
>
> The day started with introductions. Guido introduced himself as its
> all his fault.
>
> Release management discussion
> ==
>
> Larry Hastings started the day with discussion on 3.5 release. 3.4
> release was actually in 16 months. He wanted a
> feedback on the next release, if we want it in a smaller release cycle
> than the usual 18 months. Guido mentioned to
> stay with the 18 month cycle.
>
> Larry also asked about opinions on state of the SCM after release
> candidate 1, should we create 3.5 branch and if yes
> then should we allow people to commit there or not? Default should
> point to 3.5.1 or 3.6 at that time? There can be another
> scenario where we do not create the 3.5 branch and keep the default as
> 3.5 release itself. The discussion will continue
> in the mailing list.
>
> Next topic in the agenda was reports from different implementations.
>
> PyPy
> =
>
> Alex Gaynor gave us the current status of `PyPy `_
> project. There will be a second fund raiser on STM.
> The next release is targeting 2.7.6, there were a million downloads.
> While discussing about Python 3 branch he explained
> that it it only 3 bugs away from shipping and it is based on 3.2.
>
>
> There was a small discussion about state of CFFI for standard library
> inclusion. Alex and David Beazley are supposed to
> work on cleaning PLY for the same. General opinion was that it will be
> hidden as a private part of the standard lib and to
> be used by the language only.
>

No, the opinion was that it _shouldn't_ be hidden as a private part of the
standard library :) But some cleanup needs to happen before it can be added
to the stdlib.


>
> Ironpython
> ===
>
> Dino Viehland talked about the status of `Ironpython
> `_ project. Development is going on both 2.7
> and 3.x
> series. 2.7.4 was released last year. Many new contributors came into
> the project which is a good news.
>
> Jython
> ===
>
> The developers sent a detailed report to Micheal Foord and he will
> forward it to the python-dev list. The takeaways from the mail are
>
> * Small number of contributors is a big problem.
> * 2.7.beta2 is tagged which used Java7.
> * Buffer protocol work is done (foundation to Python3 support).
> * They are also working on PyPi tooling.
> * There is also hope for releasing CFFI backend for Jython during
> Europycon sprints.
>
>
> No standard library as module
> ==
>
> When it was asked that if the other implementations want the standard
> library as a separate module to be resused, all agreed as 'No'.
>

Their answer was mostly "don't care". It has some minor benefits, in
particular when they move to Python 3 and track active development more
closely, but no important ones.


>
> Packaging
> ===
>
> It was the longest discussion which made hungry developers really
> hungry :) Jokes aside, Nick Coghlan gave a detailed report on the
> advancement of the packaging world. Most of the development/design
> discussions are now happening on the distutils sig and in pypi mailing
> lists.
> He managed to put the use cases a very broader audience now, so we can
> except better feedbacks. On the development side, Warehouse is now
> implementing all old API(s), you may want to try it out at
> `https://warehouse.python.org/ `_.
>
> 3.4 has pip included, one usecase was to help people who downloads
> binary installers from our site. They can now install Django or other
> projects
> in wheel format.
>
> Everyone also agreed that having the buildsystem inside the language
> is a bad idea. The buildsystem should be able to do cross-version
> builds.
>
> Nick also pointed us to `http://packaging.python.org/
> `_ which is the documentation
> for the whole echosystem.  We all agreed that the Python echosystem is
> bigger than the core interpreter.
>
> Glyph wants a PSF fund to a usability study on Python. There were a
> few other suggestion on PSF support for tooling development.
>
> Pyston
> ===
>
> Kevin Modzelewski explained how they are rebuilding a complete vm
> which is targeted to Python, this also means too much work but one can
> customize. It is targeting Python2.7 as Dropbox runs on it.
>
>
> At this time of discussion Nick pointed us to
> `http://speed.python.org/ `_, he asked if
> any of the implementations
> wants to maintain it. We need more volunteers for that, target is to
> have a common set of tests

Re: [Python-Dev] Language Summit notes

2014-04-10 Thread Guido van Rossum 
On Thu, Apr 10, 2014 at 11:41 AM, Thomas Wouters  wrote:


> On Thu, Apr 10, 2014 at 4:24 AM, Kushal Das  wrote:
>


>  There was a small discussion about state of CFFI for standard library
>> inclusion. Alex and David Beazley are supposed to
>> work on cleaning PLY for the same. General opinion was that it will be
>> hidden as a private part of the standard lib and to
>> be used by the language only.
>>
>
> No, the opinion was that it _shouldn't_ be hidden as a private part of the
> standard library :) But some cleanup needs to happen before it can be added
> to the stdlib.
>

Huh, I totally missed this (and I just gave Kushal a confused answer when
he asked me about it in person). Can someone please post here what the plan
is exactly? I don't want to press for a PEP, but I would at least like to
understand the plan for CFFI and PLY before it is executed, since I have
never had to use either one, and it feels like each of these will require
some commitment to maintenance once they are in, in addition to cleanup
before they go in. And no, waving hands and saying "there's already a blog
post about CFFI somewhere" is not good enough. I want the full description
of the plan written up here in python-dev. Blog links might serve to
clarify the motivation though.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit notes

2014-04-10 Thread Eric Snow 
On Thu, Apr 10, 2014 at 12:58 PM, Guido van Rossum  wrote:
> On Thu, Apr 10, 2014 at 11:41 AM, Thomas Wouters  wrote:
>
>>
>> On Thu, Apr 10, 2014 at 4:24 AM, Kushal Das  wrote:
>
>
>>>
>>> There was a small discussion about state of CFFI for standard library
>>> inclusion. Alex and David Beazley are supposed to
>>> work on cleaning PLY for the same. General opinion was that it will be
>>> hidden as a private part of the standard lib and to
>>> be used by the language only.
>>
>>
>> No, the opinion was that it _shouldn't_ be hidden as a private part of the
>> standard library :) But some cleanup needs to happen before it can be added
>> to the stdlib.
>
>
> Huh, I totally missed this (and I just gave Kushal a confused answer when he
> asked me about it in person). Can someone please post here what the plan is
> exactly? I don't want to press for a PEP, but I would at least like to
> understand the plan for CFFI and PLY before it is executed, since I have
> never had to use either one, and it feels like each of these will require
> some commitment to maintenance once they are in, in addition to cleanup
> before they go in. And no, waving hands and saying "there's already a blog
> post about CFFI somewhere" is not good enough. I want the full description
> of the plan written up here in python-dev. Blog links might serve to clarify
> the motivation though.

The discussion happened leading up to the language summit in 2013.

ply: https://mail.python.org/pipermail/python-dev/2013-February/124389.html
pycparser: 
https://mail.python.org/pipermail/python-dev/2013-February/124341.html
(earlier part of same discussion)

My recollection was that we'd add a cleaned-up ply to the stdlib and
leave pycparser as a private implementation detail of cffi.

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

Re: [Python-Dev] Language Summit notes

2014-04-10 Thread Eli Bendersky 
On Thu, Apr 10, 2014 at 12:30 PM, Antoine Pitrou wrote:

> Le 10/04/2014 20:58, Guido van Rossum a écrit :
>
>
>> Huh, I totally missed this (and I just gave Kushal a confused answer
>> when he asked me about it in person). Can someone please post here what
>> the plan is exactly? I don't want to press for a PEP, but I would at
>> least like to understand the plan for CFFI and PLY before it is
>> executed, since I have never had to use either one, and it feels like
>> each of these will require some commitment to maintenance once they are
>> in, in addition to cleanup before they go in.
>>
>
> FWIW, I do hope there would be a PEP before including CFFI... Actually I
> don't understand what would justify an exemption


There's absolutely no reason to exempt CFFI, IMHO. On the contrary -- the
dependence on other 3rd party modules (PLY and pycparesr), and the related
dilemma of whether to expose each/both as stdlib modules or hide as
internal implementation details -- makes a PEP even more important here.

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

Re: [Python-Dev] Language Summit notes

2014-04-10 Thread Antoine Pitrou 

Le 10/04/2014 20:58, Guido van Rossum a écrit :


Huh, I totally missed this (and I just gave Kushal a confused answer
when he asked me about it in person). Can someone please post here what
the plan is exactly? I don't want to press for a PEP, but I would at
least like to understand the plan for CFFI and PLY before it is
executed, since I have never had to use either one, and it feels like
each of these will require some commitment to maintenance once they are
in, in addition to cleanup before they go in.


FWIW, I do hope there would be a PEP before including CFFI... Actually I 
don't understand what would justify an exemption.


Regards

Antoine.


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

Re: [Python-Dev] Language Summit notes

2014-04-10 Thread Guido van Rossum 
Well, I was going to put off requesting a PEP until I'd judged the plan,
but clearly (a) there isn't actually a plan (just some vague description of
an end result that some feel desirable) and (b) it's controversial. So,
yes, it definitely needs a PEP. Also, even though this came up a year ago,
nobody actually cared enough to write a PEP; which makes me think that
there are probably more than a few problems with the whole idea. (One of
which may be that while PLY is stable, it also sounds completely
unmaintainable; another may be that CFFI seems to require too much of a
development environment to be available to count as an alternative to
ctypes.)


On Thu, Apr 10, 2014 at 3:34 PM, Eli Bendersky  wrote:

> On Thu, Apr 10, 2014 at 12:30 PM, Antoine Pitrou wrote:
>
>> Le 10/04/2014 20:58, Guido van Rossum a écrit :
>>
>>
>>> Huh, I totally missed this (and I just gave Kushal a confused answer
>>> when he asked me about it in person). Can someone please post here what
>>> the plan is exactly? I don't want to press for a PEP, but I would at
>>> least like to understand the plan for CFFI and PLY before it is
>>> executed, since I have never had to use either one, and it feels like
>>> each of these will require some commitment to maintenance once they are
>>> in, in addition to cleanup before they go in.
>>>
>>
>> FWIW, I do hope there would be a PEP before including CFFI... Actually I
>> don't understand what would justify an exemption
>
>
> There's absolutely no reason to exempt CFFI, IMHO. On the contrary -- the
> dependence on other 3rd party modules (PLY and pycparesr), and the related
> dilemma of whether to expose each/both as stdlib modules or hide as
> internal implementation details -- makes a PEP even more important here.
>
> Eli
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit notes

2014-04-10 Thread Paul Moore 
On 10 April 2014 20:30, Antoine Pitrou  wrote:
> FWIW, I do hope there would be a PEP before including CFFI... Actually I
> don't understand what would justify an exemption.

I agree. I'd like to see a clear explanation of what advantages (and
disadvantages!) CFFI gives over ctypes, as well as the plan for
inclusion and how the inevitable confusion over whether to use ctypes
or cffi will be handled. The fact that cffi requires bringing in ply
and a vendored-but-not-public copy of pycparser, seems to imply to me
that there's a lot of cost and I'd like to understand the gains.
That's not to say that adding ply to the standard library mightn't be
worth it in its own right, but there are a lot of other parsers out
there, and I'd rather we blessed one as "best of breed" rather than
"because cffi uses it".

In particular, my understanding is that in order to get the key
benefits of cffi (API compatibility rather than ABI) you need to
include some sort of complex "generate and compile C" step in your
project's build. That implies that using cffi requires building
separate wheels for each Python version (as with any C extension) and
having a C compiler to do the build. There are a lot of projects that
I know of (particularly wrappers for Windows APIs like Colorama and
pyreadline) migrating to ctypes precisely because they get a pure
Python solution that doesn't need binary builds or version-dependent
distributions. Those projects won't presumably be migrating to cffi.
Also, a key area where ctypes is used seems to be the Windows API -
and there, ABI compatibility for Windows APIs is the norm so the
advantage of only needing API compatibility is minimal at best.

At the moment, I see no real reason to add cffi to the stdlib - it
certainly isn't an "obvious" decision to do so. This seems like clear
PEP territory.

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

Re: [Python-Dev] Language Summit notes

2014-04-10 Thread Ryan Gonzalez 
On Thu, Apr 10, 2014 at 3:12 PM, Paul Moore  wrote:

> On 10 April 2014 20:30, Antoine Pitrou  wrote:
> > FWIW, I do hope there would be a PEP before including CFFI... Actually I
> > don't understand what would justify an exemption.
>
> I agree. I'd like to see a clear explanation of what advantages (and
> disadvantages!) CFFI gives over ctypes, as well as the plan for
> inclusion and how the inevitable confusion over whether to use ctypes
> or cffi will be handled. The fact that cffi requires bringing in ply
> and a vendored-but-not-public copy of pycparser, seems to imply to me
> that there's a lot of cost and I'd like to understand the gains.
> That's not to say that adding ply to the standard library mightn't be
> worth it in its own right, but there are a lot of other parsers out
> there, and I'd rather we blessed one as "best of breed" rather than
> "because cffi uses it".
>
> In particular, my understanding is that in order to get the key
> benefits of cffi (API compatibility rather than ABI) you need to
> include some sort of complex "generate and compile C" step in your
> project's build. That implies that using cffi requires building
> separate wheels for each Python version (as with any C extension) and
> having a C compiler to do the build. There are a lot of projects that
> I know of (particularly wrappers for Windows APIs like Colorama and
> pyreadline) migrating to ctypes precisely because they get a pure
> Python solution that doesn't need binary builds or version-dependent
> distributions. Those projects won't presumably be migrating to cffi.
> Also, a key area where ctypes is used seems to be the Windows API -
> and there, ABI compatibility for Windows APIs is the norm so the
> advantage of only needing API compatibility is minimal at best.
>

Nope. CFFI supports both C-built extensions and ctypes-style shared library
loading. There are pure-Python bindings for modules that use CFFI and don't
require a C compiler(https://github.com/kirbyfan64/clamav-python).


> At the moment, I see no real reason to add cffi to the stdlib - it
> certainly isn't an "obvious" decision to do so. This seems like clear
> PEP territory.


It's somewhat faster but has a longer warm-up time. Useful if the same
module is going to be reused several times.


>
> Paul
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>



-- 
Ryan
If anybody ever asks me why I prefer C++ to C, my answer will be simple:
"It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
nul-terminated."
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit notes

2014-04-10 Thread Barry Warsaw 
On Apr 10, 2014, at 12:34 PM, Eli Bendersky wrote:

>There's absolutely no reason to exempt CFFI, IMHO. On the contrary -- the
>dependence on other 3rd party modules (PLY and pycparesr), and the related
>dilemma of whether to expose each/both as stdlib modules or hide as
>internal implementation details -- makes a PEP even more important here.

Agreed.  We've already started down the slippery slope of bundling third party
packages (e.g. the ensurepip dependencies) and this is causing headaches for
some of us distro guys.  Either they're in the stdlib or their not.

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

Re: [Python-Dev] Windows installers and OpenSSL

2014-04-10 Thread Gregory P. Smith 
Yep. All binary Python distributions that bundle SSL support need updating.
But... what MRAB said.

We also *likely* have SSL certificates and SSH host keys on
python.orginfrastructure that need to be revoked and new certs
reissued
*after* all of those machines have been patched and their services
restarted. Including hg.python.org.

-gps



On Thu, Apr 10, 2014 at 10:51 AM, MRAB  wrote:

> On 2014-04-10 14:41, Paul Moore wrote:
>
>> Given the OpenSSL vulnerability and the fact that we bundle OpenSSL
>> with the Windows installers (1.0.1e in Python 3.4.0) should we be
>> releasing updated installers?
>>
>>  I'd say yes, but, then, I wouldn't be doing any of the work...
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> greg%40krypto.org
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Windows installers and OpenSSL

2014-04-10 Thread Benjamin Peterson 
On Thu, Apr 10, 2014, at 14:50, Gregory P. Smith wrote:
> Yep. All binary Python distributions that bundle SSL support need
> updating.
> But... what MRAB said.
> 
> We also *likely* have SSL certificates and SSH host keys on
> python.orginfrastructure that need to be revoked and new certs
> reissued
> *after* all of those machines have been patched and their services
> restarted. Including hg.python.org.

SSH isn't affected, though, right?
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Language Summit notes

2014-04-10 Thread Nick Coghlan 
On 10 Apr 2014 10:23, "Antoine Pitrou"  wrote:
>
> Le 10/04/2014 13:24, Kushal Das a écrit :
>
>>
>> At this time of discussion Nick pointed us to
>> `http://speed.python.org/ `_, he asked if
>> any of the implementations
>> wants to maintain it. We need more volunteers for that, target is to
>> have a common set of tests to benchmark different implementations.
>
>
> I feel a bit tired to point out that there *is* a common set of
cross-implementation benchmarks at http://hg.python.org/benchmarks

Yes, I pointed that out - the issue is that they're not run regularly and
the results posted as they currently for PyPy.

That is, the discussion was about making speed.python.org a going concern,
not the benchmarks themselves.

Cheers,
Nick.

>p
> It is maintained and there is also a mailing-list to discuss it at
https://mail.python.org/mailman/listinfo/speed

>
> Regards
>
> Antoine.
>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Windows installers and OpenSSL

2014-04-10 Thread Nick Coghlan 
On 10 Apr 2014 18:55, "Benjamin Peterson"  wrote:
>
> On Thu, Apr 10, 2014, at 14:50, Gregory P. Smith wrote:
> > Yep. All binary Python distributions that bundle SSL support need
> > updating.
> > But... what MRAB said.
> >
> > We also *likely* have SSL certificates and SSH host keys on
> > python.orginfrastructure that need to be revoked and new certs
> > reissued
> > *after* all of those machines have been patched and their services
> > restarted. Including hg.python.org.
>
> SSH isn't affected, though, right?

Just SSL.

Cheers,
Nick.
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Windows installers and OpenSSL

2014-04-10 Thread M.-A. Lemburg 
On 11.04.2014 03:15, Nick Coghlan wrote:
> On 10 Apr 2014 18:55, "Benjamin Peterson"  wrote:
>>
>> On Thu, Apr 10, 2014, at 14:50, Gregory P. Smith wrote:
>>> Yep. All binary Python distributions that bundle SSL support need
>>> updating.
>>> But... what MRAB said.
>>>
>>> We also *likely* have SSL certificates and SSH host keys on
>>> python.orginfrastructure that need to be revoked and new certs
>>> reissued
>>> *after* all of those machines have been patched and their services
>>> restarted. Including hg.python.org.
>>
>> SSH isn't affected, though, right?
> 
> Just SSL.

And then only machines using OpenSSL 1.0.1. Not the earlier versions.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] arguments policy: **kwargs.pop()

2014-04-10 Thread Christian Tismer 
Hi guys,

I tried to find advice for hours, but failed so fer, so here is my question:

Whenever I think to adopt a new module that does a good job, I always
can't stand the temptation to look at the coding style and certain
principles.

Then I rather often see things like this:

class someclass(object):
# note that there is no comment about argument destruction...

def __init__(self, **kwargs):
first_arg = kwargs.pop('option_1', somedefault)
...
nth_arg = kwargs.pop('option_n', somedefault')
...

That is:
There are arguments "consumed" rigorously by the __init__ of a class,
although it would be equivalent to use kwargs.get(..., ...).

Happened to me again, today and blocked me completely, since I don't
know if I saw bad programming style or if I'm mislead.

I agree there are valid cases when if makes sense to filter out some
arguments
that a subsequently called super() might not be able to handle.
Bu even then, I would probably have a copy and make the filtering more
explicit.

But most of the time, there is no reason for using this pattern, and there
is also no comment stating that the argument dict is modified by the callee
for no good reason.

I always used the policy that arguments are never changed by a function,
unless explicitly stated.
But since I see this pattern quite frequently, I wanted to ask if I am
right by
thinking this way, or if the general policy is more like "arguments may be
destroyed by default".

What do you think? Is this bad style and should be noticed somewhere,
or is the caller supposed to protect the arguments, or are my worries
useless?

Thanks & cheers -- Chris

-- 
Christian Tismer :^)   
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/

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

Re: [Python-Dev] arguments policy: **kwargs.pop()

2014-04-10 Thread Guido van Rossum 
I'm not sure what you're worried about here. Modifying kwds doesn't
actually modify the dict that was passed in. So are you just talking about
the style issue? Or would you also object to this:

def foo(x=1):
x += 1

?


On Thu, Apr 10, 2014 at 10:12 PM, Christian Tismer wrote:

> Hi guys,
>
> I tried to find advice for hours, but failed so fer, so here is my
> question:
>
> Whenever I think to adopt a new module that does a good job, I always
> can't stand the temptation to look at the coding style and certain
> principles.
>
> Then I rather often see things like this:
>
> class someclass(object):
> # note that there is no comment about argument destruction...
>
> def __init__(self, **kwargs):
> first_arg = kwargs.pop('option_1', somedefault)
> ...
> nth_arg = kwargs.pop('option_n', somedefault')
> ...
>
> That is:
> There are arguments "consumed" rigorously by the __init__ of a class,
> although it would be equivalent to use kwargs.get(..., ...).
>
> Happened to me again, today and blocked me completely, since I don't
> know if I saw bad programming style or if I'm mislead.
>
> I agree there are valid cases when if makes sense to filter out some
> arguments
> that a subsequently called super() might not be able to handle.
> Bu even then, I would probably have a copy and make the filtering more
> explicit.
>
> But most of the time, there is no reason for using this pattern, and there
> is also no comment stating that the argument dict is modified by the callee
> for no good reason.
>
> I always used the policy that arguments are never changed by a function,
> unless explicitly stated.
> But since I see this pattern quite frequently, I wanted to ask if I am
> right by
> thinking this way, or if the general policy is more like "arguments may be
> destroyed by default".
>
> What do you think? Is this bad style and should be noticed somewhere,
> or is the caller supposed to protect the arguments, or are my worries
> useless?
>
> Thanks & cheers -- Chris
>
> --
> Christian Tismer :^)   
> Software Consulting  : Have a break! Take a ride on Python's
> Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
> 14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
> phone +49 173 24 18 776  fax +49 (30) 700143-0023
> PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
>   whom do you want to sponsor today?   http://www.stackless.com/
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] arguments policy: **kwargs.pop()

2014-04-10 Thread Tres Seaver 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/10/2014 10:12 PM, Christian Tismer wrote:

> I always used the policy that arguments are never changed by a
> function, unless explicitly stated. But since I see this pattern quite
> frequently, I wanted to ask if I am right by thinking this way, or if
> the general policy is more like "arguments may be destroyed by
> default".
> 
> What do you think? Is this bad style and should be noticed somewhere, 
> or is the caller supposed to protect the arguments, or are my worries 
> useless?

The caller can't know or care that the function / method pops arguments::

$ python
Python 2.7.3 (default, Feb 27 2014, 19:58:35)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo(**kw):
... bar = kw.pop('bar', 'BAR')
... print 'bar: %s' % bar
... print 'kw: %s' % kw
...
>>> foo()
bar: BAR
kw: {}
>>> foo(bar='baz')
bar: baz
kw: {}
>>> foo(bar='baz', bam='qux')
bar: baz
kw: {'bam': 'qux'}
>>> mykw = {'bar': 'baz', 'bam': 'qux'}
>>> foo(**mykw)
bar: baz
kw: {'bam': 'qux'}
>>> mykw
{'bam': 'qux', 'bar': 'baz'}

because the caller gets its own copy of 'kw', even when called with an
existing dict.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  [email protected]
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNHZhwACgkQ+gerLs4ltQ5RLQCeMaFvMDNexmCw9ggbg34w+AjP
DKMAn1U1WRGW9PV8R/xqJs1HPWUBVEse
=A8nP
-END PGP SIGNATURE-

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