[issue32884] Adding the ability for getpass to print asterisks when password is typed

[Jeffrey Kintscher]

Change by Jeffrey Kintscher :


--
nosy: +Jeffrey.Kintscher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41497] Potential UnicodeDecodeError in dis

[Inada Naoki]

Change by Inada Naoki :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41505] asyncio.gather of large streams with limited resources

[Kevin Amado]

Change by Kevin Amado :


Removed file: https://bugs.python.org/file49377/materialize-implementation.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41497] Potential UnicodeDecodeError in dis

[miss-islington]

miss-islington  added the comment:


New changeset d9106434f77fa84c8a59f8e60dc9c14cdd989b35 by Miss Islington (bot) 
in branch '3.9':
bpo-41497: Fix potential UnicodeDecodeError in dis CLI (GH-21757)
https://github.com/python/cpython/commit/d9106434f77fa84c8a59f8e60dc9c14cdd989b35


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41497] Potential UnicodeDecodeError in dis

[miss-islington]

miss-islington  added the comment:


New changeset 66c899661902edc18df96a5c3f22639310700491 by Miss Islington (bot) 
in branch '3.8':
bpo-41497: Fix potential UnicodeDecodeError in dis CLI (GH-21757)
https://github.com/python/cpython/commit/66c899661902edc18df96a5c3f22639310700491


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Marco Sulla]

On Sat, 8 Aug 2020 at 03:46, Christian Seberino  wrote:
> >> Readability of programming languages was measured
> >> using an objective method, and Python was one of
> >> the most readable.
>
> Do you have a source for this?

This question means you have not read at all my suggestions :-D
Anyway, this is one: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3933420/

I do not agree with the entire work, but generally speaking it seems
to me they used a good approach. What really surprises me is the
absence of languages like JS and PHP.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41507] Use utf-8 in "Reading and Writing Files" tutorial.

[Inada Naoki]

New submission from Inada Naoki :

https://docs.python.org/3/tutorial/inputoutput.html#reading-and-writing-files

Current tutorial doesn't mention about encoding and example uses locale 
encoding.
Since UTF-8 is major text encoding and many Windows environment doesn't use 
UTF-8 by default, encoding should be mentioned in the tutorial and UTF-8 should 
be recommended.

Additionally, the paragraph about line ending conversion [1] can be removed. 
This was important in Python 2. But it is not important because (en|de)coding 
binary data is nonsense already.

[1]: "This behind-the-scenes modification to file data is fine for text files, 
but will corrupt binary data like that in JPEG or EXE files. Be very careful to 
use binary mode when reading and writing such files."

--
assignee: docs@python
components: Documentation
keywords: newcomer friendly
messages: 375033
nosy: docs@python, inada.naoki
priority: normal
severity: normal
status: open
title: Use utf-8 in "Reading and Writing Files" tutorial.
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41497] Potential UnicodeDecodeError in dis

[Inada Naoki]

Inada Naoki  added the comment:


New changeset a4084b9d1e40c1c9259372263d1fe8c8a562b093 by Konge in branch 
'master':
bpo-41497: Fix potential UnicodeDecodeError in dis CLI (GH-21757)
https://github.com/python/cpython/commit/a4084b9d1e40c1c9259372263d1fe8c8a562b093


--
nosy: +inada.naoki

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41497] Potential UnicodeDecodeError in dis

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +20923
pull_request: https://github.com/python/cpython/pull/21782

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41497] Potential UnicodeDecodeError in dis

[miss-islington]

Change by miss-islington :


--
pull_requests: +20924
pull_request: https://github.com/python/cpython/pull/21783

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40275] test.support has way too many imports

[hai shi]

Change by hai shi :


--
pull_requests: +20922
pull_request: https://github.com/python/cpython/pull/21771

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41109] subclasses of pathlib.PurePosixPath never call __init__ or __new__

[Jeffrey Kintscher]

Jeffrey Kintscher  added the comment:

Clarification:

PurePath.__new__() calls PurePath._from_parts(), which then calls 
PurePath._init()

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Christian Seberino]

>> Readability of programming languages was measured
>> using an objective method, and Python was one of 
>> the most readable.

Do you have a source for this?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Symlinks already present

[2QdxY4RzWzUUiLuE]

On 2020-08-08 at 01:58:13 +0200,
Termoregolato  wrote:

> me@debsrv:~/tmp/test$ stat --format=%i /home/me/mydir
> 18481153

Try ls -i.  :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41109] subclasses of pathlib.PurePosixPath never call __init__ or __new__

[Jeffrey Kintscher]

Jeffrey Kintscher  added the comment:

The workaround is to override _init(), which I agree is not desirable.

This is the relevant code in PurePath, which is the super class of 
PurePosixPath:

@classmethod
def _from_parsed_parts(cls, drv, root, parts, init=True):
self = object.__new__(cls)
self._drv = drv
self._root = root
self._parts = parts
if init:
self._init()
return self

...

def _init(self):
# Overridden in concrete Path
pass

To me, the clean way to get the desired behavior seems like it would be to have 
_init() call self.__init__().

def _init(self):
# Overridden in concrete Path
self.__init__()

This fixes p.parent, but GithubPath() ends up calling GithubPath.__init__() 
twice – the first time by PurePath.__new__() calling PurePath._init() and the 
second time by the GithubPath object creation.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41506] Inclusion or documentation of extended with syntax in 3.9

[Aaron Meurer]

New submission from Aaron Meurer :

This discussion started at https://github.com/python/cpython/pull/19503 
(actually on Twitter https://twitter.com/asmeurer/status/1289304407696261120), 
but Guido asked me to move it bpo.

Alongside the implementation of Python 3.9's new PEG parser, a new syntax 
feature has been added, which is the ability to use parentheses in with 
statements, like

with (open('a') as f1,
open('b') as f2):
...

This is an error in lower versions of Python (or an error about tuple not 
having __enter__ if the "as" parts are omitted). 

This new feature is not documented in the "What's new in Python 3.9" document 
https://docs.python.org/3.9/whatsnew/3.9.html.

It also apparently goes against PEP 627 
https://www.python.org/dev/peps/pep-0617/, which says (in bold), "no new Python 
Grammar addition will be added that requires the PEG parser".

Note that this feature does indeed rely on the PEG parser, and it stops working 
if you use python -X oldparser or PYTHONOLDPARSER=1.

I think this feature should either

1. be removed from 3.9 and held until 3.10, or
2. be documented properly, including in the document for the "with" statement 
and the "what's new" document. Also the PEP should be updated if this option is 
chosen.

Others have stated opinions about this on the issue or on Twitter, but I'll let 
them repeat them here rather than trying to summarize.

--
messages: 375029
nosy: asmeurer
priority: normal
pull_requests: 20921
severity: normal
status: open
title: Inclusion or documentation of extended with syntax in 3.9
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41505] asyncio.gather of large streams with limited resources

[Kevin Amado]

New submission from Kevin Amado :

Sometimes when dealing with high concurrency systems developers face the 
problem of executing concurrently a large number of tasks while taking care of 
a finite pool of resources

Just to mention some examples:
- reading asynchronously a lot of files without exceeding the maximum number of 
open files by the operative system
- making millions of requests to a website, doing it in sufficiently small 
batches as not to be banned by the site's firewall or hitting API limits
- making a lot of DNS lookups without exceeding the maximum number of open 
sockets allowed by the operative system
- and many more

What these examples have in common is that there is a hard-limit in the maximum 
concurrency possible to solve the problem.

A naive approach is to split the long list of tasks in small batches and use 
asyncio.gather on each batch. This, however, has some downsides if one of the 
tasks takes more time than the others because at some point in time only this 
task would be running and the execution of the following batch gets delayed, 
impacting performance and overall throughput and execution time.

Another approach is to use asyncio.wait on a subset of tasks, gathering the 
done tasks and appending more tasks from the remaining subset until all tasks 
get executed. This alternative is good but still far from optimal as many 
boilerplate code is needed.

The ideal approach is to operate in the possibly infinite list of tasks with an 
always constant number of them being resolved concurrently. If one of the tasks 
being concurrently executed finishes then immediately another one is fetched 
from the input stream and added to the list of concurrently executing ones. By 
doing it in this way we optimize the resources needed while minimizing the 
total execution time and never exceeding the finite pool of resources (sockets, 
open files, http API limit), etc.

What I'm attaching is a proof of concept of a new function to add to the 
asyncio.tasks module that implements the ideal approach.

The proposed signature for such function is:

  async def materialize(aws, *, max_concurrency=None)

And functions in this way:

```
async def do(n: int) -> None:
print('running', n)
await asyncio.sleep(1)
print('returning', n)
return n

async def main():
result = []
async for x in materialize(map(do, range(5)), max_concurrency=2):
print('got', x)
result.append(x)

print(result)
```

Whose output is:

running 0
running 1
returning 0
returning 1
got 0
got 1
running 2
running 3
returning 2
returning 3
got 2
got 3
running 4
returning 4
got 4
[0, 1, 2, 3, 4]

