[Python-Dev] Re: Retiring this mailing list ?

[Senthil Kumaran]

On Mon, Nov 13, 2023 at 2:21 AM Marc-Andre Lemburg  wrote:

> Question: Should we retire and archive this mailing list ?
> (I'm asking as one of the maintainers of the ML)

+1 to retiring and archiving.

Less overhead for maintainers and information concentrated at a single
source, that is, discuss.python.org .

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

[Python-Dev] Re: urllib: addressing inflexibility in scheme-based joining

[Senthil Kumaran]

On Thu, Feb 10, 2022 at 10:23:59PM -0700, Lincoln Auster wrote:
> This is a follow-up RFC on PR #30520 (BPO 46337) with regard to urllib's
...

> It's been about a month since I wrote that PR, and it was marked stale a
> day or two ago. Would anyone be willing to give it a look for feedback
> and a potential merge?

Thanks for bringing this up.

https://github.com/python/cpython/pull/30520

I will review it. If any other core-dev reviews earlier than me, I am good with 
it too.

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

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

[Senthil Kumaran]

On Sun, Feb 06, 2022 at 03:08:40PM +0100, Victor Stinner wrote:

> I propose to deprecate the urllib module in Python 3.11. It would emit
> a DeprecationWarning which warn users, so users should consider better
> alternatives like urllib3 or httpx: well known modules, better
> maintained, more secure, support HTTP/2 (httpx), etc.
> 
> I don't propose to schedule its removal. Let's discuss the removal in
> 1 or 2 years.

I am not certain if we can deprecate/remove the whole 'urllib' module without 
any good plan for replacement 
of its facilities within the stdlib. There is heavy usage of urllib.parse in 
multiple projects (including in urllib3), 
and parse is semi-maintained. 

> Let's come back to urllib:

> * It's API is too complicated
> * It doesn't support HTTP/2 nor HTTP/3
> * It's barely maintained: there are 121 open issues including 3 security 
> issues!

I agree with all of these.
I think that removing the old cruft code, might lead to us to closing a number 
of open issues.

>  The 3 open security issues:

Just because if something marked 'security' doesn't make it actionable too. 
For instance the last one asks for urllib to maintain client state to be safe 
against a scenario, which it never did.

I don't think it is time to deprecate the urllib module. It will be too 
disruptive IMO. SO, -1.

Right now, I don't have a solution.  
My suggestion will be we close old bugs, and remove old code (aka maintain a 
bit, and it falls on me too).
Then we can probably chart out a deprecation / replacement path in a 
non-disruptive manner.


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

[Python-Dev] Re: compiled python3.10 is unable to find _ssl

[Senthil Kumaran]

Your configure script did pick up openssl as the support version was not
found.

What is your operating system? Make sure you have supported version of
ssl. Python requires openssl 1.1.1 or higher.

On Mac, I had to use brew to install it and --with-openssl flag.

On some linux machines, I have had to download openssl, compile it, and
point my the configure script to (location I compiled openssl).
CFLAGS="-I$HOME/openssl/include" LDFLAGS="-L$HOME/openssl/lib"

Thank you,
Senthil

On Mon, Oct 18, 2021 at 08:16:01PM +0530, Sandeep Gupta wrote:
> I  am having compilation issues again with python3.10 with ssl .
> 
> The ./configure was invoked with ssl options and ssl modules seems to
> be build successfully.
> 
> """
> The following modules found by detect_modules() in setup.py, have been
> built by the Makefile instead, as configured by the Setup files:
> _abc  _hashlib  _ssl
> pwd   time
> """
> 
> However, when I do import ssl from python, I get the  error:
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/home/shared/Builds/Python-3.10.0/lib/python3.10/ssl.py", line
> 98, in 
> import _ssl # if we can't import it, let the error propagate
> ModuleNotFoundError: No module named '_ssl'
> 
> I can't find _ssl.so in build or install directory.
> 
> Thanks
> -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/IIFABHN7DOTCXMRQ72SLJSU4VDWRM2HB/
> 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/JN6FB7675WTRB23HXD5CGBF4NUCZKSOD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: RFC: New/update the Docs Sphinx theme: responsive, edit page links,

[Senthil Kumaran]

Replying to Python-Dev. I hope you found the list and got feedback from
the documentation maintainers. Python devguide
https://devguide.python.org/ was using an updated theme, and I assume
that docs will get updated soon a responsive. There have been plenty
discussions on this front.


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

[Python-Dev] Re: Is anyone relying on new-bugs-announce/python-bugs-list/bugs.python.org summaries

[Senthil Kumaran]

>
> As part of PEP 588, migrating bugs.python.org issues to Github, there
> are two current mailing list related items that need a replacement or
> need to be turned down.
>
> 1. Weekly summary emails with bug counts and issues from the week,
> example:
> https://mail.python.org/archives/list/python-dev@python.org/thread/JRFJ4QH7TR35HFRQWOYPPCGOYRFAXK24/
>
> 2. Emails sent to the new-bugs-announce and python-bugs-list for new
> issues and comments to existing issues.
>

I occasionally rely on these. Those weren't noise to me.

I assume new instructure might bring other benefits, so we won't be certain
if we will need these new-bugs-announcements emails.
Or those might be replaced with something better.

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

[Python-Dev] Re: API's to interface python with Eclipse to execute and debug C/C++ Source files.

[Senthil Kumaran]

On Thu, Aug 19, 2021 at 04:27:19AM +, Chandrakant Shrimantrao wrote:
> Hi,
> We would like to know if there is  any option available to execute and debug(
> setting break point and delete break point) C/C++ Source files Python API's
> inside Eclipse IDE after interfacing Pydev with Eclipse.

This is a good question for PyDev Eclipse Plugin. As far as I know, tI
have not seen breakpoints for C/C++ with Pydev Eclipse, but I am not
regular use of PyDev.

For debugging Python's C Source files, I found Visual Studio Code's
support for Makefile, C and Python to be useful.

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

[Python-Dev] Re: PEP-535 (Rich comparison chaining) Discussion?

[Senthil Kumaran]

On Tue, Aug 31, 2021 at 8:57 AM Angus Hollands  wrote:


> Should look more like
> ```python
> x = np.array(...)
> y = x[2 < x < 8]
> ```
> Is there any interest in pushing this PEP along?
>

My personal opinion is, it is worth discussing again. I could see the
benefits this brings to Numpy Arrays.
The PEP itself was deferred based on boolean overload dislike than the
short-circuit or chaining operator preference.

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

[Python-Dev] Re: Windows buildbots may be broken

[Senthil Kumaran]

On Fri, Jul 30, 2021 at 02:28:08PM +, Jason R. Coombs wrote:

> If you run such a buildbot, please consider running this command on
> your repo to bypass the issue:
> 
> git rm -r :/ ; git checkout HEAD -- :/
>
> You may want to consider adding this command after every update to the
> repo to avoid the stale state.

What does this do? Especially the first command. Is this Windows specific?

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

[Python-Dev] Re: Python3 OSF/1 support?

[Senthil Kumaran]

On Wed, Jul 14, 2021 at 04:30:33AM +, Jay K wrote:
> Hi. I have an Alpha/OSF machine up and running.
> It is little slow, but it works ok.
> 
> I would like to run Python3 on it.
> 
> I have it "compiling and working". It was easy enough so far.
>   https://github.com/python/cpython/pull/27063
> 
> Admitted, I haven't figured out what is happening with the posixsubprocess
> module.
> 
> Yes? No? Maybe?
> 
> I can possibly provide ongoing "support" (I don't expect it will be much) and 
> a
> buildbot (if really required),
> if I can get it working a bit more, if this is approved, etc. I haven't looked

It is difficult to maintain support for less commonly used systems. If
you maintain it personally (like using a cron) and look at the results
over time, you could see the difficulty in maintaining the support.

Personally, my vote is a -1 here. In the PR, another core-dev, Ronald
had commented that support for explicitly removed a few years ago.

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

[Python-Dev] Re: Towards removing asynchat, asyncore and smtpd from the stdlib

[Senthil Kumaran]

On Wed, Jun 23, 2021 at 10:49:04PM +0100, Irit Katriel via Python-Dev wrote:

> The next step is to add deprecation warnings, so that we can eventually delete
> them. There is also the issue that some of the stdlib tests are still using
> these libraries, but this does not need to block removing them from the stdlib
> because we can move them to test.support until those tests are rewritten.

This is a very good idea. I also read in another discussion that
offering these as pip installable external packages could be considered,
either by the core-dev or by community, just in case there is a reliance
on these packages in production code and the developers don't want those
the break and aren't ready to upgrade or migrate.

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

[Python-Dev] Re: Why list.sort() uses mergesort and not timsort?

[Senthil Kumaran]

On Sun, Jun 06, 2021 at 04:07:57PM -0700, Dan Stromberg wrote:
> I've got a comparison of sort algorithms in both Cython and Pure Python (your
> choice) at:
> https://stromberg.dnsalias.org/~strombrg/sort-comparison/ 
> ...including a version of timsort that is in Cython or Pure Python.
> 

Interesting! timsort get's to near-linear in your benchmark.

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

[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

[Senthil Kumaran]

On Thu, Jun 03, 2021 at 07:08:06PM +0100, Robin Becker wrote:
> The regression may well be a platform issue. I am by no means an expert at
> building python; I followed a recipe from the ARCH PKGBUILD of some time

I meant the change in the diff we were suspecting was supposed to be
"Windows" specific. But interesting that it was observed in ARCH. The
non-windows piece of changes were probably responsible

> You guys can certainly develop language changes faster than us maintainers
> can use them; the dead hand of past usage is a real handicap.

I was thinking in terms of Bug-Fix (https://bugs.python.org/issue43105)
that is causing an interesting behavior change (still not certain to
call this a regression).

> I have managed a smaller example which breaks for me in arch linux latest.
> 
> The self contained code is here
> 
> https://www.reportlab.com/ftp/timport-310b1.py
> 
> I switched to using importlib.import_module as I think that can now always be 
> used in the versions we support.

Thanks for this report, Robin. 

I will reference this in the issue43105, which has probably has the
context to this.

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

[Python-Dev] Re: Proposal: declare "unstable APIs"

[Senthil Kumaran]

On Thu, Jun 03, 2021 at 10:10:53AM -0700, Guido van Rossum wrote:
> This is not a complete thought yet, but it occurred to me that while we have
> deprecated APIs (which will eventually go away), and provisional APIs (which
> must mature a little before they're declared stable), and stable APIs (which
> everyone can rely on), it might be good to also have something like *unstable*
> APIs, which will continually change without ever going away or stabilizing.

The first grey area will between Provisional API vs Unstable API.

Do developers consider provisional APIs as stable and start relying upon
heavily? I am not sure. 

I also lack the experience for the use-cases that you are thinking
about.

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

[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

[Senthil Kumaran]

On Thu, Jun 03, 2021 at 09:55:57AM -0700, Guido van Rossum wrote:
> Maybe this?
> 
> 04732ca993 bpo-43105: Importlib now resolves relative paths when creating
> module spec objects from file locations (GH-25121)

Likely!. But
https://github.com/python/cpython/commit/04732ca993fa077a8b9640cc77fb2f152339585a
was supposed to a platform specific bug fix.

I didn't a sense that reportlab regression detected was platform
specific one.  The behavior change is an interesting one though.

More interesting thing for me was developers running large test suites
between alpha and beta releases, and reporting bugs! :-)

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

[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

[Senthil Kumaran]

On 3 Jun 2021, at 09:31, Robin Becker  wrote:

> ReportLab has quite a large codebase and I think it would be hard to
> get a concise test of this behaviour change. I would be glad if this
> is an expected change a7-->b1 and if the use of '.' in this way has
> become somehow wrong.

To me, this sounds like an excellent candidate for git bisect to help
and figure out which exact commit caused this behavior change.

Was it possible for you to detect that?

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

[Python-Dev] Re: expanduser('~other') reliability and future

[Senthil Kumaran]

On Wed, Apr 28, 2021 at 05:44:06PM +0100, Barney Gale wrote:
> From a bit of googling, Python seems to be an outlier in having a function to
> retrieve another user’s home directory.

> Any views on this? Is expanduser(‘~other’) fixable and worth fixing? If not,
> should we deprecate this functionality? Or something else?

+1 to deprecate this functionality. This does not seem to be common usecase to
be present in stdlib, and reliablity across platform seems difficult.

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

[Python-Dev] Re: bz2.BZ2File doesn't support name?

[Senthil Kumaran]

Hello Hasan,

Thank you. Please submit your patch as a PR in Github.
https://devguide.python.org/pullrequest/
Also, why did you have a self.filename and (getter?) as name. You could set
the attribute as name.

Thank you,
Senthil

On Tue, Apr 27, 2021 at 12:32 AM Hasan Diwan  wrote:

> I just added the .name property to bz2.Bzip2File and added a test to
> verify it. -- H
>
> On Mon, 26 Apr 2021 at 21:40, Senthil Kumaran  wrote:
>
>> There is an open bug report https://bugs.python.org/issue24258
>>
>> I guess it was overlooked. It could be a good task for someone
>> interested.
>> Please add me as a reviewer if you submit a patch, I can help review and
>> move it forward.
>>
>> On Mon, Apr 26, 2021 at 9:22 PM  wrote:
>>
>>> I was surprised recently to discover that BZ2File (at least in 3.7)
>>> doesn't have a name attribute.  Is there some fundamental reason name
>>> couldn't be supported, or is it just a bug that it wasn't implemented?
>>> ___
>>> 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/N3Q7AN5ISRGKS76GT4YSJX2SV6BNQIWM/
>>> 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/NCGH6EYRIDFANEAWDQ3KVE6LFXNS4ROV/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> OpenPGP: https://hasan.d8u.us/openpgp.asc
> If you wish to request my time, please do so using 
> *bit.ly/hd1AppointmentRequest
> <http://bit.ly/hd1AppointmentRequest>*.
> Si vous voudrais faire connnaisance, allez a *bit.ly/hd1AppointmentRequest
> <http://bit.ly/hd1AppointmentRequest>*.
>
> <https://sks-keyservers.net/pks/lookup?op=get=0xFEBAD7FFD041BBA1>Sent
> from my mobile device
> Envoye de mon portable
> ___
> 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/B3CCQRW7UKPK3GD7A6ZSRYNRV3CVXG6V/
> 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/EHDAR5JN2NIV4NEQXWJG525XUPZYNYTQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: bz2.BZ2File doesn't support name?

[Senthil Kumaran]

There is an open bug report https://bugs.python.org/issue24258

I guess it was overlooked. It could be a good task for someone interested.
Please add me as a reviewer if you submit a patch, I can help review and
move it forward.

On Mon, Apr 26, 2021 at 9:22 PM  wrote:

> I was surprised recently to discover that BZ2File (at least in 3.7)
> doesn't have a name attribute.  Is there some fundamental reason name
> couldn't be supported, or is it just a bug that it wasn't implemented?
> ___
> 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/N3Q7AN5ISRGKS76GT4YSJX2SV6BNQIWM/
> 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/NCGH6EYRIDFANEAWDQ3KVE6LFXNS4ROV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merge Request Review Reminder

[Senthil Kumaran]

Given this discussion, I am motivated to review this and merge this
into stdlib. The conversation was helpful to me to understand for
utility value of the method introduced by the patch.
I had stated in the PR as well.

Thank you, both, Faisal and Jakub.

On Mon, Mar 22, 2021 at 5:40 PM Jakub Stasiak  wrote:
>
>
>
> > On 22 Mar 2021, at 13:07, Faisal Mahmood  wrote:
> >
> > Thanks Jakub, I wasn't aware of the netaddr library but just gave it a play 
> > and it does seem very similar and I think it's very useful and completely 
> > valid.
> >
> > I think the subtle difference is also that my implementation allows you to 
> > specify the next prefix as well, so it won't just find the next prefix of 
> > the same size.  This is a common use case when you are trying to find free 
> > address spaces, you will need to look for networks of different sizes 
> > depending on what you are doing.
> >
> > Currently, you could say that you were given a network of 10.200.20.0/24 
> > and asked to split this network into a bunch of /26 networks, you can do 
> > this easily using the subnets method:
> > >>> list(IPv4Network("10.200.20.0/24").subnets(prefixlen_diff=2))
> > [IPv4Network('10.200.20.0/26'), IPv4Network('10.200.20.64/26'), 
> > IPv4Network('10.200.20.128/26'), IPv4Network('10.200.20.192/26')]
> >
> > That is very simple and effective, but not a very realistic example of how 
> > you would split networks up.  Given how limited the IPv4 address space is, 
> > normally you may have to use that /24 block for multiple things, so can't 
> > just simply split it up into /26's, you may need to instead get two /30's, 
> > one /27 and one /25.  Currently, I don't think there is any straightforward 
> > way to do this without a 'next_network' method that I have implemented.
> >
> > Example, given a network of 10.200.20.0/24, to get two /30's out of it, one 
> > /27 and one /25, I would do the following with my method:
> > >>> first_network = IPv4Network("10.200.20.0/30")
> > # first_network = IPv4Network("10.200.20.0/30")
> >
> > Then get the next one (note not specifying prefix just gives me another /30 
> > - i.e. same prefix size):
> > >>> second_network = first_network.next_network()
> > # second_network = IPv4Network("10.200.20.4/30")
> >
> > Then I would need to get the /27, so do this:
> > >>> third_network = second_network.next_network(new_prefixlen=27)
> > # third_network = IPv4Network("10.200.20.32/27)
> >
> > Finally the /25:
> > >>> fourth_network = third_network.next_network(new_prefixlen=25)
> > # fourth_network = IPv4Network("10.200.20.128/25)
> >
> > When you are dealing with the same prefix size for each new network, I 
> > think it's just a simple case of adding 1 to the broadcast address each 
> > time, but when you have different prefix sizes it's a bit more complicated.
> >
> > On Sat, 20 Mar 2021 at 22:04, Jakub Stasiak  wrote:
> >
> >
> >
> > I don’t know if this is gonna support Faisal’s cause (“It’s used in a third 
> > party library in the wild, that means stdlib could use it!”) or the exact 
> > opposite (“it’s provided by a third party library, so may as well use third 
> > party library and stdlib doesn’t necessarily need this”) but the quite 
> > popular netaddr library that I’m a maintainer of does have IPNetwork.next() 
> > and IPNetwork.previous() methods[1][2]. The main difference is that in 
> > netaddr:
> >
> > * next() and previous() can produce networks arbitrary number of steps 
> > away, not just the first closest network forwards or backwards
> > * going from a network to its supernetwork or subnetwork is done through a 
> > separate set of supernet() and subnet() methods[3][4]
> >
> > I can’t say how many library users actually consume this particular section 
> > of the API, of course, but I expect this API to be used and it seems rather 
> > useful.
> >
> > Best,
> > Jakub
> >
> > [1] https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IPNetwork.next
> > [2] 
> > https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IPNetwork.previous
> > [3] 
> > https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IPNetwork.subnet
> > [4] 
> > https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IPNetwork.supernet
>
> Thank you for the explanation – now I understand better how that prefix 
> parameter is useful.
>
> It’s not *that* difficult to emulate this using netaddr, there’s an extra 
> switch-to-supernet or switch-to-subnet step but that’s about it:
>
> >>> from netaddr import IPNetwork
> >>> first_network = IPNetwork("10.200.20.0/30")
> >>> second_network = first_network.next()
> >>> second_network
> IPNetwork('10.200.20.4/30')
> >>> third_network = second_network.supernet(27)[0].next()
> >>> third_network
> IPNetwork('10.200.20.32/27')
> >>> fourth_network = third_network.supernet(25)[0].next()
> >>> fourth_network
> IPNetwork('10.200.20.128/25’)
>
> That said, if merging this into the Python stdlib doesn’t work out I’m open 
> to improving netaddr’s interface to 

[Python-Dev] Re: Merge Request Review Reminder

[Senthil Kumaran]

On Mon, Feb 15, 2021 at 8:36 AM Faisal Mahmood
 wrote:
>
> Hello,
>
> I hope you are all well, I currently have an issue / merge request that has 
> become stale and as per the guidelines I am sending this e-mail to request 
> someone to review it for me please.
>
> Issue Number: 42861 (https://bugs.python.org/issue42861)
> Pull Request: 24180 (https://github.com/python/cpython/pull/24180)
>

Could you share some motivation references that could help explain why
this next_network method will be helpful? Is this common enough to
warrant a method in the stdlib IP-Address module?
If there is prior-art in other external libraries or libraries of
other languages, that will be helpful to know and review too.

I had looked at this a month ago when you pinged for review, but I
could not immediately determine the benefit of having this method in
stdlib, irrespective of implementation correctness or API Signature.
I also lack extensive experience with ipv6.

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

[Python-Dev] Re: Requesting Review for GH-24118 (Fix for bpo-27820)

[Senthil Kumaran]

On Sat, Mar 06, 2021 at 02:08:05PM +0700, Pandu Poluan wrote:
> I have submitted a PR, GH-24118 
> (https://github.com/python/cpython/pull/24118),
> on January 5.
> 
> It's a relatively simple patch that fixes smtplib.SMTP logic for AUTH LOGIN,
> alongside a fix for the test for that class.

I've reviewed it. I have a question on the change, and once that is addressed,
we could move forward with this.

The premise of the PR looks right.

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

[Python-Dev] Re: Suggestion About Python Syntax

[Senthil Kumaran]

Hello Anthony,

Welcome to this list. :) Python is written in C, and developers use
semicolons and branches in C. However, when Guido designed Python, he
specifically wanted white-space indented language. The idea was it
will be less intimidating to beginners and more readables.
It seems to have been a great decision and as the design is still
going strong and is unlikely to change in future.


On Wed, Mar 3, 2021 at 9:48 AM Anthony Farino  wrote:
>
> I love the Python scripting language, but there’s something that would make 
> it much better. Almost every other programming language uses curly braces to 
> enclose blocks of code and semicolons after the lines of code. That means 
> that:
>
> You can have as much white space as you want.
>
> You don’t need to worry about indentation, and you can indent whenever you 
> want.
>
> I hope that you consider these issues and fix them in Python 4 (if you ever 
> make it).
>
> Sincerely, Anthony, age 10.
>
>
>
> --
>mmm#
>##   m mm   mm#mm  # mmmmm   m mm   m   m
>   #  #  #"  ###"  #  #" "#  #"  #  "m m"
>   #mm#  #   ###   #  #   #  #   #   #m#
>  ## #   #"mm  #   #  "#m#"  #   #   "#
> m"
>""
> ___
> 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/RZR2O3Y6Z6RCAXW72Y4WPWZ6HN3MYVFJ/
> 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/DZC4DZIASQJKZSAYV3VJP5WRZKEGMRFC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Requesting Review of Pull Request

[Senthil Kumaran]

Hello Nathan,

The PR is merged. Thank you for contributing and following up here.

--
Senthil

On Tue, Mar 02, 2021 at 07:50:13PM +, Nathan Beals wrote:
> Good Afternoon Python Devs,
> 
> I'm requesting that someone review the pull request linked to this issue:
> https://bugs.python.org/issue42994 (github PR: https://github.com/python/
> cpython/pull/24287).
> 
> I'm following the contributing guidelines instructions to email this address 
> if
> the PR hasn't been addressed in a month (+1 week after pinging it again).
> Thankfully this PR is tiny, at 9 lines total (and even then, it's just 9 new
> entries to a dictionary).
> 
> Thank you for your time,
> Nathan Beals
> 

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

[Python-Dev] Re: Happy 30th Birthday, Python!

[Senthil Kumaran]

On Sun, Feb 21, 2021 at 12:05 AM Larry Hastings  wrote:
> I guess we forgot to observe it yesterday, but: February 19, 1991, was the 
> day Guido first posted Python 0.9.1 to alt.sources:
>
> https://groups.google.com/g/alt.sources/c/O2ZSq7DiOwM/m/gcJTvCA27lMJ
>
> Happy 30th birthday, Python!

Happy 30th Birthday, Python.

Congrats to Guido. The way software was distributed then seems incredible.
It's been an exciting journey for all of us.

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

[Python-Dev] Re: Python 0.9.1

[Senthil Kumaran]

On Tue, Feb 16, 2021 at 1:58 PM Skip Montanaro 
wrote:

>
> I then pushed the result to a Github repo:
>
> https://github.com/smontanaro/python-0.9.1
>

Wow. Was white-space not significant in this release of Python? I see the
lack of indentation in the first Python programs.
___
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/OBWWV3HP7GI24SL6NDN7UPUFTHRKJFXZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] [ Release ] Python 3.10a5 and release blockers

[Senthil Kumaran]

Hi Pablo,

Looks like alpha 5 was scheduled for today.  I am willing to take care of
this issue - https://bugs.python.org/issue42967
The patch is reasonable, but the changes are backwards incompatible.
Since it is with an underlying parsing library, the decision here is tricky
one way or the other.
I will let you know if I decide it for 3.10, an easier decision than
backport. I just have to see how other libraries took care of this issue.

But if for some reason, we couldn't include in -alpha5, we should plan
-alpha6.

Thanks,
Senthil





On Mon, Feb 1, 2021 at 11:48 AM Pablo Galindo Salgado 
wrote:

> Hi everyone,
>
> I am prepared to start the release process for Python 3.10 a5 but there
> are several
> issues marked as release blockers that affect 3.10:
>
> * https://bugs.python.org/issue38302
> * https://bugs.python.org/issue42634
> * https://bugs.python.org/issue41490
> * https://bugs.python.org/issue42967
> * https://bugs.python.org/issue42899
>
> Although release blockers mainly apply to important releases, there are
> two are security issues and some
> of the rest involve changes in bytecode or the tracing machinery, so I
> would prefer if these issues are addressed
> before making a new release as many maintainers are waiting for the next
> alpha to test again the bugs that they
> reported.
>
> Please, if you are involved in any of these issues try to see if is
> possible to address them or if you think
> is ok to release the alpha without a fix, please, drop me an email stating
> so.
>
> Thanks,
>
> Regards from cloudy London,
> Pablo Galindo Salgado
> ___
> python-committers mailing list -- python-committ...@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committ...@python.org/message/ZVOFYB5K6UZZLQXQCCCWAJNLTMBF5Z63/
> Code of Conduct: https://www.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/CMHC46SZZGJ37UAYWLPG6OAFVXAK3WWF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

[Senthil Kumaran]

On Mon, Jan 25, 2021 at 06:46:51PM +0300, Ivan Pozdeev via Python-Dev wrote:
> There's a recurring error case when a 3rd-party module
> overrides a standard one if it happens to have the same name.

Any argument and expectation is off in this case. We shouldn't worry about such
scenarios.

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

[Python-Dev] Re: Upcoming 3.7.10 and 3.6.13 Security Releases

[Senthil Kumaran]

On Wed, Jan 20, 2021 at 7:22 PM Ned Deily  wrote:

>
>
> In the meantime, another potential security issue has arisen that might
> impact 3.7 and 3.6 so I'm going to continue to hold off on the releases
> until we have a resolution of that.
>
> https://bugs.python.org/issue42967
>
>
And another security issue was brought up to our attention here (today):

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

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

[Senthil Kumaran]

On Fri, Jan 15, 2021 at 08:24:54AM +, Julien Palard via Python-Dev wrote:
> I think the best way to handle this is to make the three next releases 
> (3.10, 3.11, 3.12) Sphinx 2 and Sphinx 3 compatible, this would gather 
> requiered benefits:
> 
> If this plan is OK for everyone, I'll try a PR soon™ to make this 
> compatibility with Sphinx2/3 land in 3.10.
> 

This sounds great. It makes one less thing to worry about from a CPython
developer perspective.

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

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

[Senthil Kumaran]

On Wed, Jan 13, 2021 at 02:53:30AM +0300, Ivan Pozdeev via Python-Dev wrote:
> > I support keeping same Sphinx version across all the supported python 
> > versions.
> 
> This is not a sustainable route since this way, there's no way to change the 
> version at all.
> 

By supported, I mean the active versions that we backport patches to.
Same as what Victor said.

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

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

[Senthil Kumaran]

On Wed, Jan 13, 2021 at 12:28:42AM +0100, Victor Stinner wrote:

> The alternative is to keep Sphinx 2 support, use
> strip_signature_backslash and don't use :no-trim-doctest-flags: ?

+1. :no-trim-doctest-flags: was introduced to python docs only recently, so not
using that is a reasonable suggestion.

I support keeping same Sphinx version across all the supported python versions.

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

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

[Senthil Kumaran]

On Tue, Jan 12, 2021 at 08:38:17PM +, Julien Palard via Python-Dev wrote:

> - Some functions declarations are lacking a backslash, like
>print(*objects, sep=' ', end='n', ...
> 
> Which is bad.

Wouldn't this a bug with Sphinx?
Why would that be special cased with a flag (strip_signature_backslash)?


> For the moment this is where we go, but if 

+1. Keeping the documentation dependency updated

I noticed that you suggested not to backport this PR
https://github.com/python/cpython/pull/24142

* Would that mean we have to careful not to use/merge sphinx features like
  `no-trim-doctest-flags` to older docs?

* What would it take to keep all active versions of Cpython docs build at the
  same min version (possibly 3.2)?

As Cpython developer, I see nothing bad, but platform maintainers seem to have
some concerns, and it will be good to see points against this.

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

[Python-Dev] Re: Dusting off PEP 533?

[Senthil Kumaran]

Hi Paul,

> Per PEP 525, I can call aclose coroutine method to cleanup the generator, but
> it requires the code iterating to be aware that that closing the generator is
> necessary.

How about treating this as a bug for the specific use case that you mentioned,
rather than a complete addition of " PEP 533 -- Deterministic cleanup for
iterators". I am not certain why PEP 533 was deffered.

I'd also suggest a documentation update if the details of aclose requirement is
mentioned only in a PEP and not in the documentation.

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

[Python-Dev] Re: Remove formatter module

[Senthil Kumaran]

+1 vote on removal. No concerns. It's been deprecated for a long time now
(since 3.4).

On Tue, Nov 24, 2020 at 3:54 AM Victor Stinner  wrote:

> Since importing the module emits a DeprecationWarning at runtime since
> Python 3.4 and the deprecation is properly documented, IMO it's fine
> to remove it right now:
> https://docs.python.org/dev/library/formatter.html
>
> I never used this module, I don't know what it is.
>
> "Formatter objects transform an abstract flow of formatting events
> into specific output events on writer objects."
>
> Victor
>
> Le mar. 24 nov. 2020 à 06:42, Dong-hee Na  a écrit
> :
> >
> > A few days ago, Terry J. Reedy created the issue about the formatter
> module.
> > (https://bugs.python.org/issue42299)
> >
> > The issue is mainly about testing code but also discussing the removal
> of the module.
> > I noticed that the formatter module was deprecated in 3.4 and it was
> originally scheduled to be removed in 3.6. But the removal was delayed
> until 2.7 EOL.
> >
> > Now 2.7 is EOL and there is no usage in stdlib.
> > So IMHO, it is good to remove the formatter module in 3.10
> >
> > So before removing it, I would like to hear the concern.
> >
> > Regards,
> > Dong-hee
> >
> >
> > ___
> > 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/ZEDIBBYCWI34GVOXDEUYXQY3LYXOFHA2/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> 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/CG7C333BJADUZPNRPZH7FKYJ2VP5ZTK7/
> 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/P2C64ZQSKYBHUB5I7CUHYD5INMNLDSCS/
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] Re: When to remove BytesWarning?

[Senthil Kumaran]

On Sat, Oct 24, 2020 at 6:18 AM Christian Heimes 
wrote:

>
>
> In my experience it would be useful to keep the bytes warning for
> implicit representation of bytes in string formatting. It's still a
> common source of issues in code.
>

I am with Christian here. Still notice a possibility of people running into
this because all the Python2 code is not dead yet.
Perhaps this warning might stay for a long time.

> BytesWarning has maintenance costs. It is not huge, but significant.

Should we know by how much so that the proposal of `-b` switch can be
weighted against?

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

[Python-Dev] Re: [python-committers] Please welcome our next Release Manager, Pablo!

[Senthil Kumaran]

Congratulations, Pablo!

Thank you for taking care of buildbots, and donning this new role.


On Tue, May 19, 2020 at 3:54 PM Barry Warsaw  wrote:

> In light of the release of Python 3.9b1, let’s take a moment to celebrate
> all the great work that our Python 3.8 and 3.9 release manager Łukasz has
> done.  The role of Python Release Manager is hugely important to each
> successful release, and it can be a lot of work, often unseen and thankless
> to shepherd a new Python version through its first alpha release to its
> last security release.  With all of your immeasurable help, the Release
> Manager ensures solid, feature-full releases that the entire Python
> community eagerly awaits.
>
> Łukasz carries on the fine tradition of all of our past release managers,
> and now that his second release has entered beta phase, I’m very happy to
> announce our next Release Manager, for Python 3.10 and 3.11: Pablo Galindo
> Salgado!
>
> Since becoming a core developer in 2018, Pablo has contributed
> significantly to Python.  With the change to an annual release cycle (PEP
> 602, authored by Łukasz), the time commitment for release managers has been
> reduced as well, and we will continue to look for ways to make the
> selection process for release managers more transparent and accessible.  I
> know that in addition to admirably managing the releases for 3.10 and 3.11,
> Pablo will also help to continually improve the process of selecting and
> serving as release manager.
>
> Please join me in welcoming Pablo in his new role!
>
> Cheers,
> -Barry
>
> ___
> python-committers mailing list -- python-committ...@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committ...@python.org/message/44TLJO5YX6XYM4ICWSHMBMCKPBBQQP5S/
> Code of Conduct: https://www.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/6I2IJ332M7NKAFV5O7C46NVWR2M2226M/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-Dev] [python-committers] PEP 581 (Using GitHub issues for CPython) is accepted

[Senthil Kumaran]

On Wed, May 15, 2019 at 6:44 PM Ezio Melotti  wrote:

>
> I share the same concerns:

1) the PEP contains several factual errors.  I pointed this out during
> the core-sprints last year and more recently Berker pointed out some
> on GitHub: https://github.com/python/peps/pull/1013 ;
> 4) Berker is/was writing a competing PEP, in order to address the
> problems of PEP 581 more effectively since his comments on GitHub
> haven't been addressed;
>

This concerns me a bit. The PEP/announcement acknowledges the work Ezio and
Berker. However, it does not express if the PEP had addressed their review
comments or had the current maintainers on-board with the proposal. I was
of the assumption that if the current maintainers (/domain experts) were
on-board, then it will be easier for the rest of us to adopt the new
changes.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Season of Docs

[Senthil Kumaran]

Hello Python Developers,

Google is running a program called Season of Docs (
https://developers.google.com/season-of-docs/) to encourage technical
writers to improve the documentation of Open Source Projects.

As Python-Dev, and Python Software Foundation, do you think:

a) We should participate?
b) If yes to a), are you willing to be a mentor and identify project ideas?

If you are willing to mentor and have project ideas, please let us know and
we can think about the next steps. The deadline for org application is
April 23, 2019.

This discussion started here
https://discuss.python.org/t/will-python-apply-for-season-of-docs-and-allow-suborgs/

Thank you,
Senthil
___
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] [python-committers] Welcome the 3.8 and 3.9 Release Manager - Łukasz Langa!

[Senthil Kumaran]

Congrats, Łukasz.  And Thank you, Ned, for managing the 3.6 and 3.7
Releases.

-- 
Senthil


On Sat, Jan 27, 2018 at 1:02 PM, Barry Warsaw  wrote:

> As Ned just announced, Python 3.7 is very soon to enter beta 1 and thus
> feature freeze.  I think we can all give Ned a huge round of applause for
> his amazing work as Release Manager for Python 3.6 and 3.7.  Let’s also
> give him all the support he needs to make 3.7 the best version yet.
>
> As is tradition, Python release managers serve for two consecutive
> releases, and so with the 3.7 release branch about to be made, it’s time to
> announce our release manager for Python 3.8 and 3.9.
>
> By unanimous and enthusiastic consent from the Python Secret Underground
> (PSU, which emphatically does not exist), the Python Cabal of Former and
> Current Release Managers, Cardinal Ximénez, and of course the BDFL, please
> welcome your next release manager…
>
> Łukasz Langa!
>
> And also, happy 24th anniversary to Guido’s Python 1.0.0 announcement[1].
> It’s been a fun and incredible ride, and I firmly believe that Python’s
> best days are ahead of us.
>
> Enjoy,
> -Barry
>
> [1] https://groups.google.com/forum/?hl=en#!original/comp.
> lang.misc/_QUzdEGFwCo/KIFdu0-Dv7sJ
>
>
> ___
> python-committers mailing list
> python-committ...@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Guido's Python 1.0.0 Announcement from 27 Jan 1994

[Senthil Kumaran]

Someone in HackerNews shared the Guido's Python 1.0.0 announcement from 27
Jan 1994. That is, on this day, 20 years ago.

https://groups.google.com/forum/?hl=en#!original/comp.lang.misc/_QUzdEGFwCo/KIFdu0-Dv7sJ


It is very entertaining to read.

* Guido was the release manager, which is now taken up by other core-dev
volunteers.

* Announcement highlighted *readable* syntax.

* The announcement takes a dig at Perl and Bash. While Bourne shell is
still very relevant and might continue for a long time, we recognize the
difference is use cases for Bash and Python.

* Documentation was LaTeX and PostScript.

* Error-free builds on  SGI IRIX 4 and 5, Sun SunOS 4 and Solaris 2, HP-UX,
DEC Ultrix and OSF/1, IBM AIX, and SCO ODT 3.0.  :-) We no longer have them.

