Roundup Robot added the comment:
New changeset d7950e916f20 by R David Murray in branch '3.3':
#7475: Remove references to '.transform' from transform codec docstrings.
http://hg.python.org/cpython/rev/d7950e916f20
New changeset 83d54ab5c696 by R David Murray in branch 'default':
Merge #7475:
Serhiy Storchaka added the comment:
Docstrings for new codecs mention bytes.transform() and bytes.untransform()
which are nonexistent.
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
Changes by Jakub Wilk jw...@jwilk.net:
--
nosy: +jwilk
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Python-bugs-list mailing list
Nick Coghlan added the comment:
The 3.4 portion of issue 19619 has been addressed, so removing it as a
dependency again.
--
dependencies: -Blacklist base64, hex, ... codecs from bytes.decode() and
str.encode()
___
Python tracker
Nick Coghlan added the comment:
With issue 19619 resolved for Python 3.4 (the issue itself remains open
awaiting a backport to 3.3), Victor has softened his stance on this topic and
given the go ahead to restore the codec aliases:
http://bugs.python.org/issue19619#msg203897
I'll be
Roundup Robot added the comment:
New changeset 5e960d2c2156 by Nick Coghlan in branch 'default':
Close #7475: Restore binary text transform codecs
http://hg.python.org/cpython/rev/5e960d2c2156
--
nosy: +python-dev
resolution: - fixed
stage: - committed/rejected
status: open - closed
Nick Coghlan added the comment:
Note that I still plan to do a documentation-only PEP for 3.4, proposing some
adjustments to the way the codecs module is documented, making binary and test
transform defined terms in the glossary, etc.
I'll probably aim for beta 2 for that.
--
Changes by Nick Coghlan ncogh...@gmail.com:
--
dependencies: +Blacklist base64, hex, ... codecs from bytes.decode() and
str.encode()
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
Nick Coghlan added the comment:
Victor is still -1, so to Python 3.5 it goes.
--
versions: +Python 3.5 -Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
Nick Coghlan added the comment:
Attached patch restores the aliases for the binary and text transforms, adds a
test to ensure they exist and restores the Aliases column to the relevant
tables in the documentation. It also updates the relevant section in the What's
New document.
I also
Nick Coghlan added the comment:
Issue 17823 is now closed, but not because it has been implemented. It turns
out that the data driven nature of the incompatibility means it isn't really
amenable to being detected and fixed automatically via 2to3.
Issue 19543 is a replacement proposal for the
Nick Coghlan added the comment:
Providing the 2to3 fixers in issue 17823 now depends on this issue rather than
the other way around (since not having to translate the names simplifies the
fixer a bit).
--
dependencies: -2to3 fixers for missing codecs
Nick Coghlan added the comment:
For anyone interested, I have a patch up on issue 17828 that produces the
following output for various codec usage errors:
import codecs
codecs.encode(bhello, bz2_codec).decode(bz2_codec)
Traceback (most recent call last):
File stdin, line 1, in module
Nick Coghlan added the comment:
With issue 17839 fixed, the error from invoking the base64 codec through the
method API is now substantially more sensible:
bZXhhbXBsZQ==\n.decode(base64_codec)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: decoder did not return
Nick Coghlan added the comment:
I just wanted to note something I realised in chatting to Armin Ronacher
recently: in both Python 2.x and 3.x, the encode/decode method APIs are
constrained by the text model, it's just that in 2.x that model was effectively
basestring-basestring, and thus
Nick Coghlan added the comment:
We should fix the docs for the earlier versions as well.
--
versions: +Python 2.7, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
Changes by Nick Coghlan ncogh...@gmail.com:
--
Removed message: http://bugs.python.org/msg198847
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
Changes by Nick Coghlan ncogh...@gmail.com:
--
versions: -Python 2.7, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Changes by Martin Morrison m...@ensoft.co.uk:
--
nosy: +isoschiz
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Python-bugs-list
Nick Coghlan added the comment:
Also adding 17839 as a dependency, since part of the reason the base64 errors
in particular are so cryptic is because the base64 module doesn't accept
arbitrary PEP 3118 compliant objects as input.
--
dependencies: +base64 module should use memoryview
Changes by Serhiy Storchaka storch...@gmail.com:
--
dependencies: +2to3 fixers for missing codecs
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
Nick Coghlan added the comment:
I also created issue 17841 to cover that that the 3.3 documentation incorrectly
states that these aliases still exist, even though they were removed before 3.2
was released.
--
___
Python tracker
Changes by Serhiy Storchaka storch...@gmail.com:
--
dependencies: +Add link to alternatives for bytes-to-bytes codecs
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
Changes by Guido van Rossum gu...@python.org:
--
nosy: -gvanrossum
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Python-bugs-list
Martin v. Löwis added the comment:
I don't see any point in merely bringing the codecs back, without any
convenience API to use them. If I need to do
import codecs
result = codecs.getencoder(base64).encode(data)
I don't think people would actually prefer this over
import base64
Ezio Melotti added the comment:
IMHO it's also a documentation problem. Once people figure out that they can't
use encode/decode anymore, it's not immediately clear what they should do
instead. By reading the codecs docs[0] it's not obvious that it can be done
with
Nick Coghlan added the comment:
It turns out MAL added the convenience API I'm looking for back in 2004, it
just didn't get documented, and is hidden behind the from _codecs import *
call in the codecs.py source code:
http://hg.python.org/cpython-fullhistory/rev/8ea2cb1ec598
So, all the
Marc-Andre Lemburg added the comment:
Just copying some details here about codecs.encode() and
codec.decode() from python-dev:
Just as reminder: we have the general purpose
encode()/decode() functions in the codecs module:
import codecs
r13 = codecs.encode('hello world', 'rot-13')
These
Ezio Melotti added the comment:
It works in 3.x as well, you just need to add the _codec to the end
to account for the missing aliases:
FTR this is because of ff1261a14573 (see #10807).
--
___
Python tracker rep...@bugs.python.org
Nick Coghlan added the comment:
Issue 17827 covers adding documentation for codecs.encode and codecs.decode
Issue 17828 covers adding exception handling improvements for all encoding and
decoding operations
--
___
Python tracker
Nick Coghlan added the comment:
For me, the killer argument *against* a method based API is memoryview (and,
equivalently, array.array). It should be possible to use those as inputs for
the bytes-bytes codecs, and once you endorse codecs.encode and codecs.decode
for that use case, it's hard
Florent Xicluna added the comment:
Another rant, because it matters to many of us:
http://lucumr.pocoo.org/2012/8/11/codec-confusion/
IMHO, the solution to restore str.decode and bytes.encode and return TypeError
for improper use is probably the most obvious for the average user.
--
Ezio Melotti added the comment:
-1
I see encoding as the process to go from text to bytes, and decoding the
process to go from bytes to text, so (ab)using these terms for other kind of
conversions is not an option IMHO.
Anyway I think someone should write a PEP and list the possible options
R. David Murray added the comment:
transform/untransform has approval-in-principle, adding encode/decode to the
type that doesn't have them has been explicitly (and repeatedly :) rejected.
(I don't know about anybody else, but at this point I have written code that
assumes that if an object
Florent Xicluna added the comment:
I am not a native english speaker, but it seems that the common usage of
encode/decode is wider than the restricted definition applied for Python 3.3:
Some examples:
* RFC 4648 specifies Base16, Base32, and Base64 Data Encodings
Ezio Melotti added the comment:
While not strictly necessary, a PEP would be certainly useful and will help
reaching a consensus. The PEP should provide a summary of the available
options (transform/untransforms, reintroducing encode/decode for bytes/str,
maybe others), their intended
Nick Coghlan added the comment:
+1 for someone stepping up to write a PEP on this if they would like to see the
situation improved in 3.4.
transform/untransform has at least one core developer with an explicit -1 on
the proposal at the moment (me).
We *definitely* need a generic
R. David Murray added the comment:
I was visualizing transform/untransform as being restricted to
buffertype-bytes and stringtype-string, which at least for binascii-type
transforms is all the modules support. After all, you don't get to choose what
type of object you get back from encode or
Nick Coghlan added the comment:
If transform is a method, how do you plan to accept arbitrary buffer supporting
types as input?
This is why I mentioned memoryview: it doesn't provide decode(), but there's no
good reason you should have to copy the data from the view before decoding it.
R. David Murray added the comment:
I agree with you. transform/untransform are parallel to encode/decode, and I
wouldn't expect them to exist on any type that didn't support either encode or
decode. They are convenience methods, just as encode/decode are.
I am also probably not invested
Guido van Rossum added the comment:
str.decode() and bytes.encode() are not coming back.
Any proposal had better take into account the API design rule that the *type*
of a method's return value should not depend on the *value* of one of the
arguments. (The Python 2 design failed this test,
Georg Brandl added the comment:
FWIW, I'm not interested in seeing this added anymore.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
Gregory P. Smith added the comment:
consensus here appears to be bad idea... don't do this.
--
nosy: +gregory.p.smith
priority: high - normal
resolution: - wont fix
stage: - committed/rejected
status: open - closed
___
Python tracker
Nick Coghlan added the comment:
No, transform/untransform as methods are a bad idea, but these *codecs*
should definitely come back.
The minimal change needed for that to be feasible is to give errors raised
during encoding and decoding more context information (at least the codec
name and
Gregory P. Smith added the comment:
okay, but i don't personally find any of these to be good ideas as codecs
given they don't have anything to do with translating between bytes-unicode.
--
resolution: wont fix -
stage: committed/rejected -
status: closed - open
Nick Coghlan added the comment:
The codecs module is generic, text encodings are just the most common use
case (hence the associated method API).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
Changes by Phil Connell pconn...@gmail.com:
--
nosy: +pconnell
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Python-bugs-list mailing
Changes by Florent Xicluna florent.xicl...@gmail.com:
--
nosy: -flox
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Python-bugs-list
Changes by Florent Xicluna florent.xicl...@gmail.com:
--
nosy: +flox
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Python-bugs-list
Uzume added the comment:
Many have chimed in on this topic but I thought I would lend my stance--for
whatever it is worth.
I also believe most of these do not fit concept of a character codec and some
sort of transforms would likely be useful, however most are sort of specialized
(e.g.,
Changes by Uzume uz...@users.sourceforge.net:
--
nosy: -uzume
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Python-bugs-list mailing
Changes by Nick Coghlan ncogh...@gmail.com:
--
priority: release blocker - high
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Nick Coghlan ncogh...@gmail.com added the comment:
FWIW it's, I've been thinking further about this recently and I think
implementing this feature as builtin methods is the wrong way to approach it.
Instead, I propose the addition of codecs.encode and codecs.decode methods that
are type
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Python-bugs-list
Nick Coghlan ncogh...@gmail.com added the comment:
My current opinion is that this should be a PEP for 3.4, to make sure we flush
out all the corner cases and other details correctly.
--
versions: +Python 3.4 -Python 3.3
___
Python tracker
Nick Coghlan ncogh...@gmail.com added the comment:
For that matter, with the relevant codecs restored in 3.2, a transform() helper
could probably be added to six (or a new project on PyPI) to prototype the
approach.
--
___
Python tracker
Nick Coghlan ncogh...@gmail.com added the comment:
Setting as a release blocker for 3.4 - this is important.
--
priority: normal - release blocker
stage: commit review -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Python-bugs-list mailing list
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Python-bugs-list mailing
STINNER Victor victor.stin...@gmail.com added the comment:
What is the status of this issue? Is there still a fan of this issue motivated
to write a PEP, a patch or something like that?
--
___
Python tracker rep...@bugs.python.org
Nick Coghlan ncogh...@gmail.com added the comment:
It's still on my radar to come back and have a look at it. Feedback from the
web folks doing Python 3 migrations is that it would have helped them in quite
a few cases.
I want to get a couple of other open PEPs out of the way first, though
Petri Lehtinen pe...@digip.org added the comment:
Issue 13600 has been marked as a duplicate of this issue.
FRT, +1 to the idea of adding encoded_format and decoded_format attributes to
CodecInfo, and also to adding {str,bytes}.{transform,untransform} back.
--
nosy: +petri.lehtinen
Nick Coghlan ncogh...@gmail.com added the comment:
They were removed because adding new methods to builtin types violated the
language moratorium.
Now that the language moratorium is over, the transform/untransform convenience
APIs should be added again for 3.3. It's an approved change, the
Nick Coghlan ncogh...@gmail.com added the comment:
Sorry, I meant to state my rationale for the unassignment - I'm assuming this
issue is covered by MAL's recent decision to step away from Unicode and codec
maintenance issues. If that's incorrect, MAL can reclaim the issue, otherwise
Nick Coghlan ncogh...@gmail.com added the comment:
Some further comments after getting back up to speed with the actual status of
this problem (i.e. that we had issues with the error checking and reporting in
the original 3.2 commit).
1. I agree with the position that the codecs module itself
Nick Coghlan ncogh...@gmail.com added the comment:
Oops, typo in my second error example. The command should be:
b'a'.decode('rot_13')
(Since str objects don't offer a decode() method any more)
--
___
Python tracker rep...@bugs.python.org
STINNER Victor victor.stin...@haypocalc.com added the comment:
*.encode('rot_13') == CodecLookupError
I like the idea of raising a lookup error on .encode/.decode if the codec is
not a classic text codec (like ASCII or UTF-8).
*.transform('ascii') == CodecLookupError
Same comment.
Nick Coghlan ncogh...@gmail.com added the comment:
On Thu, Oct 20, 2011 at 8:34 AM, STINNER Victor rep...@bugs.python.org wrote:
str.transform('bz2') == CodecLookupError
A lookup error is surprising here. It may be a TypeError instead. The bz2 can
be used with .transform, but not on str.
STINNER Victor victor.stin...@haypocalc.com added the comment:
I think it may even make sense to build the filtering
options into codecs.lookup() itself:
def lookup(encoding, decoded_format=None, encoded_format=None):
info = _lookup(encoding) # The existing codec lookup algorithm
Nick Coghlan ncogh...@gmail.com added the comment:
I'm fine with people needing to drop down to the lower level lookup() API if
they want the filtering functionality in Python code. For most purposes,
constraining the expected codec input and output formats really isn't a major
issue - we
Éric Araujo mer...@netwok.org added the comment:
transform() and untransform() methods were also removed, I don't remember
why/how exactly,
I don’t remember either; maybe it was too late in the release process, or we
lacked enough consensus.
So we have rot13 friends in Python 3.2 and 3.3,
STINNER Victor victor.stin...@haypocalc.com added the comment:
What is the status of this issue?
rot13 codecs friends were added back to Python 3.2 with
{bytes,str}.(un)transform() methods: commit 7e4833764c88. Codecs were disabled
because of surprising error messages before the release of
Éric Araujo mer...@netwok.org added the comment:
So. This was reverted before 3.2 was out, right? What is the status for 3.3?
--
components: -2to3 (2.x to 3.0 conversion tool), Documentation
___
Python tracker rep...@bugs.python.org
Changes by Cherniavsky Beni b...@google.com:
--
nosy: +cben
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Python-bugs-list mailing
Changes by Éric Araujo mer...@netwok.org:
--
versions: +Python 3.3 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
See issue #10807: 'base64' can be used with bytes.decode() (and str.encode()),
but it raises a confusing exception (TypeError: expected bytes, not memoryview).
--
___
Python tracker
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
With Georg's approval, I am reopening this issue until a decision is made on
whether {str,bytes,bytearray}.{transform,untransform} methods should go into
3.2.
I am adding Guido to nosy because the decision may turn on
Marc-Andre Lemburg m...@egenix.com added the comment:
Martin v. Löwis wrote:
Martin v. Löwis mar...@v.loewis.de added the comment:
As per
http://mail.python.org/pipermail/python-dev/2010-December/106374.html
I think this checkin should be reverted, as it's breaking the language
Martin v. Löwis mar...@v.loewis.de added the comment:
As per
http://mail.python.org/pipermail/python-dev/2010-December/106374.html
I think this checkin should be reverted, as it's breaking the language
moratorium.
--
___
Python tracker
Georg Brandl ge...@python.org added the comment:
I leave this to MAL, on whose behalf I finished this to be in time for beta.
--
assignee: - lemburg
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
Marc-Andre Lemburg m...@egenix.com added the comment:
Alexander Belopolsky wrote:
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I am probably a bit late to this discussion, but why these things should be
called codecs and why should they share the registry with
Georg Brandl ge...@python.org added the comment:
Codecs brought back and (un)transform implemented in r86934.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I am probably a bit late to this discussion, but why these things should be
called codecs and why should they share the registry with the encodings? It
looks like the proper term would be transformations or transforms.
Martin v. Löwis mar...@v.loewis.de added the comment:
I would like to know what happened with hex_codec and what is the new py3 for
this.
If you had read this bug report, you'd know that the codec was removed
in Python 3. Use binascii.hexlify/binascii.unhexlify instead (as you
should in 2.x,
Marc-Andre Lemburg m...@egenix.com added the comment:
Martin v. Löwis wrote:
Martin v. Löwis mar...@v.loewis.de added the comment:
I would like to know what happened with hex_codec and what is the new py3
for this.
If you had read this bug report, you'd know that the codec was removed
Georg Brandl ge...@python.org added the comment:
... but don't wait too long!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Changes by Georg Brandl ge...@python.org:
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Python-bugs-list mailing list
Unsubscribe:
Georg Brandl ge...@python.org added the comment:
... but don't wait to long to add them!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
Marc-Andre Lemburg m...@egenix.com added the comment:
Georg Brandl wrote:
Georg Brandl ge...@python.org added the comment:
... but don't wait to long to add them!
I plan to work on that after EuroPython. Florent already provided
the patch for the codecs, so what's left is adding the
Changes by Marc-Andre Lemburg m...@egenix.com:
--
versions: -Python 2.7, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Éric Araujo mer...@netwok.org added the comment:
I am confused by MvL’s reply. From the first paragraph documentation for
binascii: “Normally, you will not use these functions directly but use wrapper
modules like uu, base64, or binhex instead. The binascii module contains
low-level functions
Martin v. Löwis mar...@v.loewis.de added the comment:
I am confused by MvL’s reply. From the first paragraph documentation
for binascii: “Normally, you will not use these functions directly
but use wrapper modules like uu, base64, or binhex instead. The
binascii module contains low-level
sorin sorin.sbar...@gmail.com added the comment:
I would like to know what happened with hex_codec and what is the new py3 for
this.
Also, it would be really helpful to see DeprecationWarnings for all these
codecs in py2x and include a note in py3 changelist.
The official python
Éric Araujo mer...@netwok.org added the comment:
Related: bytes vs. str for base64 encoding in email, #8896
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
I agree with Martin: codecs choosed the wrong direction in Python2, and it's
fixed in Python3. The codecs module is related to charsets (encodings), should
encode str to bytes, and should decode bytes (or any read buffer) to str.
STINNER Victor victor.stin...@haypocalc.com added the comment:
Explanation the change in Python3 by Guido:
We are adopting a slightly different approach to codecs: while in Python 2,
codecs can accept either Unicode or 8-bits as input and produce either as
output, in Py3k, encoding is always
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
STINNER Victor victor.stin...@haypocalc.com added the comment:
I agree with Martin: codecs choosed the wrong direction in Python2, and it's
fixed in Python3. The codecs module is related to charsets (encodings),
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +merwok
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Python-bugs-list mailing
Changes by Skip Montanaro s...@pobox.com:
--
nosy: -skip.montanaro
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7475
___
___
Python-bugs-list
1 - 100 of 121 matches
Mail list logo
