Re: [Python-Dev] Reviving restricted mode?

[Nick Coghlan]

On 14 August 2014 07:25, Victor Stinner  wrote:
> Hi,
>
> I heard that PyPy sandbox cannot be used out of the box. You have to write a
> policy to allow syscalls. The complexity is moved to this policy which is
> very hard to write, especially if you only use whitelists.
>
> Correct me if I'm wrong. To be honest, I never take a look at this sandbox.

By default, the PyPy sandbox requires all system access to be proxied
through the host application (which is running in a separate process).
Similarly, using "sandbox" on Fedora (et al) will get you a default
deny OS level sandbox, where you have to provide selective access to
things outside the box.

The effective decision taken when rexec and Bastion were removed from
the standard library was "sandboxing is hard enough for operating
systems to get right, we're not going to try to tackle the even harder
problem of an in-process sandbox".

"Deny all" sandboxes are relatively easy, but also relatively useless.
It's "allow these activities, but no others" that's difficult, since
any kind of access can often be leveraged into greater access than was
intended.

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] Documenting enum types

[Victor Stinner]

Hi,

IMO we should not document enum types because Python implementations other
than CPython may want to implement them differently (ex: not all Python
implementations have an enum module currently). By experience, exposing too
many things in the public API becomes a problem later when you want to
modify the code.

Victor
Le 14 août 2014 07:47, "Serhiy Storchaka"  a écrit :

> Should new enum types added recently to collect module constants be
> documented at all? For example AddressFamily is absent in socket.__all__
> [1].
>
> [1] http://bugs.python.org/issue20689
>
> ___
> 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] Documenting enum types

[Nick Coghlan]

On 14 August 2014 19:25, Victor Stinner  wrote:
> Hi,
>
> IMO we should not document enum types because Python implementations other
> than CPython may want to implement them differently (ex: not all Python
> implementations have an enum module currently). By experience, exposing too
> many things in the public API becomes a problem later when you want to
> modify the code.

Implementations claiming conformance with Python 3.4 will have to have
an enum module - there just aren't any of those other than CPython at
this point (I expect PyPy3 will catch up before too long, since the
changes between 3.2 and 3.4 shouldn't be too dramatic from an
implementation perspective).

In this particular case, though, I think the relevant question is "Why
are they enums?" and the answer is "for the better representations".
I'm not clear on the use case for exposing and documenting the enum
types themselves (although I don't have any real objection either).

Regards,
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] Documenting enum types

[Guido van Rossum]

The enemy must be documented and exported, since users will encounter them.
On Aug 14, 2014 4:54 AM, "Nick Coghlan"  wrote:

> On 14 August 2014 19:25, Victor Stinner  wrote:
> > Hi,
> >
> > IMO we should not document enum types because Python implementations
> other
> > than CPython may want to implement them differently (ex: not all Python
> > implementations have an enum module currently). By experience, exposing
> too
> > many things in the public API becomes a problem later when you want to
> > modify the code.
>
> Implementations claiming conformance with Python 3.4 will have to have
> an enum module - there just aren't any of those other than CPython at
> this point (I expect PyPy3 will catch up before too long, since the
> changes between 3.2 and 3.4 shouldn't be too dramatic from an
> implementation perspective).
>
> In this particular case, though, I think the relevant question is "Why
> are they enums?" and the answer is "for the better representations".
> I'm not clear on the use case for exposing and documenting the enum
> types themselves (although I don't have any real objection either).
>
> Regards,
> 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/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] Documenting enum types

[Ben Hoyt]

> The enemy must be documented and exported, since users will encounter them.

enum == enemy? Is that you, Raymond? ;-)

-Ben
___
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] Documenting enum types

[Ethan Furman]

On 08/14/2014 08:51 AM, Ben Hoyt wrote:

The enemy must be documented and exported, since users will encounter them.


enum == enemy? Is that you, Raymond? ;-)


ROFL!  Thanks, I needed that!

:D

--
~Ethan~
___
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] Documenting enum types

[Mark Lawrence]

On 14/08/2014 17:14, Ethan Furman wrote:

On 08/14/2014 08:51 AM, Ben Hoyt wrote:


The BDFL actually wrote:-


The enemy must be documented and exported, since users will encounter
them.


QOTW.



enum == enemy? Is that you, Raymond? ;-)


ROFL!  Thanks, I needed that!

:D

--
~Ethan~