* You used WWW viewer to view the documentation and got the files via FTP.

Fun times! Cheers to Guido and everyone contributing to Python.

Thanks,
Senthil
___
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] "CPython loves your Pull Requests" talk by Stéphane Wirtel

[Senthil Kumaran]

On Tue, Dec 5, 2017 at 6:25 AM, Victor Stinner 
wrote:

> Stéphane Wirtel gave a talk last month at Pycon CA about CPython pull
> requests. His slides:
>
>https://speakerdeck.com/matrixise/cpython-loves-your-pull-requests
>
> He produced interesting statistics that we didn't have before on pull
> requests (PR), from February 2017 to October 2017:
>
> * total number of merged PR: 4204
> * number of contributors: 586 !!! (96%)
> * number of core developers: 27 (4%)
> * Time to merge a PR: 3 days in average, good!
> * etc.
>

Plus, the slides were entertaining.
Congrats and thanks for those stats,  Stéphane.
___
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] bugs.python.org updated

[Senthil Kumaran]

On Wed, Sep 27, 2017 at 6:54 PM, Ezio Melotti  wrote:

>
> This update included ~300 changesets from upstream and required an
> additional ~30 to update our instances and our fork of Roundup.  A number
> of features that we added to our fork over the years have been ported
> upstream and they have now been removed from our fork, which is now --
> except for the github integration -- almost aligned with upstream.
>
>
> P.S. Roundup started moving towards Python 3.
>


