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

[Victor Stinner]

2014-04-08 3:04 GMT+02:00 Steven D'Aprano :
>> > >Python used to have an alias <> for != and I for one miss <> in 3.x.  I
>> > >don't think TOOWTDI should be the last word in this debate.
>> >
>> > PEP 401 to the rescue:
>>
>> It occurs to me that since that Aprils' Fools joke is many years old
>> now, we should remove it.
>
> -1 on removal.
>
> It makes a nice Easter Egg, especially now that "import this" has become
> less of an Easter Egg and more of a standard Python module :-)

I'm also against the removal of jokes! Removing the antigravity module
would break the backward compatibility! from __futures__ import
braces!

Ten years ago, we asked me to add the "IPv6" feature in a firewall. I
started to implement the RFC 1924 to have a full support. In the C
language, handling the base 85 is not simple because you need
arithmetic operations on large integers (128 bits).
https://tools.ietf.org/html/rfc1924

3 days later, when my code was working, I saw the date of the RFC... I
was young and naive :-)

Victor
___
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-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!


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

[Sturla Molden]

Björn Lindqvist  wrote:

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

Perhaps. But you don't need to know matrix multiplication to see that those
expressions are not readable. And by extension, you can still imagine that
bugs can easily hide in unreadable code.  

Matrix multiplications are used extensively in anything from engineering to
statistics to computer graphics (2D and 3D). This operator will be a good
thing for a lot of us.

Sturla

___
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 12:23 GMT+02:00 Sturla Molden :
> Björn Lindqvist  wrote:
>
>> 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!
>
> Perhaps. But you don't need to know matrix multiplication to see that those
> expressions are not readable. And by extension, you can still imagine that
> bugs can easily hide in unreadable code.
>
> Matrix multiplications are used extensively in anything from engineering to
> statistics to computer graphics (2D and 3D). This operator will be a good
> thing for a lot of us.

All I ask for is to be able to see that with my own eyes. Maybe there
is some drastic improvement I can invent to make the algorithm much
more readable? Then the PEP:s motivation falls down. I don't want to
have to believe that the code the pep author came up with is the most
optimal. I want to prove that for myself.


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

[Daniel Holth]

On Tue, Apr 8, 2014 at 12:08 AM, Nick Coghlan  wrote:
>
> On 7 Apr 2014 21:58, "MRAB"  wrote:
>>
>> On 2014-04-08 02:45, Guido van Rossum wrote:
>>>
>>> So what? Aren't we allowed to have fun? :-)
>>>
>> Next thing you know, he'll be threatening people with The Comfy Chair!
>
> You may want to take a look at the packaging metadata 2.0 spec ;)
>
> I was also going to add a +1 for the actual topic of this thread, but
> Guido's acceptance of the PEP rendered that point rather moot :)

@ [1]
___
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

[Nick Coghlan]

On 8 April 2014 21:24, Björn Lindqvist  wrote:
> 2014-04-08 12:23 GMT+02:00 Sturla Molden :
>> Björn Lindqvist  wrote:
>>
>>> 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!
>>
>> Perhaps. But you don't need to know matrix multiplication to see that those
>> expressions are not readable. And by extension, you can still imagine that
>> bugs can easily hide in unreadable code.
>>
>> Matrix multiplications are used extensively in anything from engineering to
>> statistics to computer graphics (2D and 3D). This operator will be a good
>> thing for a lot of us.
>
> All I ask for is to be able to see that with my own eyes. Maybe there
> is some drastic improvement I can invent to make the algorithm much
> more readable? Then the PEP:s motivation falls down. I don't want to
> have to believe that the code the pep author came up with is the most
> optimal. I want to prove that for myself.

