[Python-Dev] Re: Remove module's __version__ attributes in the stdlib

[Karthikeyan]

On Fri, Oct 16, 2020, 12:45 AM Serhiy Storchaka  wrote:

> 14.10.20 20:56, Brett Cannon пише:
> > I think if the project is not maintained externally and thus synced into
> > the stdlib we can drop the attributes.
>
> I have found only one exception. decimal.__version__ refers to the
> version of the external specification which was not changed since 2009.
> I think it should be kept, although it might be better to use different
> name for it (like "spec_version").
>
> I do not know about any current projects maintained externally and
> synced into the stdlib. simplejson and ElementTree are too different now
> from the stdlib versions. Some features flow in both directions, but
> selectively on case by case basis, not as full sync. External argparse
> is outdated now.
>
I guess zipp that is maintained externally has code adopted into
zipfile.ZipPath regularly : https://github.com/jaraco/zipp

__version__ was removed from mock and it broke a package in fedora. The PR
has a discussion and also links to the bpo to remove __version__ from all
of stdlib : https://github.com/python/cpython/pull/17977

I am also in favor of removing since it causes confusion when the package
is not maintained externally n synced into stdlib.

Thanks

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

[Python-Dev] Re: Doc tests failing for many PRs on GitHub

[Karthikeyan]

Hi,
>
> There seems to be something wrong with the doc tests for PRs on Github.
>
> https://github.com/python/cpython/pull/22026/checks?check_run_id=1050881634
> https://github.com/python/cpython/pull/22025/checks?check_run_id=1050403463
>
> Anyone know what the issue is?
>
> Cheers,
> Mark.
>
> (apologies for the previous empty email)
> ___
> 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/KMXK6BQWQZRR2TGVRLECMR7CUVIVTUMQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Regards,
Karthikeyan S
___
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/TJE5XWLKRC3EQUXKSHCJNA25H3WGVP5B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

[Karthikeyan]

On Thu, Dec 5, 2019 at 6:23 PM Mark Shannon  wrote:

>
>
> On 05/12/2019 12:45 pm, Karthikeyan wrote:
> > On Thu, Dec 5, 2019, 5:53 PM Mark Shannon  > <mailto:m...@hotpy.org>> wrote:
> >
> >
> >
> > On 04/12/2019 2:31 am, Gregory P. Smith wrote:
> >  >
> >  >
> >  > On Tue, Dec 3, 2019 at 8:21 AM Mark Shannon  > <mailto:m...@hotpy.org>
> >  > <mailto:m...@hotpy.org <mailto:m...@hotpy.org>>> wrote:
> >  >
> >  > Hi Everyone,
> >  >
> >  > I am proposing a new PEP, still in draft form, to impose a
> > limit of one
> >  > million on various aspects of Python programs, such as the
> > lines of
> >  > code
> >  > per module.
> >  >
> >  > Any thoughts or feedback?
> >  >
> >
> > [snip]
> >
> >  >
> >  >
> >  > Overall I /like/ the idea of limits... /But.../ in my experience,
> > limits
> >  > like this tend to impact generated source code or generated
> > bytecode,
> >  > and thus any program that transitively uses those.
> >  >
> >  > Hard limits within the Javaish world have been *a major pain* on
> the
> >  > Android platform for example.  I wouldn't call workarounds
> >  > straightforward when it comes to total number of classes or
> > methods in a
> >  > process.
> >
> > Do you have any numbers? 1M is a lot bigger then 64K, but real world
> > numbers would be helpful.
> >
> >
> > I guess the relevant case in question is with Facebook patching the
> > limit of 65,000 classes in Android :
> >
> https://m.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920
>
> Is that the correct link? That seems to be an issue with an internal
> buffer size, not the limit on the number of classes.
>

Sorry, it should have been about the number of methods limit in Android
that is around 65,000 methods :
https://developer.android.com/studio/build/multidex . I guess facebook
worked around the limit but couldn't find a reliable source for it. There
was also a post on Facebook iOS app with large number of classes but not
essentially hitting a limit on the iOS platform :
https://quellish.tumblr.com/post/126712999812/how-on-earth-the-facebook-ios-application-is-so
.
I guess it's the number referred but I could be mistaken.