Thanks a lot for your work on this, Ezio!
___
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] [python-committers] Cherry picker bot deployed in CPython repo

[Senthil Kumaran]

On Tue, Sep 5, 2017 at 6:10 PM, Mariatta Wijaya 
wrote:

> Hi,
>
> The cherry picker bot has just been deployed to CPython repo, codenamed
> miss-islington.
>
> miss-islington made the very first backport PR for CPython and became a
> first time GitHub contributor: https://github.com/python/cpython/pull/3369
>
>
>
Thanks Mariatta.  This is an awesome contribution. It's going to extremely
helpful.

-- 
Senthil
___
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] Reports on my CPython contributions

[Senthil Kumaran]

On Fri, Feb 24, 2017 at 3:50 PM, Victor Stinner
 wrote:
> Recently, I wrote reports of my CPython contributions since 1 year
> 1/2. Some people on this list might be interested, so here is the
> list.

They are prolific!

Thanks for keeping a log and sharing.

-- 
Senthil
___
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] GitHub migration scheduled for Friday

[Senthil Kumaran]

On Tue, Feb 7, 2017 at 11:38 PM, Victor Stinner
 wrote:
> I know that different people have different expectation on GitHub. I
> would like to take the opportunity of migrating to Git to use the
> "author" and "committer" fields. If the author is set to the real
> author, the one who proposed the change on the bug tracker or someone
> else, we will be able to compute statistics on most active
> contributors to more easily detect them and promote them to core
> developers.
>
> What do you think?

