[Python-Dev] Re: review for doctest fix: bpo-35753

[Steven D'Aprano]

For the benefit of others, the problem is that 
`unittest.mock.call.__wrapped__` generates a new object, which in turn 
has a dynamic `__wrapped__` attribute, which does the same, thus 
generating an infinite chain of *distinct* proxies.

Being distinct proxy objects defeats the loop detection algorithm of 
`inspect.unwrap`, which raises ValueError when the recursion limit is 
reached, and that breaks doctest.

(I am explicitly stating that here because I spent an embarassingly long 
time misunderstanding the nature of the bug, then more time digging into 
the PR and bug track issues to understand what it was, rather than what 
it isn't. Maybe I can save anyone else from my misunderstanding.)

I'm not convinced that this should be fixed by catching the ValueError 
inside doctest. Or at least, not *just* by doing so. There's a deeper 
problem that should be fixed, outside of doctest. Looking at the 
similar issue here:

https://bugs.python.org/issue25532

`mock.call` has broken other functions in the past, and will probably 
continue to do so in the future.

I don't think this infinite chain is intentional, I think it just 
happens by accident, which makes this a bug in `call`. I think.

Michael Foord (creator of mock, if I recall correctly) suggested 
blacklisting `__wrapped__` from the proxying:

https://bugs.python.org/issue25532#msg254726

which I think is the right solution, rather than touching doctest.

Michael also said he wasn't happy with an arbitrary limit on the depth 
of proxies, but I would say that limiting the depth to 
sys.getrecursionlimit() is not arbitrary and should avoid or at least 
mitigate the risk of infinite loops and/or memory exhaustion in the 
general case of arbitrary attribute lookups:


py> a = unittest.mock.call
py> for i in range(5):  # for arbitrary large values of 5
... a = a.wibble
... 
py> a
wibble.wibble.wibble.wibble.wibble


I'm not a mock expert, but I guess such mock dynamic lookups should be 
limited to the recursion limit. Currently they will loop forever or 
until you run out of memory.

Setting `call.__wrapped__` to None seems to directly fix the problem 
with doctest:

[steve@susan test]$ cat demo2.py 
"""
Run doctest on this module.
"""

from unittest.mock import call
call.__wrapped__ = None

[steve@susan test]$ python3.9 -m doctest -v demo2.py
1 items had no tests:
demo2
0 tests in 1 items.
0 passed and 0 failed.
Test passed.


but I don't know if that will break any uses of `mock.call`.

Another fix (untested) would be to explicitly test for mocked call:

inspect.unwrap(val, stop=lambda obj: isinstance(obj, unittest.mock._Call))

but I don't like that much.


-- 
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2PBZDDVIPW63NJDVATRJ2Y32RQQC3JWL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: My thoughts on Pattern Matching.

[Greg Ewing]

On 7/11/20 4:03 am, Thomas Wouters wrote:

It's also why I'm not in favour of PEP 642 and other proposals for 
solving some of the problems in the Structural Pattern Matching proposal 
(sigils, etc): it widens the gap instead of closing it.


Does that mean you're against *any* proposal that involves sigils, or
just PEP 642 in particular?

Also, I'm very confused about why you're against PEP 642. It seems to
do a good job of meeting your stated goals -- syntax in common between
unpacking and matching has the same meaning, and the way is left open
for making them more like each other in the future. Can you elaborate
on what you don't like about it?

--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2X3IME7SD6HOA6D5HRHWR3VSSDKEOGUZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] review for doctest fix: bpo-35753

[Alfred Perlstein]

Hello,

We are using doctest to give our developers easy access to write very 
fast unit tests and encourage "tests as documentation".


Recently we hit an issue where doctest crashes on certain objects that 
fail to "unwrap".


Looking at the code and reasoning behind the crash it seems like we can 
simply ignore a failed call to unwraps.


There is now a PR open against against trunk and 3.8 branch (happy to 
make a 3.9 branch PR as well) here:


trunk: https://github.com/python/cpython/pull/22981

3.8: https://github.com/python/cpython/pull/22834

Does anyone have time to review and/or comment on this?

Thank you,

-Alfred
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HXN27UKPYB7E2MGKL2I32HFS7YKHNGUT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: My thoughts on Pattern Matching.

[Senthil Kumaran]

On Fri, Nov 6, 2020 at 7:05 AM Thomas Wouters  wrote:

>
> The primary reason I care about the integration with the rest of Python is
> because it limits the future expansion of the language.
>

I did not think as deeply as you have done on this subject here.

My exposure to pattern matching was in Scala and I didn't notice/observe
that this feature was considered a limitation in future expansion or
language or even usage in ecosystem.

Also, for the examples that you mentioned, I thought, those would be an
_extreme cases_ (?) of writing some really hard to comprehend code by the
developer? Because in most common cases in Scala that I could come across,
the
pattern matching was used mostly in routing logic based on the decision.
Seldom on complex assignments. But, my exposure is limited.

If you augment your arguments by sharing some example code base evolutions
in languages that have already supported pattern matching, it might help us
understand further.

Thanks for sharing the context of this email with SC standings.

Thank you,
Senthil
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZALNYEYRGV6I3ZZHGTNESBPVXV73O626/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2020-10-30 - 2020-11-06)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7617 ( -9)
  closed 46397 (+75)
  total  54014 (+66)

