Re: [Python-Dev] Withdraw PEP 546? Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

[Antoine Pitrou]

+1 for withdrawing it.  It's much too late in the 2.7 maintenance
schedule to start bothering with such a large and perilous backport.

Regards

Antoine.



On Wed, 30 May 2018 16:28:22 +0200
Victor Stinner  wrote:
> Hi,
> 
> tl; dr I will withdraw the PEP 546 in one week if noboy shows up to
> finish the implementation.
> 
> 
> Last year,I wrote the PEP 546 with Cory Benfield:
> "Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7"
> https://www.python.org/dev/peps/pep-0546/
> 
> The plan was to get a Python 2.7 implementation of Cory's PEP 543:
> "A Unified TLS API for Python"
> https://www.python.org/dev/peps/pep-0543/
> 
> Sadly, it seems like Cory is no longer available to work on the projec
> (PEP 543 is still a draft)t.
> 
> The PEP 546 is implemented:
> https://github.com/python/cpython/pull/2133
> 
> Well, I closed it, but you can still get it as a patch with:
> https://patch-diff.githubusercontent.com/raw/python/cpython/pull/2133.patch
> 
> But tests fail on Travis CI whereas I'm unable to reproduce the issue
> on my laptop (on Fedora). The failure seems to depend on the version
> of OpenSSL. Christian Heimes has a "multissl" tool which automates
> tests on multiple OpenSSL versions, but I failed to find time to try
> this tool.
> 
> Time flies and one year later, the PR of the PEP 546 is still not
> merged, tests are still failing.
> 
> One month ago, when 2.7.15 has been released, Benjamin Peterson,
> Python 2.7 release manager, simply proposed:
> "The lack of movement for a year makes me wonder if PEP 546 should be
> moved to Withdrawn status."
> 
> Since again, I failed to find time to look at the test_ssl failure, I
> plan to withdraw the PEP next week if nobody shows up :-( Sorry Python
> 2.7!
> 
> Does anyone would benefit of MemoryBIO in Python 2.7? Twisted,
> asyncio, trio, urllib3, anyone else? If yes, who is volunteer to
> finish the MemoryBIO backport (and maintain it)?
> 
> Victor



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

[Python-Dev] PyIndex_Check conflicts with PEP 384

[Christian Tismer]

Hi friends,

when implementing the limited API for PySide2, I recognized
a little bug where a function was replaced by a macro.

The file number.rst on python 3.6 says

"""
.. c:function:: int PyIndex_Check(PyObject *o)

   Returns ``1`` if *o* is an index integer (has the nb_index slot of the
   tp_as_number structure filled in), and ``0`` otherwise.
"""

Without notice, this function was replaced by a macro a while
ago, which reads

#define PyIndex_Check(obj) \
   ((obj)->ob_type->tp_as_number != NULL && \
(obj)->ob_type->tp_as_number->nb_index != NULL)

This contradicts PEP 384, because there is no way for non-heaptype
types to access the nb_index field.

If nobody objects, I would like to submit a patch that adds the
function back when the limited API is active.
I think to fix that before Python 3.7 is out.

Ciao -- Chris

-- 
Christian Tismer-Sperling:^)   tis...@stackless.com
Software Consulting  : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : http://pyside.org
14482 Potsdam: GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023



signature.asc
Description: OpenPGP digital signature
___
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] PyIndex_Check conflicts with PEP 384

[Nathaniel Smith]

Indeed, that sounds like a pretty straightforward bug in the stable ABI.
You should file an issue on bugs.python.org so it doesn't get lost (and if
it's the main new stable ABI break in 3.7 then you should probably mark
that bug as a release blocker so that Ned notices it).

Unfortunately, very few people use the stable ABI currently, so it's easy
for things like this to get missed. Hopefully it Qt starts using it then
that will help us shake these things out... But it also means we need your
help to catch these kinds of issues :-). Thanks!

On Fri, Jun 1, 2018, 06:51 Christian Tismer  wrote:

> Hi friends,
>
> when implementing the limited API for PySide2, I recognized
> a little bug where a function was replaced by a macro.
>
> The file number.rst on python 3.6 says
>
> """
> .. c:function:: int PyIndex_Check(PyObject *o)
>
>Returns ``1`` if *o* is an index integer (has the nb_index slot of the
>tp_as_number structure filled in), and ``0`` otherwise.
> """
>
> Without notice, this function was replaced by a macro a while
> ago, which reads
>
> #define PyIndex_Check(obj) \
>((obj)->ob_type->tp_as_number != NULL && \
> (obj)->ob_type->tp_as_number->nb_index != NULL)
>
> This contradicts PEP 384, because there is no way for non-heaptype
> types to access the nb_index field.
>
> If nobody objects, I would like to submit a patch that adds the
> function back when the limited API is active.
> I think to fix that before Python 3.7 is out.
>
> Ciao -- Chris
>
> --
> Christian Tismer-Sperling:^)   tis...@stackless.com
> Software Consulting  : http://www.stackless.com/
> Karl-Liebknecht-Str. 121 : http://pyside.org
> 14482 Potsdam: GPG key -> 0xFB7BEE0E
> phone +49 173 24 18 776  fax +49 (30) 700143-0023
>
> ___
> 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/njs%40pobox.com
>
___
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] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2018-05-25 - 2018-06-01)
Python tracker at https://bugs.python.org/

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

Issues counts and deltas:
  open6684 (-15)
  closed 38802 (+102)
  total  45486 (+87)

Open issues with patches: 2631 


Issues opened (64)
==

#31731: [2.7] test_io hangs on x86 Gentoo Refleaks 2.7
https://bugs.python.org/issue31731  reopened by zach.ware

#33532: test_multiprocessing_forkserver: TestIgnoreEINTR.test_ignore()
https://bugs.python.org/issue33532  reopened by vstinner

#33622: Fix and improve errors handling in the garbage collector
https://bugs.python.org/issue33622  reopened by serhiy.storchaka

#33649: asyncio docs overhaul
https://bugs.python.org/issue33649  opened by yselivanov

#33650: Prohibit adding a signal handler for SIGCHLD
https://bugs.python.org/issue33650  opened by yselivanov

#33656: IDLE: Turn on DPI awareness on Windows
https://bugs.python.org/issue33656  opened by terry.reedy

#33658: Introduce a method to concatenate regex patterns
https://bugs.python.org/issue33658  opened by aleskva

#33660: pathlib.Path.resolve() returns path with double slash when res
https://bugs.python.org/issue33660  opened by QbLearningPython

#33661: urllib may leak sensitive HTTP headers to a third-party web si
https://bugs.python.org/issue33661  opened by artem.smotrakov

#33663: Web.py wsgiserver3.py raises TypeError when CSS file is not fo
https://bugs.python.org/issue33663  opened by jmlp

#33664: IDLE:  scroll text by lines, not pixels.
https://bugs.python.org/issue33664  opened by terry.reedy

#33665: tkinter.ttk.Scrollbar.fraction() is inaccurate, or at least in
https://bugs.python.org/issue33665  opened by pez

#33666: Document removal of os.errno
https://bugs.python.org/issue33666  opened by hroncok

#33668: Wrong behavior of help function on module
https://bugs.python.org/issue33668  opened by Oleg.Oleinik

#33669: str.format should raise exception when placeholder number does
https://bugs.python.org/issue33669  opened by xiang.zhang

#33671: Efficient zero-copy for shutil.copy* functions (Linux, OSX and
https://bugs.python.org/issue33671  opened by giampaolo.rodola

#33676: test_multiprocessing_fork: dangling threads warning
https://bugs.python.org/issue33676  opened by vstinner

#33678: selector_events.BaseSelectorEventLoop.sock_connect should pres
https://bugs.python.org/issue33678  opened by sebastien.bourdeauducq

#33679: IDLE: Configurable color on code context
https://bugs.python.org/issue33679  opened by cheryl.sabella

#33680: regrtest: re-run failed tests in a subprocess
https://bugs.python.org/issue33680  opened by vstinner

#33683: asyncio: sendfile tests ignore SO_SNDBUF on Windows
https://bugs.python.org/issue33683  opened by vstinner

#33684: parse failed for mutibytes characters, encode will show in \xx
https://bugs.python.org/issue33684  opened by zhou.ronghua

#33686: test_concurrent_futures: test_pending_calls_race() failed on x
https://bugs.python.org/issue33686  opened by vstinner

#33687: uu.py calls os.path.chmod which doesn't exist
https://bugs.python.org/issue33687  opened by bsdphk

#33688: asyncio child watchers aren't fork friendly
https://bugs.python.org/issue33688  opened by yselivanov

#33689: Blank lines in .pth file cause a duplicate sys.path entry
https://bugs.python.org/issue33689  opened by Malcolm Smith

#33692: Chinese characters issue with input() function
https://bugs.python.org/issue33692  opened by Valentin Zhao

#33694: test_asyncio: test_start_tls_server_1() fails on Python on x86
https://bugs.python.org/issue33694  opened by vstinner

#33695: Have shutil.copytree(), copy() and copystat() use cached scand
https://bugs.python.org/issue33695  opened by giampaolo.rodola