As you can see, tasks are resolved concurrently without exceeding the max 
concurrency allowed, yet always executing concurrently as many tasks as the 
limit specifies. Yielding results as soon as available, keeping a small memory 
footprint (proportional to the max concurrency allowed) and returning results 
in the same order of the input stream (opposite to asyncio.as_completed)

Since it's an asynchronous generator it can deal with infinite input streams, 
which is nice!

I'm willing to work further on a PR

--
components: asyncio
files: materialize.py
messages: 375028
nosy: asvetlov, kamadorueda, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.gather of large streams with limited resources
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file49377/materialize.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41474] Missing dependency on Include/cpython/frameobject.h

[Guido van Rossum]

Guido van Rossum  added the comment:

Wrong issue, sorry. (Bpo bug?)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41474] Missing dependency on Include/cpython/frameobject.h

[Guido van Rossum]

Guido van Rossum  added the comment:

Sorry to rain on your parade, but couldn’t this be a new package on PyPI?

--
nosy: +gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Symlinks already present

[Termoregolato]

Il 27/07/20 20:37, Chris Angelico ha scritto:


Unfortunately there's no real way to shortcut this if you just want to
check one target directory. You'd still have to readlink() every
symlink to try to find them.


Sorry for 10 days of delay (hardware problems at home). Yes, that is. 
It's a mode to order directories from their content, but due the first 
chars are always the same, and then I got a tree like


finaldir/f/firstpart/secondpart [changing_values]

and the test should be done only on a small list of links, so they're fast.

--
Pastrano
   con un altro account
--
https://mail.python.org/mailman/listinfo/python-list

[issue41494] Add window resizing support [ SIGWINCH ] to Lib/pty

[Soumendra Ganguly]

Soumendra Ganguly  added the comment:

Updated diff.

Changes _ekill()

--
Added file: https://bugs.python.org/file49376/pty.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Symlinks already present

[Termoregolato]

Il 28/07/20 02:50, Dennis Lee Bieber ha scritto:


inode numbers apply for HARD LINKS


Thanks

--
Pastrano
   con un altro account
--
https://mail.python.org/mailman/listinfo/python-list

Re: Symlinks already present

[Termoregolato]

Il 28/07/20 00:19, Grant Edwards ha scritto:


You err.


I read it, I had to test. In effects, it was simple to test.

me@debsrv:~/tmp/test$ ln -s /home/me/mydir aaa
me@debsrv:~/tmp/test$ ln -s /home/me/mydir bbb

me@debsrv:~/tmp/test$ ls
aaa  bbb

me@debsrv:~/tmp/test$ stat --format=%i /home/me/mydir
18481153
me@debsrv:~/tmp/test$ stat --format=%i aaa
2364513
me@debsrv:~/tmp/test$ stat --format=%i bbb
2374065

Thanks

--
Pastrano
   con un altro account
--
https://mail.python.org/mailman/listinfo/python-list

[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

[Steve Dower]

Change by Steve Dower :


--
versions:  -Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

[Steve Dower]

Steve Dower  added the comment:


New changeset 70e9243a55be9c32b41f2149cdfa3957f96f8471 by Steve Dower in branch 
'3.9':
bpo-41490: Update ensurepip to install pip 20.2.1 and setuptools 49.2.1 
(GH-21774)
https://github.com/python/cpython/commit/70e9243a55be9c32b41f2149cdfa3957f96f8471


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Richard Damon]

On 8/7/20 6:55 PM, Marco Sulla wrote:
> On Sat, 8 Aug 2020 at 00:28, Richard Damon  wrote:
>> The really interesting part is that since Lisp programs manipulate lists
>> as data, and the program is just a list, Lisp programs have the
>> theoretical ability to edit themselves (assuming the implementation give
>> access to the list of the program to the program).
> This is a bit hard to understand for me.
> I know that code can be translated to an AST, that is a tree. It's
> quite difficult for me to imagine the code organized as a list. Do you
> have some links about it?

Lisp is built on Nested list, Lists were some (many) of the nodes are
other list. (Somewhat like you might build the AST in Python)

Generally the first element of the list defines what the list is, type
of statement or operation, and the rest are the parameters for it. Many
of these will be lists for sub expressions or dependent statements.

Perhaps the best option would be to search for the Lisp Language, and
see how you write programs.

>
> On Sat, 8 Aug 2020 at 00:28, Richard Damon  wrote:
>> One advantage of blurring the line between statements and expressions is
>> power, putting assignments in the middle of an expression, can allow
>> code to be more compact.
> I agree with you. I experimented a little with CPython code and I saw
> assignments inside if statements. The code without them was less
> readable. I also found this example:
> https://stackoverflow.com/a/151920/1763602
> My only fear is the abuse. How many people really use the walrus
> operator to render the code more readable? My fear is that the
> majority of programmer will use it for laziness and because it's
> "cool" ^^

There is always the danger, that as you give the programmer more
expressive power, they can use it for 'good', or they can miss-use it to
make code harder to read. The question comes how much are you willing to
trust the programmer, or are you just going to give them enough rope so
that can do themselves in. 

-- 
Richard Damon

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41455] Python Devguide differs from python docs

[Terry J. Reedy]

Change by Terry J. Reedy :


--
nosy: +pablogsal, pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Marco Sulla]

On Sat, 8 Aug 2020 at 00:28, Richard Damon  wrote:
> The really interesting part is that since Lisp programs manipulate lists
> as data, and the program is just a list, Lisp programs have the
> theoretical ability to edit themselves (assuming the implementation give
> access to the list of the program to the program).

This is a bit hard to understand for me.
I know that code can be translated to an AST, that is a tree. It's
quite difficult for me to imagine the code organized as a list. Do you
have some links about it?

On Sat, 8 Aug 2020 at 00:28, Richard Damon  wrote:
> One advantage of blurring the line between statements and expressions is
> power, putting assignments in the middle of an expression, can allow
> code to be more compact.

I agree with you. I experimented a little with CPython code and I saw
assignments inside if statements. The code without them was less
readable. I also found this example:
https://stackoverflow.com/a/151920/1763602
My only fear is the abuse. How many people really use the walrus
operator to render the code more readable? My fear is that the
majority of programmer will use it for laziness and because it's
"cool" ^^
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

[Steve Dower]

Change by Steve Dower :


--
versions:  -Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Richard Damon]

On 8/7/20 3:54 PM, Marco Sulla wrote:
> On Fri, 7 Aug 2020 at 19:48, Richard Damon  wrote:
>> The difference is that the two languages define 'expression' differently. 
>> [...]
> I don't know if this is interesting or pertinent to the topic.
>
> Christian Seberino just expressed a doubt about how a clear separation
> between a statement and an expression is quite desiderable in the
> "real" programming world. And I tried to explain it with the
> assignment operation, since a ton of programmers feel very frustrated
> about reading code of other programmers with assignment in an if
> statement. I'm quite sure that they thought, as I thought: "What do
> this?"
> Worse when their program failed and they discovered that they wrote
> `if (a=b)` instead of `if (a==b)`.
>
> I'm just more curious about why Lisp programmers think that it's
> better to not make a hard distinction between statements and
> expressions.

Actually, they might put a fairly hard distinction between statements
and expressions, a statement is a list that begins with a programmatic
atom, while an expression is a list that begins with an operator atom.

The fact that EVERYTHING is a list, makes those not used to the idea see
it as all the same (which I suppose in a way it is).

One side effect of this is that a program isn't just a bunch of
statements in sequence, but is actually a LIST of those statements, so
the whole program becomes effectively a single list.

The really interesting part is that since Lisp programs manipulate lists
as data, and the program is just a list, Lisp programs have the
theoretical ability to edit themselves (assuming the implementation give
access to the list of the program to the program).

Now for the general separation of expression from statement, which isn't
really as applicable to Lisp, since (if I remember right) assignment
doesn't use the = token, so you are less apt to make the mistake, there
are several arguments.

The confusion of assignment for equality comparison is likely on of the
big issues.

Some languages solve the problem by making assignments a special type of
statement, so you can't make the mistake, some of these even make = be
both, so the have to make the distinction.

Some languages (like C) make assignment just a 'normal' operator,  and
either just trust the programmer or use conventions to help generate
warnings (either at compile time or a separate Lint phase). People using
these languages will either like the additional power it give, or curse
the language for the additional opportunities to make mistakes (or
both). Some langagues make the mistake harder to make by using some
symbol other than = for assignment, like Pythons new := symbol.

One advantage of blurring the line between statements and expressions is
power, putting assignments in the middle of an expression, can allow
code to be more compact. Some extensions to C are even trying to take
this farther, and letting the programmer embed a { } block into a
statement as an expression, which is perhaps taking that idea to an extreme.

-- 
Richard Damon

-- 
https://mail.python.org/mailman/listinfo/python-list

Any ideas for a new language inspired to Python?

[Marco Sulla]

Let me first say that I don't know if my post is on topic with the
mailing list. If so, please inform me.