>
> >
> >  >
> >  > If we're to adopt limits where there were previously none, we
> > need to do
> >  > it via a multi-release deprecation cycle feedback loop to give
> > people a
> >  > way to find report use cases that exceed the limits in real world
> >  > practical applications.  So the limits can be reconsidered or the
> >  > recommended workarounds tested and agreed upon.
> >  >
> >  > -gps
> > ___
> > Python-Dev mailing list -- python-dev@python.org
> > <mailto:python-dev@python.org>
> > To unsubscribe send an email to python-dev-le...@python.org
> > <mailto: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/ECKES7IPWGD74DAKFYV7JEWNOBAFEWYF/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
>


-- 
Regards,
Karthikeyan S
___
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/EHHH44J6KDRQGZCEUNMCGUUIZ5JUX6UV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

[Karthikeyan]

On Thu, Dec 5, 2019, 5:53 PM Mark Shannon  wrote:

>
>
> On 04/12/2019 2:31 am, Gregory P. Smith wrote:
> >
> >
> > On Tue, Dec 3, 2019 at 8:21 AM Mark Shannon  > > wrote:
> >
> > Hi Everyone,
> >
> > I am proposing a new PEP, still in draft form, to impose a limit of
> one
> > million on various aspects of Python programs, such as the lines of
> > code
> > per module.
> >
> > Any thoughts or feedback?
> >
>
> [snip]
>
> >
> >
> > Overall I /like/ the idea of limits... /But.../ in my experience, limits
> > like this tend to impact generated source code or generated bytecode,
> > and thus any program that transitively uses those.
> >
> > Hard limits within the Javaish world have been *a major pain* on the
> > Android platform for example.  I wouldn't call workarounds
> > straightforward when it comes to total number of classes or methods in a
> > process.
>
> Do you have any numbers? 1M is a lot bigger then 64K, but real world
> numbers would be helpful.
>

I guess the relevant case in question is with Facebook patching the limit
of 65,000 classes in Android :
https://m.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920

>
> > If we're to adopt limits where there were previously none, we need to do
> > it via a multi-release deprecation cycle feedback loop to give people a
> > way to find report use cases that exceed the limits in real world
> > practical applications.  So the limits can be reconsidered or the
> > recommended workarounds tested and agreed upon.
> >
> > -gps
> ___
> 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/ECKES7IPWGD74DAKFYV7JEWNOBAFEWYF/
> 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/DYW4WQKNEKUGK526OPP7XQ3XF25WZCJU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: 3.10 or 4.0?

[Karthikeyan]

On Thu, Nov 28, 2019, 9:50 PM Paul Moore  wrote:

> On Thu, 28 Nov 2019 at 15:55, Victor Stinner  wrote:
> >
> > It has been discussed a few months ago. There is the "if six.PY3: ..."
> > issue and similar issues which should be solved first. Basic example:
>
> I've seen a few fixes to projects to remove assumptions that the "X"
> in 3.X is a single digit. So I think that the momentum in the
> community is definitely assuming 3.10 as well.
>

CPython CI configuration itself had the assumption :
https://github.com/python/cpython/pull/14831 . I think there were some
issues raised with the title having [3.10] preparation for similar cases.

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

[Python-Dev] Re: Docs: audit event table empty

[Karthikeyan]

On Tue, Jul 9, 2019 at 5:34 PM Julien Palard via Python-Dev <
python-dev@python.org> wrote:

> Hi Christian,
>
> > the table with auditing events does not render on docs.python.org,
> > https://docs.python.org/3.9/library/audit_events.html. Steve and I are
> > going to present the auditing feature tomorrow at EuroPython. It would
> > be helpful to have the table available.
>
> This was not an easy one... and it may be a Sphinx issue, yet I'm still
> not sure, maybe Steve can shed some light on it:
>
> It's the "-j" option of sphinx-build (to parallelize) that causes the
> issue. I double checked it (full commands at the end of the message in case
> someone want to reproduce it):
>
> - Run with -j4 → No table
> - Run without -j → Table is here
> - Run again with -j4 → No table!
> - Run again without -j → Table is back!
>

I can reproduce the same with table not appearing in parallel builds and
table is successfully built on non-parallel builds. On adding -j4 to
ALLSPHINXOPTS in my Makefile in Docs/ folder there is no table generated.
Currently, the audit events are collected in a dictionary and are stored in
self.state.document.settings.env that is initialized with empty dict in
AuditEvent directive [0].