Note that the relationship between the CPython core development team
and the Numeric Python community is based heavily on trust - we don't
expect them to teach us to become numeric experts, we just expect them
to explain themselves well enough to persuade us that a core language
or interpreter change is the only realistic way to achieve a
particular goal. This does occasionally result in quirky patterns of
feature adoption, as things like extended slicing, full rich
comparison support, ellipsis support, rich buffer API support, and now
matrix multiplication support, were added for the numeric community's
benefit without necessarily offering any immediately obvious benefit
for those not using the numeric Python stack - it was only later that
they became pervasively adopted throughout the standard library (with
matmul, for example, a follow on proposal to allow tuples, lists and
arrays to handle vector dot products may make sense).

This particular problem has been kicking around long enough, and is
sufficiently familiar to several of us, that what's in the PEP already
presents a compelling rationale for the *folks that need to be
convinced* (which is primarily Guido, but if enough of the other core
devs think something is a questionable idea, we can often talk him out
of it - that's not the case here though).

Attempting to condense that preceding 10+ years of history *into the
PEP itself* wouldn't be a good return on investment - the links to the
earlier PEPs are there, as are the links to these discussion threads.

Cheers,
Nick.

P.S. We've been relatively successful in getting a similar trust based
dynamic off the ground for the packaging and distribution community
over the past year or so. The next big challenge in trust based
delegation for the core development team will likely be around a
Python 3.5+ only WSGI 2.0 (that can assume the Python 3 text model,
the restoration of binary interpolation, the availability of asyncio,
etc), but most of the likely principals there are still burned out
from the WSGI 1.1 debate and the Python 3 transition in general :(

>
>
> --
> 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/ncoghlan%40gmail.com



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

[Thomas Wouters]

On Apr 8, 2014 2:39 PM, "Nick Coghlan"  wrote:
>
> On 8 April 2014 21:24, Björn Lindqvist  wrote:
> > 2014-04-08 12:23 GMT+02:00 Sturla Molden :
> >> Björn Lindqvist  wrote:
> >>
> >>> 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!
> >>
> >> Perhaps. But you don't need to know matrix multiplication to see that
those
> >> expressions are not readable. And by extension, you can still imagine
that
> >> bugs can easily hide in unreadable code.
> >>
> >> Matrix multiplications are used extensively in anything from
engineering to
> >> statistics to computer graphics (2D and 3D). This operator will be a
good
> >> thing for a lot of us.
> >
> > All I ask for is to be able to see that with my own eyes. Maybe there
> > is some drastic improvement I can invent to make the algorithm much
> > more readable? Then the PEP:s motivation falls down. I don't want to
> > have to believe that the code the pep author came up with is the most
> > optimal. I want to prove that for myself.
>
> Note that the relationship between the CPython core development team
> and the Numeric Python community is based heavily on trust - we don't
> expect them to teach us to become numeric experts, we just expect them
> to explain themselves well enough to persuade us that a core language
> or interpreter change is the only realistic way to achieve a
> particular goal. This does occasionally result in quirky patterns of
> feature adoption, as things like extended slicing, full rich
> comparison support, ellipsis support, rich buffer API support, and now
> matrix multiplication support, were added for the numeric community's
> benefit without necessarily offering any immediately obvious benefit
> for those not using the numeric Python stack - it was only later that
> they became pervasively adopted throughout the standard library (with
> matmul, for example, a follow on proposal to allow tuples, lists and
> arrays to handle vector dot products may make sense).
>
> This particular problem has been kicking around long enough, and is

Just to give an indication how long, this came up in the discussion around
PEP 203, too. Fourteen years ago. In fact, augmented assignment could be
listed as one of the features added for the benefit of numeric array folks.

At the time, the discussions were not as focused and the proposals much
more pie-in-the-sky (the idea to have all of @*, @+, @-, @%, etc, as
individual operators specifically stuck in my mind.) This is a much more
grounded proposal.

> sufficiently familiar to several of us, that what's in the PEP already
> presents a compelling rationale for the *folks that need to be
> convinced* (which is primarily Guido, but if enough of the other core
> devs think something is a questionable idea, we can often talk him out
> of it - that's not the case here though).
>
> Attempting to condense that preceding 10+ years of history *into the
> PEP itself* wouldn't be a good return on investment - the links to the
> earlier PEPs are there, as are the links to these discussion threads.
>
> Cheers,
> Nick.
>
> P.S. We've been relatively successful in getting a similar trust based
> dynamic off the ground for the packaging and distribution community
> over the past year or so. The next big challenge in trust based
> delegation for the core development team will likely be around a
> Python 3.5+ only WSGI 2.0 (that can assume the Python 3 text model,
> the restoration of binary interpolation, the availability of asyncio,
> etc), but most of the likely principals there are still burned out
> from the WSGI 1.1 debate and the Python 3 transition in general :(
>
> >
> >
> > --
> > 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/ncoghlan%40gmail.com
>
>
>
> --
> 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/thomas%40python.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubsc

[Python-Dev] issue with itertools leads the crash

[Kirill]

 issue with itertools leads the crash


 The following code leads to system failure and crash on Ubuntu 12.04.3 with
 Python 2.7.6.

 import itertools

 r = range (1,10)

 r[1:9:2] = itertools.cycle([0])

 Kirill .
___
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 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? ;-)

See also:
https://mail.python.org/pipermail/python-ideas/2014-March/027077.html

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

[Python-Dev] issue with itertools leads the crash

[Brett Cannon]

Please a file a bug at bugs.python.org, otherwise this is most likely going
to get lost track of.

On Tue Apr 08 2014 at 11:30:15 AM, Kirill  wrote:

>  issue with itertools leads the crash
>
>   The following code leads to system failure and crash on Ubuntu 12.04.3
> with Python 2.7.6.
>
> import itertools
>
> r = range (1,10)
>
> r[1:9:2] = itertools.cycle([0])
>
>  Kirill .
>
> ___
> 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/
> brett%40python.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

[Ryan]

Ooooh...that stings.

Victor Stinner  wrote:
>2014-04-08 3:04 GMT+02:00 Steven D'Aprano :
>>> > >Python used to have an alias <> for != and I for one miss <> in
>3.x.  I
>>> > >don't think TOOWTDI should be the last word in this debate.
>>> >
>>> > PEP 401 to the rescue:
>>>
>>> It occurs to me that since that Aprils' Fools joke is many years old
>>> now, we should remove it.
>>
>> -1 on removal.
>>
>> It makes a nice Easter Egg, especially now that "import this" has
>become
>> less of an Easter Egg and more of a standard Python module :-)
>
>I'm also against the removal of jokes! Removing the antigravity module
>would break the backward compatibility! from __futures__ import
>braces!
>
>Ten years ago, we asked me to add the "IPv6" feature in a firewall. I
>started to implement the RFC 1924 to have a full support. In the C
>language, handling the base 85 is not simple because you need
>arithmetic operations on large integers (128 bits).
>https://tools.ietf.org/html/rfc1924
>
>3 days later, when my code was working, I saw the date of the RFC... I
>was young and naive :-)
>
>Victor
>___
>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

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.___
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-08 16:31, Brett Cannon wrote:

Please a file a bug at bugs.python.org ,
otherwise this is most likely going to get lost track of.

On Tue Apr 08 2014 at 11:30:15 AM, Kirill mailto:kir_...@rambler.ru>> wrote:

issue with itertools leads the crash


  The following code leads to system failure and crash on Ubuntu
12.04.3 with Python 2.7.6.

import itertools

r = range (1,10)

r[1:9:2] = itertools.cycle([0])


If the RHS yields too few, e.g. 3, you'll get:

ValueError: attempt to assign sequence of size 3 to extended slice of size 4

If it yields too many, e.g. 10, you'll get:

ValueError: attempt to assign sequence of size 10 to extended slice of 
size 4


It'll try to get all the values from the generator, which, of course,
will never happen with 'cycle'. It'll just consume more and more
memory, until it fails.

The fix would be to complain of raise StopIteration doesn't occur after
N+1 yields, where N is the number of values needed by the LHS.

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

[Eric Snow]

On Apr 8, 2014 10:31 AM, "MRAB"  wrote:
> If the RHS yields too few, e.g. 3, you'll get:
>
> ValueError: attempt to assign sequence of size 3 to extended slice of size 4
>
> If it yields too many, e.g. 10, you'll get:
>
> ValueError: attempt to assign sequence of size 10 to extended slice of size 4
[snip]
> The fix would be to complain of raise StopIteration doesn't occur after
> N+1 yields, where N is the number of values needed by the LHS.

Perhaps N+2 would be better:

  raise RuntimeError('{} is right out'.format(n+2))

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

[Antoine Pitrou]

Le 08/04/2014 04:02, Steven D'Aprano a écrit :


Many, many more people take part in the CPython core developer culture
than just the core developers themselves. Look at the readership of this
mailing list, which is open to the public and has regular posters who
aren't core developers. In-jokes like Guido as the BDFL


Is it a joke? I thought Guido was the BDFL for real :-o

Regards

Antoine.


___
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

[Chris Angelico]

On Wed, Apr 9, 2014 at 2:40 AM, Eric Snow  wrote:
> On Apr 8, 2014 10:31 AM, "MRAB"  wrote:
>> If the RHS yields too few, e.g. 3, you'll get:
>>
>> ValueError: attempt to assign sequence of size 3 to extended slice of size 4
>>
>> If it yields too many, e.g. 10, you'll get:
>>
>> ValueError: attempt to assign sequence of size 10 to extended slice of size 4
> [snip]
>> The fix would be to complain of raise StopIteration doesn't occur after
>> N+1 yields, where N is the number of values needed by the LHS.
>
> Perhaps N+2 would be better:
>
>   raise RuntimeError('{} is right out'.format(n+2))

It would be nice to have a simple notation that fetches what it needs
and ignores any extras.

a, b, c, * = x.split("-")

Bomb if there aren't two hyphens in x, but if there are more, just
take the first three and ignore the rest. Would work with infinite
iterators quite happily.

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] PEP 465: A dedicated infix operator for matrix multiplication

