Re: [Python-Dev] 3.4.2rc1 online docs: cannot access tkinter, idle pages

[Terry Reedy]

On 10/5/2014 11:13 PM, Chris Angelico wrote:

On Mon, Oct 6, 2014 at 6:49 AM, Terry Reedy  wrote:

I can access every page I have tried except for the tkinter and idle pages,
which either give interminable 'Connecting...' or in one try, 404.
https://docs.python.org/3/library/tkinter.html
https://docs.python.org/3/library/idle.html


Is this still the case? I just tried them and they work for me.


Me too, now.

--
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] bytes-like objects

[Nick Coghlan]

On 6 October 2014 10:15, Greg Ewing  wrote:
> I wrote:
>
>>> But you can't
>>> create an object that supports the buffer protocol by implementing
>>> Python methods.
>
>
> Another thing is that an object implementing the buffer
> interface doesn't have to look anything at all like a
> bytes object from Python, so calling it "bytes-like"
> could be rather confusing.

"bytes-like object" is already used that way - e.g. memoryview is a
bytes-like object, as is array.arrray. Even numpy.ndarray, PIL images,
etc can all be accessed as bytes-like objects.

The term itself isn't new - we've been using it to progressively
eliminate awkward docs references to "objects that support the buffer
protocol" for years. David's post was just to say that the process of
adopting it is now largely complete, as the exception messages that
mentioned the buffer protocol have also been updated.

As near as I can figure out, some of the the reasons it appears to
work better than relying on the "buffer" term include:

1. Anyone learning Python 3 will know "bytes", and "A bytes-like
object is one that can be treated like a bytes object by adapting it
with memoryview" is a relatively simple step to take (although we
could likely be more explicit about that in the glossary entry).
2. When reporting errors, it conveys more clearly that passing a bytes
object will work, since the assumption that "bytes instances are bytes
like objects" is both obvious and correct. It also isn't too hard to
figure out that "str instances are not bytes like objects". With those
two figured out as category anchors, it becomes easier to start
grouping other types by comparing them with the two archetypal
examples. By contrast, is not *at all* obvious why bytes supports the
buffer protocol, while str does not.
3. "buffer" is a completely new term for most users, and one that
refers to an implementation detail of memoryview, moreso than
something developers actually need to care about. Using it directly in
error messages and documentation is to make the abstraction leak in a
way that raises unnecessary barriers to entry.
4. As a term, "buffer" in Python 3 also suffers from meaning something
*different* from what the buffer builtin refers to in Python 2 (the
fact str implemented the buffer protocol in Python 2 doesn't help).

In many way, it's similar to "file-like object" - those vary wildly in
how much of the file API they support, based on underlying technical
details (like whether it's backed by a file descriptor or not, whether
it's a binary or text stream, whether it's seekable, etc). However, by
saying "file-like object", we make the interface easy to learn to use
productively, as there are some obvious immediate inclusions (like the
actual file objects returned by open()) and exclusions (like strings
and bytes objects). Navigating the grey area can then be postponed
until later (and for many users, it will never be necessary to
navigate it at all).

If anything, bytes-like object is *better* defined than file-like
object, since the one thing that is expected to work for *any*
bytes-like object is "raw_data = memoryview(obj)". Everything beyond
that is negotiable (including the rest of the bytes API, and whether
or not the object is immutable or not).

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] bytes-like objects

[Nick Coghlan]

On 6 October 2014 07:24, Greg Ewing  wrote:
> anatoly techtonik wrote:
>>
>> That's a cool stuff. `bytes-like object` is really a much better name for
>> users.
>
>
> I'm not so sure. Usually when we talk about an "xxx-like object" we
> mean one that supports a certain Python interface, e.g. a "file-like
> object" is one that has read() and/or write() methods. But you can't
> create an object that supports the buffer protocol by implementing
> Python methods.
>
> I'm worried that using the term "bytes-like object" will lead
> people to ask "What methods do I have to implement to make my
> object bytes-like?", to which the answer is "mu".

That's a defect in the language definition, which requires volunteers
willing and able to work through the task of defining and gathering
consensus around a Python level counterpart to PEP 3118 that works
across arbitrary Python implementations:
http://bugs.python.org/issue13797

Ideally the drive for this would come from the Cython, PyPy,
IronPython and Jython communities, as they would all likely benefit
from a C independent way to express support for the buffer protocol.
Enabling this level of flexibility in defining bytes-like objects is
likely to be a key step in extending deep array oriented programming
support from CPython to other Python implementations.

