Re: [Python-Dev] Every Release Can Be a Mini "Python 4000", Within Reason (was (name := expression) doesn't fit the narrative of PEP 20)

[Jeff Allen]

On 27/04/2018 08:38, Greg Ewing wrote:

How would you complete the following sentence? "The ':='
symbol is a much better symbol for assignment than '=',
because..."

... users new to programming but with a scientific background expect '=' 
to be a statement of an algebraic relationship between mathematical 
quantities, not an instruction to the machine to do something.


That's easy to answer.  (I can remember this particular light bulb 
moment in a fellow student, who had been using a different name in every 
assignment statement, and had found loops impossible to understand.) 
Also it frees up '=' to be used with something like its expected meaning 
in conditional statements, without making parsing hard/impossible. There 
are arguments the other way, like brevity and familiarity to other 
constituencies. But I feel we all know this.


Having chosen to go the '=', '==' route, the cost is large to change, 
especially to get the other half of the benefit ('=' as a predicate). So 
I think the question might be who is it better for and how much do we care.


And whether the days are gone when anyone learns algebra before programming.

I speculate this all goes back to some pre-iteration version of FORmula 
TRANslation, where to its inventors '=' was definition and these really 
were "statements" in the normal sense of stating a truth.


Jeff Allen

___
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 572 contradicts PEP 3099

[Nick Coghlan]

On 29 April 2018 at 12:52, Greg Ewing  wrote:

> Alex Walters wrote:
>
>> PEP 3099 is the big list of things that will not happen in Python 3.
>>
>> "There will be no alternative binding operators such as :=."
>>
>
> The thread referenced by that is taling about a different issue,
> i.e. using a different symbol to rebind names in an outer scope.
>

Right, and that's also noted again in the accepted PEP which introduced
"nonlocal" declarations:
https://www.python.org/dev/peps/pep-3104/#rebinding-operator

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

[Python-Dev] Review of Pull Request 5974 please

[Anthony Flury via Python-Dev]

All,

Can someone please review Pull Request 5974 
 on Python3.8 - the Pull 
request was submitted on 4th March - this pull request is associated 
with bpo-32933 


To summarize the point of this pull request:

It fixes a bug of omission within mock_open 
 
(part of unittest.mock)


The functionality of mock_open enables the test code to mock a file 
being opened with some data which can be read. Importantly, mock_open 
has a read_data attrribute which can be used to specify the data to read 
from the file.


The mocked file which is opened correctly supports file.read(), 
file.readlines(), file.readline(). These all make use of the read_data 
as expected, and the mocked file also supports being opened as a context 
manager.


But the mock_open file does not support iteration  - so pythonic code 
which uses a for loop to iterate around the file content will only ever 
appear to iterate around an empty file, regardless of the read_data 
attribute when the mock_open is created


So non-pythonic methods to iterate around the file contents - such as 
this :


    data = opened_file.readlines()
    for line in data:
        process_line(line)

and this :

       line = opened_file.readline()
       while line:
   process_line(line)
               line = opened_file.readline()

Can both be tested with the mocked file containing simulated data (using 
the read_data attribute) as expected.


But this code (which by any standard is the 'correct' way to iterate 
around the file content of a text file):


    for line in opened_file:
        process_line(line)

Will only ever appear to iterate around an empty file when tested using 
mock_open.


I would like this to be reviewed so it can be back-ported into Python3.7 
and 3.6 if at all possible. I know that the bug has existed since the 
original version of mock_open, but it does seem strange that code under 
test which uses a pythonic code structure can't be fully tested fully 
using the standard library.


--
Anthony Flury
email : *anthony.fl...@btinternet.com*
Twitter : *@TonyFlury *

___
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] Review of Pull Request 5974 please

[Yury Selivanov]

Reviewed. This seems to be an omission that needs to fixed, thanks for the
PR! Almost good to go in 3.8. As for 3.7, this isn't a bug fix it's up to
Ned if he wants to accept it.

