[Python-Dev] Contribution to github repos.

[Manak Wadhwa]

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/

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

[Carol Willing]

Thanks Inada-san for bringing up this issue. I agree with your point and
Guido's that the tutorial should target learning Python if new to the
language but not coding. It's likely that in the future there will be an
even more basic tutorial for those newer to coding.

An advanced concept, as Kyle mentions, is fine when it is a sentence or two
and refers back to the in-depth documentation. Care should be taken when
introducing an advanced topic or use case to have it at the end of a
section and not interleaved with the examples that suit the majority of
learners (Python beginners and intermediate developers).

On Thu, Nov 5, 2020 at 12:35 PM Kyle Stanley  wrote:

> I can't speak for all of the members of the upcoming documentation WG, but
> as someone that will be on it (based on our discussions at the recent core
> dev sprint), my personal vote would be for keeping it as a comprehensive
> guide for beginners of Python. Detailed enough that it covers the
> fundamentals, but skips out on more advanced topics and info that is likely
> going to be less applicable to most new users.
>
> I would consider __cause__ and __context__ to fall under the category of
> being "useful to know, but far from essential for beginners". You can have
> a decent understanding of most python programs without ever knowing about
> those two dunders.  So I would definitely be in favor of removing the
> mention of __cause__ and not adding __context__, in my opinion it adds
> extra unneeded complexity.
>
> That being said, I'm not opposed to something like having something like a
> footnote at the bottom of the section that links to a more advanced topic
> (maybe an exception how-to?). It should be at the bottom of the section so
> it doesn't add extra cognitive overhead for those trying to grasp the
> basics, but allows for those who are interested to get a more in-depth
> understanding if they want to. I would suggest redirecting the contributor
> who proposed those changes to working on something like an exception
> how-to; assuming that's something they're interested in.
>
> On Thu, Nov 5, 2020 at 2:07 PM Brett Cannon  wrote:
>
>> A documentation WG is going to be formed which will be in a better
>> position to answer this, so until that WG is started I think we should keep
>> the tutorial aimed towards beginners.
>>
>> On Thu, Nov 5, 2020 at 1:13 AM Inada Naoki 
>> wrote:
>>
>>> Hi, all.
>>>
>>> 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?
>>>
>>> There is ongoing issue for example: https://bugs.python.org/issue42179
>>>
>>> Chaining exception was added in tutorial.  Current tutorial mention to
>>> `__cause__` attribute.
>>> https://docs.python.org/3/tutorial/errors.html#exception-chaining
>>>
>>> bpo-42179 proposes to add mention to `__context__` to make the
>>> tutorial more accurate about implicit chaining.
>>> And https://github.com/python/cpython/pull/23160 is the pull request
>>> to mention `__context__`.
>>>
>>> On the other hand, I want to remove confusion by removing mention to
>>> `__cause__`.
>>> Because I don't think `__context__` and `__cause__` is important for new
>>> users.
>>> See https://github.com/python/cpython/pull/23162 for my proposal.
>>>
>>> Regards,
>>>
>>> --
>>> Inada Naoki  
>>> ___
>>> 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/MXMEFFYB6JXAKSS36SZ7DX4ASP6APWFP/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>> ___
>> 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/IWW2YBLJK4T3OWSKDUDVDVXPWDGIFWTC/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> 

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

[Greg Ewing]

On 6/11/20 4:54 am, Steven D'Aprano wrote:

On Wed, Nov 04, 2020 at 12:15:08PM +1300, Greg Ewing wrote:


If "_" is a non-binding wildcard, linters will have to allow
"case _, _" otherwise it might as well not be there. And then
if it is later changed to be binding,


Why would we want to do that?


I'm not suggesting we should. I was replying to a post proposing
to not treat "_" specially, and pointing out that if we don't
make it special now we can't change our mind later.

--
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/3TJC6U7LQOTOZGZVMTP4XXVMGQK6NQP3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Kyle Stanley]