In the meantime, the answer to "How do I define a bytes-like type?" is:

1. Use the appropriate implementation specific buffer protocols; or
2. Inherit from an existing bytes-like type

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] bytes-like objects

[Greg Ewing]

I wrote:


But you can't
create an object that supports the buffer protocol by implementing
Python methods.


Another thing is that an object implementing the buffer
interface doesn't have to look anything at all like a
bytes object from Python, so calling it "bytes-like"
could be rather confusing.

--
Greg
___
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] bytes-like objects

[Nick Coghlan]

On 6 October 2014 07:32, Victor Stinner  wrote:
> Hi,
>
> I prefer "bytes-like" than "buffer protocol". By the way, is there a
> documentation in Python doc which explains "bytes-like" and maybe list most
> compatible types?

https://docs.python.org/3/glossary.html#term-bytes-like-object

It only specifically lists bytes, bytearray and memoryview.

It also links to the current formal definition of what constitutes a
bytes like object:
https://docs.python.org/3/c-api/buffer.html#bufferobjects

memoryview.cast() offers a lot of capabilities to write interesting
buffer exporters in pure Python, but it's currently not possible as
there's no standard API defined for doing so:
http://bugs.python.org/issue13797

PyPy created a private Python level protocol to allow bytes-like
objects to be defined in RPython, but their approach hasn't been
proposed for standardisation (it's also not clear whether or not their
internal protocol offers the full range of features offered by PEP
3118).

> I'm not sure that the term has an unique definition. In some parts of
> Python, I saw explicit checks on the type: bytes or bytearray, sometimes
> memoryview is accepted. The behaviour is different in C functions using
> PyArg API. It probably depends if the function relies on the content (read
> bytes) or on methods (ex: call .find).

The core practical definition of a "bytes-like object" is whether or
not "memoryview(obj)" works. An object can be bytes like without
supporting the full bytes/bytearray API.

Some APIs that theoretically *could* accept arbitrary bytes like
objects are currently more limited - expanding those cases to accept
arbitrary bytes-like objects is generally considered a minor RFE
rather than a bug fix.

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] 3.4.2rc1 online docs: cannot access tkinter, idle pages

[Chris Angelico]

On Mon, Oct 6, 2014 at 6:49 AM, Terry Reedy  wrote:
> I can access every page I have tried except for the tkinter and idle pages,
> which either give interminable 'Connecting...' or in one try, 404.
> https://docs.python.org/3/library/tkinter.html
> https://docs.python.org/3/library/idle.html

Is this still the case? I just tried them and they work for me.

ChrisA
___
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] bytes-like objects

[David Wilson]

On Sun, Oct 05, 2014 at 11:32:08PM +0200, Victor Stinner wrote:

> I'm not sure that the term has an unique definition. In some parts of
> Python, I saw explicit checks on the type: bytes or bytearray,
> sometimes memoryview is accepted. The behaviour is different in C
> functions using PyArg API. It probably depends if the function relies
> on the content (read bytes) or on methods (ex: call .find).

Buffers aren't "bytes like" in that many of them aren't immutable, even
when the buffer object itself is hashable. An example of this is the
buffer exposed by mmap.mmap() with MAP_SHARED.

This came up during the StringIO optimization changes a few months back,
it seems some oversight in the original design that got carried through
to Python 3. If we're approaching the topic of defining bytes-like
things with improved rigor, it might be worth discussing.


Making bytes-like objects an explicit thing in the language feels like
solidifying what is mostly a CPython implementation detail. For example,
at least until recently, PyPy emulated buffers in ways that often made
them much slower to use than regular bytes.

Another aspect is that the ability to twiddle bits derived from a
buffer mostly implies that the code you are calling is going to always
be written in C, or its future implementation will remain sufficiently
restricted as to always accept buffers (perhaps by first copying them to
bytes -- exactly what PyPy did until recently).


+1 on improving the notion of bytes-like things in Python, but not
necessarily by concretizing the existing interface.


David
> 
> 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/dw%2Bpython-dev%40hmmz.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] bytes-like objects

[Serhiy Storchaka]

On 06.10.14 00:24, Greg Ewing wrote:

anatoly techtonik wrote:

That's a cool stuff. `bytes-like object` is really a much better name
for users.