* On non-parallel builds when I use print statement with hasattr to check
for all_audit_events, it's False for first time and then remains True with
tuple set for rest of the collection. In process_audit_events for
non-parallel builds the attribute is set with a dictionary of all audit
events.
* On parallel builds when I use print statement with hasattr to check for
all_audit_events, it returns True and False randomly throughout the build.
I guess it's due to attribute not being properly initialized. In
process_audit_events for parallel builds the all_audit_events attribute is
not at all set during table creation and falls back to empty tuple writing
no rows to the table.

I am not sure if modifying the env attribute on parallel builds is safe
since I couldn't find any guarantees from the sphinx docs. The default docs
Makefile is not parallel which could be the reason it was not reproducible
locally.

Thanks for fixing this.

[0]
https://github.com/python/cpython/blob/73ea54620a6f91c3f2e53880373dd47813691a21/Doc/tools/extensions/pyspecific.py#L187


> I'm patching docsbuild-scripts to stop using -j4 with is not really
> helpfull anyway as docsbuild script is parallelizing by starting multiple
> sphinx-build (for multiple languages / versions).
>
> I also copied the file and invalidated the cache, so
> https://docs.python.org/3.9/library/audit_events.html is good again.
>
> If I'm too slow testing locally and releasing a new docsbuild_script.py,
> the cron MAY break the file again, don't hesitate to poke me if it happen
> without me noticing first.
>
> Full test:
>
> docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$
> /srv/docsbuild/venv/bin/sphinx-build -b html -d build/doctrees -D
> latex_elements.papersize= -D latex_engine=xelatex -D
> latex_elements.inputenc= -D latex_elements.fontenc= -j4 -q -Ea -A daily=1
> -A switchers=1  . build/html
> docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ grep breakpoint
> build/html/library/audit_events.html
> docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$
> /srv/docsbuild/venv/bin/sphinx-build -b html -d build/doctrees -D
> latex_elements.papersize= -D latex_engine=xelatex -D
> latex_elements.inputenc= -D latex_elements.fontenc= -q -Ea -A daily=1 -A
> switchers=1  . build/html
> docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ grep breakpoint
> build/html/library/audit_events.html
> builtins.breakpoint
>  class="pre">breakpointhook
>  href="functions.html#breakpoint">[1]
> docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$
> /srv/docsbuild/venv/bin/sphinx-build -b html -d build/doctrees -D
> latex_elements.papersize= -D latex_engine=xelatex -D
> latex_elements.inputenc= -D latex_elements.fontenc= -j4 -q -Ea -A daily=1
> -A switchers=1  . build/html
> docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ grep breakpoint
> build/html/library/audit_events.html
> docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$
> /srv/docsbuild/venv/bin/sphinx-build -b html -d build/doctrees -D
> latex_elements.papersize= -D latex_engine=xelatex -D
> latex_elements.inputenc= -D latex_elements.fontenc= -q -Ea -A daily=1 -A
> switchers=1  . build/html
> docsbuild@docs:/srv/docsbuild/3.9/cpython-en/Doc$ grep breakpoint
> build/html/library/audit_events.html
> builtins.breakpoint
>  class="pre">breakpointhook
>  href="functions.html#breakpoint">[1]
>
> Bests,
> --
> Julien Palard
> https://mdk.fr
> ___
> Python-Dev mailing list -- pytho

[Python-Dev] Preserve keyword argument order in unittest.mock call repr output

[Karthikeyan Singaravelan]

>From Python 3.6 the order of keyword arguments to a function is preserved. In 
>https://bugs.python.org/issue21256 the order of keyword arguments for 
>unittest.mock's repr were sorted to return deterministic output for usage in 
>doctest and other use cases. This currently gives little inconsistent output 
>where the keyword argument order in below mock call is (b=2, a=1) but it's 
>sorted in the error message and mock_calls list to give (a=1, b=2). 

I have opened https://bugs.python.org/issue37212 to preserve the order. It was 
recommended in the issue 21256 too at 
https://bugs.python.org/issue21256#msg216512 . The drawback is that it's 
backwards incompatible where tests that assert error messages might have used 
the sorted order. Due to equality implementation call(a=1, b=2) == call(b=2, 
a=1) is still True so assertions are not affected. There are no test failures 
in mock test suite except the test in the original issue where sorted output is 
asserted. Sorting the keyword arguments was also not documented. I propose 
removing this sorted order in 3.9 and to preserve the original order. The 
change is straightforward and I can add a PR if this change is accepted.

>>> from unittest.mock import Mock, call
>>> m = Mock(name='m')
>>> m(b=2, a=1)

