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

[Nick Coghlan]

On 8 April 2014 18:32, cjw  wrote:
> Guido,
>
> I am sorry to read this.
>
> I shall be responding more completely in a day or two.
>
> In my view, @ and @@ are completely redundant.  Both operations are  already
> provided, * and **, in numpy.matrix.
>
> PEP 465 provides no clear indication as to how the standard operators fail.

Note that numpy.matrix is specifically discussed in
http://www.python.org/dev/peps/pep-0465/#rejected-alternatives-to-adding-a-new-operator
(it's the first rejected alternative listed).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

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

[Robert Kern]

On 2014-04-09 12:12, Nick Coghlan wrote:

On 8 April 2014 18:32, cjw  wrote:

Guido,

I am sorry to read this.

I shall be responding more completely in a day or two.

In my view, @ and @@ are completely redundant.  Both operations are  already
provided, * and **, in numpy.matrix.

PEP 465 provides no clear indication as to how the standard operators fail.


Note that numpy.matrix is specifically discussed in
http://www.python.org/dev/peps/pep-0465/#rejected-alternatives-to-adding-a-new-operator
(it's the first rejected alternative listed).


To be fair to Colin, the PEP asserts that the community at large would prefer an 
operator to the status quo but only alludes to the reason why it does so rather 
than explaining it fully. Personally, I think that's a reasonable allocation of 
Nathaniel's time, but then I happen to have agreed with the PEP's position 
before it was written, and I personally witnessed all of the history myself so I 
don't need it repeated back to me.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

___
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

Re: [Python-Dev] issue with itertools leads the crash

[Mark Lawrence]

On 08/04/2014 17:30, MRAB wrote:

On 2014-04-08 16:31, Brett Cannon wrote:

Something for Python 3.5, maybe? :-)

It's not going to happen in Python 2.7; that's the end of the Python 2
series, and it's getting security fixes only.


According to http://legacy.python.org/dev/peps/pep-0373/ the final 
release of 2.7 is scheduled to be 2.7.9 in May 2015.  Did you mean to 
say that 2.7 isn't getting new features?


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


___
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

[Python-Dev] A Friendly IDLE

[adnanumer95]

Greeting Everyone. First of all I want to introduce my self Adnan Umer as a 
student of bachelors in Information Technology.


I’ve few suggestions on improving IDLE. Here are few:

On windows we can open any python file from context menu because IDLE is not a 
application. I recommends to create a simple executable that  just calls 
‘idle.pyw’ module in lib\idlelib.


On executing python script with IDLE we can’t determine which file is executed. 
I recommends to print file name before executing. I made a little try to do 
that and I succeed.


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.


There is almost no difference on displayed result of these two command




>>> print (1)

1

>>> 1

1


there must be some difference as this creates a lot of confusion for beginners 
to understand purpose of print statement.


Adnan Umer___
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

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

[Nathaniel Smith]

On 9 Apr 2014 12:34, "Robert Kern"  wrote:
>
> On 2014-04-09 12:12, Nick Coghlan wrote:
>>
>> On 8 April 2014 18:32, cjw  wrote:
>>>
>>> Guido,
>>>
>>> I am sorry to read this.
>>>
>>> I shall be responding more completely in a day or two.
>>>
>>> In my view, @ and @@ are completely redundant.  Both operations are
 already
>>> provided, * and **, in numpy.matrix.
>>>
>>> PEP 465 provides no clear indication as to how the standard operators
fail.
>>
>>
>> Note that numpy.matrix is specifically discussed in
>>
http://www.python.org/dev/peps/pep-0465/#rejected-alternatives-to-adding-a-new-operator
>> (it's the first rejected alternative listed).
>
>
> To be fair to Colin, the PEP asserts that the community at large would
prefer an operator to the status quo but only alludes to the reason why it
does so rather than explaining it fully. Personally, I think that's a
reasonable allocation of Nathaniel's time, but then I happen to have agreed
with the PEP's position before it was written, and I personally witnessed
all of the history myself so I don't need it repeated back to me.

It could doubtless be clearer or signposted better, but the most explicit
explanation of why the two type solution doesn't work is in the first
section, search for "network effects".

-n
___
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

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

[Björn Lindqvist]

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?


-- 
mvh/best regards Björn Lindqvist
___
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

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

[Terry Reedy]

On 4/8/2014 6:32 PM, cjw wrote:

Larry Hastings

wasn't far from the truth.


Larry's note was about adding (redundant) *NON-ascii* unicode symbols, 
in particular × == \xd7, as in A × B, as a synonym for '@'. Various 
people have suggested adding various symbol synonyms, such as the Greek 
letter lambda for 'lambda', or a middle dot for '*'.


--
Terry Jan Reedy


___
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

Re: [Python-Dev] A Friendly IDLE

[Benjamin Peterson]

On Tue, Apr 8, 2014, at 21:25, adnanume...@gmail.com wrote:
> Greeting Everyone. First of all I want to introduce my self Adnan Umer as
> a student of bachelors in Information Technology.
> 
> 
> I’ve few suggestions on improving IDLE. Here are few:
> 
> On windows we can open any python file from context menu because IDLE is
> not a application. I recommends to create a simple executable that  just
> calls ‘idle.pyw’ module in lib\idlelib.
> 
> 
> On executing python script with IDLE we can’t determine which file is
> executed. I recommends to print file name before executing. I made a
> little try to do that and I succeed.
> 
> 
> 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.
> 
> 
> There is almost no difference on displayed result of these two command
> 
> 
> 
> 
> >>> print (1)
> 
> 1
> 
> >>> 1
> 
> 1
> 
> 
> there must be some difference as this creates a lot of confusion for
> beginners to understand purpose of print statement.

Python 3.3.3 (default, Jan 19 2014, 01:10:27) 
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print("hello")
hello
>>> "hello"
'hello'
___
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

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

[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.

-n

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org
___
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

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

[cjw]

  
  
Guido,

I am sorry to read this.

I shall be responding more completely in a day or two.

In my view, @ and @@ are completely redundant.  Both operations are 
already provided, * and **, in numpy.matrix.

PEP 465 provides no clear indication as to how the standard
operators fail.  Larry


  Hastings wasn't far from the truth.

Thanks for all the work you have put into Python and continue to do.

Best wishes,

 Colin W.
  

___
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

Re: [Python-Dev] issue with itertools leads the crash

[MRAB]

On 2014-04-09 14:26, Mark Lawrence wrote:

On 08/04/2014 17:30, MRAB wrote:

On 2014-04-08 16:31, Brett Cannon wrote:

Something for Python 3.5, maybe? :-)

It's not going to happen in Python 2.7; that's the end of the Python 2
series, and it's getting security fixes only.


According to http://legacy.python.org/dev/peps/pep-0373/ the final
release of 2.7 is scheduled to be 2.7.9 in May 2015.  Did you mean to
say that 2.7 isn't getting new features?


Err, probably... :-(
___
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

Re: [Python-Dev] issue with itertools leads the crash

[Ryan Gonzalez]

2015!?!? I was hoping it was a tad further off...the PyPy team is going to
have to start freaking out in about 12 months.


On Wed, Apr 9, 2014 at 8:26 AM, Mark Lawrence wrote:

> On 08/04/2014 17:30, MRAB wrote:
>
>> On 2014-04-08 16:31, Brett Cannon wrote:
>>
>> Something for Python 3.5, maybe? :-)
>>
>> It's not going to happen in Python 2.7; that's the end of the Python 2
>> series, and it's getting security fixes only.
>>
>
> According to http://legacy.python.org/dev/peps/pep-0373/ the final
> release of 2.7 is scheduled to be 2.7.9 in May 2015.  Did you mean to say
> that 2.7 isn't getting new features?
>
> --
> My fellow Pythonistas, ask not what our language can do for you, ask what
> you can do for our language.
>
> Mark Lawrence
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>
>
>
> ___
> 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/
> 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
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

Re: [Python-Dev] issue with itertools leads the crash

[Geoffrey Spear]

On Wed, Apr 9, 2014 at 1:53 PM, MRAB  wrote:
> On 2014-04-09 14:26, Mark Lawrence wrote:
>>
>> On 08/04/2014 17:30, MRAB wrote:
>>>
>>> On 2014-04-08 16:31, Brett Cannon wrote:
>>>
>>> Something for Python 3.5, maybe? :-)
>>>
>>> It's not going to happen in Python 2.7; that's the end of the Python 2
>>> series, and it's getting security fixes only.
>>
>>
>> According to http://legacy.python.org/dev/peps/pep-0373/ the final
>> release of 2.7 is scheduled to be 2.7.9 in May 2015.  Did you mean to
>> say that 2.7 isn't getting new features?
>>
> Err, probably... :-(

Of course, this raises the question of whether making slice assignment
not go into an infinite loop when the programmer asks it to is a
bugfix or a new feature.

Calling:

list(itertools.cycle([0]))

exhibits the same behavior for the same reason, and I don't think
anyone would call that a bug in Python.
___
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

Re: [Python-Dev] A Friendly IDLE

[Terry Reedy]

On 4/9/2014 12:25 AM, adnanume...@gmail.com wrote:

Greeting Everyone. First of all I want to introduce my self Adnan Umer
as a student of bachelors in Information Technology.

I’ve few suggestions on improving IDLE. Here are few:


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



 1.
On windows we can open any python file from context menu because
IDLE is not a application. I recommends to create a simple
executable that  just calls ‘idle.pyw’ module in lib\idlelib.


I do not understand this. Idle is an application, and there already is 
an idle.pyw. On windows, there is a Start Menu entry that calls 
idle.pyw. In Win7, one can pin the icon to the task bar. I presume one 
could make a desktop shortcut also.



 2.
On executing python script with IDLE we can’t determine which file
is executed. I recommends to print file name before executing. I
made a little try to do that and I succeed.


I created http://bugs.python.org/issue21192. Post a patch there if you 
have one.



 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.

--
Terry Jan Reedy


___
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

Re: [Python-Dev] issue with itertools leads the crash

[Steven D'Aprano]

On Wed, Apr 09, 2014 at 02:40:21PM -0400, Geoffrey Spear wrote:

> Of course, this raises the question of whether making slice assignment
> not go into an infinite loop when the programmer asks it to is a
> bugfix or a new feature.

Definitely a new feature.

> Calling:
> 
> list(itertools.cycle([0]))
> 
> exhibits the same behavior for the same reason, and I don't think
> anyone would call that a bug in Python.

It's not a bug, nevertheless it is a problem that can be amiliated. 
Some objects now have a __length_hint__  method. cycle could use that to 
indicate that it was infinitely long, and list could raise an exception 
*before* consuming all available memory.

http://legacy.python.org/dev/peps/pep-0424/


-- 
Steven
___
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

[Python-Dev] Language Summit notes

[Guido van Rossum]

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@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Benjamin Peterson]

This email is to share idea that has been bouncing around in my head for
a while about 2.7 releases. Guido's last email containing notes from the
language summit made me think it's time to propose it.

We'll keep doing what we're currently doing for another year, making
normal bug fix releases with installers. After that, we _won't_ close
2.7 to normal bug fixes as is currently implied by the release schedule.
Instead dealing 2.7 will just be completely optional for core
developers. (The much anticipated vendor support arrives at this point.)
Releases will continue at a measured (6-12 months) pace. These releases
will be source only (unless someone steps up to make installers).

Planning-on-making-2.7-releases-'til-the-cows-come-home-ly yours,
Benjamin
___
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

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

[Guido van Rossum]

I think this is pretty much what Nick Coghlan implied at the summit.


On Wed, Apr 9, 2014 at 9:22 PM, Benjamin Peterson wrote:

> This email is to share idea that has been bouncing around in my head for
> a while about 2.7 releases. Guido's last email containing notes from the
> language summit made me think it's time to propose it.
>
> We'll keep doing what we're currently doing for another year, making
> normal bug fix releases with installers. After that, we _won't_ close
> 2.7 to normal bug fixes as is currently implied by the release schedule.
> Instead dealing 2.7 will just be completely optional for core
> developers. (The much anticipated vendor support arrives at this point.)
> Releases will continue at a measured (6-12 months) pace. These releases
> will be source only (unless someone steps up to make installers).
>
> Planning-on-making-2.7-releases-'til-the-cows-come-home-ly yours,
> Benjamin
> ___
> 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/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
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

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

[Benjamin Peterson]

On Wed, Apr 9, 2014, at 18:31, Guido van Rossum wrote:
> I think this is pretty much what Nick Coghlan implied at the summit.

He implied that it's currently the plan or that it should be the plan?
___
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

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

[Chris Angelico]

On Thu, Apr 10, 2014 at 11:22 AM, Benjamin Peterson  wrote:
> Planning-on-making-2.7-releases-'til-the-cows-come-home-ly yours,

Past 2.7.9, will you make 2.7.10 etc, or does that violate other policies?

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.

Apologies if these questions were answered at the Summit. Montreal's
treatment of thirty-person-parties at one hour's notice may or may not
be considered a bug to be fixed in 2.7, but its geographic barrier to
Australians is definitely a feature addition. And will need to be
thoroughly bikeshedded on -ideas before implementation (can the time
machine be used to travel in relative dimensions in space?)

ChrisA
___
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

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

[Senthil Kumaran]

On Wed, Apr 9, 2014 at 9:22 PM, Benjamin Peterson wrote:

> Instead dealing 2.7 will just be completely optional for core
> developers. (The much anticipated vendor support arrives at this point.)
>

Could you clarify your thoughts a bit on the "completely optional" part.
What if vendors take a really long time to come to support the latest minor
release? AFAIK, the discussion centered around keep it "alive", for some
definition of alive. We did not define what do we mean by 'alive'.

Bringing back all the security related enhancement features seem ok.
Guido's last email talks about all the other compatibility goodies /tools
targeting 2.7 that may or may not go with 2.7 code base itself.


-- 
Senthil
___
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

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

[Benjamin Peterson]

On Wed, Apr 9, 2014, at 18:43, Chris Angelico wrote:
> On Thu, Apr 10, 2014 at 11:22 AM, Benjamin Peterson 
> wrote:
> > Planning-on-making-2.7-releases-'til-the-cows-come-home-ly yours,
> 
> Past 2.7.9, will you make 2.7.10 etc, or does that violate other
> policies?

I'm not aware that two digit minor version numbers violate anything but
some people's aesthetic senses.

> 
> 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.

> 
> Apologies if these questions were answered at the Summit. Montreal's
> treatment of thirty-person-parties at one hour's notice may or may not
> be considered a bug to be fixed in 2.7, but its geographic barrier to
> Australians is definitely a feature addition. And will need to be
> thoroughly bikeshedded on -ideas before implementation (can the time
> machine be used to travel in relative dimensions in space?)
___
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

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

[Benjamin Peterson]

On Wed, Apr 9, 2014, at 18:46, Senthil Kumaran wrote:
> On Wed, Apr 9, 2014 at 9:22 PM, Benjamin Peterson
> wrote:
> 
> > Instead dealing 2.7 will just be completely optional for core
> > developers. (The much anticipated vendor support arrives at this point.)
> >
> 
> Could you clarify your thoughts a bit on the "completely optional" part.
> What if vendors take a really long time to come to support the latest
> minor
> release? AFAIK, the discussion centered around keep it "alive", for some
> definition of alive. We did not define what do we mean by 'alive'.

Alive means I will keep making 2.7 releases while there are still
interesting changes to release.

> 
> Bringing back all the security related enhancement features seem ok.
> Guido's last email talks about all the other compatibility goodies /tools
> targeting 2.7 that may or may not go with 2.7 code base itself.

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.
___
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

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

[Guido van Rossum]

On Wed, Apr 9, 2014 at 9:39 PM, Benjamin Peterson wrote:

>
>
> On Wed, Apr 9, 2014, at 18:31, Guido van Rossum wrote:
> > I think this is pretty much what Nick Coghlan implied at the summit.
>
> He implied that it's currently the plan or that it should be the plan?
>

As you might understand, we couldn't actually *decide* anything at the
summit, but that should be the plan. Nick implied that Red Hat has a
relevant announcement it will make in two weeks, but wouldn't say more.

-- 
--Guido van Rossum (python.org/~guido)
___
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

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

[Senthil Kumaran]

On Wed, Apr 9, 2014 at 10:02 PM, Benjamin Peterson 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 core developers

I was worried about this part, that if bug-fixes are
optionally back-ported, then we may end up a inconsistent, undesirable
state.
Instead it could be that bug-fixes fixes will be back-ported as long as it
is alive (and folks seem be excited about keep it alive for a long long
term).

-- 
Senthil
___
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

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

[Guido van Rossum]

On Wed, Apr 9, 2014 at 9:39 PM, Benjamin Peterson wrote:

>
>
> On Wed, Apr 9, 2014, at 18:31, Guido van Rossum wrote:
> > I think this is pretty much what Nick Coghlan implied at the summit.
>
> He implied that it's currently the plan or that it should be the plan?
>

As you might understand, we couldn't actually *decide* anything at the
summit, but that should be the plan. Nick implied that Red Hat has a
relevant announcement it will make in two weeks, but wouldn't say more.

-- 
--Guido van Rossum (python.org/~guido)
___
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

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

[Benjamin Peterson]

On Wed, Apr 9, 2014, at 19:09, Senthil Kumaran wrote:
> On Wed, Apr 9, 2014 at 10:02 PM, Benjamin Peterson
> >> Instead dealing 2.7 will just be completely optional for core developers
> 
> I was worried about this part, that if bug-fixes are
> optionally back-ported, then we may end up a inconsistent, undesirable
> state.
> Instead it could be that bug-fixes fixes will be back-ported as long as
> it
> is alive (and folks seem be excited about keep it alive for a long long
> term).

I wouldn't worry about that too much. We should be encouraging a culture
of conservatism for 2.7 anyway.
___
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

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

[Guido van Rossum]

On Wed, Apr 9, 2014 at 9:58 PM, Benjamin Peterson wrote:

> On Wed, Apr 9, 2014, at 18:43, Chris Angelico wrote:
> > On Thu, Apr 10, 2014 at 11:22 AM, Benjamin Peterson  >
> > wrote:
> > > Planning-on-making-2.7-releases-'til-the-cows-come-home-ly yours,
> >
> > Past 2.7.9, will you make 2.7.10 etc, or does that violate other
> > policies?
>
> I'm not aware that two digit minor version numbers violate anything but
> some people's aesthetic senses.
>

In particular, mine, but if it's better than stopping at that point, I'll
be fine.


>  > 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.
>

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.


>  > Apologies if these questions were answered at the Summit. Montreal's
> > treatment of thirty-person-parties at one hour's notice may or may not
> > be considered a bug to be fixed in 2.7, but its geographic barrier to
> > Australians is definitely a feature addition. And will need to be
> > thoroughly bikeshedded on -ideas before implementation (can the time
> > machine be used to travel in relative dimensions in space?)
>

Only across branches of an AST though.

-- 
--Guido van Rossum (python.org/~guido)
___
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

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

[Guido van Rossum]

On Wed, Apr 9, 2014 at 9:58 PM, Benjamin Peterson wrote:

> On Wed, Apr 9, 2014, at 18:43, Chris Angelico wrote:
> > On Thu, Apr 10, 2014 at 11:22 AM, Benjamin Peterson  >
> > wrote:
> > > Planning-on-making-2.7-releases-'til-the-cows-come-home-ly yours,
> >
> > Past 2.7.9, will you make 2.7.10 etc, or does that violate other
> > policies?
>
> I'm not aware that two digit minor version numbers violate anything but
> some people's aesthetic senses.
>

In particular, mine, but if it's better than stopping at that point, I'll
be fine.


>  > 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.
>

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 he
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 for this and some other unglamorous tasks.


> > Apologies if these questions were answered at the Summit. Montreal's
> > treatment of thirty-person-parties at one hour's notice may or may not
> > be considered a bug to be fixed in 2.7, but its geographic barrier to
> > Australians is definitely a feature addition. And will need to be
> > thoroughly bikeshedded on -ideas before implementation (can the time
> > machine be used to travel in relative dimensions in space?)
>

Only across branches of an AST though.

-- 
--Guido van Rossum (python.org/~guido)
___
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

Re: [Python-Dev] Language Summit notes

[Senthil Kumaran]

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  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

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

[Ned Deily]

In article 
,
 Guido van Rossum  wrote:
> On Wed, Apr 9, 2014 at 9:58 PM, Benjamin Peterson wrote: 
> > 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. 
> 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 he
> 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 for this and some other unglamorous tasks.

WRT the other set of installers we provide, I'm willing to keep 
producing OS X installers for an indeterminate future of 2.7.  I reserve 
the right to get tired of it before 2038.  And I certainly am not 
volunteering to take over the Windows Installer.  I have it easy 
compared to Martin.

If we decide to keep going past 2015, I will likely propose some changes 
in the supported OS X levels of the 2.7 installers, in particular 
dropping at least 10.3 and 10.4 which we already did for Py3 starting 
with 3.3.0.  (By this I am not proposing to do anything to break source 
builds for those older systems.)  That has some potential impact to end 
users, e.g. breaking ABI compatibility in a minor release, but I think 
the impact would be outweighed by the benefits of supporting newer 
os-dependent features and build tools.  Any changes could be mitigated 
by a transitional release with installers for both the old and the new 
configurations.  But that's just a head's up: I'm not prepared to go 
into details at the moment.

-- 
 Ned Deily,
 n...@acm.org

___
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

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

[Nick Coghlan]

On 9 Apr 2014 22:11, "Guido van Rossum"  wrote:
>
> On Wed, Apr 9, 2014 at 9:39 PM, Benjamin Peterson 
wrote:
>>
>>
>>
>> On Wed, Apr 9, 2014, at 18:31, Guido van Rossum wrote:
>> > I think this is pretty much what Nick Coghlan implied at the summit.
>>
>> He implied that it's currently the plan or that it should be the plan?
>
>
> As you might understand, we couldn't actually *decide* anything at the
summit, but that should be the plan.

Yeah, I think it's on us and other commercial redistributors to figure out
how to best meet our long term support commitments to our users, and I
personally think that meeting those obligations cost effectively will
involve more direct *upstream* involvement in the long term maintenance of
the Python 2.7 series. That's largely boring-but-necessary drudgery, and
that's the kind of development gap that open source vendors excel at
addressing.

Still a lot of legwork to get from "I think this is a good way to handle
the problem" to actually making it happen, but as the saying goes: if you
don't ask, you don't get :)

I believe a defined end date for volunteer provided backports actually
helps make that case (and the advance warning also provides lead time to
hopefully do something about it).

> Nick implied that Red Hat has a relevant announcement it will make in two
weeks, but wouldn't say more.

Kinda wishing I hadn't said anything at all, now - I suspect the temporary
vagueness means I'm now building up anticipation that will inevitably lead
to disappointment with any actual announcement :(

I *can* at least say that we're (all too well) aware of the issues
associated with consuming newer dynamic language runtimes on our stable
platforms, and we're definitely interested in making it easier for users to
deploy and use newer versions of these without harming the consistency and
integrity of their system. Assuming we can find an approach (or approaches)
that work well for a wide variety of use cases, this should allow us to
help reduce the pressure on the developers of upstream Python libraries and
frameworks to keep supporting the versions installed system wide in our
long term maintenance releases (OpenShift and software collections are a
couple of existing efforts that handle some aspects of this issue, but I
certainly don't consider the general problem solved at this point).

Regards,
Nick.

>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> 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/ncoghlan%40gmail.com
>
___
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

[Python-Dev] Language Summit notes

[Stephen J. Turnbull]

Guido van Rossum writes:

 > - We should make an effort to publicize that we're NOT sunsetting
 > Python 2.7 just yet;

Maybe just add "Windows XP" to the SEO keywords for that page?  Like
*today* would be perfect timing.

___
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

Re: [Python-Dev] Language Summit notes

[Donald Stufft]

On Apr 9, 2014, at 10:30 PM, Senthil Kumaran  wrote:

> Mentioned about https://pypi-preview.a.ssl.fastly.net/ 

For what it’s worth, https://warehouse.python.org/ is a somewhat easier to 
remember demo url for that :]

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



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