Re: [Python-Dev] [Speed] speed.python.org

[Gregory P. Smith]

Displaying ratios linearly rather than on a log scale axis can be
misleading depending on what you are looking for.  (feature request: allow
a log scale?)

major kudos to everyone involved in getting this setup!

On Fri, Feb 5, 2016 at 11:06 PM Nick Coghlan  wrote:

> On 6 February 2016 at 04:07, Brett Cannon  wrote:
> > On Thu, 4 Feb 2016 at 05:46 Nick Coghlan  wrote:
> >> Heh, cdecimal utterly demolishing the old pure Python decimal module
> >> on the telco benchmark means normalising against CPython 3.5 rather
> >> than 2.7 really isn't very readable :)
> >
> > I find viewing the graphs using the horizontal layout is much easier to
> read
> > (the bars are a lot thicker and everything zooms in more).
>
> That comment was based on the horizontal layout - the telco benchmark
> runs ~53x faster in Python 3 than it does in Python 2 (without
> switching to cdecimal), so you end up with all the other benchmarks
> being squashed into the leftmost couple of grid cells.
>
> 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/greg%40krypto.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] PEP 0492 __aenter__ & __aexit__

[Brett Cannon]

On Sat, 6 Feb 2016 at 13:50 Daniel Miller  wrote:

> Hi Python-Dev Group,
>
> I am trying to implement __aenter__ and __aexit__ for the RethinkDB
>  Python driver. Looking at the PEP I don't see any
> definitions as to what the expected parameters that __exit__ are supposed
> to take and couldn't find any other similar implementations. Is there a
> piece of documentation I should be looking at that I'm missing?
>
>
> https://www.python.org/dev/peps/pep-0492/#asynchronous-context-managers-and-async-with
>

The arguments to __aexit__ are the same as __exit__ in a normal context
manager. See
https://docs.python.org/3.5/reference/datamodel.html#object.__aexit__ for
the official docs for __aexit__.
___
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] PEP 0492 __aenter__ & __aexit__

[Daniel Miller]

Hi Python-Dev Group,

I am trying to implement __aenter__ and __aexit__ for the RethinkDB
 Python driver. Looking at the PEP I don't see any
definitions as to what the expected parameters that __exit__ are supposed
to take and couldn't find any other similar implementations. Is there a
piece of documentation I should be looking at that I'm missing?

https://www.python.org/dev/peps/pep-0492/#asynchronous-context-managers-and-async-with

Many thanks,

Daniel
___
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] PEP 514: Python environment registration in the Windows Registry

[Steve Dower]

I've posted an updated version of this PEP that should soon be visible at 
https://www.python.org/dev/peps/pep-0514.

Leaving aside the fact that the current implementation of Python relies on 
*other* information in the registry (that is not specified in this PEP), I'm 
still looking for feedback or concerns from developers who are likely to create 
or use the keys that are described here.



PEP: 514
Title: Python registration in the Windows registry
Version: $Revision$
Last-Modified: $Date$
Author: Steve Dower 
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 02-Feb-2016
Post-History: 02-Feb-2016

Abstract


This PEP defines a schema for the Python registry key to allow third-party
installers to register their installation, and to allow applications to detect
and correctly display all Python environments on a user's machine. No
implementation changes to Python are proposed with this PEP.

Python environments are not required to be registered unless they want to be
automatically discoverable by external tools.

The schema matches the registry values that have been used by the official
installer since at least Python 2.5, and the resolution behaviour matches the
behaviour of the official Python releases.

Motivation
==

When installed on Windows, the official Python installer creates a registry key
for discovery and detection by other applications. This allows tools such as
installers or IDEs to automatically detect and display a user's Python
installations.

Third-party installers, such as those used by distributions, typically create
identical keys for the same purpose. Most tools that use the registry to detect
Python installations only inspect the keys used by the official installer. As a
result, third-party installations that wish to be discoverable will overwrite
these values, resulting in users "losing" their Python installation.

By describing a layout for registry keys that allows third-party installations
to register themselves uniquely, as well as providing tool developers guidance
for discovering all available Python installations, these collisions should be
prevented.

Definitions
===

A "registry key" is the equivalent of a file-system path into the registry. Each
key may contain "subkeys" (keys nested within keys) and "values" (named and
typed attributes attached to a key).

``HKEY_CURRENT_USER`` is the root of settings for the currently logged-in user,
and this user can generally read and write all settings under this root.

``HKEY_LOCAL_MACHINE`` is the root of settings for all users. Generally, any
user can read these settings but only administrators can modify them. It is
typical for values under ``HKEY_CURRENT_USER`` to take precedence over those in
``HKEY_LOCAL_MACHINE``.

On 64-bit Windows, ``HKEY_LOCAL_MACHINE\Software\Wow6432Node`` is a special key
that 32-bit processes transparently read and write to rather than accessing the
``Software`` key directly.

Structure
=

We consider there to be a single collection of Python environments on a machine,
where the collection may be different for each user of the machine. There are
three potential registry locations where the collection may be stored based on
the installation options of each environment::

HKEY_CURRENT_USER\Software\Python\\
HKEY_LOCAL_MACHINE\Software\Python\\
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\\

Environments are uniquely identified by their Company-Tag pair, with two options
for conflict resolution: include everything, or give priority to user
preferences.

Tools that include every installed environment, even where the Company-Tag pairs
match, should ensure users can easily identify whether the registration was
per-user or per-machine.

Tools that give priority to user preferences must ignore values from
``HKEY_LOCAL_MACHINE`` when a matching Company-Tag pair exists is in
``HKEY_CURRENT_USER``.