>>> call(a=1, b=2) == call(b=2, a=1)
True
>>> m.mock_calls
[call(a=1, b=2)]
>>> m.assert_called_with(c=1)
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/unittest/mock.py", 
line 870, in assert_called_with
raise AssertionError(_error_message()) from cause
AssertionError: expected call not found.
Expected: m(c=1)
Actual: m(a=1, b=2)
___
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/6F2NGCERZLZ2CDGYIAR5QOHMGAAE5VHE/

Re: [Python-Dev] "if __name__ == '__main__'" at the bottom of python unittest files

[Karthikeyan]

> I thought https://www.python.org/dev/peps/pep-0582/ had something about
> no longer add '.' to sys.path, but looks like I was mistaken.
>

It was discussed [0] in the past with respect to security since Perl did a
similar change and PEP 432 is also mentioned in the thread. [1]

[0] https://mail.python.org/pipermail/python-ideas/2017-June/045842.html
[1] https://mail.python.org/pipermail/python-ideas/2017-June/045849.html

-- 
Regards,
Karthikeyan S
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "if __name__ == '__main__'" at the bottom of python unittest files

[Karthikeyan]

On Wed, May 1, 2019 at 6:13 PM Serhiy Storchaka  wrote:

> 01.05.19 10:09, Chris Withers пише:
> > Right, but that's not the documented way of running individual suites in
> > the devguide.
> >
> > I'm happy to remove these on the basis that there should be one and only
> > one way of doing things like this.
>
> This principle is not applicable here because the Python testsuite is
> not a public API. It is not for use of Python users.
>
> We try to support several different ways of running tests. This allows
> to catch some environment depended flaws in tests and serves as a kind
> of the test of unittest itself. Not all test files are made discoverable
> yet, but we move in this direction.
>

Agreed. This also has helped in the past to find issues like
https://bugs.python.org/issue29512#msg299045.


>
> I do not see what is wrong here and suggest to not break working code.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/tir.karthi%40gmail.com
>


-- 
Regards,
Karthikeyan S
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Any core dev event plans for EP19?

[Karthikeyan]

On Fri, Apr 26, 2019 at 3:40 AM Ivan Levkivskyi 
wrote:

> Hi,
>
> I want to come to EP this year, but didn't register yet, is registration
> already open?
>
> Just to add to this core developers are eligible for free entry to the
conference : https://www.europython-society.org/core-grant

-- 
Regards,
Karthikeyan S
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Need help to fix HTTP Header Injection vulnerability

[Karthikeyan]

> 1. Is there a library of URL / Header injection tests e.g. for fuzzing
> that we could generate additional test cases with or from?


https://github.com/swisskyrepo/PayloadsAllTheThings seems to contain
payload related stuff but not sure how useful it is for URL parsing.

>
> 2. Are requests.get() and requests.post() also vulnerable?
>

urllib3 seems to be vulnerable as noted in
https://bugs.python.org/issue36276#msg337837 . requests uses urllib3 under
the hood. The last time I checked requests passed encoded URL to urllib3
where this doesn't seem to be exploitable but I could be wrong.

-- 
Regards,
Karthikeyan S
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Need help to fix HTTP Header Injection vulnerability

[Karthikeyan]

Thanks Gregory. I think it's a good tradeoff to ensure this validation only
for URLs of http scheme.

I also agree handling newline is little problematic over the years and the
discussion over the level at which validation should occur also prolongs
some of the patches. https://bugs.python.org/issue35906 is another similar
case where splitlines is used but it's better to raise an error and the
proposed fix could be used there too. Victor seemed to wrote a similar PR
like linked one for other urllib functions only to fix similar attack in
ftplib to reject newlines that was eventually fixed only in ftplib

* https://bugs.python.org/issue30713
* https://bugs.python.org/issue29606

Search also brings multiple issues with one duplicate over another that
makes these attacks scattered over the tracker and some edge case missing.
Slightly off topic, the last time I reported a cookie related issue where
the policy can be overriden by third party library I was asked to fix it in
stdlib itself since adding fixes to libraries causes maintenance burden to
downstream libraries to keep up upstream. With urllib being a heavily used
module across ecosystem it's good to have a fix landing in stdlib that
secures downstream libraries encouraging users to upgrade Python too.

Regards,
Karthikeyan S

>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Need help to fix HTTP Header Injection vulnerability

[Karthikeyan]