My idea seems to be very simple (so probably it's not simple at all):
a language similar to Python, but statically compiled.

(Yes, I know Cython, RPython, Julia, Rust...)

Since I've not great skill in low-level programming, I'm trying first
to define what I really want.

My core ideas are:

1. Statically compiled (of course...). So if you write:

var a = 1

the variable `a` is an integer and it's value can't be changed to
anything that is not an integer

2. Use of smart pointers. Instead of having a refcount in every
object, the language implementation will use a smart pointer as a sort
of "proxy" to the "real" pointer. This could allow the language
implementation to delete the object only when really necessary (lack
of memory) and/or do JIT optimizations (move the object to a slower or
a faster memory; compute and cache some object attributes, as hash;
remove object duplicates...)

3. functional programming under-the-hood. Users can write also in
imperative style, but in the language implementation only the
functional style is really used. This way *maybe* it's more simple to
write concurrent programs without a GIL.

But I have a lot of doubts. The one that bothers me most is: compile
to binary or to C?

My idea at the beginning was to compile to C code without creating an
AST. Virtually any system has its own C compiler. Maybe it *seems*
more simple, but it's quite more difficult?
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

[Steve Dower]

Steve Dower  added the comment:


New changeset 135de08128a76f49752ac57c316129500275e828 by Steve Dower in branch 
'3.8':
bpo-41490: Update ensurepip to install pip 20.2.1 and setuptools 49.2.1 
(GH-21775)
https://github.com/python/cpython/commit/135de08128a76f49752ac57c316129500275e828


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

[Steve Dower]

Steve Dower  added the comment:

GitHub Actions has decided not to run CI today, so you'll have to look at Azure 
Pipelines for the test failures: 
https://dev.azure.com/Python/cpython/_build/results?buildId=67152=logs=c83831cd-3752-5cc7-2f01-8276919eb334=5a421c4a-0933-53d5-26b9-04b36ad165eb=8012

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Terry Reedy]

On 8/7/2020 11:55 AM, Marco Sulla wrote:


@Chris: note that "real" recursion in Python is not possible,


This is backwards.  Python only does real recursion when one writes 
recursive calls.


since there's no support for tail recursion. 


I am pretty sure that what you mean by 'support' is to turn tail 
recursive syntax into iteration, making it fake recursion.



--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

[issue40275] test.support has way too many imports

[STINNER Victor]

STINNER Victor  added the comment:


New changeset fcce8c649a14f7a81fae82f9f203bb5b5ee0c205 by Hai Shi in branch 
'master':
bpo-40275: Use new test.support helper submodules in tests (GH-21772)
https://github.com/python/cpython/commit/fcce8c649a14f7a81fae82f9f203bb5b5ee0c205


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +20920
pull_request: https://github.com/python/cpython/pull/21775

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +20919
pull_request: https://github.com/python/cpython/pull/21774

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

[Steve Dower]

Steve Dower  added the comment:

Added some test cases to the PR that directly trigger the issue, specifically 
this one:

def test_entered_path_does_not_keep_open(self):
# This is what certifi does on import to make its bundle
# available for the process duration.
c = resources.path('ziptestdata', 'binary.file').__enter__()
self.zip_path.unlink()

All the tests I added pass on 3.9 (with minor tweaks for moved test utils).

To unblock the upcoming releases, I'm going to do the backports first and leave 
this as a release blocker for 3.10.

--
nosy: +brett.cannon, eric.snow
priority: normal -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Python]

On Sat, Aug 08, 2020 at 01:46:28AM +1000, Chris Angelico wrote:
> On Sat, Aug 8, 2020 at 1:38 AM Python  wrote:
> TBH most people won't get the recursive version right the first time
> either.

So FWIW, I/my team don't find this to be true.  I was originally going
to mention this in my previous post but decided to leave it out
for brevity (and in part because I assumed anyone familiar with the
problem already expected it was so).

In fact my team frequently uses Fibonacci as an interview question.
We've been doing so for at least a decade, so we do have a
not-insubstantial sample size.  We find that candidates can much more
easily implement the recursive version correctly, and do so on the
first try roughly 70-80% of the time.  Nearly all candidates choose to
implement the recursive version for that reason.  Those that don't are
pretty familiar with the problem, and choose the iterative version so
they can "show off" their knowledge of the performance benefits.  They
typically also implement the recursive version immediately after,
because it's pretty trivial to do it in most programming languages,
and because they assume the point of the question is to ascertain
whether they grok recursion.  Which is partly true, but only
partly--we use it because it is a short problem that can be quickly
implemented, and demonstrates a few different interesting concepts,
one of which is recursion.

When we do use it, we always follow up with "Can you implement this
iteratively?" (assuming they didn't already). A small percentage
insist that it is impossible.  Most who try (again, roughly 70-80%)
fail on the first try.  Figuring out how to correctly prime the state
is pretty much invariably the sticking point.

These are not students, they are experienced programmers.  This may
explain why they usually can easily implement the recursive version,
but it does not really address why most of them have trouble with the
iterative version. :)

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41504] Add links to asttokens, leoAst, LibCST and Parso to ast.rst

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
nosy: +python-dev
nosy_count: 2.0 -> 3.0
pull_requests: +20918
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21773

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41504] Add links to asttokens, leoAst, LibCST and Parso to ast.rst

[Edward K Ream]

New submission from Edward K Ream :

These links added with the provisional approval of GvR, pending approval of the 
PR.

--
assignee: docs@python
components: Documentation
messages: 375019
nosy: docs@python, edreamleo
priority: normal
severity: normal
status: open
title: Add links to asttokens, leoAst, LibCST and Parso to ast.rst
type: enhancement
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Richard Damon]

On 8/7/20 4:08 PM, Terry Reedy wrote:
> On 8/7/2020 11:46 AM, Chris Angelico wrote:
>
>> My point is that doing Fibonacci recursively is arguably more elegant
>> while being materially worse at performance.
>
> This is a common misconception.  Linear iteration and tail recursion
> are equivalent.  The issue is calculating values once versus multiple
> times.  Here is the fast recursion equivalent to the fast iteration.
>
> def fib(n, pair=(1,0)):
>    previous, current = pair
>    if n:
>   return fib(n-1, (current, previous + current))
>    else:
>   return current
>
> for i in range(10): print(fib(i), end=' ')
> # 0 1 1 2 3 5 8 13 21 34
>
> One can also do the slow algorithm, with wasteful duplication,
> iteratively with one or two stacks of values instead of the hidden
> stack of execution frames.  I don't remember the details right now
> without checking a text.
>
But your example breaks the 'problem' in the recursion that Fibonacci,
when expressed 'naturally', the current value is based on two different
earlier values. You have morphed the definition, using basically the
iterative solution, so that the recursive call to fir(0, ...) doesn't
actually calculate the fib(0) value, but fib(n).

Yes, this shows that you can convert an iterative solution into a
recursive solution with a bit of hand waving, but you still end up with
a program based on the iterative algorithm, not the possibly natural
recursive one.

-- 
Richard Damon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Chris Angelico]

On Sat, Aug 8, 2020 at 6:34 AM Terry Reedy  wrote:
>
> On 8/7/2020 11:46 AM, Chris Angelico wrote:
>
> > My point is that doing Fibonacci recursively is arguably more elegant
> > while being materially worse at performance.
>
> This is a common misconception.  Linear iteration and tail recursion are
> equivalent.  The issue is calculating values once versus multiple times.
>   Here is the fast recursion equivalent to the fast iteration.
>
> def fib(n, pair=(1,0)):
> previous, current = pair
> if n:
>return fib(n-1, (current, previous + current))
> else:
>return current
>
> for i in range(10): print(fib(i), end=' ')
> # 0 1 1 2 3 5 8 13 21 34
>
> One can also do the slow algorithm, with wasteful duplication,
> iteratively with one or two stacks of values instead of the hidden stack
> of execution frames.  I don't remember the details right now without
> checking a text.

I'm aware you can do recursion iteratively and iteration recursively,
but why WOULD you ever do this? The version you've shown here isn't
any more elegant than the purely iterative version, and all it's doing
is implementing a for loop using recursive calls. (Also, it has one
thing that rankles with me, and that's a function signature that is
intentionally different for the recursive calls as for the main call.
You should *never* pass the 'pair' parameter on the initial call, and
it will *always* be passed on the recursive calls.) The idiomatic
recursive version is not tail recursive. Same with the idiomatic
recursive merge sort, which does forking recursion and then tail-calls
the merge operation. (Or you can implement the merge inline, but
whenever I'm explaining it, I prefer to write merge() as a separate
function.)

Knowing how to translate recursion into iteration and vice versa is a
useful skill (picture this: you're trying to build some actual coded
logic into an alias expansion system, where the only conditional you
have is "execute this file" with text substitution in the file name,
and the only looping you have is to re-execute the same file), but
it's not the way to show off the beauty of recursion.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Marco Sulla]

On Fri, 7 Aug 2020 at 22:35, Terry Reedy  wrote:
> This is a common misconception.  Linear iteration and tail recursion are
> equivalent.  The issue is calculating values once versus multiple times.
>   Here is the fast recursion equivalent to the fast iteration.
>
> def fib(n, pair=(1,0)):
> previous, current = pair
> if n:
>return fib(n-1, (current, previous + current))
> else:
>return current
>
> for i in range(10): print(fib(i), end=' ')
> # 0 1 1 2 3 5 8 13 21 34

It seems to me a sort of not persistent caching. If you do:

fib(very_large_number)

