Re: [Python-Dev] Drop support for old unsupported FreeBSD and Linux kernels?

[Christian Heimes]

On 2018-01-19 06:36, Benjamin Peterson wrote:
> +1 to both of your specific proposals.
> 
> More generally, I think it makes good sense to allow dropping support for a 
> platform in the next major Python release after vendor support for the 
> platform stops. Even we say we support something, it will break quickly 
> without buildbot validation.

Do you mean minor release? We haven't done a major release in about a
decade. :)

I was going to suggest a similar policy for OpenSSL.

Christian

___
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] Drop support for old unsupported FreeBSD and Linux kernels?

[Terry Reedy]

On 1/19/2018 1:04 AM, Nathaniel Smith wrote:

On Thu, Jan 18, 2018 at 12:27 PM, Victor Stinner
 wrote:

CPython still has compatibility code for Linux 2.6, whereas the
support of Linux 2.6.x ended in August 2011, longer than 6 years ago.
Should we also drop support for old Linux kernels? If yes, which ones?
The Linux kernel has LTS version, the oldest is Linux 3.2 (support
will end in May, 2018).

Linux kernel support:

   https://www.kernel.org/category/releases.html


RHEL 5 uses 2.6.28, and still has "extended life cycle support" until
2020, but I guess no-one should be running Python 3.7 on that. CentOS
6 and RHEL 6 use 2.6.32, and their EOL is also 2020 (or 2024 for RHEL
6 with extended life cycle support). Redhat does ship and support 3.6
on CentOS/RHEL 6 through their "software collections" product, and
presumably is planning to do the same for 3.7.

It is a little surprising to see a Redhat employee suggest dropping
support for RHEL 6. Hopefully you know what you're doing :-)


Microsoft offers *paid* private support of some sort to corporations for 
publicly unsupported versions of Windows, such as xp and, we may expect, 
Vista.  But we dropped support of xp and should, by policy, do so for 
Vista.  I am not familiar with what Redhat does, but if it is similar, I 
think we should apply the same policy.


--
Terry Jan Reedy

___
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] Drop support for old unsupported FreeBSD and Linux kernels?

[Antoine Pitrou]

On Thu, 18 Jan 2018 22:04:34 -0800
Nathaniel Smith  wrote:
> On Thu, Jan 18, 2018 at 12:27 PM, Victor Stinner
>  wrote:
> > CPython still has compatibility code for Linux 2.6, whereas the
> > support of Linux 2.6.x ended in August 2011, longer than 6 years ago.
> > Should we also drop support for old Linux kernels? If yes, which ones?
> > The Linux kernel has LTS version, the oldest is Linux 3.2 (support
> > will end in May, 2018).
> >
> > Linux kernel support:
> >
> >   https://www.kernel.org/category/releases.html  
> 
> RHEL 5 uses 2.6.28, and still has "extended life cycle support" until
> 2020, but I guess no-one should be running Python 3.7 on that. CentOS
> 6 and RHEL 6 use 2.6.32, and their EOL is also 2020 (or 2024 for RHEL
> 6 with extended life cycle support).

What is the problem with supporting Linux 2.6?  Do we need to rely on
newer features? (which ones?)

I'm sure some people will want to be running Python 3.7 on RHEL 6 or
CentOS 6.  After all, there's a reason RedHat provides 3.6 builds
for it.  Of course, you may say it's RedHat's (or other vendors')
responsibility to apply compatibility patches.  But if the
compatibility code is already there, maybe it doesn't cost us much to
keep it?

Regards

Antoine.


___
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] Exposing different versions of a system call in Python

[Pablo Galindo Salgado]

Hello everyone,

In today's episode of exposing useful Linux system calls I am exposing
preadv2 in this PR:

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

as requested in this issue:

https://bugs.python.org/issue31368

As njsmith has commented in the PR, preadv2 only exists because regular
preadv was missing a flags argument, and in C the only way to add an
argument is to make a new function. In Python we have already exposed
preadv2 and a possible solution would be add a optional argument that
passes the new parametera to preadv and calls preadv2 if this happens.

On the other side, we have pipe and pipe2 as an example of exposing two
versions when this situation happens.

The question is:

What is preferable, exposing both functions or augment the old one?

Thank you everyone for your 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] Drop support for old unsupported FreeBSD and Linux kernels?

[Antoine Pitrou]