I can't speak for all of the members of the upcoming documentation WG, but
as someone that will be on it (based on our discussions at the recent core
dev sprint), my personal vote would be for keeping it as a comprehensive
guide for beginners of Python. Detailed enough that it covers the
fundamentals, but skips out on more advanced topics and info that is likely
going to be less applicable to most new users.

I would consider __cause__ and __context__ to fall under the category of
being "useful to know, but far from essential for beginners". You can have
a decent understanding of most python programs without ever knowing about
those two dunders.  So I would definitely be in favor of removing the
mention of __cause__ and not adding __context__, in my opinion it adds
extra unneeded complexity.

That being said, I'm not opposed to something like having something like a
footnote at the bottom of the section that links to a more advanced topic
(maybe an exception how-to?). It should be at the bottom of the section so
it doesn't add extra cognitive overhead for those trying to grasp the
basics, but allows for those who are interested to get a more in-depth
understanding if they want to. I would suggest redirecting the contributor
who proposed those changes to working on something like an exception
how-to; assuming that's something they're interested in.

On Thu, Nov 5, 2020 at 2:07 PM Brett Cannon  wrote:

> A documentation WG is going to be formed which will be in a better
> position to answer this, so until that WG is started I think we should keep
> the tutorial aimed towards beginners.
>
> On Thu, Nov 5, 2020 at 1:13 AM Inada Naoki  wrote:
>
>> Hi, all.
>>
>> 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?
>>
>> There is ongoing issue for example: https://bugs.python.org/issue42179
>>
>> Chaining exception was added in tutorial.  Current tutorial mention to
>> `__cause__` attribute.
>> https://docs.python.org/3/tutorial/errors.html#exception-chaining
>>
>> bpo-42179 proposes to add mention to `__context__` to make the
>> tutorial more accurate about implicit chaining.
>> And https://github.com/python/cpython/pull/23160 is the pull request
>> to mention `__context__`.
>>
>> On the other hand, I want to remove confusion by removing mention to
>> `__cause__`.
>> Because I don't think `__context__` and `__cause__` is important for new
>> users.
>> See https://github.com/python/cpython/pull/23162 for my proposal.
>>
>> Regards,
>>
>> --
>> Inada Naoki  
>> ___
>> 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/MXMEFFYB6JXAKSS36SZ7DX4ASP6APWFP/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> 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/IWW2YBLJK4T3OWSKDUDVDVXPWDGIFWTC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/FWQWF6BNVILXLYGZ7VVFBWP7OV23URSD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

Agreed, I like to refer beginners there who are new to Python but not new
to coding.

On Thu, Nov 5, 2020 at 11:03 AM Brett Cannon  wrote:

> A documentation WG is going to be formed which will be in a better
> position to answer this, so until that WG is started I think we should keep
> the tutorial aimed towards beginners.
>
> On Thu, Nov 5, 2020 at 1:13 AM Inada Naoki  wrote:
>
>> Hi, all.
>>
>> 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?
>>
>> There is ongoing issue for example: https://bugs.python.org/issue42179
>>
>> Chaining exception was added in tutorial.  Current tutorial mention to
>> `__cause__` attribute.
>> https://docs.python.org/3/tutorial/errors.html#exception-chaining
>>
>> bpo-42179 proposes to add mention to `__context__` to make the
>> tutorial more accurate about implicit chaining.
>> And https://github.com/python/cpython/pull/23160 is the pull request
>> to mention `__context__`.
>>
>> On the other hand, I want to remove confusion by removing mention to
>> `__cause__`.
>> Because I don't think `__context__` and `__cause__` is important for new
>> users.
>> See https://github.com/python/cpython/pull/23162 for my proposal.
>>
>> Regards,
>>
>> --
>> Inada Naoki  
>> ___
>> 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/MXMEFFYB6JXAKSS36SZ7DX4ASP6APWFP/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> 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/IWW2YBLJK4T3OWSKDUDVDVXPWDGIFWTC/
> 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/U36KWMWDAQGIVBGSJGJKCRQGFFH22W27/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

A documentation WG is going to be formed which will be in a better position
to answer this, so until that WG is started I think we should keep the
tutorial aimed towards beginners.

On Thu, Nov 5, 2020 at 1:13 AM Inada Naoki  wrote:

> Hi, all.
>
> 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?
>
> There is ongoing issue for example: https://bugs.python.org/issue42179
>
> Chaining exception was added in tutorial.  Current tutorial mention to
> `__cause__` attribute.
> https://docs.python.org/3/tutorial/errors.html#exception-chaining
>
> bpo-42179 proposes to add mention to `__context__` to make the
> tutorial more accurate about implicit chaining.
> And https://github.com/python/cpython/pull/23160 is the pull request
> to mention `__context__`.
>
> On the other hand, I want to remove confusion by removing mention to
> `__cause__`.
> Because I don't think `__context__` and `__cause__` is important for new
> users.
> See https://github.com/python/cpython/pull/23162 for my proposal.
>
> Regards,
>
> --
> Inada Naoki  
> ___
> 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/MXMEFFYB6JXAKSS36SZ7DX4ASP6APWFP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/IWW2YBLJK4T3OWSKDUDVDVXPWDGIFWTC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

[Steven D'Aprano]

On Wed, Nov 04, 2020 at 12:15:08PM +1300, Greg Ewing wrote:

> If "_" is a non-binding wildcard, linters will have to allow
> "case _, _" otherwise it might as well not be there. And then
> if it is later changed to be binding, 

Why would we want to do that?

Apart from the backward incompatibility of such a change, why would we 
want to make `_` binding? There is an effectively unlimited number of 
possible capture patterns available to choose from. Just use another 
variable.

We aren't going to use `_` as a normal capturing pattern regardless of 
what the language allows: that would go against idiomatic Python 
convention. If we use `_` other Pythonistas will snigger at our lack of 
clue, our programs will fail code review, and linters will complain 
about it. And it will go against the common practice among most current 
pattern matching languages.


> "case _, _" will
> either become invalid or start forcing the two occurrences to
> be equal, depending on which change is made, thus breaking
> existing code.

Right. We will have no good reason to remove the non-binding wildcard 
pattern, and very good reason to *not* break people's code by removing 
it. So why are we discussing this?


> The only way I can see to keep our future options open in this
> area is not to have a wildcard at all,

Why would we want to "keep our options open" here? What benefit do we 
have for going against half a century of pattern matching theory and 
practice and common usage in other languages?

There is a lot of prior art here, probably a dozen or more languages: 
Haskell, Rust, Nemerle, Erlang, Ocaml, Prolog, F#, Elixer, Mathematica, 
etc. I haven't done a full survey of the prior art, but I doubt that I 
have even scratched the surface here. I'm sure there are many others, 
depending on how widely you want to define pattern matching.

Coconut already uses `_` as the wildcard:

https://coconut.readthedocs.io/en/master/DOCS.html#match

Were they wrong to do so? Does the Coconut community -- to say nothing 
of Haskell, Rust etc -- wish that they had kept their options open?


> and make people use
> a different throwaway name for each don't-care position in a
> pattern.

That would be:

(1) Annoying and frustrating.

(2) Misleading: using a capture pattern means you care about the 
value you are capturing. Using a capture pattern to bind a 
value you don't care about is obfuscates the code.

(3) Inefficient: that would mean things you don't care about 
will be captured as real, potentially long-lived, name bindings. 
Bindings aren't free.

While it is true that we don't normally care too much about wasting the 
odd name binding here and there, neither do we go out of our way to 
*intentionally* be wasteful by unnecessarily capturing values we don't 
care about:


who_cares1 = my_list.sort()
who_cares2 = print(my_list)
still_don't_care = values.reverse()
honestly_i_don't_care_what_this_returns = settings.update(config)


especially not chosing a different name each time.


-- 
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/KF6FOYNQCWWKXS55EUAA7VFT43CEC4R6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

[Gustavo Carneiro]

I think using symbols like ? and == in patterns looks stylistically ugly,
and unintuitive, albeit more explicit.

I, too, would rather have pattern matching more explicit, but it shouldn't
need to be so ugly (yes, I know, ugly is a subjective term, so be it).

I would propose that, opposite to what this PEP 642 proposes, matching as
literal terms should be the default, and a special notation should be used
for binding to names.

match number:
case 0:
print("Nothing")
case 1:
print("Just one")

This would be equivalent:

zero = 0
one = 1
match number:
case zero:
print("Nothing")
case one:
print("Just one")


And I would propose to use "as" for the notation of binding to a variable,
possibly in combination with "_" for the wildcard pattern:

expected_value = "xxx"
match some_json:
case {"foo": expected_value}:  # matches {"foo": "xxx"}
pass
case {"foo": _ as bar}:  # matches any {"foo": }
print(f"json got foo value {bar}")


Yes, I understand that being forced to use "_ as name" in a lot of patterns
is more verbose, but I posit that it is both explicit _and_ intuitive.  And
perhaps not as ugly as ? and ==.

In my mind, I don't see that this "as" usage causes any confusion with the
"as" in context managers.  That is a cop-out.  I see this "as" as more akin
to the exception handling:

try:
   ...
except RuntimeError as error:
   ...


See?  No context manager protocol involved here.  "as" is simply
representing a name binding.


On Sat, 31 Oct 2020 at 07:17, Nick Coghlan  wrote:

> Hi folks,
>
> This is a mailing list repost of the Discourse thread at
>
> https://discuss.python.org/t/pep-642-constraint-pattern-syntax-for-structural-pattern-matching/5614
>
> The rendered version of the PEP can be found here:
> https://www.python.org/dev/peps/pep-0642/
>
> The full text is also quoted in the Discourse thread.
>
> The remainder of this email is the same introduction that I posted on
> Discourse.
>
> I’m largely a fan of the Structural Pattern Matching proposal in PEP
> 634, but there’s one specific piece of the syntax proposal that I
> strongly dislike: the idea of basing the distinction between capture
> patterns and value patterns purely on whether they use a simple name
> or a dotted name.
>
> Thus PEP 642, which retains most of PEP 634 unchanged, but adjusts
> value checks to use an explicit prefix syntax (either `?EXPR` for
> equality constraints, or `?is EXPR` for identity constraints), rather
> than relying on users learning that literals and attribute lookups in
> a capture pattern mean a value lookup check, while simple names mean a
> capture pattern (unlike both normal expressions, where all three mean
> a value lookup, and assignment targets, where both simple and dotted
> names bind a new reference).
>
> The PEP itself has a lot of words explaining why I’ve made the design
> decisions I have, as well as the immediate and potential future
> benefits offered by using an explicit prefix syntax for value
> constraints, but the super short form goes like this:
>
> * if you don’t like match statements at all, or wish we were working
> on designing a C-style switch statement instead, then PEP 642 isn’t
> going to appeal to you any more than PEP 634 does
> * if, like me, you don’t like the idea of breaking the existing
> property of Python that caching the result of a value lookup
> subexpression in a local variable and then using that variable in
> place of the original subexpression should “just work”, then PEP 642’s
> explicit constraint prefix syntax may be more to your liking
> * however, if the idea of the `?` symbol becoming part of Python’s
> syntax doesn’t appeal to you, then you may consider any improved
> clarity of intent that PEP 642 might offer to not be worth that cost
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> 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/WT3ZZ42XJ4G6Y3H26RWUFN5GCUIFLMQ7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
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/3Q5KSGEXWGNC5JNUIXNTZJB4Q36IM3DY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

[Ronald Oussoren via Python-Dev]

> On 3 Nov 2020, at 16:36, Paul Svensson  wrote:
> 
> On Tue, 3 Nov 2020, Greg Ewing wrote:
> 
>> On 3/11/20 11:01 am, Ethan Furman wrote:
>> 
>>> I believe supporting
>>> 
>>> case x, x   # look ma!  no guard!
>>> is a possible future enhancement.
>> 
>> In which case there will be a need for *some* kind of true
>> "don't care" placeholder. If it's not "_" then it will have
>> to be something else like "?". And we need to decide about
>> it now, because once people start using "_" as a wildcard
>> in patterns, it will be too late to go back.
>> 
> 
> But will it, really ?
> It seems to me, that if we leave the "_" magic out,
> and leave "case x, x" to the linters,
> that leaves a clear path forward
> for whatever can be decided whenever it can be decided.

Leaving this to linters makes it harder to change the behaviour of “case x, x” 
later.  Also: not everyone uses a linter.

The particular example of “case x, x” also seems to be a bit of a red herring 
because that scenario is close to regular tuple unpacking. If I read the PEP 
correctly binding the same name multiple times is also forbidden in more 
complex scenario’s where multiple binding is not so easily recognised, such as 
"case Rect(Point(x, y), Size(x, w))”.

Ronald

—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/___
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/HFZAGUKJUYO5D4BTMNDCGPNA74ZHTUCN/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Abdur-Rahmaan Janhangeer]