I'm not so sure. Usually when we talk about an "xxx-like object" we
mean one that supports a certain Python interface, e.g. a "file-like
object" is one that has read() and/or write() methods. But you can't
create an object that supports the buffer protocol by implementing
Python methods.

I'm worried that using the term "bytes-like object" will lead
people to ask "What methods do I have to implement to make my
object bytes-like?", to which the answer is "mu".


Other (rarely used) alternatives are "buffer-like object" and 
"buffer-compatible object".


___
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] bytes-like objects

[Victor Stinner]

Hi,

I prefer "bytes-like" than "buffer protocol". By the way, is there a
documentation in Python doc which explains "bytes-like" and maybe list most
compatible types?

I'm not sure that the term has an unique definition. In some parts of
Python, I saw explicit checks on the type: bytes or bytearray, sometimes
memoryview is accepted. The behaviour is different in C functions using
PyArg API. It probably depends if the function relies on the content (read
bytes) or on methods (ex: call .find).

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

Re: [Python-Dev] bytes-like objects

[Greg Ewing]

anatoly techtonik wrote:

That's a cool stuff. `bytes-like object` is really a much better name for users.


I'm not so sure. Usually when we talk about an "xxx-like object" we
mean one that supports a certain Python interface, e.g. a "file-like
object" is one that has read() and/or write() methods. But you can't
create an object that supports the buffer protocol by implementing
Python methods.

I'm worried that using the term "bytes-like object" will lead
people to ask "What methods do I have to implement to make my
object bytes-like?", to which the answer is "mu".

--
Greg
___
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] 3.4.2rc1 online docs: cannot access tkinter, idle pages

[Terry Reedy]

I can access every page I have tried except for the tkinter and idle 
pages, which either give interminable 'Connecting...' or in one try, 404.

https://docs.python.org/3/library/tkinter.html
https://docs.python.org/3/library/idle.html

This is true from the index, previous/next from adjacent pages, and the 
index page

https://docs.python.org/3/library/tk.html

--
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] bytes-like objects

[anatoly techtonik]

That's a cool stuff. `bytes-like object` is really a much better name for users.
___
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] Weekly Python Patch/Bug Summary

[Lyndal]

Sent from my iPhone
___
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] bytes-like objects

[Georg Brandl]

On 10/05/2014 06:11 PM, R. David Murray wrote:
> Over the past while we've been cleaning up the docs in the area of "how
> do we refer to bytes, bytearray, memoryview, etc, etc?" in the APIs that
> deal with bytes.  As you may or may not remember, we settled on the term
> 'bytes-like object', and have changed the docs to (we hope) consistently
> use this term, which has a glossary entry most of the references to it
> link to.
> 
> I just committed (to 3.5) the final changes for issue 16518, the change
> to consistently using the term 'bytes-like object' for things that
> support the buffer interface.  This means that messages that previously
> read:
> 
> 'sometype' does not support the buffer interface
> 
> now read
> 
> a bytes-like object is required, not 'sometype'
> 
> The 'buffer interface' messages were rather confusing, since you have to
> dig to find out what the 'buffer interface' is.  It isn't any sort of
> python object, nor is there any object in python3 that has a name
> related to it.  'bytes-like object', on the other hand, is fairly
> intuitive[*], and if you look it up in the glossary it links to the
> explanation of the buffer interface.
> 
> We felt it was worth explicitly mentioning this patch on python-dev to point
> out to everyone that the docs and error messages now use a consistent
> terminology, instead of the mis-mash we had before, which should make it 
> easier
> to help people with issues where this comes up.
> 
> If there are objections to this change to the messages it is easy enough to
> back out, but personally I find the new error messages *much* clearer, and I'm
> an experienced dev.

I agree. Thanks for the effort you two!

Georg

___
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] bytes-like objects

[R. David Murray]

Over the past while we've been cleaning up the docs in the area of "how
do we refer to bytes, bytearray, memoryview, etc, etc?" in the APIs that
deal with bytes.  As you may or may not remember, we settled on the term
'bytes-like object', and have changed the docs to (we hope) consistently
use this term, which has a glossary entry most of the references to it
link to.

I just committed (to 3.5) the final changes for issue 16518, the change
to consistently using the term 'bytes-like object' for things that
support the buffer interface.  This means that messages that previously
read:

'sometype' does not support the buffer interface

now read