On Thu, 18 Jan 2018 22:04:34 -0800
Nathaniel Smith  wrote:

> On Thu, Jan 18, 2018 at 12:27 PM, Victor Stinner
>  wrote:
> > CPython still has compatibility code for Linux 2.6, whereas the
> > support of Linux 2.6.x ended in August 2011, longer than 6 years ago.
> > Should we also drop support for old Linux kernels? If yes, which ones?
> > The Linux kernel has LTS version, the oldest is Linux 3.2 (support
> > will end in May, 2018).
> >
> > Linux kernel support:
> >
> >   https://www.kernel.org/category/releases.html  
> 
> RHEL 5 uses 2.6.28, and still has "extended life cycle support" until
> 2020, but I guess no-one should be running Python 3.7 on that. CentOS
> 6 and RHEL 6 use 2.6.32, and their EOL is also 2020 (or 2024 for RHEL
> 6 with extended life cycle support).

As another data point, 2.6 is often run on cheap OpenVZ-based virtual
servers.  For example, I have this OVH entry-level VPS (2014 range)
with an up-to-date Debian stable:

$ cat /etc/debian_version 
9.3
$ uname -rv
2.6.32-042stab127.2 #1 SMP Thu Jan 4 16:41:44 MSK 2018

Regards

Antoine.


___
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] LibreSSL support

[Steve Holden]

On Fri, Jan 19, 2018 at 12:09 AM, Nathaniel Smith  wrote:

> On Jan 18, 2018 07:34, "Christian Heimes"  wrote:
>
> On 2018-01-16 21:17, Christian Heimes wrote:
> > FYI, master on Travis CI now builds and uses OpenSSL 1.1.0g [1]. I have
> > created a daily cronjob to populate Travis' cache with OpenSSL builds.
> > Until the cache is filled, Linux CI will take an extra 5 minute.
>
> I have messed up my initial research. :( When I was checking LibreSSL
> and OpenSSL for features, I draw a wrong conclusion. LibreSSL is *not*
> OpenSSL 1.0.2 compatible. It only implements some of the required
> features from 1.0.2 (e.g. X509_check_hostname) but not
> X509_VERIFY_PARAM_set1_host.
>
> X509_VERIFY_PARAM_set1_host() is required to perform hostname
> verification during the TLS handshake. Without the function, I'm unable
> to fix Python's hostname matching code [1]. LibreSSL upstream knows
> about the issue since 2016 [2]. I have opened another bug report [3].
>
> We have two options until LibreSSL has addressed the issue:
>
> 1) Make the SSL module more secure, simpler and standard conform
> 2) Support LibreSSL
>
>
> ​[...]
>


> We have *very* few people qualified to maintain the ssl module, so given
> the new landscape I think we should focus on keeping our core OpenSSL
> support solid and not worry about LibreSSL. If LibreSSL wants to be
> supported as well then – like any other 2nd tier platform – they need to
> find someone to do the work. And if people are worried about supporting
> more diversity in SSL implementations, then PEP 543 is probably the thing
> to focus on.
>
> ​Given the hard limit on resources it seems only sensible to focus on the
"industry standard" library​. I'm rather disappointed that LibreSSL isn't a
choice, but given the lack of compatibility that's hardly Python's problem.
___
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] LibreSSL support

[Christian Heimes]

On 2018-01-19 10:43, Steve Holden wrote:
> On Fri, Jan 19, 2018 at 12:09 AM, Nathaniel Smith  > wrote:
> 
> On Jan 18, 2018 07:34, "Christian Heimes"  > wrote:
> 
> On 2018-01-16 21:17, Christian Heimes wrote:
> > FYI, master on Travis CI now builds and uses OpenSSL 1.1.0g [1]. I 
> have
> > created a daily cronjob to populate Travis' cache with OpenSSL 
> builds.
> > Until the cache is filled, Linux CI will take an extra 5 minute.
> 
> I have messed up my initial research. :( When I was checking
> LibreSSL
> and OpenSSL for features, I draw a wrong conclusion. LibreSSL is
> *not*
> OpenSSL 1.0.2 compatible. It only implements some of the required
> features from 1.0.2 (e.g. X509_check_hostname) but not
> X509_VERIFY_PARAM_set1_host.
> 
> X509_VERIFY_PARAM_set1_host() is required to perform hostname
> verification during the TLS handshake. Without the function, I'm
> unable
> to fix Python's hostname matching code [1]. LibreSSL upstream knows
> about the issue since 2016 [2]. I have opened another bug report
> [3].
> 
> We have two options until LibreSSL has addressed the issue:
> 
> 1) Make the SSL module more secure, simpler and standard conform
> 2) Support LibreSSL
> 
> 
> ​[...]
> 
>  
> 
> We have *very* few people qualified to maintain the ssl module, so
> given the new landscape I think we should focus on keeping our core
> OpenSSL support solid and not worry about LibreSSL. If LibreSSL
> wants to be supported as well then – like any other 2nd tier
> platform – they need to find someone to do the work. And if people
> are worried about supporting more diversity in SSL implementations,
> then PEP 543 is probably the thing to focus on.
> 
> ​Given the hard limit on resources it seems only sensible to focus on
> the "industry standard" library​. I'm rather disappointed that LibreSSL
> isn't a choice, but given the lack of compatibility that's hardly
> Python's problem.