#33696: Install python-docs-theme even if SPHINXBUILD is defined
https://bugs.python.org/issue33696  opened by adelfino

#33697: test_zipfile.test_write_filtered_python_package() failed on Ap
https://bugs.python.org/issue33697  opened by vstinner

#33698: `._pth` does not allow to populate `sys.path` with empty entry
https://bugs.python.org/issue33698  opened by excitoon

#33699: Don't describe try's else clause in a footnote
https://bugs.python.org/issue33699  opened by adelfino

#33700: [doc] Old version picker don't understand language tags in URL
https://bugs.python.org/issue33700  opened by mdk

#33701: test_datetime crashed (SIGSEGV) on Travis CI
https://bugs.python.org/issue33701  opened by vstinner

#33702: Add some missings links in production lists and a little polis
https://bugs.python.org/issue33702  opened by adelfino

#33705: Unicode is normalised after keywords are checked for
https://bugs.python.org/issue33705  opened by steven.daprano

#33708: Doc: Asyncio's Event documentation typo.
https://bugs.python.org/issue33708  opened by socketpair

#33709: test.support.FS_NONASCII returns incorrect result in Windows w
https://bugs.python.org/issue33709  ope

Re: [Python-Dev] How to watch buildbots?

[Eric Snow]

On Wed, May 30, 2018 at 7:36 AM, Nick Coghlan  wrote:
> There are a few key details here:
>
> 1. We currently need to run post-merge CI anyway, as we're not doing
> linearised commits (where core devs just approve a change without merging
> it, and then a gating system like Zuul ensures that the tests are run
> against the latest combination of the target branch and the PR before
> merging the change)

This is more of a concern when non-conflicting PRs against the same
(or related) code are active at the same time.  For the CPython code
base this isn't as much of a problem, right?  Under normal
circumstances [fresh] active PRs typically do not run afoul of each
other.  Furthermore, during peak-activity events (like sprints) folks
tend to keep a closer eye on the buildbots.  I suppose
old-but-still-active PRs that previously passed CI could cause a
problem.  However, it would be unlikely for such a PR to sit for a
long time without needing changes before merging, whether to address
reviewer concerns or to resolve merge conflicts.

So post-merge CI (or merge gating) doesn't seem like much of a factor
for us.  In that regard I'd consider the buildbots more that
sufficient.

> 2. Since the buildbots are running on donated dedicated machines (rather
> than throwaway instances from a dynamic CI provider), we need to review the
> code before we let it run on the contributed systems
> 3. The buildbot instances run *1* build at a time,

...where each build incorporates potentially several merged PRs...

> which would lead to major
> PR merging bottlenecks during sprints if we made them a gating requirement

Agreed.  There's enough of a delay already when watching the buildbots
post-merge (especially some of them). :)

> 4. For the vast majority of PRs, the post-merge cross-platform testing is a
> formality, since the code being modified is using lower level cross-platform
> APIs elsewhere in the standard library, so if it works on Windows, Linux,
> and Mac OS X, it will work everywhere Python runs

This is especially true of changes proposed by non-core contributors.
It is also very true for buildbots with the OS/hardware combos that
match CI.  That said, when working with the C-API you can end up
breaking things on the less common OSes and hardware platforms.  So
*those* buildbots are invaluable.  I'm dealing with that right now.

> 5. We generally don't *want* to burden new contributors with the task of
> dealing with the less common (or harder to target) platforms outside the big
> 3 - when they do break, it often takes a non-trivial amount of platform
> knowledge to understand what's different about the platform in question

As hinted above, I would not expect new contributors to provide
patches very often (if ever) that would have the potential to cause
buildbot failures but not fail under CI.  So this point seems somewhat
moot. :)

> P.S. That said, if VSTS or Travis were to offer FreeBSD as an option for
> pre-merge CI, I'd suggest we enable it, at least in an advisory capacity -
> it's a better check against Linux-specific assumptions creeping into the
> code base than Mac OS X, since the latter is regularly different enough from
> other *nix systems that we need to give it dedicated code paths.

+1

-eric
___
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] Stable ABI

[Jeroen Demeyer]

On 2018-06-01 17:18, Nathaniel Smith wrote:

Unfortunately, very few people use the stable ABI currently, so it's
easy for things like this to get missed.


So there are no tests for the stable ABI in Python?

___
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] PyIndex_Check conflicts with PEP 384

[Christian Tismer]

Hi Nate,

I just did that, and I got some follow-up work, too, which is fine
with me. Just as a note for you:

Qt not itself, but PyQt5 did that already and submitted a stable
ABI for Python 3.5 and up.