Official Python releases use ``PythonCore`` for Company, and the value of
``sys.winver`` for Tag. Other registered environments may use any values for
Company and Tag. Recommendations are made in the following sections.

Python environments are not required to register themselves unless they want to
be automatically discoverable by external tools.

Backwards Compatibility
---

Python 3.4 and earlier did not distinguish between 32-bit and 64-bit builds in
``sys.winver``. As a result, it is possible to have valid side-by-side
installations of both 32-bit and 64-bit interpreters.

To ensure backwards compatibility, applications should treat environments listed
under the following two registry keys as distinct, even when the Tag matches::

HKEY_LOCAL_MACHINE\Software\Python\PythonCore\
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\PythonCore\

Environments listed under ``HKEY_CURRENT_USER`` may be treated as distinct from
both of the above keys, potentially resulting in three environments discovered
using the same T

Re: [Python-Dev] More optimisation ideas

[Stephen Hansen]

On Fri, Feb 5, 2016, at 10:33 AM, Emile van Sebille wrote:
> On 2/5/2016 9:37 AM, Alexander Walters wrote:
> >
> > On 2/5/2016 12:27, Emile van Sebille wrote:
> >> On 2/1/2016 9:20 AM, Ethan Furman wrote:
> >>> On 02/01/2016 08:40 AM, R. David Murray wrote:
> >> 
>  On the other hand, if the distros go the way Nick has (I think) been
>  advocating, and have a separate 'system python for system scripts' that
>  is independent of the one installed for user use, having the
>  system-only
>  python be frozen and sourceless would actually make sense on a
>  couple of
>  levels.
> >>>
> >>> Agreed.
> >>
> >> Except for that nasty licensing issue requiring source code.
> >>
> >> Emile
> > Licensing requires, in the GPL at least, that the *modified* sources be
> > made *available*, not that they be shipped with the product. Looking at
> > the Python license, and what tools already do, there is zero need to
> > ship the source to stay compliant.
> 
> Hmm, the annotated Open Source Definition explicitly states "The program 
> must include source code" -- how did I misinterpret that?

Couple things.

First, the OSD is not authoritative. Python's license establishes the
rules of its distribution: that Python's license is considered
compatible with the OSD doesn't actually mean your reading of anything
on the OSD page as having any binding meaning.

Second, OSD's Rule 2 means that those who are distributing Python -- the
PSF, originally -- must provide source code if they're distributing it
under Python's license, but it doesn't actually mean it must be packaged
with it in every download. In fact, its not today. The standard library
source is included in normal downloads, but the C source of Python
isn't. But you can download it readily though, so that's fine. Its fully
compliant with the OSD.

But! If Debian (pulling them out of a hat randomly) is distributing
Python, they aren't the PSF, and notably are not bound by the OSD rules,
only by Python's license terms. The PSF satisfied their requirements to
the licensing terms when releasing Python, but now Debian has Python,
and they are distributing it-- that's an entirely separate act, and you
must look at them as a separate actor in terms of the license. They
don't have to distribute it in the same license. They must be ABLE to
(as OSD's Rule 3 says), but they don't HAVE to. Some random person can
take Python, rename it Snakey, and release it under almost any license
they want and give no one the source code at all. 

Python has from the beginning allowed this:its actually in quite a few
closed source / proprietary products without ever advertising it and
providing no source, entirely legally and ethically -- Python's gone out
of its way to support this sort of use-case. 

As it happens, Debian usually distributes something very close to the
official release (sometimes they backport patches and such), and always
does so under the same license as Python (AFAICT), but they don't *have*
to. 

GPL is copyleft and requires its derivative works to be GPL'd (or at
least, no more restrictive then GPL)-- so in GPL, to distribute it you
MUST distribute it under GPL-compatible terms. Python is a permissive
license and allows anyone to do basically anything, INCLUDING produce
closed source releases if someone wanted to, or just release
modifications or modules that are available under different licenses. 

The OSD encompasses both ends of the spectrum: the GPL's mandate of
source access and the OSD's mandate of the receiver to be able to
distribute in the same terms they received (notably, NOT the same terms
it was originally released under).

-- 
Stephen Hansen
  m e @ i x o k a i  . i o
___
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] Licensing issue (?) for Frozen Python? [was: More optimisation ideas]

[Barry Warsaw]

On Feb 06, 2016, at 04:38 PM, Chris Angelico wrote:

>Right, sure. The technical problems are still there. Although I'm
>fairly confident that Debian's binaries would correspond to Debian's
>source - but honestly, if I'm looking for sources for anything other
>than the kernel, I probably want to get the latest from source
>control, rather than using the somewhat older version shipped in the
>repos.
>
>As to availability, though, most of the big distros (including Debian)
>keep their sources around for a long time.

Not to get too deep into what other projects do, but yes in Debian, you can
always get the patched source that corresponds to the binary you've
installed, usually in both version controlled form and otherwise.  I'd expect
this to be true of most if not all of the Linux distros.

A more interesting question is how you can actually verify this equivalence,
and there are folks across the ecosystem working on reproducible builds.  The
idea is that you should be able to take the source that *claims* to correspond
to that binary, and using the established build tools, locally reproduce a
bit-wise exact duplicate of the binary.  I've applied and submitted several
patches to various upstreams that help with this effort, such as being able to
pass in "locked" datetimes instead of the package always using
e.g. datetime.now().

Let's not dive down the rabbit hole too far into how you can trust your build
tool chain, and every other layer down to the quantum.

Cheers,
-Barry
___
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