without calculating any previous Fibonacci number before, it will be
very slow and you could have a stack overflow.

A language with tail call optimization will execute it faster and with
less memory. Otherwise why asyncio de-facto implemented tail
optimization?

PS: it seems there's a module that implement tail call:
https://github.com/baruchel/tco
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Marco Sulla]

On Fri, 7 Aug 2020 at 19:41, Christian Seberino  wrote:
> I think this is really significant point why more syntax does necessarily 
> mean less readability.

I don't think so. Readability of programming languages was measured
using an objective method, and Python was one of the most readable.

The fact that a grammar is simpler does not mean it's more readable
for human beings. It's surely most simple to optimize for compilers.
For example, RISC instructions in CPUs were simpler than CISC. Even if
Intel tried to defend CISC, modern Intel CPUs have reduced their set
of instructions a lot. Furthermore, the majority of smartphone CPUs
are ARM, that have RISC instructions.
Think also about NAND. You can express the whole boolean logic using
only NAND or NOR. In the beginning, only the Military and NASA
constructed electrical circuits only with NAND or NOR gates. Now there
are electronic circuits made for common people, using only or mainly
NAND gates: they are, for example, pen cards and SSD drives.

But they are not simpler to understand. For example, in math you
*could* think a*b as a+a done b times. But what if a and b are
imaginary numbers?

There are many programmers that just feel Python much more simple to
read and use. Google can tell you a lot about this. Also Rosetta code
can show it to you clearly:
http://www.rosettacode.org/wiki/Rosetta_Code

It seems to me that you want to convince your colleagues that Python
is better than Lisp. I think that:

1. there's not a "best". The "best" depends heavily on what you need.
2. the people you have to convince is only yourselves
3. to convince yourselves, you have to try. "Refuse the temptation to guess" :)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[2QdxY4RzWzUUiLuE]

On 2020-08-07 at 13:43:06 -0500,
Wyatt Biggs  wrote:

> > It's also probably significantly slower, so you'd likely still want to
> > use the iterative version
> 
> Generalizing this to the majority of recursive functions/methods, are
> their iterative counterparts more efficient? (I say "majority of"
> because I've personally encountered one or two recursive
> functions/methods that were either very difficult for me to translate
> to iteration or just not possible with my skill level at the time)

As usual, it depends.  :-)

Often, a recursive algorithn in the *source* code is rewritten/optimized
by a compiler into an iterative algorithm in the *object* code.  And
sometimes, iterative code is rewritten into straight line imperative
code (i.e., loop unrolling, constant folding, etc.).  At runtime, that
stack of pending items has to be somewhere, and the hardware stack
(where the CPU-level return addresses are stored) can be as good a place
as any, which means that the recursive version *might* be as fast or
faster than the iterative version, under certain circunstances.

> For just a moment, allow me to abstract this argument to include
> languages other than Lisp I'm better versed in. Older languages, like
> Java and C, required explicit typing for their variables, explicit
> output types for their methods, and semicolons and brackets instead of
> utilized whitespace.  Please correct me if I'm wrong, but this system
> was primarily for saving memory because computers were far less
> powerful when these languages were born. Python, being a relatively
> young language, is free from these shackles and was built to run on
> more modern computers where bits and bytes are not a common
> constraint.

Lisp is older than both C and Java (by decades), and there's still no
explicit typing for variables.  In Lisp, the data has a type, and the
"variables" are just names for it (just like Python, or rather Python is
just like Lisp).

> That said, if I were to ever design a software I planned on sharing, I
> would write it in one of the more space-friendly languages.

Space-friendly?
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41109] subclasses of pathlib.PurePosixPath never call __init__ or __new__

[Jeffrey Kintscher]

Change by Jeffrey Kintscher :


--
nosy: +Jeffrey.Kintscher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Terry Reedy]

On 8/7/2020 11:46 AM, Chris Angelico wrote:


My point is that doing Fibonacci recursively is arguably more elegant
while being materially worse at performance.


This is a common misconception.  Linear iteration and tail recursion are 
equivalent.  The issue is calculating values once versus multiple times. 
 Here is the fast recursion equivalent to the fast iteration.


def fib(n, pair=(1,0)):
   previous, current = pair
   if n:
  return fib(n-1, (current, previous + current))
   else:
  return current

for i in range(10): print(fib(i), end=' ')
# 0 1 1 2 3 5 8 13 21 34

One can also do the slow algorithm, with wasteful duplication, 
iteratively with one or two stacks of values instead of the hidden stack 
of execution frames.  I don't remember the details right now without 
checking a text.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

[issue5141] C API for appending to arrays

[Jeffrey Kintscher]

Change by Jeffrey Kintscher :


--
nosy: +Jeffrey.Kintscher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[2QdxY4RzWzUUiLuE]

On 2020-08-07 at 21:54:35 +0200,
Marco Sulla  wrote:

> On Fri, 7 Aug 2020 at 19:48, Richard Damon  wrote:

> Christian Seberino just expressed a doubt about how a clear separation
> between a statement and an expression is quite desiderable in the
> "real" programming world. And I tried to explain it with the
> assignment operation, since a ton of programmers feel very frustrated
> about reading code of other programmers with assignment in an if
> statement. I'm quite sure that they thought, as I thought: "What do
> this?"
> Worse when their program failed and they discovered that they wrote
> `if (a=b)` instead of `if (a==b)`.

Don't conflate the concept with the syntax.  The fact that Python now
has "the walrus operator" says that assignment expressions are useful.
The issue with the C version is that the assignment and comparison
operators look too much alike and using the wrong one can cause *silent*
catastrophes (although modern C compilers can and do emit appropriate
warnings or errors, if you ask them nicely).

> I'm just more curious about why Lisp programmers think that it's
> better to not make a hard distinction between statements and
> expressions.

Simplicity of syntax.  Very few languages have a simpler syntax than
Lisp (Ook, et al, notwithstanding).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[2QdxY4RzWzUUiLuE]

On 2020-08-07 at 11:02:50 -0700,
Christian Seberino  wrote:

> > In Lisp, your hammer is the list.
> 
> > In, say, Java, your tool is classes and inheritance.
> 
> And yet if Lisp or Java programmers were here they would say their
> languages //are// multi-paradigm too.  For example, Lisp has the
> Common Lisp Object System (CLOS) and Java has the Vector class and so on.

Of what is "Java has the Vector class" an example?  That the tools in
Java are classes and inheritance?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Marco Sulla]

On Fri, 7 Aug 2020 at 19:48, Richard Damon  wrote:
> The difference is that the two languages define 'expression' differently. 
> [...]

I don't know if this is interesting or pertinent to the topic.

Christian Seberino just expressed a doubt about how a clear separation
between a statement and an expression is quite desiderable in the
"real" programming world. And I tried to explain it with the
assignment operation, since a ton of programmers feel very frustrated
about reading code of other programmers with assignment in an if
statement. I'm quite sure that they thought, as I thought: "What do
this?"
Worse when their program failed and they discovered that they wrote
`if (a=b)` instead of `if (a==b)`.

I'm just more curious about why Lisp programmers think that it's
better to not make a hard distinction between statements and
expressions.
-- 
https://mail.python.org/mailman/listinfo/python-list

Vulture 1.6

[Jendrik Seipp]

Vulture - Find dead code


Vulture finds unused code in Python programs. This is useful for
cleaning up and finding errors in large code bases. If you run Vulture
on both your library and test suite you can find untested code.

Due to Python's dynamic nature, static code analyzers like Vulture are
likely to miss some dead code. Also, code that is only called
implicitly may be reported as unused. Nonetheless, Vulture can be a
very helpful tool for higher code quality.


Download

https://github.com/jendrikseipp/vulture
http://pypi.python.org/pypi/vulture


Features

* fast: uses static code analysis
* tested: tests itself and has complete test coverage
* complements pyflakes and has the same output syntax
* sorts unused classes and functions by size with ``--sort-by-size``
* supports Python 2.7 and Python 3.5+


News

* Differentiate between functions and methods (Jendrik Seipp, #112, #209).
* Move from Travis to GitHub actions (RJ722, #211).


Cheers
Jendrik




___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[issue41478] Empty representation of AssertionError

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Since you should print the exception class anyway, I think that using repr 
should be sufficient and that this issue should be closed.  In any case, the 
current behavior does not seem like a bug.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Wyatt Biggs]

> It's also probably significantly slower, so you'd likely still want to
> use the iterative version

Generalizing this to the majority of recursive functions/methods, are their
iterative counterparts more efficient? (I say "majority of" because I've
personally encountered one or two recursive functions/methods that were
either very difficult for me to translate to iteration or just not possible
with my skill level at the time)

> It is related to the old saying "If all you have is a hammer, then
> everything looks like a nail".

Using this saying in the context of programming languages is extremely
accurate! Because Python can be object oriented or data oriented, it is a
large toolbox capable of tackling an even larger set of problems quite
simply.

I've never personally used Lisp, but I have used Java a bit. Even just the
strict object-oriented nature of Java was fairly cumbersome. The freedom,
fluidity, and the dynamic nature of Python are the reasons it's my
preferred language.

For just a moment, allow me to abstract this argument to include languages
other than Lisp I'm better versed in. Older languages, like Java and C,
required explicit typing for their variables, explicit output types for
their methods, and semicolons and brackets instead of utilized whitespace.
Please correct me if I'm wrong, but this system was primarily for saving
memory because computers were far less powerful when these languages were
born. Python, being a relatively young language, is free from these
shackles and was built to run on more modern computers where bits and bytes
are not a common constraint.

That said, if I were to ever design a software I planned on sharing, I
would write it in one of the more space-friendly languages.

Thank y'all for the great reading about Lisp vs Python and letting me get
very off-topic.

Best,
Wyatt Biggs
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41478] Empty representation of AssertionError

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Ilya, in the future, when responding by email, please delete the message you 
are responding to.  It is already present on the web page.

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41460] Translation Error in in Functional Programming HOWTO page