Open issues with patches: 3062 


Issues opened (43)
==

#37319: Deprecate using random.randrange() with non-integers
https://bugs.python.org/issue37319  reopened by serhiy.storchaka

#42160: unnecessary overhead in tempfile
https://bugs.python.org/issue42160  reopened by vstinner

#42213: Get rid of cyclic GC hack in sqlite3.Connection and sqlite3.Ca
https://bugs.python.org/issue42213  opened by erlendaasland

#42215: urlparse with a Windows path returns the drive name as the sch
https://bugs.python.org/issue42215  opened by rangelspam

#42217: compiler: merge co_code and co_lnotab
https://bugs.python.org/issue42217  opened by methane

#42220: Argparse: wildcards processing
https://bugs.python.org/issue42220  opened by Andrew

#4: Modernize integer test/conversion in randrange()
https://bugs.python.org/issue4  opened by rhettinger

#42225: Tkinter hangs or crashes when displaying astral chars
https://bugs.python.org/issue42225  opened by terry.reedy

#42228: Activate.ps1 clears PYTHONHOME
https://bugs.python.org/issue42228  opened by mathstuf

#42231: test_zipimport failure
https://bugs.python.org/issue42231  opened by vstinner

#42232: mmap module add Darwin specific madvise options
https://bugs.python.org/issue42232  opened by devnexen

#42233: GenericAlias does not support union type expressions
https://bugs.python.org/issue42233  opened by kj

#42234: pathlib relative_to behaviour change
https://bugs.python.org/issue42234  opened by armins.bagrats

#42235: [macOS] Use --enable-optimizations in build-installer.py
https://bugs.python.org/issue42235  opened by ronaldoussoren

#42237: test_socket.SendfileUsingSendfileTest fails on illumos
https://bugs.python.org/issue42237  opened by wiedi

#42238: Deprecate suspicious.py?
https://bugs.python.org/issue42238  opened by mdk

#42239: IDLE: Restore or keep calltip when needed
https://bugs.python.org/issue42239  opened by terry.reedy

#42243: Don't access the module dictionary directly
https://bugs.python.org/issue42243  opened by erlendaasland

#42244: TimedRotatingFileHandler doesn’t handle the switch to/from D
https://bugs.python.org/issue42244  opened by Cristian Martinez de Morentin

#42245: concurrent.futures.ProcessPoolExecutor freezes depending on co
https://bugs.python.org/issue42245  opened by DanilZ

#42246: Implement PEP 626
https://bugs.python.org/issue42246  opened by Mark.Shannon

#42247: unittest hides traceback frames in chained exceptions
https://bugs.python.org/issue42247  opened by dseomn

#42248: Raised exception in Enum keeping user objects alive unnecessar
https://bugs.python.org/issue42248  opened by efroemling

#42252: Embeddable Python indicates that it uses PYTHONPATH
https://bugs.python.org/issue42252  opened by teeks99

#42253: xml.dom.minidom.rst missed informations
https://bugs.python.org/issue42253  opened by jedie2

#42255: webbrowser.MacOSX is unused, untested and undocumented
https://bugs.python.org/issue42255  opened by ronaldoussoren

#42256: BaseCookie.__parse_string() doesn't work with expires= between
https://bugs.python.org/issue42256  opened by paulie4

#42257: platform.libc_ver() doesn't consider in case of executable is 
https://bugs.python.org/issue42257  opened by kurochan

#42258: argparse: show choices once per argument
https://bugs.python.org/issue42258  opened by mendelmaleh