[Chris Angelico]

On Wed, Apr 9, 2014 at 2:49 AM, Antoine Pitrou  wrote:
> Le 08/04/2014 04:02, Steven D'Aprano a écrit :
>
>>
>> Many, many more people take part in the CPython core developer culture
>> than just the core developers themselves. Look at the readership of this
>> mailing list, which is open to the public and has regular posters who
>> aren't core developers. In-jokes like Guido as the BDFL
>
>
> Is it a joke? I thought Guido was the BDFL for real :-o
>

Is it a joke, or is it serious? Where do you draw the line between wit
for the purpose of making a point, and a joke that bears a kernel of
truth?

   I've wisdom from the East and from the West,
That's subject to no academic rule;
   You may find it in the jeering of a jest,
Or distil it from the folly of a fool.
   I can teach you with a quip, if I've a mind;
   I can trick you into learning with a laugh;
   Oh, winnow all my folly, and you'll find
A grain or two of truth among the chaff!

-- WS Gilbert, via Jack Point the jester, in "Yeomen of the Guard"

To many people, the concept of a benevolent dictator for life whom
nobody has to obey is a joke. And yet that's exactly the truth; Guido
*is* dictator, because Python is his project. But on the other hand
(I'm running out of hands here), he wants his project to be useful to
people, so he has to follow the paradoxical plan of Jim Hacker: "I'm
their leader! I must follow them!". Joke? Truth? Neither? Both? It's
really hard to say...

It's even harder to draw the line when you have, for instance, Monty
Python references being used as metasyntactic variables. A perfectly
serious document needs to explain how to split a string into words:

>>> "Nobody expects the Spanish Inquisition!".split()
['Nobody', 'expects', 'the', 'Spanish', 'Inquisition!']

Is that a joke, or a serious example of an important string operation?
Or perchance a brilliant combination of both... and there I go quoting
another jester, in this case "The Court Jester" starring Danny Kaye.
Am I joking around because I'm citing four different comedies, or am I
making a completely serious point?

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] PEP 465: A dedicated infix operator for matrix multiplication