I would recommend fixing it since it's potentially remote code execution on
systems like Redis (latest versions of Redis have this mitigated) though I
must admit I don't fully understand the complexity since there are multiple
issues linked. Go was also assigned a CVE for linked issue and it seemed to
be the same reporter by username : CVE-2019-9741 . I tried using go's
approach in the commit but urlopen accepts more URLs like data URLs [0]
that seemed to accept \n as a valid case and the patch broke some tests.
Looking at the issue discussion complexity also involves backwards
compatibility. golang also pushed an initial fix that seemed to broke their
internal tests [0] to arrive at a more simpler fix.

[0]
https://github.com/python/cpython/blob/a40681dd5db8deaf05a635eecb91498dac882aa4/Lib/test/test_urllib.py#L482
[1]
https://go-review.googlesource.com/c/go/+/159157/2#message-39c6be13a192bf760f6318ac641b432a6ab8fdc8

-- 
Regards,
Karthikeyan S
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bedevere pipelines hang on github

[Karthikeyan]

This seems to be fixed now :
https://github.com/python/core-workflow/issues/321

Regards,
Karthikeyan S
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] how to rerun the job “Azure Pipelines PR”?

[Karthikeyan]

Closing and re-opening the PR will trigger the CI run again that might help
in this case but it will run all the jobs.

-- 
Regards,
Karthikeyan S
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 581: Using GitHub Issues for CPython

[Karthikeyan]

On Fri, Mar 8, 2019 at 12:41 AM Mariatta  wrote:

> I'd like to formally present to Python-dev PEP 581: Using GitHub Issues
> for CPython
>
> Full text: https://www.python.org/dev/peps/pep-0581/
>
>
Thanks a lot for doing this!

* The current bug tracker has low contributions and moving to a place like
GitHub would open up to a lot of opportunities like integrations, webhooks
where people can build custom workflow etc. along with reducing the
maintenance burden on the team.
* GitHub also allows markdown and syntax highlighting on code snippets
would be much easier to read compared to current tracker. In some cases
GitHub can even inline the code for a permalink to a single line which adds
more context. Also support for editing comments to fix minor typos links
are great. Emoji support :)
* The current bpo search is surprisingly very effective though it just does
substring search across comments and patches I believe. If not I can google
keywords with site:bugs.python.org to get relevant results. I expect search
to be better on GitHub but worth experimenting since searching to get
related issues/discussion helps a lot in triaging.

Some points worth considering and some of them are addressed in the PEP
already.

* Moving to GitHub also comes at a cost of accessibility where there might
be people posting questions that are more suitable for stackoverflow,
python-list etc. Thus there might be more incoming issues that would
require more effort on triaging.
* There could be explicit guidelines on when a triager should close an
issue and current bpo supports custom fields for resolution, state of the
issue (open/close/pending/needs-test/patch-review)  that are updated.
Besides closing the issue there could be labels or a comment format to
describe the rationale and resolution.
* There could also be guidelines on when to lock the thread since there
could be cases where security issues or issues that can trigger heated
arguments are posted. It could get even more attention when it's posted on
Reddit or hackernews attracting unwanted attention e.g. security issues in
npm posted to reddit. Someone can chime in to lock it but guidelines on
when to do this would be helpful so that decision is not based on personal
opinion to lock it.
* Extended discussions in some cases along with no proper support for
threading could result in lot of duplicated messages that would be hard to
scroll through. It's a problem with current tracker too but something that
can come up where people will use +1 comments instead of using thumbs up
emoji. Rust community had some similar concerns since they do RFC
discussions on GitHub that result in 200+ comments. Though we don't do PEP
discussions some bugs can result in this.
* I wish python-bug-list, weekly summary continues to be integrated with
GitHub too since some of us don't want to watch the repo to get all the
activity along with pull requests and just want to track activity on issues.
* Currently there is some link rot on bpo for svn related links, broken
patch file links etc. Moving to GitHub I guess they are handled like magic
links for PEPs, bpo-, etc. that are mentioned in the PEP 581.

Personally, I think more people will love it once they get to use it so if
something like 100 issues can be migrated to a sample repo with labels,
content etc. As a shameless plug I tried migrating around 150 issues in
current bpo to GitLab sometime back with components as labels. Though an
apple to oranges comparison (GitLab UI vs GitHub UI) I personally find the
UI (also GitHub UI) very easy to navigate in terms of clicking on labels,
search, sort, filter etc. in https://gitlab.com/tirkarthi/python-bugs/issues
and the issue is more easy to read with markdown support for code where I
added highlight to snippet
https://gitlab.com/tirkarthi/python-bugs/issues/140