I was challenged end of last December to try that, and I succeeded
after a long struggle, because I also needed to convert all of PySide2
to using heaptypes, and that was really hard. Actually, I succeeded
yesterday, after 5 months. And now I know all the subtle things
that people need to know when converting existing types to heaptypes.

Since QtC has adopted PySide2 in 2016, including myself as a consultant,
now it is really a Qt product, and the limited API is due to my work.
It comes naturally that I also should fix the problems which showed up
during that process.

I also think to submit a paper to python.org where I document all the
subtle problems which occured during the conversion process. It looks
simple, but it really is not.

All the best -- Chris


On 01.06.18 17:18, Nathaniel Smith wrote:
> Indeed, that sounds like a pretty straightforward bug in the stable ABI.
> You should file an issue on bugs.python.org  so
> it doesn't get lost (and if it's the main new stable ABI break in 3.7
> then you should probably mark that bug as a release blocker so that Ned
> notices it).
> 
> Unfortunately, very few people use the stable ABI currently, so it's
> easy for things like this to get missed. Hopefully it Qt starts using it
> then that will help us shake these things out... But it also means we
> need your help to catch these kinds of issues :-). Thanks!
> 
> On Fri, Jun 1, 2018, 06:51 Christian Tismer  > wrote:
> 
> Hi friends,
> 
> when implementing the limited API for PySide2, I recognized
> a little bug where a function was replaced by a macro.
> 
> The file number.rst on python 3.6 says
> 
> """
> .. c:function:: int PyIndex_Check(PyObject *o)
> 
>    Returns ``1`` if *o* is an index integer (has the nb_index slot
> of the
>    tp_as_number structure filled in), and ``0`` otherwise.
> """
> 
> Without notice, this function was replaced by a macro a while
> ago, which reads
> 
> #define PyIndex_Check(obj) \
>    ((obj)->ob_type->tp_as_number != NULL && \
>     (obj)->ob_type->tp_as_number->nb_index != NULL)
> 
> This contradicts PEP 384, because there is no way for non-heaptype
> types to access the nb_index field.
> 
> If nobody objects, I would like to submit a patch that adds the
> function back when the limited API is active.
> I think to fix that before Python 3.7 is out.
> 
> Ciao -- Chris
> 
> -- 
> Christian Tismer-Sperling    :^)   tis...@stackless.com
> 
> Software Consulting          :     http://www.stackless.com/
> Karl-Liebknecht-Str. 121     :     http://pyside.org
> 14482 Potsdam                :     GPG key -> 0xFB7BEE0E
> phone +49 173 24 18 776  fax +49 (30) 700143-0023
> 
> ___
> 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/njs%40pobox.com
> 


-- 
Christian Tismer-Sperling:^)   tis...@stackless.com
Software Consulting  : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : http://pyside.org
14482 Potsdam: GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023



signature.asc
Description: OpenPGP digital signature
___
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 history of PyXML

[Jan Claeys]

On Thu, 2018-05-31 at 09:23 -0600, Jeremy Kloth wrote:
> I had also contacted SourceForge prior to me uploading a Github repo.
> They have just restored the project files for PyXML as well (CVS,
> downloads, ...).

So I was right thinking they might have a backup?  :-)


I have to say it seems like the new owners of SourceForge are doing
their best to make it a good place for project hosting again.
(Not always as fast as one would wish, but I understand it's big, and
the previous owners did a lot of damage to the brand...)


-- 
Jan Claeys
___
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] Stable ABI

[Nick Coghlan]

On 2 June 2018 at 03:45, Jeroen Demeyer  wrote:

> On 2018-06-01 17:18, Nathaniel Smith wrote:
>
>> Unfortunately, very few people use the stable ABI currently, so it's
>> easy for things like this to get missed.
>>
>
> So there are no tests for the stable ABI in Python?
>

Unfortunately not.

https://bugs.python.org/issue21142 is an old issue suggesting automating
those checks (so we don't inadvertently add or remove symbols for
previously published stable ABI definitions), but it's not yet made it to
the state of being sufficiently well automated that it can be a release
checklist item in PEP 101.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] PyIndex_Check conflicts with PEP 384

[Serhiy Storchaka]

02.06.18 00:37, Christian Tismer пише:

I was challenged end of last December to try that, and I succeeded
after a long struggle, because I also needed to convert all of PySide2
to using heaptypes, and that was really hard. Actually, I succeeded
yesterday, after 5 months. And now I know all the subtle things
that people need to know when converting existing types to heaptypes.


Are you aware of the following pitfall Christian?

https://bugs.python.org/issue26979

___
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