a bytes-like object is required, not 'sometype'

The 'buffer interface' messages were rather confusing, since you have to
dig to find out what the 'buffer interface' is.  It isn't any sort of
python object, nor is there any object in python3 that has a name
related to it.  'bytes-like object', on the other hand, is fairly
intuitive[*], and if you look it up in the glossary it links to the
explanation of the buffer interface.

We felt it was worth explicitly mentioning this patch on python-dev to point
out to everyone that the docs and error messages now use a consistent
terminology, instead of the mis-mash we had before, which should make it easier
to help people with issues where this comes up.

If there are objections to this change to the messages it is easy enough to
back out, but personally I find the new error messages *much* clearer, and I'm
an experienced dev.

(This work was done by Ezio Melotti, but I committed the final patch as
part of my quest to clear the 'commit review' queue in the tracker.)

--David

[*] the more esoteric cases are not often encountered in regular (as opposed to
NumPy) code, and when they are, the extension to "something that can be
interpreted as a sequence of bytes" is pretty straightforward conceptually.
___
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] Microsoft Visual C++ Compiler for Python 2.7

[Steve Dower]

If you update setuptools to 6.0 or later, it shouldn't have any trouble 
detecting it. No need to set any environment variables.

FWIW, I put my vcvarsall.bat where I did because it's not the original version. 
All the files in VC and WinSDK after unmodified from their original release.

Cheers,
Steve

Top-posted from my Windows Phone

From: Georg Brandl
Sent: ‎10/‎5/‎2014 3:23
To: python-dev@python.org
Subject: Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

I just tried out the compiler and built wininst and wheel dists. Thanks!

distutils was *almost* fine using it, but for two snags:

* I had to set VS90COMNTOOLS

* distutils expects vcvarsall.bat in VC, while you have it in the parent dir

The first could be set by the installer of your package.  But if it is not
feasible to do so, setting an envvar is something that developers can surely
be expected to do with instruction.

The second is a little more inconvenient.  Wouldn't it be possible to put
the .bat file in the "right" folder, or if it has to be there, put *another*
one in "VC"?  (That is what I did.)

cheers,
Georg

On 09/27/2014 05:16 PM, Steve Dower wrote:
> Plain distutils won't detect it. It would be easy enough to fix 2.7.9, but
> "update Python" is a big/impossible ask for a lot of people, whereas "update
> setuptools" is easy and also covers Python 2.6 and <3.3.
>
> The compiler installer can't set the keys that distutils looks for without
> losing the per-user installation, and it may also corrupt actual installs of
> Visual Studio. A monkey patch via setuptools was the best way to handle this -
> covers pip and Cython and can be ported to other libraries that care but avoid
> setuptools.
>
> Now that we have a patch, there's very limited value in fixing 2.7.9, IMO. But
> I'm willing to be convinced - we can always add a version check to the
> setuptools patch.
>
> Cheers,
> Steve


___
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/steve.dower%40microsoft.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] Microsoft Visual C++ Compiler for Python 2.7

[Georg Brandl]

I just tried out the compiler and built wininst and wheel dists. Thanks!

distutils was *almost* fine using it, but for two snags:

* I had to set VS90COMNTOOLS

* distutils expects vcvarsall.bat in VC, while you have it in the parent dir

The first could be set by the installer of your package.  But if it is not
feasible to do so, setting an envvar is something that developers can surely
be expected to do with instruction.

The second is a little more inconvenient.  Wouldn't it be possible to put
the .bat file in the "right" folder, or if it has to be there, put *another*
one in "VC"?  (That is what I did.)

cheers,
Georg

On 09/27/2014 05:16 PM, Steve Dower wrote:
> Plain distutils won't detect it. It would be easy enough to fix 2.7.9, but
> "update Python" is a big/impossible ask for a lot of people, whereas "update
> setuptools" is easy and also covers Python 2.6 and <3.3.
> 
> The compiler installer can't set the keys that distutils looks for without
> losing the per-user installation, and it may also corrupt actual installs of
> Visual Studio. A monkey patch via setuptools was the best way to handle this -
> covers pip and Cython and can be ported to other libraries that care but avoid
> setuptools.
> 
> Now that we have a patch, there's very limited value in fixing 2.7.9, IMO. But
> I'm willing to be convinced - we can always add a version check to the
> setuptools patch.
> 
> Cheers,
> Steve


___
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