#42259: pprint: infinite recursion for saferepr() when using nested ob
https://bugs.python.org/issue42259  opened by danbst

#42260: [C API] Add PyInterpreterState_SetConfig(): reconfigure an int
https://bugs.python.org/issue42260  opened by vstinner

#42261: Windows legacy I/O mode mistakenly ignores the device encoding
https://bugs.python.org/issue42261  opened by eryksun

#42264: Deprecate or remove sqlite3.OptimizedUnicode
https://bugs.python.org/issue42264  opened by erlendaasland

#42267: Python 3.9 broken installer
https://bugs.python.org/issue42267  opened by JackSkellington

#42268: ./configure failing when --with-memory-sanitizer specified
https://bugs.python.org/issue42268  opened by JaonHax

#42269: Add ability to set __slots__ in dataclasses
https://bugs.python.org/issue42269  opened by eric.smith

#42270: libregrtest BrokenPipeError on OpenEmbedded builds
https://bugs.python.org/issue42270  opened by threexc

#42271: Remove the error and the zipfile.ZipFile.BadZipfile aliases
https://bugs.python.org/issue42271  opened by PedanticHacker

#42272: Warning filter message/module documentation is misleading
https://bugs.python.org/issue42272  opened by kevinoid

#42273: Using LazyLoader leads to AttributeError
https://bugs.python.org/issue42273  opened by KevKeating

#42275: Jupyter Lab Terminals not available (error was No 

[Python-Dev] Re: Who is target reader of tutorial?

[Guido van Rossum]

Ouch, that's bad. It seems the class tutorial could use an overhaul.

We might also cut a few areas where we go unnecessarily deep (e.g.
position-only parameters).

On Fri, Nov 6, 2020 at 9:31 AM Mats Wichmann  wrote:

> On 11/6/20 9:07 AM, Marco Sulla wrote:
> > I started to learn Python with the tutorial, and two things come into my
> > mind:
> > 1. The class section seems quite difficult and intimidating for a novel,
> > while classes in Python are really more simple than in other OO languages
>
> Indeed - we got some complaints about the class chapter at the
> webmas...@python.org alias a while back. The introductory section
> repeatedly mentions Modula-3 and Smalltalk, languages which more
> recently minted programmers aren't very likely to be familiar with,
> which makes it a bit of a daunting beginning - this is the one chapter
> that could really use a bit of rework, IMO.
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/B54VI2DN2AYUXJG4SWSW2BMU5OOCIGSX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QRWFPASA6TKQCDSIOUBYU5OGHPFAUXW3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Who is target reader of tutorial?

[Steve Dower]

Hopefully that was a dataclass :)

But yes, point taken. Classes need to be there. And now I've gone and 
re-read the table of contents for the tutorial, I really don't have any 
complaints about the high-level ordering. It does seem to go 
unnecessarily deep in some areas (*very* few people will ever need 
position-only parameters, for example, and I'd say all special 
parameters matter more in the tutorial because of how you _call_ them, 
rather than how you define them).


Cheers,
Steve

On 06Nov2020 1714, Guido van Rossum wrote:
I agree with you that the tutorial should focus at users, not library 
developers. But assuming that users will never write a class seems 
wrong. For example, while ago I went through a PyTorch tutorial, which 
assumes barely any programming knowledge, and yet the first or second 
example has the user write a class, as this is apparently the 
conventional way to store parameters for ML models.


--Guido

On Fri, Nov 6, 2020 at 8:32 AM Steve Dower > wrote:


It would also be nice for the tutorial to separate between "things you
need to know to use Python" vs "things you need to write a Python
library".

For example, the fact that operators can do different things for
different values (e.g. int, str, list, pathlib) would be in the first
category, while the details of how to override operators can wait for
the second.

I see many people suffer from content that goes too deep too quickly,
and I'm more and more convinced over time that this is the right place
to draw a separator for Python. Many devs are just using the language
and never implementing a class (or often, even writing a function).
Having a canonical tutorial to get these users through this stage first
before going deeper would be great.

Cheers,
Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VVJOMFE44ZO6UTA432EQGPSHZI23ULQU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Who is target reader of tutorial?

[Mats Wichmann]

On 11/6/20 9:07 AM, Marco Sulla wrote:
I started to learn Python with the tutorial, and two things come into my 
mind:
1. The class section seems quite difficult and intimidating for a novel, 
while classes in Python are really more simple than in other OO languages