Thanks!

I'd prefer to support LibreSSL, too. Paul Kehrer from PyCA summed up the
issue with LibreSSL nicely:

> It was marketed as an API compatible drop-in replacement and it is
failing in that capacity. Additionally, it is missing features needed to
improve the security and ease the maintenance burden of CPython’s dev team.


Since I haven given up on LibreSSL, I spent some time and implemented
some autoconf magic in https://github.com/python/cpython/pull/5242. It
checks for the presence of libssl and X509_VERIFY_PARAM_set1_host()
function family:

...
checking whether compiling and linking against OpenSSL works... yes
checking for X509_VERIFY_PARAM_set1_host in libssl... yes
...

The ssl module will regain compatibility with LibreSSL as soon as a new
release provides the necessary functions.

Christian

___
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] Exposing different versions of a system call in Python

[Random832]

On Fri, Jan 19, 2018, at 04:28, Pablo Galindo Salgado wrote:
> On the other side, we have pipe and pipe2 as an example of exposing two
> versions when this situation happens.
> 
> The question is:
> 
> What is preferable, exposing both functions or augment the old one?

A large number, possibly a majority, of system calls in the os module, have 
"dir_fd" arguments that cause them to call the *at counterpart of the 
underlying system call. And chdir can also be called with a file descriptor, 
which will call fchdir (though there is also a fchdir function) I don't know 
why pipe2 was implemented as a separate call.
___
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-01-12 - 2018-01-19)
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:
  open6400 (+31)
  closed 37949 (+28)
  total  44349 (+59)

Open issues with patches: 2489 


Issues opened (46)
==

#32493: UUID Module - FreeBSD build failure
https://bugs.python.org/issue32493  reopened by vstinner

#32540: venv docs - doesn't match behavior
https://bugs.python.org/issue32540  opened by jason.coombs

#32541: cgi.FieldStorage constructor assumes all lines terminate with 
https://bugs.python.org/issue32541  opened by Ian Craggs

#32542: memory not freed, aka memory leak continues...
https://bugs.python.org/issue32542  opened by Michael.Felt

#32545: Unable to install Python 3.7.0a4 on Windows 10 - Error 0x80070
https://bugs.python.org/issue32545  opened by mwr256

#32546: Unusual TypeError with dataclass decorator
https://bugs.python.org/issue32546  opened by rhettinger

#32547: csv.DictWriter emits strange errors if fieldnames is an iterat
https://bugs.python.org/issue32547  opened by bendotc

#32548: IDLE: Add links for email and docs to help_about
https://bugs.python.org/issue32548  opened by csabella

#32549: Travis: Test with OpenSSL 1.1.0
https://bugs.python.org/issue32549  opened by christian.heimes

#32550: STORE_ANNOTATION bytecode is unnecessary and can be removed.
https://bugs.python.org/issue32550  opened by Mark.Shannon

#32551: Zipfile & directory execution in 3.5.4 also adds the parent di
https://bugs.python.org/issue32551  opened by nedbat

#32552: Improve text for file arguments in argparse.ArgumentDefaultsHe
https://bugs.python.org/issue32552  opened by elypter

#32553: venv says to use python3 which does not exist in 3.6.4
https://bugs.python.org/issue32553  opened by Paul Watson

#32554: random.seed(tuple) uses the randomized hash function and so is
https://bugs.python.org/issue32554  opened by johnnyd