I'll be seeing the PSF in court, on the grounds that I've just bust a 
gut laughing :)


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
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 467: Minor API improvements for bytes & bytearray

[Nick Coghlan]

I just posted an updated version of PEP 467 after recently finishing
the updates to the Python 3.4+ binary sequence docs to decouple them
from the str docs.

Key points in the proposal:

* deprecate passing integers to bytes() and bytearray()
* add bytes.zeros() and bytearray.zeros() as a replacement
* add bytes.byte() and bytearray.byte() as counterparts to ord() for binary data
* add bytes.iterbytes(), bytearray.iterbytes() and memoryview.iterbytes()

As far as I am aware, that last item poses the only open question,
with the alternative being to add an "iterbytes" builtin with a
definition along the lines of the following:

def iterbytes(data):
try:
getiter = type(data).__iterbytes__
except AttributeError:
iter = map(bytes.byte, data)
else:
iter = getiter(data)
return iter

Regards,
Nick.

PEP URL: http://www.python.org/dev/peps/pep-0467/

Full PEP text:
=
PEP: 467
Title: Minor API improvements for bytes and bytearray
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2014-03-30
Python-Version: 3.5
Post-History: 2014-03-30 2014-08-15


Abstract


During the initial development of the Python 3 language specification, the
core ``bytes`` type for arbitrary binary data started as the mutable type
that is now referred to as ``bytearray``. Other aspects of operating in
the binary domain in Python have also evolved over the course of the Python
3 series.

This PEP proposes a number of small adjustments to the APIs of the ``bytes``
and ``bytearray`` types to make it easier to operate entirely in the binary
domain.


Background
==

To simplify the task of writing the Python 3 documentation, the ``bytes``
and ``bytearray`` types were documented primarily in terms of the way they
differed from the Unicode based Python 3 ``str`` type. Even when I
`heavily revised the sequence documentation
`__ in 2012, I retained that
simplifying shortcut.

However, it turns out that this approach to the documentation of these types
had a problem: it doesn't adequately introduce users to their hybrid nature,
where they can be manipulated *either* as a "sequence of integers" type,
*or* as ``str``-like types that assume ASCII compatible data.

That oversight has now been corrected, with the binary sequence types now
being documented entirely independently of the ``str`` documentation in
`Python 3.4+ 
`__

The confusion isn't just a documentation issue, however, as there are also
some lingering design quirks from an earlier pre-release design where there
was *no* separate ``bytearray`` type, and instead the core ``bytes`` type
was mutable (with no immutable counterpart).

Finally, additional experience with using the existing Python 3 binary
sequence types in real world applications has suggested it would be
beneficial to make it easier to convert integers to length 1 bytes objects.


Proposals
=

As a "consistency improvement" proposal, this PEP is actually about a few
smaller micro-proposals, each aimed at improving the usability of the binary
data model in Python 3. Proposals are motivated by one of two main factors:

* removing remnants of the original design of ``bytes`` as a mutable type
* allowing users to easily convert integer values to a length 1 ``bytes``
  object


Alternate Constructors
--

The ``bytes`` and ``bytearray`` constructors currently accept an integer
argument, but interpret it to mean a zero-filled object of the given length.
This is a legacy of the original design of ``bytes`` as a mutable type,
rather than a particularly intuitive behaviour for users. It has become
especially confusing now that some other ``bytes`` interfaces treat integers
and the corresponding length 1 bytes instances as equivalent input.
Compare::

>>> b"\x03" in bytes([1, 2, 3])
True
>>> 3 in bytes([1, 2, 3])
True

>>> bytes(b"\x03")
b'\x03'
>>> bytes(3)
b'\x00\x00\x00'

This PEP proposes that the current handling of integers in the bytes and
bytearray constructors by deprecated in Python 3.5 and targeted for
removal in Python 3.7, being replaced by two more explicit alternate
constructors provided as class methods. The initial python-ideas thread
[ideas-thread1]_ that spawned this PEP was specifically aimed at deprecating
this constructor behaviour.

Firstly, a ``byte`` constructor is proposed that converts integers
in the range 0 to 255 (inclusive) to a ``bytes`` object::

>>> bytes.byte(3)
b'\x03'
>>> bytearray.byte(3)
bytearray(b'\x03')
>>> bytes.byte(512)
Traceback (most recent call last):
  File "", line 1, in 
ValueError: bytes must be in range(0, 256)

One specific use case for this alternate construct