-- 
Regards,
Karthikeyan S
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] configparser: should optionxform be idempotent?

[Karthikeyan]

On Thu, Mar 7, 2019 at 2:51 PM Inada Naoki  wrote:

> Hi, all.
>
> I came from https://bugs.python.org/issue35838
> Since there are no "expert" for configparser in
> Expert Index, I ask here to make design decision.
>

There is lukasz.langa in the expert index for configparser at
https://devguide.python.org/experts/#stdlib and that's why I deferred to
them.

The default behavior of CofigParser.optionxform
> is str.lowercase().  This is used to canonicalize
> option key names.
>
> The document of the optionxform shows example
> overrides it to identity function `lambda option: option`.
>
> https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.optionxform
>
> BPO-35838 is issue about optionxform can be called twice
> while ConfigParser.read_dict().
> If optionxfrom is not idempotent, it creates unexpected option
> name.
> https://bugs.python.org/issue35838#msg334439
>
> But even if all APIs calls optionxform exactly once, user may
> read option name and value, and write updated value with same name.
> In this case, user read option name already optionxform-ed
> (canonicalized).  So non-idempotent optionxform will break
> option name.
>
> So what should we do about optionxform?
>
> a)  Document "optionxform must be idempotent".
>

I also feel this is restrictive since wrapping keys with () looks like a
valid use case to me.

b) Ensure all APIs calls optionxform exactly once, and document
>"When you get option name from section objects, it is already
> optionxform-ed.  You can not reuse the option name if
> optionxform is not idempotent, because optionxform will be
> applied to the name again."
>
> I prefer (a) to (b) because it's simple and easy solution.
>

I initially preferred (b) while read_dict is one case. As you have
mentioned in the tracker there are various scenarios where the transform is
done and stored in the underlying internal dict and then while setting one
section key to another it might apply it again. Also I am afraid there is
less test coverage for optionxform itself so there could be more scenarios
to cover increasing the complexity.

-- 
Regards,
Karthikeyan S
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "Good first issues" on the bug tracker

[Karthikeyan]

On Sun, Feb 24, 2019 at 1:07 PM Terry Reedy  wrote:

> On 2/23/2019 2:50 PM, Cheryl Sabella wrote:
>
>   AM Karthikeyan  wrote:
> > I would also recommend waiting for a core dev or someone to provide
> > some feedback or confirmation on even an easy issue's fix since it's
> > easy to propose a fix to be later rejected due to various reasons
> > resulting in wasted work and disappointment.
> >
> > Agreed, but perhaps the most helpful way to do that is to propose the
> > fix in a comment on the bug tracker and then, if a core dev or expert
> > says it's a good idea, then move ahead with it?
>
> I agree with both of you as to what contributors, especially new
> contributors, *should* do.  But they sometimes race to 'grab' an issue
> by (prematurely) submitting a PR, sometimes after ignoring coredev
> comments and disagreements.  I have occasionally said on an issue that a
> PR was premature.
>

I guess it could be due to the initial excitement in contributing to a
large project. I must admit I too did some mistakes in my initial set of
PRs along similar lines. I guess it's one of the things both someone
contributing new and a regular contributor should learn over the course of
time that there are cases where the solution might seem important from the
perspective of the contributor in getting code merged but provides less
value amidst other factors like code maintenance, backwards compatibility,
etc.

There is also high interest in creating a PR and less on reviewing other
PRs (1020 open PRs on GitHub) which could be a separate topic on its own.
There could be some action or motivation on making sure there is a balance
in the incoming PRs and review bandwidth since there might be a stage where
there is a lot of interest or efforts in getting new contributors who
create a PR with less bandwidth to review resulting in potentially making
them disappointed in having work not reviewed. We should be getting new
people on board and it's not that I complaining but this is something that
the steering council could discuss upon regarding reviews and there was a
recent thread on it [0]

[0]
https://mail.python.org/pipermail/python-committers/2019-February/006517.html

-- 
Regards,
Karthikeyan S
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] "Good first issues" on the bug tracker

[Karthikeyan]

de. I ask you to not
> write everything yourself, and sometimes give the simplest issues to
> contributors who are eager to help you.
>
> Victor
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/tir.karthi%40gmail.com
>
-- 

Regards,
Karthikeyan S
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com