#32555: Encoding issues with the locale encoding
https://bugs.python.org/issue32555  opened by vstinner

#32556: support bytes paths in nt _getdiskusage, _getvolumepathname, a
https://bugs.python.org/issue32556  opened by eryksun

#32557: allow shutil.disk_usage to take a file path
https://bugs.python.org/issue32557  opened by eryksun

#32560: inherit the py launcher's STARTUPINFO
https://bugs.python.org/issue32560  opened by eryksun

#32561: Add API to io objects for non-blocking reads/writes
https://bugs.python.org/issue32561  opened by njs

#32562: Support fspath protocol in AF_UNIX sockaddr resolution
https://bugs.python.org/issue32562  opened by njs

#32563: -Werror=declaration-after-statement expat build failure on Pyt
https://bugs.python.org/issue32563  opened by ncoghlan

#32565: Document the version of adding opcodes
https://bugs.python.org/issue32565  opened by serhiy.storchaka

#32566: Not able to open Python IDLE
https://bugs.python.org/issue32566  opened by Kiran

#32567: Venv’s config file (pyvenv.cfg) should be compatible with Co
https://bugs.python.org/issue32567  opened by uranusjr

#32568: Fix handling of sizehint=-1 in select.epoll()
https://bugs.python.org/issue32568  opened by taleinat

#32571: Speed up and clean up getting optional attributes in C code
https://bugs.python.org/issue32571  opened by serhiy.storchaka

#32572: Add the ftplib option, overrides the IP address.
https://bugs.python.org/issue32572  opened by studioes

#32573: sys.argv documentation should include caveat for embedded envi
https://bugs.python.org/issue32573  opened by pgacv2

#32574: asyncio.Queue, put() leaks memory if the queue is full
https://bugs.python.org/issue32574  opened by Mordis

#32579: UUID module fix, uuid1 python module function
https://bugs.python.org/issue32579  opened by David CARLIER2

#32580: Fallback to dev_urandom doesn't work when py_getrandom returns
https://bugs.python.org/issue32580  opened by jernejs

#32581: A bug of the write funtion of ConfigParser.py
https://bugs.python.org/issue32581  opened by jiangjinhu666

#32582: chr raises OverflowError
https://bugs.python.org/issue32582  opened by ukl

#32583: Crash during decoding using UTF-16/32 and custom error handler
https://bugs.python.org/issue32583  opened by sibiryakov

#32584: Uninitialized free_extra in code_dealloc
https://bugs.python.org/issue32584  opened by jeethu

#32585: Add ttk::spinbox to tkinter.ttk
https://bugs.python.org/issue32585  opened by Alan Moore

#32587: Make REG_MULTI_SZ support PendingFileRenameOperations
https://bugs.python.org/issue32587  opened by nanonyme

#32589: Statistics as a result from timeit
https://bugs.python.org/issue32589  opened by MGilch

#32590: Proposal: add an "ensure(arg)" builtin for parameter validatio
https://bugs.python.org/issue32590  opened by ncoghlan

#32591: Deprecate sys.set_coroutine_wrapper and replace it with more f
https://bugs.python.org/issue32591  opened by njs

#32592: Drop support of Windows Vist

[Python-Dev] Intention to accept PEP 567 (Context Variables)

[Guido van Rossum]

There has been useful and effective discussion on several of the finer
points of PEP 567. I think we've arrived at a solid specification, where
every part of the design is well motivated. I plan to accept it on Monday,
unless someone brings up something significant that we've overlooked before
then. Please don't rehash issues that have already been debated -- we're
unlikely to reach a different conclusion upon revisiting the same issue
(read the Rejected Ideas section first).

-- 
--Guido van Rossum (python.org/~guido)
___
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] Exposing different versions of a system call in Python

[Brett Cannon]

On Fri, 19 Jan 2018 at 01:30 Pablo Galindo Salgado 
wrote:

> Hello everyone,
>
> In today's episode of exposing useful Linux system calls I am exposing
> preadv2 in this PR:
>
> https://github.com/python/cpython/pull/5239
>
> as requested in this issue:
>
> https://bugs.python.org/issue31368
>
> As njsmith has commented in the PR, preadv2 only exists because regular
> preadv was missing a flags argument, and in C the only way to add an
> argument is to make a new function. In Python we have already exposed
> preadv2 and a possible solution would be add a optional argument that
> passes the new parametera to preadv and calls preadv2 if this happens.
>
> On the other side, we have pipe and pipe2 as an example of exposing two
> versions when this situation happens.
>
> The question is:
>
> What is preferable, exposing both functions or augment the old one?
>

