[issue1753718] base64 "legacy" functions violate RFC 3548

[Martin Panter]

Martin Panter added the comment:

Uploaded a Python 3 patch to Issue 22088 which includes the doc string changes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[Martin Panter]

Martin Panter added the comment:

I was waiting for you to finish here to avoid any new merge conflicts. Now that 
you have committed your patch, I will try and work on mine in the next few 
days, and I am happy to update the doc strings at the same time.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[R. David Murray]

R. David Murray added the comment:

Thanks everyone.

--
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[Roundup Robot]

Roundup Robot added the comment:

New changeset 105bf5dd93b8 by R David Murray in branch '3.5':
#1753718: clarify RFC compliance and bytes/string argument types.
https://hg.python.org/cpython/rev/105bf5dd93b8

New changeset 92760d2edc9e by R David Murray in branch 'default':
Merge: #1753718: clarify RFC compliance and bytes/string argument types.
https://hg.python.org/cpython/rev/92760d2edc9e

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

While we are here, may be update docstrings too?

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[Martin Panter]

Martin Panter added the comment:

I understood “bytes-like” to mean what is now defined in the glossary: what is 
accepted by the C-level y* format for the PyArg parsing functions. I tend to 
agree with  that it may not have 
been the best term to choose when you really mean “C-contiguous buffer”.

I am understanding that you take “bytes-like” to be a more specific thing. 
Perhaps we could instead have two distinct terms, say “C-contiguous buffer”, 
which is what FileIO.write() and PyArg supports, and “byte sequence”, perhaps 
implementing an API common to bytes() and memoryview(), which is easier to work 
with using native Python.

In general, I think ctypes and array.array produce my stricter kind of 
C-contiguous buffers. But since Issue 15944 native Python code can access these 
buffers by casting to a second memoryview:

>>> c = ctypes.c_char(b"A")
>>> with memoryview(c) as array_view, array_view.cast("B") as byte_view:
... print(repr(byte_view[0]))
... 
65

Nick’s commit d90f25e1a705 mentions multi-dimensional input for the “modern” 
interface. That is not the problem. In 
 he decided to be less permissive 
for the “legacy” interface, which seems unnecessary to me.

Anyway, this is all rather off-topic. Apart from the bytes-like errors, the 
rest of the current patch is good. Even if you committed with those four 
errors, I can live with that. I think there are similar problems elsewhere in 
the documentation, HTTPConnection.request() over TLS for instance.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[R. David Murray]

R. David Murray added the comment:

The term "bytes-like object" is specifically designed for those situations 
where python used to say "X does not support the buffer interface" if passed 
something else.  Which is the case here...now it says "a bytes-like object is 
required".  I'm not sure if we fixed that everywhere, but I think we did.  It 
is certainly true in the cases you cite, except that it turns out that 
ignorechars accepts an ASCII string.

So, if there is any sort of remaining problem, it is a separate issue: my edits 
match the current error message behavior.  I'll fix ignorechars and commit.

--
stage: patch review -> commit review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[R. David Murray]

R. David Murray added the comment:

The altchars 2 char limit is an assertion.  That's a bug that should be dealt 
with separately.  Either it should be turned into an error, or it should be 
dropped to match the docs.  Probably the latter, since it is documented as OK 
and it might break code that is currently working in -O mode or on python2.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[R. David Murray]

R. David Murray added the comment:

Fixed the spurious 'u'.

--
Added file: http://bugs.python.org/file41343/issue-01753718.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[R. David Murray]

R. David Murray added the comment:

"or on python2" should be "or ported from python2".

Also note that Nick's commit message specifically mentions a test for 
multi-dimensional input, so the module does indeed conform to the current 
bytes-like object definition in that regard.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[R. David Murray]

R. David Murray added the comment:

The intent of the term "bytes-like object" it to make it possible to use it in 
documentation in the way I have used it here.  That the buffer has a len is 
clearly discussed in the Buffer Protocol documentation, but of course that's 
only talking about the C level API.  Perhaps what is needed is an addition to 
the bytes-like object description that clarifies that a bytes-like object is a 
Sequence that supports the buffer protocol?  (So: "A Sequence object that 
supports the Buffer Protocol and...")  Do we also need to clarify that the item 
size must be one byte?  That would seem to me to be implicit in the name.

I don't know if what ctypes produces is a bytes-like object in this sense, 
since I don't understand ctypes very well, but it sounds like it isn't.  Trying 
to wrap it in a memoryview gives an error ('unsupported format 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[R. David Murray]

R. David Murray added the comment:

Updated patch that addresses most of the comments.

--
Added file: http://bugs.python.org/file41325/issue-01753718.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[R. David Murray]

Changes by R. David Murray :


--
versions:  -Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[R. David Murray]

R. David Murray added the comment:

How about we just make the docs more correct and say that input is read until 
readline() returns an empty bytes object?  That should make it clear that a 
line-oriented file is expected.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[R. David Murray]

R. David Murray added the comment:

Updated patch.

--
Added file: http://bugs.python.org/file41306/issue-01753718.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[Martin Panter]

Martin Panter added the comment:

The change to readline() works well.

Any thoughts regarding my other comments? In particular, altchars and 
ignorechars cannot be arbitrary bytes-like objects.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[R. David Murray]

R. David Murray added the comment:

I missed the other comments somehow.  Will take a look soon.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[Martin Panter]

Martin Panter added the comment:

Left some review comments. I left a comment about the original patch as well, 
because I didn’t notice the new patch in time :)

Also, maybe we should say the input to the “legacy” MIME decode() function 
should be multiple lines, since it calls readline() with no line limit.

--
nosy: +martin.panter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[R. David Murray]

R. David Murray added the comment:

I started tweaking this patch, and wound up going through the whole doc and 
fixing the references to 'byte string' and 'string' throughout, as well as 
making all the entries consistent in how they reference the function arguments 
and output (previously some did not reference the output at all, nor was it 
clear that the output is always bytes).  I believe I also clarified some 
confusing wordings along the way.

Since there are so many changes I need some eyes checking my work before I 
commit.

Note that the primary motivation for this change (the incorrect claim that both 
interfaces supported the RFC) is not made by the 2.7 docs, and since those docs 
are very different now, I don't plan to touch them.

--
stage:  -> patch review
Added file: http://bugs.python.org/file41296/issue-01753718.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[R. David Murray]

R. David Murray added the comment:

See also the discussion in issue 25495.  I will try to review both of these 
issues soon.

--
nosy: +r.david.murray
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.1, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 "legacy" functions violate RFC 3548

[Isobel Hooper]

Isobel Hooper added the comment:

Attached patch fixes library/base64.rst as requested, and adds a mention of RFC 
3548 into the b2a_base64() docs in library/binascii.rst.

I'm not sure I've made the changes against the right version of the docs - I 
think this might be against the 3.3 docs.

--
keywords: +patch
nosy: +Isobel Hooper
Added file: http://bugs.python.org/file41250/issue-1753718.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 legacy functions violate RFC 3548

[Mark Lawrence]

Changes by Mark Lawrence breamore...@yahoo.co.uk:


--
assignee: barry - d...@python
nosy: +d...@python
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1753718
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 legacy functions violate RFC 3548

[Terry J. Reedy]

Changes by Terry J. Reedy tjre...@udel.edu:


--
versions:  -Python 2.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1753718
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1753718] base64 legacy functions violate RFC 3548

[Christian Heimes]

Changes by Christian Heimes:


--
versions: +Python 2.5, Python 2.6

_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1753718
_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com