Indeed - we got some complaints about the class chapter at the 
webmas...@python.org alias a while back. The introductory section 
repeatedly mentions Modula-3 and Smalltalk, languages which more 
recently minted programmers aren't very likely to be familiar with, 
which makes it a bit of a daunting beginning - this is the one chapter 
that could really use a bit of rework, IMO.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/B54VI2DN2AYUXJG4SWSW2BMU5OOCIGSX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Who is target reader of tutorial?

[Guido van Rossum]

This I also agree with. We should not assume readers know any particular
other language, so any mention of "this is just like " or
"unlike " should probably be avoided. (I didn't check if there
are any, but I wouldn't be surprised if some had crept in, given Python's
strong roots in C.)

--Guido

On Fri, Nov 6, 2020 at 7:30 AM Federico Salerno 
wrote:

> I think it's important to remember that many novice programmers today
> learn python as their first language.
> While i don't think the python tutorial is the right place for teaching
> how to program, i also think it would be best if it didn't make too many
> assumptions on the reader's knowledge.
> When it comes to the basics, assuming one already knows another language
> isn't very beneficial anyway, in my opinion. If all one is looking for is a
> table comparing a known thing with its python equivalent, there are many of
> those on the internet already and in much more compact form.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/AGYLMJQOWV6SQVBVT7VGEII77V4ALVT6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/D2J3K7GB6XU3JT2ZNHFDJ3MQ52HTAZTE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Who is target reader of tutorial?

[Guido van Rossum]

I agree with you that the tutorial should focus at users, not library
developers. But assuming that users will never write a class seems wrong.
For example, while ago I went through a PyTorch tutorial, which assumes
barely any programming knowledge, and yet the first or second example has
the user write a class, as this is apparently the conventional way to store
parameters for ML models.

--Guido

On Fri, Nov 6, 2020 at 8:32 AM Steve Dower  wrote:

> It would also be nice for the tutorial to separate between "things you
> need to know to use Python" vs "things you need to write a Python library".
>
> For example, the fact that operators can do different things for
> different values (e.g. int, str, list, pathlib) would be in the first
> category, while the details of how to override operators can wait for
> the second.
>
> I see many people suffer from content that goes too deep too quickly,
> and I'm more and more convinced over time that this is the right place
> to draw a separator for Python. Many devs are just using the language
> and never implementing a class (or often, even writing a function).
> Having a canonical tutorial to get these users through this stage first
> before going deeper would be great.
>
> Cheers,
> Steve
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/E7Y5MB4JJEB3VW2J24HA7JQZH6JRAOMO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XSR3P3E7K4EZQKG5IO3PD3UPHISISIVB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Who is target reader of tutorial?

[Abdur-Rahmaan Janhangeer]

@MarcoSulla

You started from the tutorials?

you are a real legend 

great people were already great before they became great it seems ~

Kind Regards,


Abdur-Rahmaan Janhangeer

https://www.github.com/Abdur-RahmaanJ

Mauritius

sent from gmail client on Android, that's why the signature is so ugly.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Z4UC5PUJQ5HFEAF4RTC27TP2DVQML5QM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

[Victor Stinner]

Le jeu. 29 oct. 2020 à 22:43, Victor Stinner  a écrit :
> I propose to drop the Solaris support in Python to reduce the Python
> maintenance burden:
>
>https://bugs.python.org/issue42173
> (...)

Since I created the issue and the PR, and sent this email to
python-dev (one week ago), many Solaris and Solaris-like (ex: Illumos)
users replied that the operating system is definitively alive. I
didn't know that Oracle still ships new Solaris updates every month:
that's a good thing!

But this is not enough to support a platform. We would need proactive
contributors to fix known Solaris issues, but also fix new Solaris
issues (either regressions, or bugs newly discovered). We would also
need a buildbot to run the Python test suite on Solaris (or again, a
Solaris-like OS).

The good news is that Jakub Kulik started to fix some Solaris issues.
I understood that Solaris and Solaris-like operating systems do have
downstream patches on Python to fix a bunch of bugs. It seems like
some people want to push these fixes to Python upstream which is also
a good sign.

The other problem that I wanted to discuss is that fixing Solaris
issues require core devs (who merge PRs) accessing Solaris. If
contributors send patches and some core devs are fine with merging
fixes without being able to test them manually, I'm also fine with
that.