I guess the question is whether discoverability would be hurt  by
combining. My guess is no, in which case if the only difference between the
two system calls is a single argument then I would make a single function.
___
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] Drop support for old unsupported FreeBSD and Linux kernels?

[Brett Cannon]

On Thu, 18 Jan 2018 at 21:39 Benjamin Peterson  wrote:

> +1 to both of your specific proposals.
>
> More generally, I think it makes good sense to allow dropping support for
> a platform in the next major Python release after vendor support for the
> platform stops. Even we say we support something, it will break quickly
> without buildbot validation.
>

+1 from me as well. We all only have so much bandwidth and if someone wants
extended support there are plenty of contractors who could be hired to
extend it.

-Brett


>
> On Thu, Jan 18, 2018, at 12:27, Victor Stinner wrote:
> > Hi,
> >
> > I'm working on a exhaustive list of platforms supported by Python:
> >
> >   http://vstinner.readthedocs.io/cpython.html#supported-platforms
> >
> >
> > I noticed that the extended support phase of Windows Vista is expired,
> > so I proposed to drop Vista support:
> >
> >   "Drop support of Windows Vista in Python 3.7"
> >   https://bugs.python.org/issue32592
> >   https://github.com/python/cpython/pull/5231
> >
> > Python has an explicit policy for Windows support, extract of the PEP 11:
> >
> > "CPython’s Windows support now follows [Microsoft product support
> > lifecycle]. A new feature release X.Y.0 will support all Windows
> > releases whose extended support phase is not yet expired. Subsequent
> > bug fix releases will support the same Windows releases as the
> > original feature release (even if the extended support phase has
> > ended)."
> >
> >
> > For Linux and FreeBSD, we have no explicit rule. CPython code base
> > still contains code for FreeBSD 4... but FreeBSD 4 support ended
> > longer than 10 years ago (January 31, 2007). Maybe it's time to drop
> > support of these old platforms to cleanup the CPython code base to
> > ease its maintainance.
> >
> > I proposed: "Drop FreeBSD 9 and older support:"
> >
> >   https://bugs.python.org/issue32593
> >   https://github.com/python/cpython/pull/5232
> >
> > FreeBSD 9 supported ended 1 year ago (December 2016).
> >
> > FreeBSD support:
> >
> >   https://www.freebsd.org/security/
> >   https://www.freebsd.org/security/unsupported.html
> >
> >
> > CPython still has compatibility code for Linux 2.6, whereas the
> > support of Linux 2.6.x ended in August 2011, longer than 6 years ago.
> > Should we also drop support for old Linux kernels? If yes, which ones?
> > The Linux kernel has LTS version, the oldest is Linux 3.2 (support
> > will end in May, 2018).
> >
> > Linux kernel support:
> >
> >   https://www.kernel.org/category/releases.html
> >
> >
> > Note: I'm only talking about changing the future Python 3.7. We should
> > have the same support policy than for Windows. If Python 3.x.0
> > supports a platform, this support should be kept in the whole lifetime
> > of the 3.x cycle (until it's end-of-line).
> >
> > 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/benjamin%40python.org
> ___
> 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/brett%40python.org
>
___
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] Positional-only parameters in Python

[Mario Corchero]

I am happy to put some work into this (and Pablo Galindo in CC offered to
pair on it) but it is not clear for me whether the next step is drafting a
new PEP or this is just blocked on "re-evaluating" the current one.

If someone can clarify we can put something together.

Thanks!

On 18 January 2018 at 14:40, Nick Coghlan  wrote:

> On 18 January 2018 at 19:26, Larry Hastings  wrote:
> > Would we be adding yet a third argument-parsing function,
> > PyArg_ParseTupleAndKeywordsWithPositionalOnly()?
>
> Checking the docs, it turns out PyArg_ParseTupleAndKeywords already
> gained positional-only argument support in 3.6 by way of empty strings
> in the keyword array.
>
> 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/
> mariocj89%40gmail.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] Unexpected bytecode difference

[Alexander Belopolsky]

I have encountered the following difference between Python 3 and 2:

(py3)
>>> compile('xxx', '<>', 'eval').co_code
b'e\x00S\x00'