I am +1 to this idea. The intention behind this idea is also good one.

* When the patches come from Github PRs, the contribution authors are
automatically tracked. The comitter would be merging the changes from
the authors.

* When contribution comes via Patches/ or for many existing patches,
setting the author is a good idea.

I have one question. If we disallow direct push to branches and the
core-dev has to create a PR to merge the changes in, I guess it is
still possible to have author information in the commit.
___
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] IRC logs via BotBot.me

[Senthil Kumaran]

On Wed, Jan 4, 2017 at 3:27 PM, INADA Naoki  wrote:
> I wonder if #python-dev is logged by BotBot.me.
>
> I'm sorry if it had rejected already.

I don't think so, but channel ops could request it.

Also, I found (https://www.irccloud.com) to be helpful to look at IRC
logs when away. (You can also permanently stay connected for a paid
service, afaict, they have put some interesting work into IRC over
web).

-- 
Senthil
___
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] Fwd: Cssdbpy is a simple SSDB client written on Cython. Faster standart SSDB client.

[Senthil Kumaran]

On Tue, Sep 13, 2016 at 12:01 PM, Yurij Alexandrovich 
wrote:

>
> Cssdbpy is a simple SSDB client written on Cython. Faster standart SSDB
> client.
>
> https://github.com/deslum/cssdbpy
>

Congrats.  You should post this in python-annouce@ list. This list
python-dev is about CPython development.

Thank you,
Senthil
___
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] Tracker Etiquette

[Senthil Kumaran]

On Sat, May 7, 2016 at 4:17 PM, MRAB  wrote:

> I think you shouldn't delete them. It would be better just to say that
> you've changed your mind and explain why.
>

I support this. Please leave your new comments correcting previous one and
support your current stance. I think, it is alright to make revisions in
comments.

-- 
Senthil
___
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] Most 3.x buildbots are green again, please don't break them and watch them!

[Senthil Kumaran]

On Wed, Apr 13, 2016 at 4:40 AM, Victor Stinner 
wrote:

> Last months, most 3.x buildbots failed randomly. Some of them were
> always failing. I spent some time to fix almost all Windows and Linux
> buildbots. There were a lot of different issues.
>
> So please try to not break buildbots again and remind to watch them
> sometimes:
>

Piling in my thanks again, Victor. This is a great gesture from you to fix
all the build bots.
Keeping them stable is a proper thing to do and should be expected from all
committers.

--
Senthil
___
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] The next major Python version will be Python 8

[Senthil Kumaran]

On Thu, Mar 31, 2016 at 2:40 PM, Victor Stinner 
wrote:

> For example, rename utils.py to utils_noqa.py. A side
> effect is that you have to update all imports. For example, replace
> "import django" with "import django_noqa". After a study of the PSF,
> it's a best option to split again the Python community and make sure
> that all users are angry.
>

We have a huge production code base, lacking tests, running successfully
against python2.4.
We would like to upgrade our code base to python 8 as we consider it as
most sensible update the python developers have ever done till date.
Is there is setuptools addition that can automatically change our imports
to _noqa ?

Thank you!
Senthil
___
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] Very old git mirror under github user "python-git"

[Senthil Kumaran]

> On Feb 27 2016, at 2:47 pm, Ian Lee ianlee1...@gmail.com wrote:  

>

> Perhaps the better / easier solution is to promote the *real* “Sem-official
read-only mirror of the Python Mercurial repository” [1] ? And perhaps this
goes away entirely (in time) with PEP-512 [2]?  

  

We will be working to promote the github repo, once the migration and PEP-512
is complete.

Promoting semi-official repo in the interim (as opposed the active one in
hg.python.org) does not seem like a good idea.

  

This thread about claiming ownership of look-alike repo and we could
concentrate our discussion on that alone.

  