[Terry J. Reedy]

Terry J. Reedy  added the comment:

This tracker is only for the original English version of the docs.  The 
translations are by a different group with different tools and workflow.  This 
page
https://docs.python.org/ja/3/bugs.html#
should not literally translate the instructions for the English version.

Julien, I thought there was something about translations in the devguide but 
cannot find it.  https://devguide.python.org/docquality/ would seen line a good 
place.

--
nosy: +terry.reedy
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

[Steve Dower]

Steve Dower  added the comment:

Okay, I've tracked it down to the new importlib.readers.ZipReader class keeping 
the zip file open, presumably until it gets GC'd. This is used by certifi to 
extract the CA certs from the whl when ensurepip is doing the self-install from 
the mounted wheel.

Jason is already on this bug, which is convenient :)

I haven't yet figured out whether there's a convenient way for the reader to 
not keep the ZIP open for as long as it exists, but I think that's going to be 
the safest fix.

We should definitely fix this one ourselves without forcing users to make 
changes to accommodate. As I mentioned above, it's only in 3.10 right now, but 
it's blocking updated pip and setuptools versions downlevel.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41455] Python Devguide differs from python docs

[Terry J. Reedy]

Change by Terry J. Reedy :


--
versions:  -Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40934] Default RLock does not work well for Manager Condition

[Irit Katriel]

Irit Katriel  added the comment:

I was unable to reproduce what you're seeing on windows 10, master branch. 

Please provide more information regarding the python version and system you are 
seeing this problem on.

--
nosy: +iritkatriel

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41490] Update bundled pip to 20.2.1 and setuptools to 49.2.1

[Steve Dower]

Steve Dower  added the comment:

The issue above doesn't appear to repro on 3.9, so I guess master has started 
leaking a file handle, presumably in zipimport.

I'll see what I can track down, but can't be sure I'll have enough time to get 
it done for RC, so if anyone else wants to help out feel free.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Christian Seberino]

> In Lisp, your hammer is the list.

> In, say, Java, your tool is classes and inheritance.

And yet if Lisp or Java programmers were here they would say their
languages //are// multi-paradigm too.  For example, Lisp has the
Common Lisp Object System (CLOS) and Java has the Vector class and so on.

Maybe Python somehow gives more paradigms //better// syntax support 
whereas in Lisp and Java they are somewhat "bolted on" and not done 
as well?

cs
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[2QdxY4RzWzUUiLuE]

On 2020-08-07 at 10:00:25 -0600,
Akkana Peck  wrote:

> I wrote:
> > > > Trying to maintain that recursive list of unclosed lists in your
> > > > brain is fun. It stretches the brain in interesting ways.
> > > > [ ... ] But I never found Lisp code very maintainable, [ ... ]
> 
> 2qdxy4rzwzuui...@potatochowder.com writes:
> > "[R]ecursive list of unclosed lists"?  Can you (whoever you are) expand
> > on that?  Yes, if you eschew helper functions and local variables, then
> > you can end up with depply nested code, but that's true in any language.
> 
> To pick a function that I know is readily available in lots
> of languages, let's look at a couple implementations of the
> Haversine function (from http://rosettacode.org/wiki/Haversine_formula).
> Comments to illustrate language differences are mine.
> 
> Here's the Common Lisp version.
> 
> (defparameter *earth-radius* 6372.8)
> (defparameter *rad-conv* (/ pi 180))
> ;; Minor complication right off: assignment of variables or constants
> ;; is completely different depending on whether you're
> ;; defining something in general, like here, or only for
> ;; a subsequent clause, like the let* functions later on.
> 
> (defun deg->rad (x)
>   (* x *rad-conv*))
> ;; Prefix notation for arithmatic is unfamiliar to most people
> ;; since that's not what we learn in school, so that's a first
> ;; hurdle for readability.

My first calculator was RPN, so prefix wasn't really a hurdle.  ;-)

> (defun haversine (x)
>   (expt (sin (/ x 2)) 2))
> ;; To grok this function you need to have four levels of
> ;; parentheses simultaneously open in your head.
> 
> (defun dist-rad (lat1 lng1 lat2 lng2)
>   (let* ((hlat (haversine (- lat2 lat1)))
> ;; Then there's the let vs. let* issue,
> ;; no big deal for experienced programmers
> ;; but not entirely easy to explain to a beginner.
> ;; On the other hand, Python has its own confusing points on
> ;; that issue, like when you need to specify "global".
>  (hlng (haversine (- lng2 lng1)))
>  (root (sqrt (+ hlat (* (cos lat1) (cos lat2) hlng)
>;; for that expression you need 7 levels of mental parens open
> (* 2 *earth-radius* (asin root
> 
> (defun dist-deg (lat1 lng1 lat2 lng2)
>   (dist-rad (deg->rad lat1)
> (deg->rad lng1)
> (deg->rad lat2)
> (deg->rad lng2)))
> 
> ;; End Lisp example
> 
> Seven levels of unclosed lists that you need to keep in your head
> in order to read and understand the program at its deepest point.

Seven?  Oh, there it is, inside the calculation of root in dist-rad.

> Here's the same thing in Python:

It's equivalent.  It's not the same.  (For example, in Lisp, the
parameters are clearly marked as such by the form defparameter, but in
Python, the parameters and the temporary variables are created with the
same syntax.  When I read the Python code, how can I tell that R is a
parameter rather than a temporary variable?  But that's not related to
the question of open parentheses.  Also, the Lisp example separates the
conversion to radians into a helper function, but the Python version
doesn't.)

> from math import radians, sin, cos, sqrt, asin
>  
> def haversine(lat1, lon1, lat2, lon2):
> R = 6372.8  # Earth radius in kilometers
>  
> dLat = radians(lat2 - lat1)
> dLon = radians(lon2 - lon1)
> lat1 = radians(lat1)
> lat2 = radians(lat2)
>  
> a = sin(dLat / 2)**2 + cos(lat1) * cos(lat2) * sin(dLon / 2)**2
> c = 2 * asin(sqrt(a))
>  
> return R * c
> 
> # end Python example
> 
> The equation is still the same equation, but it looks a lot more
> like the equation you'd see in a math textbook, or write on a
> homework assignment, modulo notational issues like ** instead of
> superscripts. The deepest level of parentheses you ever need to
> keep in your head is two, but the second level is just a very
> simple function call, sqrt(a). The indentation level (the program
> structure) never gets beyond one.
> 
> On the other hand, your brain does need to keep track of more
> intermediate variables (dLat, dLon etc.) Perhaps some people might
> find that harder.

On the other other hand, there's no confusing operator precedence rules
in Lisp.  We know the basic arithmetic operators from grade school, but
who can remember whether & or and bind more tightly than or and | (sic)?
Instead of memory, some programmers use *parentheses* to *clarify*.  ;-)

> And yes, you could write the Lisp to look more like the Python or
> vice versa. You're welcome to try that, but I predict you'll find that
> even if you use the same number of intermediate variables, Lisp will
> always require you to keep that larger mental stack of open parens.

A larger stack of *parentheses*, yes, but I don't think a larger stack.

Python:  def f(x):
 y = b + m * x
 return y

Lisp:(defun f (x)
   (let ((y (+ b (* m x
   

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Richard Damon]

On 8/7/20 12:52 PM, Marco Sulla wrote:
> About statement vs expression: maybe you, Richard and
> 2QdxY4RzWzUUiLuE, are right, maybe not. This is hard to say, since the
> official C documentation is not public and you have to pay a small fee
> to obtain it.
>
> Anyway, I said "in C, the assignment is a statement that can be used
> in expression". You're saying "No, in C the assignment IS an
> expression".
> I don't see the difference. If the assignment is a statement that can
> be used as an expression, Python simply forbids that. If in C the
> assignment is an expression, Python on the contrary treats it as a
> statement.
>
> The only real difference is that Python not only clearly separated the
> concepts of statement and expression, but also _where_ you can use
> them, for practical reasons.

The difference is that the two languages define 'expression' differently.

In Python, the = operation is not part of the general expression syntax,
but is specifically allowed only in specific locations.

In C, the = operator is exactly like all the other operators in how it
is parsed, it just has some restrictions on the type that can be on the
left side, and that it changes that value (but then, so do a few other
operators like ++)

In C, there is NO 'statement' called an assignment statement, because
assignments are just parts of expressions, so the statement type
'expression statement' handles both.

In Python, because assignment is NOT just part of an expression, it
needs a separate statement type to handle assignments, to allow them.


(BTW, while the official C Standards are only available at a price, the
draft standards prepared during the development of the final are all
available for free and the last published draft standard is almost
always virtually identical to the final released standard, so most
people will just use those. People who really need the official versions
can pay the price for it, and for them, that price isn't that high to
them). I keep the free downloads of all the major version of the C and
C++ language available on my computer.

-- 
Richard Damon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Christian Seberino]

> Another point to consider is the ecosystem of your language. If you 
> install Python, then you get basic math, I/O, a GUI toolkit, network 
> libraries, ... In more "traditional" languages like C or Lisp, you get 
> math and I/O, period. For everything else you need to hunt down a 
> library. Therefore, solve the task "download the gimp installer from 
> github via https" requires 2,3 lines in Python and installing a 
> (possibly complex) library for the same task in Lisp or C.
> 
>   Christian

I like this post so much I printed it.  It seems you're saying
Python has lots of syntax forms or "mini-languages" in it and *that* is a big
reason why you can typically find syntax that makes an arbitrary
problem more readable in Python. On the other hand, Lisp tries
to everything with less syntax forms (paradigms) and hence it is less readable.

A Lisp person would probably say that they can create domain specific
languages (DSLs) for whatever they wish.  However, many people like
that Python has so many standardized "DSLs" ready to go for you from
the start.

I think this is really significant point why more syntax does necessarily mean 
less readability.

I would just add that Clojure finally solved the ecosystem problem with 
Lisp by giving it access to the Java libraries.

cs

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue40275] test.support has way too many imports

[hai shi]

Change by hai shi :


--
pull_requests: +20917
pull_request: https://github.com/python/cpython/pull/21772

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Christian Seberino]

Your iterative fib(x) code and comment was quite nice.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Marco Sulla]

On Fri, 7 Aug 2020 at 18:48, Chris Angelico  wrote:
> Tail call optimization (there's no reason to restrict it to recursion
> alone) is something a Python implementation could choose to do, but
> the trouble is that full optimization tends to destroy traceback
> information

Indeed this is implemented in asyncio.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Marco Sulla]

About statement vs expression: maybe you, Richard and
2QdxY4RzWzUUiLuE, are right, maybe not. This is hard to say, since the
official C documentation is not public and you have to pay a small fee
to obtain it.

Anyway, I said "in C, the assignment is a statement that can be used
in expression". You're saying "No, in C the assignment IS an
expression".
I don't see the difference. If the assignment is a statement that can
be used as an expression, Python simply forbids that. If in C the
assignment is an expression, Python on the contrary treats it as a
statement.

The only real difference is that Python not only clearly separated the
concepts of statement and expression, but also _where_ you can use
them, for practical reasons.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Chris Angelico]

On Sat, Aug 8, 2020 at 2:44 AM Richard Damon  wrote:
>
> On 8/7/20 11:46 AM, Chris Angelico wrote:
> > My point is that doing Fibonacci recursively is arguably more elegant
> > while being materially worse at performance, but there are other
> > examples that are fundamentally recursive, are just as elegant (merge
> > sort: "fracture the array in half, sort each half, then merge them"),
> > and can't be done better iteratively. So IMO Fibonacci is a flawed
> > demonstration of what is a very valid point ("recursion can be really
> > elegant"), and other examples would serve the purpose better.
>
> I would say that doing the recursive Fibonacci version can be an
> important step (near the end) of the recursion unit as a learning
> experience on some of the dangers of recursion (like turning an O(N)
> problem into O(2**N). It perhaps can lead to discussions on optimization
> techniques (like caching results) that can alleviate some of the issues
> (at other costs).

Yes, I'd definitely agree. It's great to have some demonstrations of
the advantages and disadvantages of recursion, and Fibonacci offers
both in one tidy package :)

Here's another really great example: triangle numbers.

def tri(n):
if n < 1: return 0
return n + tri(n - 1)

def tri(n):
tot = n
for i in range(n):
tot += i
return tot

def tri(n):
return functools.reduce(operator.add, range(n + 1))

def tri(n):
return n * (n + 1) // 2

A great demo of different ways to think about the same problem, with a
nice O(1) reference at the end that you can validate them against :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Chris Angelico]

On Sat, Aug 8, 2020 at 2:21 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2020-08-07 at 17:55:45 +0200,
> Marco Sulla  wrote:
> > @Chris: note that "real" recursion in Python is not possible, since
> > there's no support for tail recursion. Maybe something similar can be
> > done using async functions.
>
> Python has real recursion.  Whether or not there's tail recursion on the
> inside is an implementation detail.

More specifically: Python has real recursion. Whether or not tail
recursion is optimized away is an implementation detail.

Tail call optimization (there's no reason to restrict it to recursion
alone) is something a Python implementation could choose to do, but
the trouble is that full optimization tends to destroy traceback
information, so it's often not worth doing. And the cases where
partial optimization is of value just aren't compelling enough for
anyone to implement it into CPython, nor any other major
implementation (to my knowledge). The biggest uses for TCO tend to be
the situations where recursion is the wrong solution to the problem.

But recursion? Recursion is definitely possible.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Richard Damon]

On 8/7/20 11:46 AM, Chris Angelico wrote:
> My point is that doing Fibonacci recursively is arguably more elegant
> while being materially worse at performance, but there are other
> examples that are fundamentally recursive, are just as elegant (merge
> sort: "fracture the array in half, sort each half, then merge them"),
> and can't be done better iteratively. So IMO Fibonacci is a flawed
> demonstration of what is a very valid point ("recursion can be really
> elegant"), and other examples would serve the purpose better.

I would say that doing the recursive Fibonacci version can be an
important step (near the end) of the recursion unit as a learning
experience on some of the dangers of recursion (like turning an O(N)
problem into O(2**N). It perhaps can lead to discussions on optimization
techniques (like caching results) that can alleviate some of the issues
(at other costs).

-- 
Richard Damon

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41433] Logging libraries BufferingHandler flushed twice at shutdown

[Irit Katriel]

Irit Katriel  added the comment:

I think this may be the same issue as in:

https://stackoverflow.com/questions/47549602/logging-handlers-bufferinghandler-subclassed-handler-showing-log-twice

Did you call flush on super()?

If this is not the same issue, please post a code snippet to explain what 
exactly you are seeing.

--
nosy: +iritkatriel

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41303] perf_counter result does not count system sleep time in Mac OS

[STINNER Victor]

STINNER Victor  added the comment:

> For time.time in Windows, Python 3.10 should switch to using 
> GetSystemTimePreciseAsFileTime [3] instead of GetSystemTimeAsFileTime. 

It's already tracked by bpo-19007: "precise time.time() under Windows 8: use 
GetSystemTimePreciseAsFileTime".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Richard Damon]

On 8/7/20 11:55 AM, Marco Sulla wrote:
> Commonly, in imperative languages like C, you can write
>
> if (a = b) {...}
>
> This is allowed in C, even if a = b is not an expression, but an
> assignment statement. 99% of times you simply wrong and wanted:

But in C (and related languages) it IS an expression, and C doesn't have
an 'assignment statement' but an 'expression statement', which is the
source of the issue. = is just another operator, which happens to modify
the value of its left operand.

Python makes assignment a full top level type of statement, so = can't
be misused in an expression thinking it means an equality test (and then
added recently the := operator, so that for the cases you actually want
to do assignments in the middle of an expression you can).

-- 
Richard Damon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[2QdxY4RzWzUUiLuE]

On 2020-08-07 at 17:55:45 +0200,
Marco Sulla  wrote:

> On Fri, 7 Aug 2020 at 17:14, Christian Seberino  wrote:

> Commonly, in imperative languages like C, you can write
> 
> if (a = b) {...}
> 
> This is allowed in C, even if a = b is not an expression ...

In C, a = b *is* an expression.  An assignment expression that uses the
assignment operator.  See
.

> ... 99% of times you simply wrong and wanted:

> if (a == b)

Where did 99% come from?

> Python separates statements and expressions, so where you expect an
> expression, you can't write a statement.

Yes.

> Maybe Lisp does not separate expressions and statements because it
> supports both functional and imperative programming ...

It's not a matter of separating expressions from statements.  Lisp
doesn't have statements.  It only has expressions.  If you choose to
write imperative code in Lisp, all you're really doing is using the
expressions for their side effects rather than their values.

> PS: Recently there's an exception: if you *really* want an assignment
> when an expression is expected, you can use the "walrus" := operator.
> IMO it renders the code less readable and I'm not sure about it's
> usefulness.

It makes some code more concise.  Readability is in the eye of the
beholder.

> @Chris: note that "real" recursion in Python is not possible, since
> there's no support for tail recursion. Maybe something similar can be
> done using async functions.

Python has real recursion.  Whether or not there's tail recursion on the
inside is an implementation detail.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41473] test_gdb fails on AMD64 Fedora Rawhide 3.x

[miss-islington]

miss-islington  added the comment:


New changeset 5e12a5b82230cfa34a9c32f58467770e2076313c by Miss Islington (bot) 
in branch '3.9':
bpo-41473: Skip test_gdb with gdb 9.2 to work around gdb bug (GH-21768)
https://github.com/python/cpython/commit/5e12a5b82230cfa34a9c32f58467770e2076313c


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41473] test_gdb fails on AMD64 Fedora Rawhide 3.x

[miss-islington]

miss-islington  added the comment:


New changeset 87bc22051fcfcf181160d06a57ac2b16ee071f8f by Miss Islington (bot) 
in branch '3.8':
bpo-41473: Skip test_gdb with gdb 9.2 to work around gdb bug (GH-21768)
https://github.com/python/cpython/commit/87bc22051fcfcf181160d06a57ac2b16ee071f8f


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Akkana Peck]

I wrote:
> > > Trying to maintain that recursive list of unclosed lists in your
> > > brain is fun. It stretches the brain in interesting ways.
> > > [ ... ] But I never found Lisp code very maintainable, [ ... ]

2qdxy4rzwzuui...@potatochowder.com writes:
> "[R]ecursive list of unclosed lists"?  Can you (whoever you are) expand
> on that?  Yes, if you eschew helper functions and local variables, then
> you can end up with depply nested code, but that's true in any language.

To pick a function that I know is readily available in lots
of languages, let's look at a couple implementations of the
Haversine function (from http://rosettacode.org/wiki/Haversine_formula).
Comments to illustrate language differences are mine.

Here's the Common Lisp version.

(defparameter *earth-radius* 6372.8)
(defparameter *rad-conv* (/ pi 180))
;; Minor complication right off: assignment of variables or constants
;; is completely different depending on whether you're
;; defining something in general, like here, or only for
;; a subsequent clause, like the let* functions later on.

(defun deg->rad (x)
  (* x *rad-conv*))
;; Prefix notation for arithmatic is unfamiliar to most people
;; since that's not what we learn in school, so that's a first
;; hurdle for readability.

(defun haversine (x)
  (expt (sin (/ x 2)) 2))
;; To grok this function you need to have four levels of
;; parentheses simultaneously open in your head.

(defun dist-rad (lat1 lng1 lat2 lng2)
  (let* ((hlat (haversine (- lat2 lat1)))
;; Then there's the let vs. let* issue,
;; no big deal for experienced programmers
;; but not entirely easy to explain to a beginner.
;; On the other hand, Python has its own confusing points on
;; that issue, like when you need to specify "global".
 (hlng (haversine (- lng2 lng1)))
 (root (sqrt (+ hlat (* (cos lat1) (cos lat2) hlng)
   ;; for that expression you need 7 levels of mental parens open
(* 2 *earth-radius* (asin root

(defun dist-deg (lat1 lng1 lat2 lng2)
  (dist-rad (deg->rad lat1)
(deg->rad lng1)
(deg->rad lat2)
(deg->rad lng2)))

;; End Lisp example

Seven levels of unclosed lists that you need to keep in your head
in order to read and understand the program at its deepest point.

Here's the same thing in Python:

from math import radians, sin, cos, sqrt, asin
 
def haversine(lat1, lon1, lat2, lon2):
R = 6372.8  # Earth radius in kilometers
 
dLat = radians(lat2 - lat1)
dLon = radians(lon2 - lon1)
lat1 = radians(lat1)
lat2 = radians(lat2)
 
a = sin(dLat / 2)**2 + cos(lat1) * cos(lat2) * sin(dLon / 2)**2
c = 2 * asin(sqrt(a))
 
return R * c

# end Python example

The equation is still the same equation, but it looks a lot more
like the equation you'd see in a math textbook, or write on a
homework assignment, modulo notational issues like ** instead of
superscripts. The deepest level of parentheses you ever need to
keep in your head is two, but the second level is just a very
simple function call, sqrt(a). The indentation level (the program
structure) never gets beyond one.

On the other hand, your brain does need to keep track of more
intermediate variables (dLat, dLon etc.) Perhaps some people might
find that harder.

And yes, you could write the Lisp to look more like the Python or
vice versa. You're welcome to try that, but I predict you'll find that
even if you use the same number of intermediate variables, Lisp will
always require you to keep that larger mental stack of open parens.

> Because of Lisp's simple syntax, text editors can nearly completely
> relieve the programmer from the tedium of indenting and formatting, and
> even closing parenthesis, which also highlights missing/extra/unbalanced
> parentheses pretty quickly.

I find that emacs mostly does a pretty good job of figuring out
indentation, closing parentheses, highlighting syntax errors and
similar boilerplate in Python. Maybe you need a smarter text editor?

But my comment about levels of parens had nothing to do with editors.
To understand the code, you need to build up that list/tree
structure in your head, because that's what defines the program logic.

Again, my point isn't that Python is a better or simpler language
than Lisp. It's that it stretches the brain in different ways, and that
I would guess (but it's just a guess) that most beginners will find
the Python approach more intuitive and easier to learn, since it
emphasizes things they've done before (simple declarative statements,
equations written out in a familiar way) rather than new and unfamiliar
concepts (prefix notation, deeply nested parentheses, tree structures).

...Akkana
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Christian Gollwitzer]

Am 06.08.20 um 17:13 schrieb Christian Seberino:

Python is my favorite language and the easiest to use in my opinion.

Lisp has a far simpler grammar and syntax.   A beginner I think could
learn Lisp much faster than Python.

Therefore, it seems like Lisp *should* be easier to work with and more 
readable.  I don't feel like it is easier to use but I can't see *why* that is.

My best guess.

   Lisp pros: simpler syntax
   Lisp cons: prefix notation, lots more parentheses

   My hypothesis is that the cons slightly outweigh the pros of Lisp
which is why Python is easier to work with and is more readable in 
the end?


I concur with Chris Angelico there. The word "simple" is ambiguous.
"Simpler" for the human is not the same as "simpler" for the computer

In Lisp, the grammar is "simpler", meaining that the definition of the 
grammar is shorter; this makes it simpler for the compiler to parse, and 
to write a compiler for Lisp.


In Python, the grammar is very complicated, writing a compiler for 
Python is a big task - still it is "simpler" to translate your ideas 
into Python


It is related to the old saying "if all you have is hammer, then 
everything looks like a nail". In Lisp, your hammer is the list. So you 
are forced to map your problems onto list processing. For some things 
that works well, for others not so well (infix math) .


In, say, Java, your tool is classes and inheritance. There are big books 
on "design patterns" that teach you how to map your problem onto 
inheritance. For some things, that works well, for others not so well 
("abstract factory", "visitor pattern", )


In Python, you have an awfully complex of syntax, so your toolset 
includes list processing, lambda, inheritance, string interpolation, 
decorators
This makes it possible to use the tool which best matches the language 
of your problem. Many problem domains have their own language, e.g. 
matrix math for linear algebra, pipes for sequential stream processing 
etc. The easier it is to translate the algorithm on paper into the 
runnable version, the


Lisp is still impressive, because it is very good at metaprogramming. It 
shows how far you can get with so little syntax.


Another point to consider is the ecosystem of your language. If you 
install Python, then you get basic math, I/O, a GUI toolkit, network 
libraries, ... In more "traditional" languages like C or Lisp, you get 
math and I/O, period. For everything else you need to hunt down a 
library. Therefore, solve the task "download the gimp installer from 
github via https" requires 2,3 lines in Python and installing a 
(possibly complex) library for the same task in Lisp or C.


Christian

--
https://mail.python.org/mailman/listinfo/python-list

[issue41477] test_genericalias fails if ctypes is missing

[STINNER Victor]

STINNER Victor  added the comment:


New changeset f44693eaed3b9d91a6e415d48224fd4750b59366 by Victor Stinner in 
branch 'master':
bpo-41477: Make ctypes optional in test_genericalias (GH-21766)
https://github.com/python/cpython/commit/f44693eaed3b9d91a6e415d48224fd4750b59366


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41473] test_gdb fails on AMD64 Fedora Rawhide 3.x

[miss-islington]

Change by miss-islington :


--
pull_requests: +20916
pull_request: https://github.com/python/cpython/pull/21770

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41473] test_gdb fails on AMD64 Fedora Rawhide 3.x

[STINNER Victor]

STINNER Victor  added the comment:


New changeset e27a51c11e10d5df79b3e48dc3e7bfedfad5a794 by Victor Stinner in 
branch 'master':
bpo-41473: Skip test_gdb with gdb 9.2 to work around gdb bug (GH-21768)
https://github.com/python/cpython/commit/e27a51c11e10d5df79b3e48dc3e7bfedfad5a794


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41473] test_gdb fails on AMD64 Fedora Rawhide 3.x

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 1.0 -> 2.0
pull_requests: +20915
pull_request: https://github.com/python/cpython/pull/21769

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Marco Sulla]

On Fri, 7 Aug 2020 at 17:14, Christian Seberino  wrote:
> This is an interesting observation.  I've heard people say the fact that
> Python has both expressions and statements is a negative.  (Lisp only
> has expressions.)

Commonly, in imperative languages like C, you can write

if (a = b) {...}

This is allowed in C, even if a = b is not an expression, but an
assignment statement. 99% of times you simply wrong and wanted:

if (a == b)

Python separates statements and expressions, so where you expect an
expression, you can't write a statement.

Maybe Lisp does not separate expressions and statements because it
supports both functional and imperative programming, while Python is
mainly an imperative language with some functional features. Not sure
about this, since I never used any Lisp dialect and I've not yet used
function programming in the real world.

PS: Recently there's an exception: if you *really* want an assignment
when an expression is expected, you can use the "walrus" := operator.
IMO it renders the code less readable and I'm not sure about it's
usefulness.

@Chris: note that "real" recursion in Python is not possible, since
there's no support for tail recursion. Maybe something similar can be
done using async functions.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Chris Angelico]

On Sat, Aug 8, 2020 at 1:38 AM Python  wrote:
>
> On Fri, Aug 07, 2020 at 04:23:42PM +1000, Chris Angelico wrote:
> > On Fri, Aug 7, 2020 at 11:11 AM Python  wrote:
> > > Pretty straightforward.  Now try yourself to write the iterative
> > > version.
> >
> > It might look slightly better to a mathematician, but it's so
> > abysmally inefficient (unless you add extra layers of indirection)
> > that it's not really a good example.
>
> Yes, I did say more or less that... but efficiency was not the point.
> Understanding was the point.
>
> > The iterative version seeds the algorithm and lets it run:
>
> Sure Chris, I fully expected YOU to get this on the first try, but the
> average programmer tends not to.  My team uses it as an interview
> question fairly often, and I'd venture a guess that upward of 80% of
> candidates get it wrong on their first try.   The recursive version
> is typically much easier to understand intuitively, not just for
> mathemeticians, because it more or less restates in simple,
> straightforward code what the natural language definition of the
> Fibonacci sequence is, rather efficiently (not efficiency of
> execution, efficiency of converting natural language to code).
>

My point is that doing Fibonacci recursively is arguably more elegant
while being materially worse at performance, but there are other
examples that are fundamentally recursive, are just as elegant (merge
sort: "fracture the array in half, sort each half, then merge them"),
and can't be done better iteratively. So IMO Fibonacci is a flawed
demonstration of what is a very valid point ("recursion can be really
elegant"), and other examples would serve the purpose better.

TBH most people won't get the recursive version right the first time
either. And that's not a problem. I actually didn't get the iterative
version perfect right away (had an off-by-one on the loop counter),
and tested it before posting. Every student I've worked with has had
the same thing - something doesn't work the first time, even with the
most brilliant students - so they test, they debug, and then they
refine their code. I'm not some sort of coding deity that gets things
right the first time; the medium of email lets me hide the
testing/debugging step and just post working code :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41473] test_gdb fails on AMD64 Fedora Rawhide 3.x

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +patch
pull_requests: +20912
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21768

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41473] test_gdb fails on AMD64 Fedora Rawhide 3.x

[STINNER Victor]

STINNER Victor  added the comment:

Since I identified a gdb regression in gdb 9.2, I wrote PR 21768 to skip 
test_gdb on gdb >= 9.2 until the bug is fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=1866884

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Python]

On Fri, Aug 07, 2020 at 04:23:42PM +1000, Chris Angelico wrote:
> On Fri, Aug 7, 2020 at 11:11 AM Python  wrote:
> > Pretty straightforward.  Now try yourself to write the iterative
> > version.
> 
> It might look slightly better to a mathematician, but it's so
> abysmally inefficient (unless you add extra layers of indirection)
> that it's not really a good example.

Yes, I did say more or less that... but efficiency was not the point.
Understanding was the point.

> The iterative version seeds the algorithm and lets it run:

Sure Chris, I fully expected YOU to get this on the first try, but the
average programmer tends not to.  My team uses it as an interview
question fairly often, and I'd venture a guess that upward of 80% of
candidates get it wrong on their first try.   The recursive version
is typically much easier to understand intuitively, not just for
mathemeticians, because it more or less restates in simple,
straightforward code what the natural language definition of the
Fibonacci sequence is, rather efficiently (not efficiency of
execution, efficiency of converting natural language to code).

The iterative version requires a bit more thought to make sure you're
seeding the state poperly, and maintaining it properly as the loop
executes.  I'd imagine most folks who hang around in this forum would
consider that you are not an average programmer.

Your example was also a fine example.

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41483] Do not acquire lock in MemoryHandler.flush() if no target defined

[Irit Katriel]

Irit Katriel  added the comment:

Regarding the change you suggest here - I think you need add another check that 
target is not None after you've acquired the lock to make it safe.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27307] string.Formatter does not support key/attribute access on unnumbered fields

[Roundup Robot]

Change by Roundup Robot :


--
nosy: +python-dev
nosy_count: 3.0 -> 4.0
pull_requests: +20911
pull_request: https://github.com/python/cpython/pull/21767

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41476] test_zoneinfo fails if the _lzma module is missing

[STINNER Victor]

Change by STINNER Victor :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> test_zoneinfo fails when lzma module is unavailable

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41477] test_genericalias fails if ctypes is missing

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +patch
pull_requests: +20910
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21766

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40275] test.support has way too many imports

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 598a951844122678de2596dbc1e0e09e2be65fd2 by Hai Shi in branch 
'master':
bpo-40275: Use new test.support helper submodules in tests (GH-21764)
https://github.com/python/cpython/commit/598a951844122678de2596dbc1e0e09e2be65fd2


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41503] Race between setTarget and flush in logging.handlers.MemoryHandler