(py2)
>>> compile('xxx', '<>', 'eval').co_code
'e\x00\x00S'

Note that 'S' (the code for RETURN_VALUE) and a zero byte are swapped
in Python 2 compared to Python 3.  Is this change documented
somewhere?
___
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] Unexpected bytecode difference

[Victor Stinner]

Python bytecode format changed deeply in Python 3.6. It now uses
regular units of 2 bytes, instead of 1 or 3 bytes depending if the
instruction has an argument.

See for example https://bugs.python.org/issue26647 "wordcode".

But CALL_FUNCTION bytecode also evolved.

Victor

2018-01-20 0:46 GMT+01:00 Alexander Belopolsky :
> I have encountered the following difference between Python 3 and 2:
>
> (py3)
 compile('xxx', '<>', 'eval').co_code
> b'e\x00S\x00'
>
> (py2)
 compile('xxx', '<>', 'eval').co_code
> 'e\x00\x00S'
>
> Note that 'S' (the code for RETURN_VALUE) and a zero byte are swapped
> in Python 2 compared to Python 3.  Is this change documented
> somewhere?
> ___
> 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/victor.stinner%40gmail.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

Re: [Python-Dev] Unexpected bytecode difference

[Guido van Rossum]

Presumably because Python 3 switched to wordcode. Applying dis.dis() to
these code objects results in the same output.

>>> dis.dis(c)
  0 LOAD_NAME   0 (0)
  3 RETURN_VALUE


On Fri, Jan 19, 2018 at 3:46 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:

> I have encountered the following difference between Python 3 and 2:
>
> (py3)
> >>> compile('xxx', '<>', 'eval').co_code
> b'e\x00S\x00'
>
> (py2)
> >>> compile('xxx', '<>', 'eval').co_code
> 'e\x00\x00S'
>
> Note that 'S' (the code for RETURN_VALUE) and a zero byte are swapped
> in Python 2 compared to Python 3.  Is this change documented
> somewhere?
> ___
> 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/
> guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
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] Unexpected bytecode difference

[Alexander Belopolsky]

On Fri, Jan 19, 2018 at 7:01 PM, Guido van Rossum  wrote:
> Presumably because Python 3 switched to wordcode. Applying dis.dis() to
> these code objects results in the same output.
>
 dis.dis(c)
>   0 LOAD_NAME   0 (0)
>   3 RETURN_VALUE

I expected these changes to be documented at
, but the EXTENDED_ARG
section, for example, is the same in the 2 and 3 versions and says
that the default argument is two bytes.
___
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] Unexpected bytecode difference

[Victor Stinner]

It seems like the EXTENDED_ARG doc wasn't updated.

Victor

2018-01-20 1:07 GMT+01:00 Alexander Belopolsky :
> On Fri, Jan 19, 2018 at 7:01 PM, Guido van Rossum  wrote:
>> Presumably because Python 3 switched to wordcode. Applying dis.dis() to
>> these code objects results in the same output.
>>
> dis.dis(c)
>>   0 LOAD_NAME   0 (0)
>>   3 RETURN_VALUE
>
> I expected these changes to be documented at
> , but the EXTENDED_ARG
> section, for example, is the same in the 2 and 3 versions and says
> that the default argument is two bytes.
> ___
> 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/victor.stinner%40gmail.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

Re: [Python-Dev] Positional-only parameters in Python

[Terry Reedy]

On 1/19/2018 4:49 PM, Mario Corchero wrote:
I am happy to put some work into this (and Pablo Galindo in CC offered 
to pair on it) but it is not clear for me whether the next step is 
drafting a new PEP or this is just blocked on "re-evaluating" the 
current one.


If someone can clarify we can put something together.


My understanding is that extending the current use of '/' has already 
been approved in principle. I personally think that this just needs an 
issue, if there is not one already, and a PR.  I think we need that, or 
the effort to produce one, to reveal any remaining issues.


--
Terry Jan Reedy

___
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] Positional-only parameters in Python

[Guido van Rossum]

Not so fast. I think a PEP is still needed. This change has more
repercussions than argument clinic, e.g. it affects 3rd party tooling and
bytecode.

On Jan 19, 2018 17:00, "Terry Reedy"  wrote:

> On 1/19/2018 4:49 PM, Mario Corchero wrote:
>
>> I am happy to put some work into this (and Pablo Galindo in CC offered to
>> pair on it) but it is not clear for me whether the next step is drafting a
>> new PEP or this is just blocked on "re-evaluating" the current one.
>>
>> If someone can clarify we can put something together.
>>
>
> My understanding is that extending the current use of '/' has already been
> approved in principle. I personally think that this just needs an issue, if
> there is not one already, and a PR.  I think we need that, or the effort to
> produce one, to reveal any remaining issues.
>
> --
> Terry Jan Reedy
>
> ___
> 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/guido%
> 40python.org
>
___
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] Unexpected bytecode difference

[Joe Jevnik via Python-Dev]

As a general rule, you should not expect the bytecode to be the same
between different versions of CPython, including minor version changes. For
example, the instructions for dictionary literals are different in 3.4,
3.5, and 3.6.

On Fri, Jan 19, 2018 at 6:54 PM, Victor Stinner 
wrote:

> Python bytecode format changed deeply in Python 3.6. It now uses
> regular units of 2 bytes, instead of 1 or 3 bytes depending if the
> instruction has an argument.
>
> See for example https://bugs.python.org/issue26647 "wordcode".
>
> But CALL_FUNCTION bytecode also evolved.
>
> Victor
>
> 2018-01-20 0:46 GMT+01:00 Alexander Belopolsky <
> alexander.belopol...@gmail.com>:
> > I have encountered the following difference between Python 3 and 2:
> >
> > (py3)
>  compile('xxx', '<>', 'eval').co_code
> > b'e\x00S\x00'
> >
> > (py2)
>  compile('xxx', '<>', 'eval').co_code
> > 'e\x00\x00S'
> >
> > Note that 'S' (the code for RETURN_VALUE) and a zero byte are swapped
> > in Python 2 compared to Python 3.  Is this change documented
> > somewhere?
> > ___
> > 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/
> victor.stinner%40gmail.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/
> joe%40quantopian.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

Re: [Python-Dev] Exposing different versions of a system call in Python

[Nick Coghlan]

On 20 January 2018 at 02:32, Random832  wrote:
> On Fri, Jan 19, 2018, at 04:28, Pablo Galindo Salgado wrote:
>> On the other side, we have pipe and pipe2 as an example of exposing two
>> versions when this situation happens.
>>
>> The question is:
>>
>> What is preferable, exposing both functions or augment the old one?
>
> A large number, possibly a majority, of system calls in the os module, have 
> "dir_fd" arguments that cause them to call the *at counterpart of the 
> underlying system call. And chdir can also be called with a file descriptor, 
> which will call fchdir (though there is also a fchdir function) I don't know 
> why pipe2 was implemented as a separate call.

I think it's mainly just that our design philosophy on this front has
changed over time, and os.pipe2 was added back in 2011. These days,
the preference is more strongly in favour of amending the existing API
if Python offers relevant features that let us hide the existence of
multiple distinct APIs at the OS level.

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] Drop support for old unsupported FreeBSD and Linux kernels?

[Nick Coghlan]

On 19 January 2018 at 16:04, Nathaniel Smith  wrote:
> On Thu, Jan 18, 2018 at 12:27 PM, Victor Stinner
>  wrote:
>> CPython still has compatibility code for Linux 2.6, whereas the
>> support of Linux 2.6.x ended in August 2011, longer than 6 years ago.
>> Should we also drop support for old Linux kernels? If yes, which ones?
>> The Linux kernel has LTS version, the oldest is Linux 3.2 (support
>> will end in May, 2018).
>>
>> Linux kernel support:
>>
>>   https://www.kernel.org/category/releases.html
>
> RHEL 5 uses 2.6.28, and still has "extended life cycle support" until
> 2020, but I guess no-one should be running Python 3.7 on that. CentOS
> 6 and RHEL 6 use 2.6.32, and their EOL is also 2020 (or 2024 for RHEL
> 6 with extended life cycle support). Redhat does ship and support 3.6
> on CentOS/RHEL 6 through their "software collections" product, and
> presumably is planning to do the same for 3.7.
>
> It is a little surprising to see a Redhat employee suggest dropping
> support for RHEL 6. Hopefully you know what you're doing :-)