[Steven D'Aprano]

On Tue, Apr 08, 2014 at 06:49:13PM +0200, Antoine Pitrou wrote:
> Le 08/04/2014 04:02, Steven D'Aprano a écrit :
> >
> >Many, many more people take part in the CPython core developer culture
> >than just the core developers themselves. Look at the readership of this
> >mailing list, which is open to the public and has regular posters who
> >aren't core developers. In-jokes like Guido as the BDFL
> 
> Is it a joke? I thought Guido was the BDFL for real :-o

The joke is the title, not the role.

https://www.artima.com/weblogs/viewpost.jsp?thread=235725




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

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

[Larry Hastings]

On 04/08/2014 12:50 PM, Chris Angelico wrote:

It would be nice to have a simple notation that fetches what it needs
and ignores any extras.

a, b, c, * = x.split("-")

Bomb if there aren't two hyphens in x, but if there are more, just
take the first three and ignore the rest. Would work with infinite
iterators quite happily.


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


//arry/
___
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

[Chris Angelico]

On Wed, Apr 9, 2014 at 3:30 AM, Larry Hastings  wrote:
> On 04/08/2014 12:50 PM, Chris Angelico wrote:
>
> It would be nice to have a simple notation that fetches what it needs
> and ignores any extras.
>
> a, b, c, * = x.split("-")
>
> Bomb if there aren't two hyphens in x, but if there are more, just
> take the first three and ignore the rest. Would work with infinite
> iterators quite happily.
>
>
> http://legacy.python.org/dev/peps/pep-0448/
>

Yes, there've been various proposals like that. The exact notation I'm
referring to here isn't mentioned in that PEP, but I know it's been
mentioned before.

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] [Python-checkins] cpython (3.4): docs: Document __objclass__. Closes #19281.