My first intent was to remove support for a definitely dead operating
system, but it seems like I was completely wrong (it's alive!). Thanks
to people starting to fix Solaris issues, I close my PR and I no
longer plan to drop Solaris support. I prefer to leave bpo-42173 open
for now, since people decide to use it as a place to collaborate on
fixing Solaris issues.

Once most tests will pass on the master branch, I also hope that
someone will set up a buildbot *and* fix issues discovered by this
buildbot. Sorry but just setting up a buildbot doesn't solve any
problem, it only increases the maintenance burden for people who
maintain the buildbot fleet. For example, we have two AIX buildbots, I
report bugs on bugs.python.org, but it seems like nobody is available
to fix them...

Overall, I'm quite happy with what is happening with Solaris! More
collaboration, issues being fixed in Python upstream. I just hope that
this work will continue next months. ;-)

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/46UUJ4J5YLCWF2JQMC5L7OIYG6PNQLRL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Who is target reader of tutorial?

[Steve Dower]

It would also be nice for the tutorial to separate between "things you 
need to know to use Python" vs "things you need to write a Python library".


For example, the fact that operators can do different things for 
different values (e.g. int, str, list, pathlib) would be in the first 
category, while the details of how to override operators can wait for 
the second.


I see many people suffer from content that goes too deep too quickly, 
and I'm more and more convinced over time that this is the right place 
to draw a separator for Python. Many devs are just using the language 
and never implementing a class (or often, even writing a function). 
Having a canonical tutorial to get these users through this stage first 
before going deeper would be great.


Cheers,
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/E7Y5MB4JJEB3VW2J24HA7JQZH6JRAOMO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Who is target reader of tutorial?

[Marco Sulla]

I started to learn Python with the tutorial, and two things come into my
mind:
1. The class section seems quite difficult and intimidating for a novel,
while classes in Python are really more simple than in other OO languages
2. I really missed a section about how to write a decorator function.
Luckily, the web is full of examples.

PS I learnt C, C++ and Fortran at university, so I was the "target
audience".
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VFXF6BQM4XQNSXCRR3NDOUBJ5C4YUY6R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Who is target reader of tutorial?

[Federico Salerno]

I think it's important to remember that many novice programmers today learn
python as their first language.
While i don't think the python tutorial is the right place for teaching how
to program, i also think it would be best if it didn't make too many
assumptions on the reader's knowledge.
When it comes to the basics, assuming one already knows another language
isn't very beneficial anyway, in my opinion. If all one is looking for is a
table comparing a known thing with its python equivalent, there are many of
those on the internet already and in much more compact form.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AGYLMJQOWV6SQVBVT7VGEII77V4ALVT6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] My thoughts on Pattern Matching.

[Thomas Wouters]