Red Hat's kernel version numbers describe the *oldest* code in that
kernel, rather than the newest. So if Red Hat customers want to run a
new version of CPython on an older version of RHEL, and the new
version of CPython needs a particular kernel feature, then that turns
into a backport request for that kernel capability (e.g. while there
were multiple drivers for Red Hat backporting the getrandom() syscall
the RHEL 7's 3.10 kernel, CPython was one of them:
https://bugzilla.redhat.com/show_bug.cgi?id=133)

So I think it makes sense to base python-dev's Linux kernel support
policy on the community LTS streams for the Linux kernel - if a
commercial Python vendor chooses to go beyond those dates they can,
just as they may go beyond python-dev's nominal support dates for
CPython itself.

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] Exposing different versions of a system call in Python

[Terry Reedy]

On 1/19/2018 11:06 PM, Nick Coghlan wrote:

On 20 January 2018 at 02:32, Random832  wrote:

On Fri, Jan 19, 2018, at 04:28, Pablo Galindo Salgado wrote:

On the other side, we have pipe and pipe2 as an example of exposing two
versions when this situation happens.

The question is:

What is preferable, exposing both functions or augment the old one?


I personally find a new parameter easier to remember than a new 
function, which will also have the new parameter.


--
Terry Jan Reedy

___
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] Positional-only parameters in Python

[Nick Coghlan]

On 20 January 2018 at 07:49, Mario Corchero  wrote:
> I am happy to put some work into this (and Pablo Galindo in CC offered to
> pair on it) but it is not clear for me whether the next step is drafting a
> new PEP or this is just blocked on "re-evaluating" the current one.

I think that would be a question for Larry, since there are two main
options here:

- proposing just the "/" part of PEP 457 (which allows positional-only
arguments, but doesn't allow the expression of all builtin and
standard library signatures)
- proposing the full PEP 547, including the "argument groups" feature
(which is a bigger change, but allows the expression of signatures
like "range([start,] stop, [step,] /)")

One key benefit I'd see to a new subset-of-457 PEP is that it would
allow a decision to be made on the basic "/" proposal without deciding
one way or the other on whether or not to provide a native way to
express signatures like the one for range().

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] Positional-only parameters in Python

[Guido van Rossum]

On Fri, Jan 19, 2018 at 8:47 PM, Nick Coghlan  wrote:

> On 20 January 2018 at 07:49, Mario Corchero  wrote:
> > I am happy to put some work into this (and Pablo Galindo in CC offered to
> > pair on it) but it is not clear for me whether the next step is drafting
> a
> > new PEP or this is just blocked on "re-evaluating" the current one.
>
> I think that would be a question for Larry,
>

I think you meant for Guido. It's not Larry's language (yet :-).


> since there are two main options here:
>
> - proposing just the "/" part of PEP 457 (which allows positional-only
> arguments, but doesn't allow the expression of all builtin and
> standard library signatures)
> - proposing the full PEP 547,
>

I assume you meant PEP 457 again. :-)


> including the "argument groups" feature
> (which is a bigger change, but allows the expression of signatures
> like "range([start,] stop, [step,] /)")
>
> One key benefit I'd see to a new subset-of-457 PEP is that it would
> allow a decision to be made on the basic "/" proposal without deciding
> one way or the other on whether or not to provide a native way to
> express signatures like the one for range().


I personally don't think such signatures are common enough to warrant
special syntax, and I don't want to encourage them. The few we have
(basically range(), slice() and a few functions in the curses module) don't
inspire a lot of copy-cat APIs.

OTOH the more plain positional-only arguments are a pretty common need --
for example, for methods that are conventionally used that way, and
overridden with disregard for argument names.

(IOW I agree with you here. ;-)

-- 
--Guido van Rossum (python.org/~guido)
___
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] Positional-only parameters in Python

[Larry Hastings]

On 01/19/2018 08:47 PM, Nick Coghlan wrote:

- proposing the full PEP 547, including the "argument groups" feature
(which is a bigger change, but allows the expression of signatures
like "range([start,] stop, [step,] /)")


I hope we don't go down that route.

I added support for "argument groups" to Argument Clinic in an attempt 
to support legacy functions with crazy argument signatures that count 
their arguments.  (For example, curses.window.overlay() takes either one 
or seven arguments exactly--not two!, and not six!.)  I have deeply 
mixed feelings about the result, and I would hate to see support for it 
added to the language.  If I had my way I'd rewrite or replace those 
functions and have only modern Pythonic signatures in the standard library.



//arry/
___
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