@PaulMoore i see this:

There is a list of tutorials suitable for experienced programmers on the
BeginnersGuide/Tutorials
 page.

written here:

https://www.python.org/about/gettingstarted/

XD


Kind Regards,


Abdur-Rahmaan Janhangeer

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

Mauritius

>
>
___
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/XUKMWMLMTIKOARSHX7HQKILYNOSG3GPC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

IMO, the tutorial should remain as a document aimed at new users, and
therefore it definitely should *not* include too much detail.

I've helped a couple of friends learn Python and I have always
directed them to the tutorial as the "official" guide for new users.
If the tutorial is no longer aimed at new users, what should we
recommend? I'm not aware of a 3rd party book or tutorial that we'd
want to endorse as the "official" one.

Paul

On Thu, 5 Nov 2020 at 09:19, Inada Naoki  wrote:
>
> Hi, all.
>
> 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?
>
> There is ongoing issue for example: https://bugs.python.org/issue42179
>
> Chaining exception was added in tutorial.  Current tutorial mention to
> `__cause__` attribute.
> https://docs.python.org/3/tutorial/errors.html#exception-chaining
>
> bpo-42179 proposes to add mention to `__context__` to make the
> tutorial more accurate about implicit chaining.
> And https://github.com/python/cpython/pull/23160 is the pull request
> to mention `__context__`.
>
> On the other hand, I want to remove confusion by removing mention to
> `__cause__`.
> Because I don't think `__context__` and `__cause__` is important for new 
> users.
> See https://github.com/python/cpython/pull/23162 for my proposal.
>
> Regards,
>
> --
> Inada Naoki  
> ___
> 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/MXMEFFYB6JXAKSS36SZ7DX4ASP6APWFP/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
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/6D5WSTGB7X7BRLXZSJNT3YPGNZW7U75R/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Abdur-Rahmaan Janhangeer]