Apologies that this is a long email, but I want to make sure I get my
points across and it's difficult to do it in a short email. I touched on
some of these things in a blogpost I wrote (
https://pyrandom.blogspot.com/2020/11/my-view-of-python-steering-council.html)
but I wanted to make the main points in detail in a way that made it easy
for people to provide feedback if they wanted, so it's an email instead of
a blog post.

We haven't broadly announced it, but the current SC has decided not to make
the final decision

on Structural Pattern Matching (PEPs 634/635/636) and the
additional/competing PEPs (640 and 642), because it's so close to the
election of the next SC. Instead, we're going to make our decision and then
leave it as a strong recommendation for the 2021 SC, as they will actually
be in charge for the release of the next version of Python. The 2021 SC
will then have to make the final decision. I understand this may be
disappointing to some, and I'm sorry, but even after the SC election
there's more than five months before the final decision has to be made for
the feature to make it into Python 3.10. I hope the next SC doesn't take
that long, but there's no rush to get it in before they are seated.

I also imagine this means the Structural Pattern Matching proposal may be a
voting issue for some, and since I will be running for the next SC, I want
to make it clear where I stand and why.

Note that this is *my* point of view, not the SC's. I don't think any of
the SC have made up their mind yet, and we all approach this differently.
We're continuing the discussion between us to come to our
decision-cum-recommendation. I would also like to hear (in private or
public, I don't mind) whether people even remotely agree with me, because
my mind can still be changed on some of these issues -- especially if it
turns out I'm alone in my concerns.

First of all, I am honestly excited about pattern matching. The impact on
existing code or the examples in the PEPs may not feel impressive, but I
can see how it would change how we think about certain problems, how we
design APIs around them, much like for example decorators and the `with`
statement has in the past. Like both of those changes, the pattern matching
design gives us convenient inversion of control. I don't usually write code
using isinstance(), but I realise switching on types is something people
want to do and sometimes might even be the best thing to do. The Structural
Pattern Matching proposal solves this by allowing the types to decide what
they match against in a way that's easier to use and *much* more
purpose-driven than the existing hammers of `__isinstance__` and
`__issubclass__`.

My concerns about the proposal all stem from the differences with the rest
of the language. Some are very minor -- for example, I wish there was a
better way to deal with the indentation of 'match' and 'case', but all of
the proposed alternatives are clearly worse to me, so the double
indentation is fine. I'm satisfied all my minor concerns have been
addressed in the Structural Pattern Matching proposal, one way or another.

I also have some small but significant concerns that keep nagging at me,
but I'm not sure how much of a big deal they will be in practice. I don't
know whether these will be a problem, but I'm worried they _might turn out
to be_, and that in hindsight we should've made a different choice.
Ideally, we make decisions that allow us to correct the mistake (like
removing u'' strings in Python 3) rather than make it hard to ever change
(like indexing bytes producing integers). Those concerns are (although I
may have forgotten one or two minor ones):

 - Mapping patterns ignoring extra items. In the proposal, unpacking "into"
a dict automatically ignores extra items.There is syntax readily available
(and explicitly disallowed) for ignoring extra items. There are also ways
to check for extra keys, like a guard on the case, but if the program
doesn't think about adding it, extra items are just silently ignored. I'm
just not sure that the don't-care-about-extra-items use-case is common
enough to warrant silently doing the wrong thing, especially since it's so
very easy to write the code for that use-case.

 - The mixture of assignment, evaluation and matching in case clauses. I
keep worrying that it will be difficult to see what's being assigned to,
what's being called, and what's being matched against. I think the current
proposal has enough safe-guards to make it hard to *write* the wrong thing,
but readability still counts. The competing proposals for solving this
issue do not seem like improvements to me, however, for reasons I'll get to
below.

 - The use of `|` instead of `or`, which falls in the same boat as the
previous point: to my eyes `or` makes it much easier to parse the more
complex cases in the examples. For the simple case of 'case 0|1:' versus
'case 0 or 

[Python-Dev] Re: Who is target reader of tutorial?

[Serhiy Storchaka]

05.11.20 11:12, Inada Naoki пише:
> Since "How To" guide is not organized well, it is very tempting to
> write all details in tutorial.
> I have seen may pull requests which "improve" tutorial by describe
> more details and make
> the tutorial more perfect.
> 
> But adding more and more information into tutorial makes it slower to
> learn Python by reading tutorial.
> 10+ years ago, Python is far less popular in Japan and reading
> tutorial is the best way to learn Python to me.
> 
> But now Python is popular and there are many free/paid good books and
> tutorials on the Web.
> Some of them would be more new user friendly than official tutorial.
> Then, should official Python tutorial become detailed guide to Python?
> Or should we keep new user learning Python as targeted reader?

I think the tutorial should be targeted to new Python users, which
already know one or more programming languages. It should not be an
introduction into programming, nor a detailed guide. I myself learned
Python by just reading tutorial. Contained enough information to start
coding and to understand some fundamental differences of Python from
other programming languages, but not too heavy. Additional details I
learned from the library reference. For advanced topics there are "How
to" and the language reference.

At that time (Python 2.2) it was the best tutorial that I read. Other
language tutorials was either too large and formal, or spent several
chapters explaining what is bits and loops.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5RPOGC2RHTFIJO5KUTRV24NENRNYXQBF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Contribution to github repos.

[Ivan Pozdeev via Python-Dev]

See https://devguide.python.org/ .

On 06.11.2020 6:57, Manak Wadhwa wrote:

Hey Guys,
I am Manak Wadhwa. I have a good hand in python language, ML Algorithms, Web 
Dev (HTML5, CSS3, JS, PHP, AJAX, Bootstrap, JQuery). I want to contribute to 
python org can someone help as which repository should i start with or work on.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TEM5YNTZ5WDJMLA5RNAQ5KMCTMPLOVRH/
Code of Conduct: http://python.org/psf/codeofconduct/


--
Regards,
Ivan
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/K6HKQBZQIIIBMJHHZKAL3I5QRZ7JPX5I/
Code of Conduct: http://python.org/psf/codeofconduct/