FWIW, that old look-alike (python-dev) repo as been in existence for years now
and it has not caused any confusion. Once python moves to github, I think, we
can ask for some logo or some kind of validation that will help users easily
identify the originality.

  

  

Thanks,

Senthil

  

___
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] Code formatter bot

[Senthil Kumaran]

On Tue, Jan 19, 2016 at 12:59 PM, francismb  wrote:

> Pros, Cons, where could be applicable (new commits, new workflow, it
> doesn't make sense), ...
>

-1. formatting should be done by humans (with the help of tools) before
committing.
It should not be left to a robot to make automatic changes.

We already some pre-commit hooks which do basic checks. If anything more
automated is desirable then enhancement to the pre-commit hooks could be
the place to look for.
As far as I know, none of the core devs have expressed any complaints the
pre-commit hooks.


-- 
Senthil
___
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 far to go with user-friendliness

[Senthil Kumaran]

On Tue, Jul 14, 2015 at 5:06 AM, Dima Tisnek dim...@gmail.com wrote:

 https://bugs.python.org/issue21238 introduces detection of
 missing/misspelt mock.assert_xxx() calls on getattr level in Python
 3.5


It was controversial when it got committed too. Discussions happened in
python-committers and IRC.
Michael is the BDFL of mock and felt alright with the change.

The sad part is once introduced and released, deprecation takes more time.
___
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] cpython (merge 3.4 - default): null merge with 3.4

[Senthil Kumaran]

On Sunday, June 14, 2015 at 6:43 PM, Ned Deily wrote:
 Senthil,
 
 There is now an active 3.5 branch, so the correct current order of 
 merging is:
 
 3.4 - 3.5
 3.5 - default
 
 I've checked in a couple of null merges to try to fix things.
Oh! Missed that. Sorry, for the trouble. 
I will update my local branches and follow the process.

3.4 - 3.5
3.5 - default

Thank you!
Senthil

___
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] Help with finding tutors for Python, Linux, R, Perl, Octave, MATLAB and/or Cytoscape for yeast microarray analysis, next generation sequencing and constructing gene interaction networ

[Senthil Kumaran]

On Saturday, January 3, 2015 at 7:06 PM, thomas hahn wrote:

 Help with finding tutors for Python, Linux, R, Perl, Octave, MATLAB and/or 
 Cytoscape for yeast microarray analysis, next generation sequencing and 
 constructing gene interaction networks 

This is an inappropriate list to seek out for those folks. python-dev is 
dedicated to development of python language itself.

Please ask python-us...@python.org


-- 
Senthil Kumaran

___
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] [Python-checkins] cpython (merge 3.4 - default): Issue #22165: Fixed test_undecodable_filename on non-UTF-8 locales.

[Senthil Kumaran]

This change is okay and not harmful. But I think, It might still not fix
the encoding issue that we encountered on Mac.

[localhost cpython]$ hg log -l 1
changeset:   92128:7cdc941d5180
tag: tip
parent:  92126:3153a400b739
parent:  92127:a894b629bbea
user:Serhiy Storchaka storch...@gmail.com
date:Sun Aug 17 12:21:06 2014 +0300
description:
Issue #22165: Fixed test_undecodable_filename on non-UTF-8 locales.


[localhost cpython]$ ./python.exe -m test.regrtest test_httpservers
[1/1] test_httpservers
test test_httpservers failed -- Traceback (most recent call last):
  File /Users/skumaran/python/cpython/Lib/test/test_httpservers.py, line
283, in test_undecodable_filename
.encode(enc, 'surrogateescape'), body)
AssertionError: b'href=%40test_5809_tmp%ED%B3%A7w%ED%B3%B0.txt' not found
in b'!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN 
http://www.w3.org/TR/html4/strict.dtd;\nhtml\nhead\nmeta
http-equiv=Content-Type content=text/html;
charset=utf-8\ntitleDirectory listing for
tmpj54lc8m1//title\n/head\nbody\nh1Directory listing for
tmpj54lc8m1//h1\nhr\nul\nlia
href=%40test_5809_tmp%25E7w%25F0.txt@test_5809_tmp%E7w%F0.txt/a/li\nlia
href=testtest/a/li\n/ul\nhr\n/body\n/html\n'

1 test failed:
test_httpservers

The underlying problem seems to be difference in which os.listdir() which
uses C-API  and os.fsdecode represent the decoded chars. Ref:
http://bugs.python.org/issue22165#msg225428





On Sun, Aug 17, 2014 at 2:52 PM, serhiy.storchaka 
python-check...@python.org wrote:

 http://hg.python.org/cpython/rev/7cdc941d5180
 changeset:   92128:7cdc941d5180
 parent:  92126:3153a400b739
 parent:  92127:a894b629bbea
 user:Serhiy Storchaka storch...@gmail.com
 date:Sun Aug 17 12:21:06 2014 +0300
 summary:
   Issue #22165: Fixed test_undecodable_filename on non-UTF-8 locales.

 files:
   Lib/test/test_httpservers.py |  5 +++--
   1 files changed, 3 insertions(+), 2 deletions(-)


 diff --git a/Lib/test/test_httpservers.py b/Lib/test/test_httpservers.py
 --- a/Lib/test/test_httpservers.py
 +++ b/Lib/test/test_httpservers.py
 @@ -272,6 +272,7 @@
  @unittest.skipUnless(support.TESTFN_UNDECODABLE,
   'need support.TESTFN_UNDECODABLE')
  def test_undecodable_filename(self):
 +enc = sys.getfilesystemencoding()
  filename = os.fsdecode(support.TESTFN_UNDECODABLE) + '.txt'
  with open(os.path.join(self.tempdir, filename), 'wb') as f:
  f.write(support.TESTFN_UNDECODABLE)
 @@ -279,9 +280,9 @@
  body = self.check_status_and_reason(response, 200)
  quotedname = urllib.parse.quote(filename, errors='surrogatepass')
  self.assertIn(('href=%s' % quotedname)
 -  .encode('utf-8', 'surrogateescape'), body)
 +  .encode(enc, 'surrogateescape'), body)
  self.assertIn(('%s' % html.escape(filename))
 -  .encode('utf-8', 'surrogateescape'), body)
 +  .encode(enc, 'surrogateescape'), body)
  response = self.request(self.tempdir_name + '/' + quotedname)
  self.check_status_and_reason(response, 200,
   data=support.TESTFN_UNDECODABLE)

 --
 Repository URL: http://hg.python.org/cpython

 ___
 Python-checkins mailing list
 python-check...@python.org
 https://mail.python.org/mailman/listinfo/python-checkins


___
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] [Python-checkins] cpython (2.7): Fix Issue #8797: Raise HTTPError on failed Basic Authentication immediately.

[Senthil Kumaran]

I added some extra coverage for basic auth in the tests and I notice that
in buildbots, some of them are throwing error: [Errno 32] Broken pipe
error.

I am looking into this and will fix this.

Thanks,
Senthil



On Sat, Aug 16, 2014 at 2:19 PM, senthil.kumaran python-check...@python.org
 wrote:

 http://hg.python.org/cpython/rev/e0510a3bdf8f
 changeset:   92111:e0510a3bdf8f
 branch:  2.7
 parent:  92097:6d41f139709b
 user:Senthil Kumaran sent...@uthcode.com
 date:Sat Aug 16 14:16:14 2014 +0530
 summary:
   Fix Issue #8797: Raise HTTPError on failed Basic Authentication
 immediately. Initial patch by Sam Bull.

 files:
   Lib/test/test_urllib2_localnet.py |  86 ++-
   Lib/urllib2.py|  19 +---
   Misc/NEWS |   3 +
   3 files changed, 90 insertions(+), 18 deletions(-)


 diff --git a/Lib/test/test_urllib2_localnet.py
 b/Lib/test/test_urllib2_localnet.py
 --- a/Lib/test/test_urllib2_localnet.py
 +++ b/Lib/test/test_urllib2_localnet.py
 @@ -1,6 +1,8 @@
 +import base64
  import urlparse
  import urllib2
  import BaseHTTPServer
 +import SimpleHTTPServer
  import unittest
  import hashlib

 @@ -66,6 +68,48 @@

  # Authentication infrastructure

 +
 +class BasicAuthHandler(SimpleHTTPServer.SimpleHTTPRequestHandler):
 +Handler for performing Basic Authentication.
 +# Server side values
 +USER = testUser
 +PASSWD = testPass
 +REALM = Test
 +USER_PASSWD = %s:%s % (USER, PASSWD)
 +ENCODED_AUTH = base64.b64encode(USER_PASSWD)
 +
 +def __init__(self, *args, **kwargs):
 +SimpleHTTPServer.SimpleHTTPRequestHandler.__init__(self, *args,
 +   **kwargs)
 +
 +def log_message(self, format, *args):
 +# Supress the HTTP Console log output
 +pass
 +
 +def do_HEAD(self):
 +self.send_response(200)
 +self.send_header(Content-type, text/html)
 +self.end_headers()
 +
 +def do_AUTHHEAD(self):
 +self.send_response(401)
 +self.send_header(WWW-Authenticate, Basic realm=\%s\ %
 self.REALM)
 +self.send_header(Content-type, text/html)
 +self.end_headers()
 +
 +def do_GET(self):
 +if self.headers.getheader(Authorization) == None:
 +self.do_AUTHHEAD()
 +self.wfile.write(No Auth Header Received)
 +elif self.headers.getheader(
 +Authorization) == Basic  + self.ENCODED_AUTH:
 +SimpleHTTPServer.SimpleHTTPRequestHandler.do_GET(self)
 +else:
 +self.do_AUTHHEAD()
 +self.wfile.write(self.headers.getheader(Authorization))
 +self.wfile.write(Not Authenticated)
 +
 +
  class DigestAuthHandler:
  Handler for performing digest authentication.

 @@ -228,6 +272,45 @@
  test_support.threading_cleanup(*self._threads)


 +class BasicAuthTests(BaseTestCase):
 +USER = testUser
 +PASSWD = testPass
 +INCORRECT_PASSWD = Incorrect
 +REALM = Test
 +
 +def setUp(self):
 +super(BasicAuthTests, self).setUp()
 +# With Basic Authentication
 +def http_server_with_basic_auth_handler(*args, **kwargs):
 +return BasicAuthHandler(*args, **kwargs)
 +self.server =
 LoopbackHttpServerThread(http_server_with_basic_auth_handler)
 +self.server_url = 'http://127.0.0.1:%s' % self.server.port
 +self.server.start()
 +self.server.ready.wait()
 +
 +def tearDown(self):
 +self.server.stop()
 +super(BasicAuthTests, self).tearDown()
 +
 +def test_basic_auth_success(self):
 +ah = urllib2.HTTPBasicAuthHandler()
 +ah.add_password(self.REALM, self.server_url, self.USER,
 self.PASSWD)
 +urllib2.install_opener(urllib2.build_opener(ah))
 +try:
 +self.assertTrue(urllib2.urlopen(self.server_url))
 +except urllib2.HTTPError:
 +self.fail(Basic Auth Failed for url: %s % self.server_url)
 +except Exception as e:
 +raise e
 +
 +def test_basic_auth_httperror(self):
 +ah = urllib2.HTTPBasicAuthHandler()
 +ah.add_password(self.REALM, self.server_url, self.USER,
 +self.INCORRECT_PASSWD)
 +urllib2.install_opener(urllib2.build_opener(ah))
 +self.assertRaises(urllib2.HTTPError, urllib2.urlopen,
 self.server_url)
 +
 +
  class ProxyAuthTests(BaseTestCase):
  URL = http://localhost;

 @@ -240,6 +323,7 @@
  self.digest_auth_handler = DigestAuthHandler()
  self.digest_auth_handler.set_users({self.USER: self.PASSWD})
  self.digest_auth_handler.set_realm(self.REALM)
 +# With Digest Authentication
  def create_fake_proxy_handler(*args, **kwargs):
  return FakeProxyHandler(self.digest_auth_handler, *args,
 **kwargs)

 @@ -544,7 +628,7 @@
  # the next line.
  #test_support.requires(network)

 -test_support.run_unittest