[Irit Katriel]

Change by Irit Katriel :


--
keywords: +patch
pull_requests: +20909
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21765

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41503] Race between setTarget and flush in logging.handlers.MemoryHandler

[Irit Katriel]

New submission from Irit Katriel :

The `logging.handlers.MemoryHandler.setTarget()` method does not acquire the 
lock, so it can change the target while flush is processing the buffer.

The script below causes flush to call target.handle when target is None, 
causing:

  File "C:\Users\User\src\cpython\lib\logging\handlers.py", line 1265, in emit
self.flush()
  File "C:\Users\User\src\cpython\lib\logging\handlers.py", line 1348, in flush
self.target.handle(record)
AttributeError: 'NoneType' object has no attribute 'handle'



import io
import logging.handlers
import threading
import time

class SlowHandler:
def __init__(self):
self.stream = io.StringIO()
self.streamHandler = logging.StreamHandler(self.stream)

def handle(self, msg):
time.sleep(1)
self.streamHandler.handle(msg)

target = SlowHandler()
mem_hdlr = logging.handlers.MemoryHandler(10, logging.ERROR, target)
mem_logger = logging.getLogger('mem')
mem_logger.propagate = False
mem_logger.addHandler(mem_hdlr)

def toggleTarget():
time.sleep(1)
mem_hdlr.setTarget(None)