[Ethan Furman]

Sorry, posted to wrong list the first time.

On 04/08/2014 09:33 AM, Ethan Furman wrote:

On 04/08/2014 09:07 AM, yury.selivanov wrote:

http://hg.python.org/cpython/rev/0973d45197cc

 >

+The :attr:`__objclass__` is interpreted by the :mod:`inspect` module as
+specifying the class where this object was defined (setting this
appropriately
+can assist in runtime introspection of dynamic class attributes). For
callables,
+it may indicate that an instance of the given type (or a subclass) is
expected
+or required as the first positional argument (for example, CPython
sets this
+attribute for unbound methods that are implemented in C).


This would read better as

The attribute :attr:`__objclass__` . . .

--
~Ethan~

___
Python-checkins mailing list
python-check...@python.org
https://mail.python.org/mailman/listinfo/python-checkins


___
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] [Python-checkins] cpython (3.4): docs: Document __objclass__. Closes #19281.

[Yury Selivanov]

Thank you, Ethan.
Fixed.

On 2014-04-08, 1:57 PM, Ethan Furman wrote:

Sorry, posted to wrong list the first time.

On 04/08/2014 09:33 AM, Ethan Furman wrote:

On 04/08/2014 09:07 AM, yury.selivanov wrote:

http://hg.python.org/cpython/rev/0973d45197cc

 >
+The :attr:`__objclass__` is interpreted by the :mod:`inspect` 
module as

+specifying the class where this object was defined (setting this
appropriately
+can assist in runtime introspection of dynamic class attributes). For
callables,
+it may indicate that an instance of the given type (or a subclass) is
expected
+or required as the first positional argument (for example, CPython
sets this
+attribute for unbound methods that are implemented in C).