Yury
On Sun, Apr 29, 2018 at 8:02 AM Anthony Flury via Python-Dev <
python-dev@python.org> wrote:

> All,

> Can someone please review Pull Request 5974
>  on Python3.8 - the Pull
> request was submitted on 4th March - this pull request is associated
> with bpo-32933 

> To summarize the point of this pull request:

> It fixes a bug of omission within mock_open
> <
https://docs.python.org/3/library/unittest.mock.html?highlight=mock_open#unittest.mock.mock_open

> (part of unittest.mock)

> The functionality of mock_open enables the test code to mock a file
> being opened with some data which can be read. Importantly, mock_open
> has a read_data attrribute which can be used to specify the data to read
> from the file.

> The mocked file which is opened correctly supports file.read(),
> file.readlines(), file.readline(). These all make use of the read_data
> as expected, and the mocked file also supports being opened as a context
> manager.

> But the mock_open file does not support iteration  - so pythonic code
> which uses a for loop to iterate around the file content will only ever
> appear to iterate around an empty file, regardless of the read_data
> attribute when the mock_open is created

> So non-pythonic methods to iterate around the file contents - such as
> this :

>   data = opened_file.readlines()
>   for line in data:
>   process_line(line)

> and this :

>  line = opened_file.readline()
>  while line:
>  process_line(line)
>  line = opened_file.readline()

> Can both be tested with the mocked file containing simulated data (using
> the read_data attribute) as expected.

> But this code (which by any standard is the 'correct' way to iterate
> around the file content of a text file):

>   for line in opened_file:
>   process_line(line)

> Will only ever appear to iterate around an empty file when tested using
> mock_open.

> I would like this to be reviewed so it can be back-ported into Python3.7
> and 3.6 if at all possible. I know that the bug has existed since the
> original version of mock_open, but it does seem strange that code under
> test which uses a pythonic code structure can't be fully tested fully
> using the standard library.

> --
> Anthony Flury
> email : *anthony.fl...@btinternet.com*
> Twitter : *@TonyFlury *

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



-- 
  Yury
___
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] Bugs Migration to OpenShift

[Mark Mangoba]

Hi All,

We’re planning to finish up the bugs.python.org migration to Red Hat
OpenShift by May 14th (US Pycon Sprints).  For the most part
everything will stay same, with the exception of cleaning up some old
URL’s and redirects from the previous hosting provider:  Upfront
Software.

We will post a more concrete timeline here by May 1st, but wanted to
share this exciting news to move bugs.python.org into a more stable
and optimal state.

Thank you all for your patience and feedback.  A special thanks to
Maciej Szulik and Red Hat for helping the PSF with this project.

Best regards,
Mark

-- 
Mark Mangoba | PSF IT Manager | Python Software Foundation |
mmang...@python.org | python.org | Infrastructure Staff:
infrastructure-st...@python.org | GPG: 2DE4 D92B 739C 649B EBB8 CCF6
DC05 E024 5F4C A0D1
___
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] Every Release Can Be a Mini "Python 4000", Within Reason (was (name := expression) doesn't fit the narrative of PEP 20)

[Eitan Adler]

On 29 April 2018 at 01:34, Jeff Allen  wrote:
> On 27/04/2018 08:38, Greg Ewing wrote:

> I speculate this all goes back to some pre-iteration version of FORmula
> TRANslation, where to its inventors '=' was definition and these really were
> "statements" in the normal sense of stating a truth.

https://www.hillelwayne.com/post/equals-as-assignment/


-- 
Eitan Adler
___
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] Every Release Can Be a Mini "Python 4000", Within Reason (was (name := expression) doesn't fit the narrative of PEP 20)

[Wes Turner]

On Sunday, April 29, 2018, Eitan Adler  wrote:

> On 29 April 2018 at 01:34, Jeff Allen  wrote:
> > On 27/04/2018 08:38, Greg Ewing wrote:
>
> > I speculate this all goes back to some pre-iteration version of FORmula
> > TRANslation, where to its inventors '=' was definition and these really
> were
> > "statements" in the normal sense of stating a truth.
>
> https://www.hillelwayne.com/post/equals-as-assignment/


https://en.wikipedia.org/wiki/Assignment_(computer_science)

C and C++ are '=' and '=='.

The Sympy solver, for example, solves Eq(lhs, rhs) equations and
expressions that are assumed to be equal to zero.
http://docs.sympy.org/latest/tutorial/solvers.html

The sage solver defines __eq__ (==) so expressions with variables produce
symbolic equations and inequalities (relations).
http://doc.sagemath.org/html/en/reference/calculus/sage/symbolic/relation.html

PyDatalog defines __eq__ so that expressions with variables produce logic
queries.
https://sites.google.com/site/pydatalog/Online-datalog-tutorial

The assignment Wikipedia article lists languages other than C and C++ which
chose = and == for assignment and definable equality testing.

https://en.wikipedia.org/wiki/Equality_(mathematics)
  https://en.wikipedia.org/wiki/Extensionality
https://en.wikipedia.org/wiki/Logical_equality



>
>
> --
> Eitan Adler
> ___
> 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/
> wes.turner%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] PEP 572 at the Language Summit next week