t = threading.Thread(target=toggleTarget, args=())
t.daemon = True
t.start()

while True:
time.sleep(0.1)
mem_logger.warning("warning not flushed")
mem_logger.error("error is flushed")



--
components: Library (Lib)
messages: 375001
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: Race between setTarget and flush in logging.handlers.MemoryHandler
type: behavior
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Christian Seberino]

> 1. Python mostly separates computation of values (expressions) from flow 
> control and name binding (statements).  When the latter are mixed with 
> the former, most people restrict the mixing to a line or two.

This is an interesting observation.  I've heard people say the fact that
Python has both expressions and statements is a negative.  (Lisp only
has expressions.)

It isn't clear to me what special Python syntax or forms you are referring to 
that separates expressions from flow control and assignments.  
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41500] InterpolationSyntaxError reading the (windows) environment with unresolved environment variables

[Ronald Oussoren]

Ronald Oussoren  added the comment:

There's multiple options:

1. Escape '%' in environment variables (%%not_existing%%) to avoid the exception

2. Switch to configparser.ExtendedInterpolation for the interpolation, which 
uses a different syntax that doesn't conflict with env. variables on Windows 
(but does conflict with that on Unix)

Note that regardless of the option ConfigParser will not expand the value of 
the environment variable reference. If you want to be able to interpolate env 
variables you need a different solution, for example by using the 'defaults' 
argument to ConfigParser and expand references using the ConfigParser 
interpolation syntax.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How explain why Python is easier/nicer than Lisp which has a simpler grammar/syntax?

[Chris Angelico]

On Sat, Aug 8, 2020 at 1:06 AM Christian Seberino  wrote:
>
>
> > ChrisA
>
> You're definitely an expert programmer.
>

Uhh thank you? I think? I'm not sure if you're complimenting me or
making some sort of joke relating to the code I posted, or if it's
actually nothing to do with me at all. All you quoted - the only
context we have - is my scribbled signature at the bottom of the post.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explicit is better than Implicit

[Python]

On Thu, Aug 06, 2020 at 07:46:25PM -0500, Python wrote:
> On Thu, Aug 06, 2020 at 07:19:01PM -0500, Skip Montanaro wrote:
> Python is *actually* easy to work with... most of the time.  "If you
> want more things for you buck there's no luck..." =8^)

[And yes, I'm aware the line is "beats" not "things" but since Python
usually doesn't have "beats" (though it can!) I paraphrased a bit...]

-- 
https://mail.python.org/mailman/listinfo/python-list