Was reading a tuto by vinay sajip on the official site the other day and i
can say that the tutos are great, they just need to be more in numbers.
With the old style look of the tutos i dont think as you pointed out that
new readers will go through it. better resources exist. I suggest we keep
it as well groomed tutos whereby people can know that if i need a good
tuto, the py site has some. Beginner infos exist in abundance and quality
materials pyramids to the top. I suggest we let masters write more
articles, preferring coverage and conciseness over full depth (if someone
wants a really detailed tuto, better go to the docs)

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/7TRTCIQVA7E23VQ2OOUIS322VRXTMYRM/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Inada Naoki]

Hi, all.

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?

There is ongoing issue for example: https://bugs.python.org/issue42179

Chaining exception was added in tutorial.  Current tutorial mention to
`__cause__` attribute.
https://docs.python.org/3/tutorial/errors.html#exception-chaining

bpo-42179 proposes to add mention to `__context__` to make the
tutorial more accurate about implicit chaining.
And https://github.com/python/cpython/pull/23160 is the pull request
to mention `__context__`.

On the other hand, I want to remove confusion by removing mention to
`__cause__`.
Because I don't think `__context__` and `__cause__` is important for new users.
See https://github.com/python/cpython/pull/23162 for my proposal.

Regards,

-- 
Inada Naoki  
___
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/MXMEFFYB6JXAKSS36SZ7DX4ASP6APWFP/
Code of Conduct: http://python.org/psf/codeofconduct/