[Larry Hastings]

In case it helps, we're planning on presentations on / a discussion of 
PEP 572 at the 2018 Python Language Summit next Wednesday.  (I'm 
assuming it won't be pronounced upon before then--after all, what's the 
rush?)  Naturally the discussion isn't going to escape the room until it 
gets reported on by Jake Edge, but delegates at the Summit will 
hopefully emerge well-informed and comfortable with the result of the 
discussion.


See (some of) you at the Summit!


//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] Every Release Can Be a Mini "Python 4000", Within Reason (was (name := expression) doesn't fit the narrative of PEP 20)

[Guido van Rossum]

On Sun, Apr 29, 2018 at 10:45 AM, Eitan Adler  wrote:

> On 29 April 2018 at 01:34, Jeff Allen  wrote:
> > On 27/04/2018 08:38, Greg Ewing wrote:
>
> > I speculate this all goes back to some pre-iteration version of FORmula
> > TRANslation, where to its inventors '=' was definition and these really
> were
> > "statements" in the normal sense of stating a truth.
>
> https://www.hillelwayne.com/post/equals-as-assignment/
>

That blog post was brought up before in this discussion (probably on
python-ideas). I have my doubts about whether it accurately represents the
historic truth 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] Every Release Can Be a Mini "Python 4000", Within Reason (was (name := expression) doesn't fit the narrative of PEP 20)

[Greg Ewing]

Jeff Allen wrote:
I speculate this all goes back to some pre-iteration version of FORmula 
TRANslation, where to its inventors '=' was definition and these really 
were "statements" in the normal sense of stating a truth.


Yeah, also the earliest FORTRAN didn't even *have* comparison
operators. A conditional branch was something like

   IF (X-Y) 10, 20, 30

going three different ways depending on whether X-Y was negative,
zero or positive.

Then when comparison operators were added, a lot of people
didn't have "<" and ">" characters available to them, so
FORTRAN used ".EQ.", ".LT.", ".GT." etc. instead. We're
actually quite spoiled with our "==" operator!

--
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] PEP 572 contradicts PEP 3099

[Greg Ewing]

Nick Coghlan wrote:
On 29 April 2018 at 12:52, Greg Ewing > wrote:


Alex Walters wrote:

PEP 3099 is the big list of things that will not happen in Python 3.

"There will be no alternative binding operators such as :=."

The thread referenced by that is taling about a different issue,
i.e. using a different symbol to rebind names in an outer scope.

Right, and that's also noted again in the accepted PEP which introduced 
"nonlocal" declarations: 
https://www.python.org/dev/peps/pep-3104/#rebinding-operator


Perhaps PEP 3099 could be amended to say "no alternative binding operators
for the purpose of distinguishing local and nonlocal bindings."

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