Re: [Python-Dev] death to 2.7; long live 2.7

[Senthil Kumaran]

On Wed, Apr 9, 2014 at 9:22 PM, Benjamin Peterson benja...@python.orgwrote:

 Instead dealing 2.7 will just be completely optional for core
 developers. (The much anticipated vendor support arrives at this point.)


Could you clarify your thoughts a bit on the completely optional part.
What if vendors take a really long time to come to support the latest minor
release? AFAIK, the discussion centered around keep it alive, for some
definition of alive. We did not define what do we mean by 'alive'.

Bringing back all the security related enhancement features seem ok.
Guido's last email talks about all the other compatibility goodies /tools
targeting 2.7 that may or may not go with 2.7 code base itself.


-- 
Senthil
___
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] death to 2.7; long live 2.7

[Senthil Kumaran]

On Wed, Apr 9, 2014 at 10:02 PM, Benjamin Peterson benja...@python.orgwrote:

 I consider the security enhancement/feature question to be in the domain
 of PEP 466. If security stuff lands in the 2.7 branch, it will get
 released eventually is all I'm saying.


Thanks for the response.

 Instead dealing 2.7 will just be completely optional for core developers

I was worried about this part, that if bug-fixes are
optionally back-ported, then we may end up a inconsistent, undesirable
state.
Instead it could be that bug-fixes fixes will be back-ported as long as it
is alive (and folks seem be excited about keep it alive for a long long
term).

-- 
Senthil
___
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] Language Summit notes

[Senthil Kumaran]

Here are my notes that I jotted down from the back row. Forgive me for any
mistakes. (As I shared in the intro, I am trying to get back and keep up.
:))


Python Release Process:
  * Larry Hastings goes for vote for shortend release process. But Guido
does not seem to be excited about it.
 Would go for go for email based voting.

 PyPy:
   * Alex Gaynor mentioned about the 7th iteration of STM - Software
Transactional Memory that is being worked on.
   * PyPy is targetting go from 2.7.3 to 2.7.6  and Brett teases about STM
enabled CPython interpreter?

 Iron Python:
   * Dino gave an updated on IronPython, 2.7.5 is under development, 3.x is
under development (/will be under development soon)
   * Contributions from community has grown recently. MaL encouraged them
to submit for a funding proposal.

  Jython:
  * Support for Buffer Protocol, For Python 3 support. cffi backend for
Python is coming up.

  Discussion about splitting the standard library:
   * IronPython, Pypy say that it is not a priority request for them.

 Packaging:
   * Nick Coghlan shares his experience on how difficult is get the packing
right. Every agrees and kind of recognize that recent efforts are in the
right direction. Mentioned about https://pypi-preview.a.ssl.fastly.net/ and
wheels packaging format.
   * Well maintained docs at http://packaging.python.org/en/latest/ -
Python packaging user guide.
   * The focus/goal is not get new users easy to understand python
ecosystem and use python packages.

Pyston:
  * Kevin shared his ideas and updates on Pyston. Folks suggested about
using the speed.pypy.org benchmarks to measure the effort.

 MyPy:
  * The optional static typing using functional annotations demonstrated by
MyPy interested a number of developers.  Few felt that it would be a nice
to have feature in Python 3.5 It basically means identify what's lacking in
current function annotations and work on enhancing it.
  * Thomos Wouters suggested to Larry Hastings that Argument clinic could
be enhanced to support such a feature.
  * Interested parties should get together on a python type checking
mailing list.

 Features we care about 3.5:
   ☐ bytes formatting redux
   ☐ Binary mode cleanup
   ☐ Type Annotations.
   ☐ Improved tooling AI based tooling to convert 2.x code to 3.x and
provide better error messages. (Sounds exciting!)




On Wed, Apr 9, 2014 at 9:08 PM, Guido van Rossum gu...@python.org wrote:

 To anyone who took notes at the language summit at PyCon today, even if
 you took them just for yourself, would you mind posting them here? It would
 be good to have some kind of (informal!) as soon as possible, before we
 collectively forget. You won't be held responsible for correctness.

 Here are some of my own recollections (I didn't take notes but I have a
 decent memory):

 - Packaging sucks, but we're improving, and we're actually doing better
 than other dynamic languages.

 - Kevin Modzelewski answered questions about Pyston, a new (very early
 stage) Python VM based on the new LLVM JIT engine (which is much different
 from what defeated Unladen Swallow). Alex Gaynor seemed unconcerned. :-)

 - Jukka Lehtosalo gave a talk and answered questions about mypy, his
 design and implementation of pragmatic type annotations (no new syntax
 required, uses Python 3 function annotations). See mypy-lang.org. In
 response, Greg P Smith pointed people to a similar project from Google,
 https://github.com/google/pytypedecl, which has annotations in a separate
 file (hence amenable to Python 2). Larry Hastings brought up that Argument
 Clinic (a new way of specifying signatures for C extensions), released as
 part of 3.4) encodes similar information in the docstring of C functions.

 - Maybe this is should be the year when we start getting agreement on a
 standard use of function annotations to specify argument and return types,
 now that we seem to have a somewhat critical mass of experience with
 annotations.

 - We should make an effort to publicize that we're NOT sunsetting Python
 2.7 just yet; support will continue (hopefully with ample support from
 distro vendors), and someone should update PEP 373. (Unclear what the new
 EOL is but we should definitely rescind the currently published schedule.)

 - We (I) still don't want to do a 2.8 release, and I don't want to
 accelerate 3.5, but I do think we should make things better for people who
 have to straddle Python 2 and 3 in a single codebase, by developing more
 tools, and by security and possibly installer updates to 2.7 (PEP 466).

 - Some suggestions that were made: PSF financial support for tool
 development and/or porting, add more -3 warnings to a future Python 2.7
 release, additional 2to3 fixers to help convert Python-2-only code to
 Python-2-and-3-single-source code, a separate linter, a sumo 2.7
 distribution that includes all known backported-from-Python-3-stdlib
 packages, adding ensure_pip to the 2.7.7 stdlib, and several more I forgot.
 IIRC Glyph and 

Re: [Python-Dev] [Python-checkins] cpython (3.3): Issue #19092 - Raise a correct exception when cgi.FieldStorage is given an

[Senthil Kumaran]

On Sat, Jan 11, 2014 at 11:53 PM, Nick Coghlan ncogh...@gmail.com wrote:

 You may want to tweak the tracker so the comment ends up on the
 appropriate issue (#19092 is something else entirely)


Yes. This was supposed to be #19097.  My bad.
___
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] urllib2.HTTPBasicAuthHandler doesn't work with GitHub API

[Senthil Kumaran]

On Mon, Nov 4, 2013 at 6:11 AM, Matěj Cepl mc...@redhat.com wrote:

 I am not sure how widespread is this breaking of RFC, but it seems to me
 that quite a lot (e.g., http://stackoverflow.com/a/9698319/164233 which
 just en passant expects urllib2 authentication stuff to be useless), and
 the question is whether it shouldn't be documented somehow and/or
 urllib2.HTTPBasicAuthHandler shouldn't be modified to try add
 Authenticate header first.

 Any suggestions?


Please file a bug report at bugs.python.org stating this. urllib2 tries to
follow the RFC as much as possible, but ofcourse consider's de-facto
standards and adopts to it. This can be documented for 2.x and can be
'fixed in 3.4.

HTH,
Senthil
___
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] [Python-checkins] cpython (merge 3.3 - default): Fix http.server's request handling case on trailing '/'.

[Senthil Kumaran]

On Fri, Sep 13, 2013 at 7:49 AM, Eric V. Smith e...@trueblade.com wrote:
 Patch contributed by Vajrasky Kok. Addresses Issue #17324

 +trailing_slash = True if path.rstrip().endswith('/') else False

 Wouldn't this be better just as:
   trailing_slash = path.rstrip().endswith('/')

I noticed this email late. Corrected it now.

Thanks,
Senthil
___
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] cpython (merge 3.3 - default): merge from 3.3

[Senthil Kumaran]

On Wed, Sep 11, 2013 at 11:14 PM, Antoine Pitrou solip...@pitrou.net wrote:
 On Thu, 12 Sep 2013 07:57:25 +0200 (CEST)
 senthil.kumaran python-check...@python.org wrote:

 + local
  Optional argument random is a 0-argument function returning a
  random float in [0.0, 1.0); if it is the default None, the
  standard random.random will be used.
 +===
 +Optional arg random is a 0-argument function returning a random
 +float in [0.0, 1.0); by default, the standard random.random.
 +
 +Do not supply the 'int' argument.
 + other

 Can you fix this?

Had done it earlier. (http://hg.python.org/cpython/rev/1398dfb59fd9 )
I missed responding back.  Sorry for the trouble.

Thanks,
Senthil
___
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] End of the mystery @README.txt Mercurial bug

[Senthil Kumaran]

On Tue, Jun 25, 2013 at 5:58 PM, Benjamin Peterson benja...@python.orgwrote:

 2013/6/25 Victor Stinner victor.stin...@gmail.com:
  And then I ran make distclean...

 You've left us hanging...


Yeah, the final part is here: http://bz.selenic.com/show_bug.cgi?id=3954#c4
But still I have question as why hg complained about @README in the first
place.
Also, I hope make distclean is not working inside .hg folder.

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

Re: [Python-Dev] The end of 2.7

[Senthil Kumaran]

On Sat, Apr 6, 2013 at 2:02 PM, Benjamin Peterson benja...@python.org wrote:

 juncture 5 total years of maintenance is reasonable. This means there
 will be approximately 4 more 2.7 releases.

That's good. From the subject of the email, I though you were
announcing This is the end of 2.7.x releases.
2 more year with 6 month cycle seem to be a good one.

Thank you!
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PyCon Sprints - Thank you

[Senthil Kumaran]

Thanks Daniel, for all the patches and improving the test coverage.
Hope you had a good time and will you enjoy contributing further.

Happy touring SF.

-- 
Senthil

On Wed, Mar 20, 2013 at 12:24 PM, R. David Murray rdmur...@bitdance.com wrote:
 Thank you for your contributions, and we look forward to anything else
 you may choose to contribute!

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

Re: [Python-Dev] [Python-checkins] cpython: ../bug-fixes/http_error_interface/.hg/last-message.txt

[Senthil Kumaran]