This would read better as

The attribute :attr:`__objclass__` . . .

--
~Ethan~

___
Python-checkins mailing list
python-check...@python.org
https://mail.python.org/mailman/listinfo/python-checkins


___
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/yselivanov.ml%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

Re: [Python-Dev] Windows buildbots are red: test_idlelib

[Zachary Ware]

On Mon, Apr 7, 2014 at 4:37 AM, Victor Stinner  wrote:
> Hi,
>
> Unit tests are failing on Windows because of this issue:
> http://bugs.python.org/issue21059
>
> It looks like a regression in test_idlelib introduced with this issue:
> http://bugs.python.org/issue15968
>
> Zachary Ware wrote a fix:
> http://bugs.python.org/issue20035
>
> Can someone please review Zachary's patch? If not, I suggest to revert
> changes of issue #15968 to have working Windows buildbots.

Rather than revert the change, I committed what should be a temporary
fix last night; Tools/buildbot/test[-amd64].bat now sets TCL_LIBRARY
before calling the test script.  It seems to be keeping the buildbots
happy until #20035 can reach a satisfactory conclusion.

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

[Greg Ewing]

Victor Stinner wrote:

I started to implement the RFC 1924 to have a full support.

3 days later, when my code was working, I saw the date of the RFC...


Do you still have the code? It needn't go to waste -- this
would make a fine addition to Python's easter egg basket!

--
Greg

___
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] Windows buildbots are red: test_idlelib

[Victor Stinner]

Thanks !

2014-04-08 22:39 GMT+02:00 Zachary Ware :
> On Mon, Apr 7, 2014 at 4:37 AM, Victor Stinner  
> wrote:
>> Hi,
>>
>> Unit tests are failing on Windows because of this issue:
>> http://bugs.python.org/issue21059
>>
>> It looks like a regression in test_idlelib introduced with this issue:
>> http://bugs.python.org/issue15968
>>
>> Zachary Ware wrote a fix:
>> http://bugs.python.org/issue20035
>>
>> Can someone please review Zachary's patch? If not, I suggest to revert
>> changes of issue #15968 to have working Windows buildbots.
>
> Rather than revert the change, I committed what should be a temporary
> fix last night; Tools/buildbot/test[-amd64].bat now sets TCL_LIBRARY
> before calling the test script.  It seems to be keeping the buildbots
> happy until #20035 can reach a satisfactory conclusion.
>
> --
> Zach
> ___
> 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/victor.stinner%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

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

[Victor Stinner]

2014-04-09 1:13 GMT+02:00 Greg Ewing :
> Victor Stinner wrote:
>>
>> I started to implement the RFC 1924 to have a full support.
>>
>> 3 days later, when my code was working, I saw the date of the RFC...
>
>
> Do you still have the code? It needn't go to waste -- this
> would make a fine addition to Python's easter egg basket!

Oh, apparently you are not aware. It's no more an april fool, Python
3.4 has support for base85!
https://docs.python.org/3.4/library/base64.html#base64.b85encode

Victor

PS: No, I didn't kept my base85 codec for IPv6 written in C.
___
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] PEP 465: A dedicated infix operator for matrix multiplication

[Nathaniel Smith]

On 9 Apr 2014 00:15, "Greg Ewing"  wrote:
>
> Victor Stinner wrote:
>>
>> I started to implement the RFC 1924 to have a full support.
>>
>> 3 days later, when my code was working, I saw the date of the RFC...
>
>
> Do you still have the code? It needn't go to waste -- this
> would make a fine addition to Python's easter egg basket!

Even if not it would be pretty easy to reimplement - maybe 10-20 loc. If
you look the joke is they represent 128 bit ipaddrs in a base that's
relatively prime to 2, necessitating a full bignum library just for io. But
python has bignums for free...

-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