Looks like I used hg commit -m /path/to/.hg/last-message.txt instead
of hg commit -l /path/to/.hg/last-message.txt
I have amended it, merged it and pushed it again.

On Tue, Mar 19, 2013 at 12:04 PM, senthil.kumaran
python-check...@python.org wrote:
 http://hg.python.org/cpython/rev/4f2080e9eee2
 changeset:   82765:4f2080e9eee2
 parent:  82763:4c6463b96a2c
 user:Senthil Kumaran sent...@uthcode.com
 date:Tue Mar 19 12:07:43 2013 -0700
 summary:
   ../bug-fixes/http_error_interface/.hg/last-message.txt

 files:
   Lib/test/test_urllib2.py |  39 +--
   1 files changed, 19 insertions(+), 20 deletions(-)


 diff --git a/Lib/test/test_urllib2.py b/Lib/test/test_urllib2.py
 --- a/Lib/test/test_urllib2.py
 +++ b/Lib/test/test_urllib2.py
 @@ -1387,6 +1387,10 @@

  class MiscTests(unittest.TestCase):

 +def opener_has_handler(self, opener, handler_class):
 +self.assertTrue(any(h.__class__ == handler_class
 +for h in opener.handlers))
 +
  def test_build_opener(self):
  class MyHTTPHandler(urllib.request.HTTPHandler): pass
  class FooHandler(urllib.request.BaseHandler):
 @@ -1439,10 +1443,22 @@
  self.assertEqual(b1234567890, request.data)
  self.assertEqual(10, request.get_header(Content-length))

 +def test_HTTPError_interface(self):
 +
 +Issue 13211 reveals that HTTPError didn't implement the URLError
 +interface even though HTTPError is a subclass of URLError.

 -def opener_has_handler(self, opener, handler_class):
 -self.assertTrue(any(h.__class__ == handler_class
 -for h in opener.handlers))
 + msg = 'something bad happened'
 + url = code = fp = None
 + hdrs = 'Content-Length: 42'
 + err = urllib.error.HTTPError(url, code, msg, hdrs, fp)
 + assert hasattr(err, 'reason')
 + err.reason
 +'something bad happened'
 + assert hasattr(err, 'headers')
 + err.headers
 +'Content-Length: 42'
 +

  class RequestTests(unittest.TestCase):

 @@ -1514,23 +1530,6 @@
  req = Request(url)
  self.assertEqual(req.get_full_url(), url)

 -def test_HTTPError_interface():
 -
 -Issue 13211 reveals that HTTPError didn't implement the URLError
 -interface even though HTTPError is a subclass of URLError.
 -
 - msg = 'something bad happened'
 - url = code = fp = None
 - hdrs = 'Content-Length: 42'
 - err = urllib.error.HTTPError(url, code, msg, hdrs, fp)
 - assert hasattr(err, 'reason')
 - err.reason
 -'something bad happened'
 - assert hasattr(err, 'headers')
 - err.headers
 -'Content-Length: 42'
 -
 -
  def test_main(verbose=None):
  from test import test_urllib2
  support.run_doctest(test_urllib2, verbose)

 --
 Repository URL: http://hg.python.org/cpython

 ___
 Python-checkins mailing list
 python-check...@python.org
 http://mail.python.org/mailman/listinfo/python-checkins

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

Re: [Python-Dev] os.path.join failure mode

[Senthil Kumaran]

And this is not just with Python. Try any other dynamic language
(Ruby), send a function in place of a string and see failure msg.  And
if the question is really about path joins and path manipulations,
then I believe PEP 428 ( http://www.python.org/dev/peps/pep-0428/)
would be better candidate to address these scenarios.

On Sat, Feb 9, 2013 at 3:45 PM, Eric V. Smith e...@trueblade.com wrote:
 On 2/9/2013 6:23 PM, Greg Ewing wrote:
 Terry Reedy wrote:
 I agree. Since the exception type is not documented and since no one
 should intentionally pass anything but strings, and therefore should
 not be writing

 try:
   os.path.join(a,b)
 except AttributeError:
   barf()

 I think it would be acceptable to make a change in 3.4.

 Why should we go out of our way to address this particular
 case, and not any of the infinitely many other situations
 where you could forget to add parens to a function call?


 I agree we do not want to go down this slippery slope. The number of
 such places in the standard library is huge. The existing error message
 is one that a user should be able to understand, since it's so common.

 --
 Eric.
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: 
 http://mail.python.org/mailman/options/python-dev/senthil%40uthcode.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Set close-on-exec flag by default in SocketServer

[Senthil Kumaran]

On Wed, Jan 9, 2013 at 4:48 AM, Victor Stinner victor.stin...@gmail.com wrote:
 My question is: would you accept to break backward compatibility (in
 Python 3.4) to fix a potential security vulnerability?

 If not, an alternative is to add an option, disabled by default, to
 enable (or disable) explicitly close-on-exec in Python 3.4, and wait
 for 3.5 to enable the option by default. So applications might disable
 the flag explicitly in Python 3.4.

If the end goal is indeed going to close-on-exec ON by default, then I
think having it 3.4 itself is a good idea.
OFF for one release just gives the framework developers who use
SocketServer some additional time.

Usually, I have realized that framework devs try our release
candidates and see if they see any potential changes to be done. If
they realize this change in their testing, it would be good for both
parties.

So, my vote. +1 for  making that in 3.4

Thank you,
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] test failed: test_urlwithfrag

[Senthil Kumaran]

Yes, this is question is for python-li...@python.org

On Fri, Jan 4, 2013 at 2:59 PM, Elli Lola lampenregensch...@web.de wrote:

 $ ./python -m test -v test_urlwithfrag


Where did you get this command from? It looks to me to me that more than
one person is trying the exact same command experiencing the same failure
(expected result). Perhaps the source which is advertising this is
misleading?

Thanks,
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Branch ancestry hiccup on the Mercurial repo

[Senthil Kumaran]

On Mon, Dec 31, 2012 at 10:47 PM, Antoine Pitrou solip...@pitrou.netwrote:


 Chances are the problem won't be very annoying in practice, but just
 FYI.


I dont get this. I see 2.7 as a separate un-merged branch again (
http://hg.python.org/cpython/graph). Just curious, what happened next?



Thanks,
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Better HTTP 1.1 support in http.server?

[Senthil Kumaran]

On Mon, Sep 24, 2012 at 9:39 AM, Christian Heimes christ...@python.org wrote:

 +1 for 3.4

 You proposed gave me another idea. What do you think about SPDY support
 in the stdlib? It's the next step after HTTP 1.1.

Yeah, it is a good idea. it should live along side with HTTP 1.1 as
another protocol layer.
Guido had given some suggestions to takle that, but I have been lazing
and lagging for while now in terms of contributions, but I am excited
about the idea.

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

Re: [Python-Dev] Should urlencode() sort the query parameters (if they come from a dict)?

[Senthil Kumaran]

On Sat, Aug 18, 2012 at 1:55 PM, Glenn Linderman v+pyt...@g.nevcal.com wrote:

 On 8/18/2012 11:47 AM, MRAB wrote:

 I vote -0. The issue can also be addressed with a small and simple
 helper function that wraps urlparse and compares the query parameter. Or
 you cann urlencode() with `sorted(qs.items)` instead of `qs` in the
 application.


 Hm. That's actually a good point.


 Seems adequate to me. Most programs wouldn't care about the order, because 
 most web frameworks grab whatever is there in whatever order, and present it 
 to the web app in their own order.

 Programs that care, or which talk to web apps that care, are unlikely to want 
 the order from a non-randomized dict, and so have already taken care of 
 ordering issues, so undoing the randomization seems like a solution in search 
 of a problem (other than for poorly written test cases).



I am of the same thought too. Changing a behavior based on the test
case expectation, no matter if the behavior is a harmless change is
still a change. Coming to the point testing query string could be
useful in some cases and then giving weightage to the change seems
interesting use case, but does not seem to warrant a change. I think,
I like Christian Heimes suggestion that a wrapper to compare query
strings would be useful and in Guido's original test case, a tittle
test code change would have been good.

Looks like Guido has withdrawn the bug report too.

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

Re: [Python-Dev] 2.7 releases

[Senthil Kumaran]

On Thu, Jul 26, 2012 at 10:56 AM, Thomas Heller thel...@ctypes.org wrote:

 Will there be more 2.7 bugfix releases, and when the next one?

 In other words; if I submit a patch and it is accepted, can I
 expect that patch be committed also to the 2.7 branch?


We are still back-porting bug fixes to 2.7 branch. Which means that yes, we
may definitely see a release.
Benjamin might be right person to answer the question on when.

Thanks,
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Fix 5931 - Python runtime hardcoded in wsgiref.simple_server - Now it specifies

[Senthil Kumaran]

On Sun, Jul 8, 2012 at 1:12 AM, Georg Brandl g.bra...@gmx.net wrote:

 Please fix the markup: no blank line, but indented. E.g.

 .. versionchanged:: 3.3
Blah, blah.

Done. Sorry for that, I only built the docs and saw if the directive
was affected and assumed it okay.

Fixed that.

Thanks,
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Another buildslave - Ubuntu again

[Senthil Kumaran]

On Thu, May 3, 2012 at 12:46 AM, Antoine Pitrou solip...@pitrou.net wrote:
 Daily code coverage builds would be nice, but that's probably beyond
 what the current infrastructure can offer. It would be nice if someone
 wants to investigate that.

Code coverage buildbots would indeed be good. I could give a try on
this. What kind of infra changes would be required? I presume, it is
the server side that you are referring to.

Thank you,
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Another buildslave - Ubuntu again

[Senthil Kumaran]

On Wed, May 2, 2012 at 1:55 PM, Martin v. Löwis mar...@v.loewis.de wrote:
 I'm not sure how useful it is to have a build slave which you can't
 commit to having for more than 3 months. So I'm -0 on adding this
 slave, but it is up to Antoine to decide.

I am likely switch to places within 3 months, but I am hoping that
having a 24/7 connected system could provide some experience for
running a dedicated system in the longer run.

Thanks,
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Another buildslave - Ubuntu again

[Senthil Kumaran]

On Wed, May 2, 2012 at 10:54 PM, Antoine Pitrou solip...@pitrou.net wrote:

 What are the characteristics of your machine? We already have several
 Linux x86/x86-64 buildbots... That said, we could also toy with other
 build options if someone has a request about that.

It is not very unique. It is Intel x86 (32 bit) and 1 GB ram. It is
running Ubuntu Server edition.  Yeah if additional build options (or
additional software configuration options) or some alternative
coverage could be thought off with current config itself, I could do
that.

Thanks,
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Another buildslave - Ubuntu again

[Senthil Kumaran]

Hello,

I just got a Ubuntu Server running at my disposal, which could be
connected 24/7 for at least next 3 months.  I am not sure how helpful
it would be to have another buildbot on Ubuntu, but i wanted to play
with it for a while (as I have more comfort with Ubuntu than any other
Unix flavor) before I could change it to cover as OS which is not
already covered by the buildbots.

As instructed here - http://wiki.python.org/moin/BuildBot  could
someone please help create a slavename/slavepasswd on
dinsdale.python.org.
Also, I think the instructions in the wiki could be improved. I was
not able to su - buildbot after installing through package manager. I
shall edit it once I have set it up and running.

Thanks,
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (3.2): #14236: fix docs for \S.

[Senthil Kumaran]

On Sun, Apr 29, 2012 at 12:37:25PM +0200, ezio.melotti wrote:
   range of Unicode whitespace characters.
 -\S   Matches any non-whitespace character; equiv. to [^ \t\n\r\f\v].
 +\S   Matches any non-whitespace character; equivalent to [^\s].

Is this correct? While I understand what meant (or implied) \s is not
a valid ascii character in the documentation we denoted the sets using
ascii characters only.

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

Re: [Python-Dev] The step command of pdb is broken

[Senthil Kumaran]

On Mon, Apr 30, 2012 at 12:09:02PM -0400, Barry Warsaw wrote:
 Maybe we should take this opportunity (Python 3.3) to consider adopting one of
 the pdb add-ons or borging the best of their bits into the stdlib?

Irrespective of this - Issue13183 seems to be an easy to verify bug in
3.2 and 3.3. I think, it would most visible if you were to use a full
screen debugger and you will notice that the return call indicator has
jumped to the next statement (skipping return) when returning. I
guess, that's why Xavier (pyclewn author) noted it.  The fix seems
fine too.

I have just requested an additional info and this particular one could
be fixed.

Thanks,
Senthil

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

Re: [Python-Dev] [Python-checkins] cpython: issue2193 - Update docs about the legal characters allowed in Cookie name

[Senthil Kumaran]

On Sun, Apr 22, 2012 at 3:17 PM, Nick Coghlan ncogh...@gmail.com wrote:
  issue2193 - Update docs about the legal characters allowed in Cookie name

 You missed the dummy merge from 3.2 to indicate that this change had
 been applied to both branches independently.

Yes. Sorry for that. I was being little cautious of  having correct
message in each version and forgot the merge.

 Should be fixed in my commit for issue #14026

Thanks for this, Nick.

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

Re: [Python-Dev] cpython: use assertWarns instead of check_warnings - Issue14341

[Senthil Kumaran]

On Wed, Apr 11, 2012 at 09:33:30PM +0200, Georg Brandl wrote:
 +
 +with self.assertWarns(DeprecationWarning) as cm:
   req.add_data(data)
 
 There's no need for adding the as cm if you don't need the cm object.

I overlooked. Thanks for spotting. I have corrected it.

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

Re: [Python-Dev] cpython: Issue #3033: Add displayof parameter to tkinter font.

[Senthil Kumaran]

Hi Andrew,

On Thu, Apr 05, 2012 at 11:16:54PM +0300, Andrew Svetlov wrote:
 I tried to:
 andrew@tiktaalik2 ~/projects hg clone ssh://h...@hg.python.org/cpython
 ssh://h...@hg.python.org/sandbox/tkdocs
 repo created, public URL is http://hg.python.org/sandbox/tkdocs
 abort: clone from remote to remote not supported

You could do the server side clone using the web form here -
http://hg.python.org/cpython/

Then you could you that repo to work on your stuff.

Thanks,
Senthil

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

Re: [Python-Dev] lzma

[Senthil Kumaran]

On Fri, Mar 16, 2012 at 07:30:31PM -0700, Andrew Svetlov wrote:
 When I build python from sources I have no lzma support (module _lzma
 cannot be built).
 

I have liblzma-dev, liblzma2 and lzma packages installed on ubuntu.  I
am able to build and import lzma module.

Thanks,
Senthil


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

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

[Senthil Kumaran]

On Mon, Mar 12, 2012 at 10:48:04PM -0700, Andrey Petrov wrote:
 @Senthil: I originally asked Guido for guidance on improving the
 standard library and perhaps including some of my favourite projects,
 but he pointed out that in a couple of years we might end up again in
 the same position as before but with one extra library people will
 complain about for being obsoleted yet remains impossible to
 deprecate.
 
 I agreed with Guido that embracing and even encouraging users to use the
 rapidly-evolving community-built packages alongside the tried-and-true
 standard library is the best move here.

I agree with that too. 

I think, any improvements which can made by external libraries, if
they can be considered as can be good improvement in the stdlib, It's
a good idea to push them in.

I looked at the requests, I think that apis for various HTTP verbs is
something interesting, I think web applications authors see some
advantage there explicit GET / POST and sending specific options to
those. That facility, if it can be brought into urllib.request (3.3
onwards) it could be nice. Also you could have noticed an addition of
method= parameter in 3.3

I have not had a chance to look at urllib3. Should do. I have been
following httplib2 and use it. 

Thanks,
Senthil


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

Re: [Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

[Senthil Kumaran]

On Mon, Mar 12, 2012 at 07:23:11PM -0700, Andrey Petrov wrote:
 I've had the pleasure of speaking with Guido at PyCon and it became evident
 that some of Python's included batteries are significantly lagging behind the
 rapidly-evolving defacto standards of the community specifically in cases like
 urllib and urllib2, which lack important features provided by alternatives 
 like
 httplib2, requests, and my own urllib3.

Well, I think I have address this because I am the maintainer of those
modules in standard lib.

First things first, it looks to me that trashing something gives good
motivation to you (and others working on related modules). I don't
have a problem with that.

But on the other hand, if you think things can be improved in stdlib,
you are welcome to contribute. Just remember that new features,
refactoring with backwards compatibility, 'cool api' for new features
should go in 3.3+ onwards. Bug fixes, confusions on what's RFC
supported vs what's defacto standards, fine line between bugs and
features, those can be considered for 2.7.

I am personally in favor of constantly improving the standard library
modules along with mention of any good libraries which can be useful
for the purposes of the user.

We already have lots of such references in standard library
documentation. If there is a well maintained package, as long as the
external package is active and maintained, we can have it as link in
the docs. Sometimes those external packages become inactive too, in
those cases, those should pruned. Its' all about maintaining libraries
and docs and being helpful.

-- 
Senthil

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

Re: [Python-Dev] PEP czar for PEP 3144?

[Senthil Kumaran]

On Tue, Feb 21, 2012 at 12:07 AM,  mar...@v.loewis.de wrote:
 supreme ruler sounds good to me. I could go for inquisitor instead
 of czar as well...

But that would be bad for developers from Spain as nobody would expect
a spanish inquisition.

:-)

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

Re: [Python-Dev] 2.7 now uses Sphinx 1.0

[Senthil Kumaran]

On Fri, Jan 20, 2012 at 07:05:41PM +, Chris Withers wrote:
 
 That's great news, does that now mean the objects inventory for
 Python 2.7 and Python 3 on python.org now supports referring to
 section headers from 3rd party packages?

Nope. It does not seem to have any relation to that. Would you care to
explain more, possibly show an example in rst as what you mean?

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

Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions

[Senthil Kumaran]

On Wed, Jan 18, 2012 at 09:26:19PM +1000, Nick Coghlan wrote:
 My original suggestion to Antoine and Georg for 3.4 was that we simply
 propose to Larry Hastings (the 3.4 RM) that we spread out the release
 cycle, releasing the first alpha after ~6 months, the second after
 about ~12, then rolling into the regular release cycle of a final
 alpha, some beta releases, one or two release candidates and then the
 actual release. However, I'm sympathetic to Antoine's point that early
 alphas aren't likely to be at all interesting to folks that would like
 a fully supported stdlib update to put into production and no longer
 think that suggestion makes much sense on its own.

This looks like a 'good bridge' of suggestion between rapid releases
and stable releases. 

What would be purpose of alpha release. Would we encourage people to
use it or test it? Which the rapid relase cycle, the encouragement is
to use rather than test.

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

Re: [Python-Dev] Python 3.4 Release Manager

[Senthil Kumaran]

On Wed, Nov 23, 2011 at 11:50 AM, Larry Hastings la...@hastings.org wrote:
 I've volunteered to be the Release Manager for Python 3.4.  The FLUFL has

That's cool.  But just my thought, wouldn't it be better for someone
who regularly commits, fixes bugs and feature requests be better for a
RM role? Once a developer gets bored with those and wants more, could
take up RM role. Is there anything wrong with this kind of thinking?

Thanks,
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Is Python insider blog dead?

[Senthil Kumaran]

No. I think, you are welcome to write something about the recent
changes you made to Python.

-- 
Senthil

On Wed, Nov 16, 2011 at 12:40:06PM +0100, Jesús Cea wrote:
 Python insider blog was a great idea, trying to open and expose python-dev to 
 the world. A great and necessary idea.
 
 But the last post was in August.
 
 I wonder if the project is dead... Would be sad :-(
 
 http://blog.python.org/
 
 Enviado desde mi iPhone
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: 
 http://mail.python.org/mailman/options/python-dev/senthil%40uthcode.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (2.7): Fix closes Issue12529 - cgi.parse_header failure on double quotes and

[Senthil Kumaran]

On Thu, Oct 20, 2011 at 07:17:10AM +1000, Nick Coghlan wrote:
 NEWS entry? (same question for the later _sre fix)

Added. Thanks for catching this.

For some reason, I had slight doubt, if those issues were NEWS worthy
items.  IIRC, devguide recommends that a NEWS entry be added for all fixes
made, but still had a suspicion, if we unnecessarily add up too many
entries to NEWS.

Thanks,
Senthil

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

Re: [Python-Dev] [Python-checkins] cpython (2.7): Fixes #10860: Handle empty port after port delimiter in httplib

[Senthil Kumaran]

On Tue, Oct 18, 2011 at 11:23 PM, Éric Araujo mer...@netwok.org wrote:

 Looks like your entry went into the Interpreter Core section instead of
 Library.

That should be corrected.


 BTW, I don’t understand “3.x version will come as a separate patch” in

I think, he meant in a separate commit.  :)

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

Re: [Python-Dev] [Python-checkins] cpython (2.7): Fix closes Issue12722 - link heapq source in the text format in the

[Senthil Kumaran]

On Wed, Aug 10, 2011 at 11:58:24PM +0300, Ezio Melotti wrote:
 
 hg.python.org/cpython/2.7/path/to/file.py should work just fine.

The correct path seems to be:

http://hg.python.org/cpython/file/2.7/Lib/modulefile.py
 
 IIRC the reason why we don't do it on 2.x is because we don't have
 the 'source' directive available in Sphinx and therefore we would
 have to update all the links manually to link to h.p.o instead of
 s.p.o.

I see.  Does sphinx have any such directive already? How is it
supposed to behave?

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

Re: [Python-Dev] cpython (3.2): Fix closes Issue12676 - Invalid identifier used in TypeError message in

[Senthil Kumaran]

On Tue, Aug 02, 2011 at 02:16:01PM +0200, Antoine Pitrou wrote:
 There are still a lot of spaces in your message. You should use string

Yes, did not realize that.. :( Georg fixed this in his commit.

Thanks,
Senthil
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (3.2): Fix closes issue12683 - urljoin to work with relative join of svn scheme.

[Senthil Kumaran]

On Wed, Aug 03, 2011 at 03:23:19PM +0200, Antoine Pitrou wrote:
 This is the same test repeated. Perhaps you meant svn+ssh?

oops, thanks for the catch. yes, I did mean svn+ssh. I shall change
it.

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