Re: [Python-Dev] Future of 2.x.
Chris McDonough writes: > It might be useful to copy the identifiers and URLs of all the backport > request tickets into some other repository, or to create some unique > state in roundup for these. A keyword would do. Please don't add a status or something like that, though. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
Victor Stinner wrote:
> There are two opposite issues in the bug tracker:
>
>#7475: codecs missing: base64 bz2 hex zlib ...
>-> reintroduce the codecs removed from Python3
>
>#8838: Remove codecs.readbuffer_encode()
>-> remove the last part of the removed codecs
>
> If I understood correctly, the question is: should codecs module only contain
> encoding codecs, or contain also other kind of codecs.
Sorry, but I can only repeat what I've already mentioned
a few times on the tracker items: this is a misunderstanding.
The codec system does not mandate a specific type combination
(and that's per design). Only the helper methods .encode() and
.decode() on bytes and str objects in Python3 do in order to
provide type safety.
> Encoding codec API is now strict (encode: str->bytes, decode: bytes->str),
> it's not possible to reuse str.encode() or bytes.decode() for the other
> codecs. Marc-Andre Lemburg proposed to add .tranform() and .untranform()
> methods to str, bytes and bytearray types. If I understood correctly, it
> would
> look like:
>
>>>> b'abc'.transform("hex")
>'616263'
>>>> '616263'.untranform("hex")
>b'abc'
No, .transform() and .untransform() will be interface to same-type
codecs, i.e. ones that convert bytes to bytes or str to str. As with
.encode()/.decode() these helper methods also implement type safety
of the return type.
The above example will read:
>>> b'abc'.transform("hex")
b'616263'
>>> b'616263'.untranform("hex")
b'abc'
> I suppose that each codec will have a different list of accepted input and
> output types. Example:
>
>bz2: encode:bytes->bytes, decode:bytes->bytes
>rot13: encode:str->str, decode:str->str
>hex: encode:bytes->str, decode: str->bytes
hex will do bytes->bytes in both directions, just like it does
in Python2.
The methods to be used will be .transform() for the encode direction
and .untransform() for the decode direction.
> And so "abc".encode("bz2") would raise a TypeError.
Yes.
> --
>
> In my opinion, we should not mix codecs of different kinds (compression,
> cipher, etc.) because the input and output types are different. It would have
> more sense to create a standard API for each kind of codec. Existing examples
> of standard APIs in Python: hashlib, shutil.make_archive(), database API, etc.
If you want, you can have those as well, but then you'd
have to introduce new APIs or modules, whereas the codec
interface have existed for quite a while in Python2 and
are in regular use.
For most applications the very simple to use codec interface
to these codecs is all that is needed, so I don't see a strong
case for adding new interfaces, e.g.
hex_data = data.transform('hex')
looks clean and neat.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jun 09 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2010-07-19: EuroPython 2010, Birmingham, UK39 days to go
::: Try our new mxODBC.Connect Python Database Interface for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
On 09/06/10 18:41, M.-A. Lemburg wrote: The methods to be used will be .transform() for the encode direction and .untransform() for the decode direction. +1, although adding this for 3.2 would need an exception to the moratorium approved (since it is adding new methods for builtin types). Adding the same-type codecs back even without the helper methods should be fine though (less useful without the helper methods, obviously, but still valid). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
On Wed, 09 Jun 2010 10:41:29 +0200
"M.-A. Lemburg" wrote:
>
> The above example will read:
>
> >>> b'abc'.transform("hex")
> b'616263'
> >>> b'616263'.untranform("hex")
> b'abc'
This doesn't look right to me. Hex-encoded "data" is really text (it's
a textual representation of binary, and isn't often used as an opaque
binary transport encoding).
Of course, this is not necessarily so for all codecs. For
base64-encoded data, for example, it is debatable whether you want it
as ASCII bytes or unicode text.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
On 09/06/2010 12:35, Antoine Pitrou wrote:
On Wed, 09 Jun 2010 10:41:29 +0200
"M.-A. Lemburg" wrote:
The above example will read:
>>> b'abc'.transform("hex")
b'616263'
>>> b'616263'.untranform("hex")
b'abc'
This doesn't look right to me. Hex-encoded "data" is really text (it's
a textual representation of binary, and isn't often used as an opaque
binary transport encoding).
Of course, this is not necessarily so for all codecs. For
base64-encoded data, for example, it is debatable whether you want it
as ASCII bytes or unicode text.
But in both cases you probably want bytes -> bytes and str -> str. If
you want text out then put text in, if you want bytes out then put bytes in.
Michael
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers arising from any
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap,
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in perpetuity, without
prejudice to my ongoing rights and privileges. You further represent that you
have the authority to release me from any BOGUS AGREEMENTS on behalf of your
employer.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
Le mercredi 09 juin 2010 à 12:38 +0100, Michael Foord a écrit :
> On 09/06/2010 12:35, Antoine Pitrou wrote:
> > On Wed, 09 Jun 2010 10:41:29 +0200
> > "M.-A. Lemburg" wrote:
> >
> >> The above example will read:
> >>
> >> >>> b'abc'.transform("hex")
> >> b'616263'
> >> >>> b'616263'.untranform("hex")
> >> b'abc'
> >>
> > This doesn't look right to me. Hex-encoded "data" is really text (it's
> > a textual representation of binary, and isn't often used as an opaque
> > binary transport encoding).
> > Of course, this is not necessarily so for all codecs. For
> > base64-encoded data, for example, it is debatable whether you want it
> > as ASCII bytes or unicode text.
> >
>
> But in both cases you probably want bytes -> bytes and str -> str. If
> you want text out then put text in, if you want bytes out then put bytes in.
No, I don't think so. If I'm using hex "encoding", it's because I want
to see a text representation of some arbitrary bytestring (in order to
display it inside another piece of text, for example).
In other words, the purpose of hex is precisely to give a textual
display of non-textual data.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
On Wed, 09 Jun 2010 21:14:33 +1000, Nick Coghlan wrote: > On 09/06/10 18:41, M.-A. Lemburg wrote: > > The methods to be used will be .transform() for the encode direction > > and .untransform() for the decode direction. > > +1, although adding this for 3.2 would need an exception to the > moratorium approved (since it is adding new methods for builtin types). > > Adding the same-type codecs back even without the helper methods should > be fine though (less useful without the helper methods, obviously, but > still valid). Agreed. And I think making an exception to the moratorium for translate/untranslate is justified, given that this is restoring a feature that Python2 had, in a Python3 compatible manner. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
Nick Coghlan wrote:
> On 09/06/10 18:41, M.-A. Lemburg wrote:
>> The methods to be used will be .transform() for the encode direction
>> and .untransform() for the decode direction.
>
> +1, although adding this for 3.2 would need an exception to the
> moratorium approved (since it is adding new methods for builtin types).
Good point.
We already discussed these methods in 2008 and Guido
approved them back then, so perhaps that's a good argument
for an exception.
> Adding the same-type codecs back even without the helper methods should
> be fine though (less useful without the helper methods, obviously, but
> still valid).
Agreed.
The new methods would make it easier to port to Python3, though,
since e.g. data.encode('hex') is easier to convert to
data.transform('hex').
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jun 09 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2010-07-19: EuroPython 2010, Birmingham, UK39 days to go
::: Try our new mxODBC.Connect Python Database Interface for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
Antoine Pitrou wrote:
> On Wed, 09 Jun 2010 10:41:29 +0200
> "M.-A. Lemburg" wrote:
>>
>> The above example will read:
>>
>> >>> b'abc'.transform("hex")
>> b'616263'
>> >>> b'616263'.untranform("hex")
>> b'abc'
>
> This doesn't look right to me. Hex-encoded "data" is really text (it's
> a textual representation of binary, and isn't often used as an opaque
> binary transport encoding).
Then we'd need new .encode() and .decode() methods, so that
we could write:
>>> b'abc'.encode("hex")
'616263'
>>> '616263'.decode("hex")
b'abc'
The reason is that we don't have helper methods for the directions
encoding: bytes->str and
decoding: str->bytes.
We do in Python2, so perhaps adding those back as well would
be a possibility, but I don't want to strain all this too much.
It's always possible to use:
codecs.encode(b'abc')
and
codecs.decode('616263')
instead.
> Of course, this is not necessarily so for all codecs. For
> base64-encoded data, for example, it is debatable whether you want it
> as ASCII bytes or unicode text.
Since there are multiple ways of choosing types, I would like
to use the ones that Python2 already chose, if possible.
The only one I'm not sure about is 'rot13': this is an encoding
that is only defined for text and works by creating mangled
text, so str->str appears to be more correct than str->bytes
(which we have in Python2).
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jun 09 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2010-07-19: EuroPython 2010, Birmingham, UK39 days to go
::: Try our new mxODBC.Connect Python Database Interface for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
On Wed, Jun 9, 2010 at 13:40, Antoine Pitrou wrote: > No, I don't think so. If I'm using hex "encoding", it's because I want > to see a text representation of some arbitrary bytestring (in order to > display it inside another piece of text, for example). > In other words, the purpose of hex is precisely to give a textual > display of non-textual data. Or I want to encode binary data in a non-binary-safe protocol, in which case I probably want bytes. Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On 9 June 2010 07:26, Chris McDonough wrote: > On Wed, 2010-06-09 at 01:15 -0400, Fred Drake wrote: >> On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran wrote: >> > it would still be a good idea to >> > introduce some of them in minor releases in 2.7. I know, this >> > deviating from the process, but it could be an option considering that >> > 2.7 is the last of 2.x release. >> >> I disagree. >> >> If there are going to be features going into *any* post 2.7.0 version, >> there's no reason not to increment the revision number to 2.8, >> >> Since there's also a well-advertised decision that 2.7 will be the >> last 2.x, such a 2.8 isn't planned. But there's no reason to violate >> the no-features-in-bugfix-releases policy. We've seen violations >> cause trouble and confusion, but we've not seen it be successful. >> >> The policy wasn't arbitrary; let's stick to it. > > It might be useful to copy the identifiers and URLs of all the backport > request tickets into some other repository, or to create some unique > state in roundup for these. Rationale: it's almost certain that if the > existing Python core maintainers won't evolve Python 2.X past 2.7, some > other group will, and losing existing context for that would kinda suck. Personally, as a user of Python, I'm already getting tired of the "we won't let Python 2.x die" arguments. Unless and until some other group comes along and says they definitely plan to pick up Python 2.x development (and set up or agree shared usage of all the relevant infrastructure, bug tracker, developers list, VCS, etc) I see the core developers' decision as made. 2.7 is the last Python 2.x release, and all further development will be on 3.x. On that basis I'm +1 on Alexandre's proposal. A 3rd party planning on working on a 2.8 release (not that I think such a party currently exists) can step up and extract the relevant tickets for their later reference if they feel the need. Let's not stop moving forward for the convenience of a hypothetical 2.8 development team. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
On Wed, 9 Jun 2010 13:57:05 +0200 Dirkjan Ochtman wrote: > On Wed, Jun 9, 2010 at 13:40, Antoine Pitrou wrote: > > No, I don't think so. If I'm using hex "encoding", it's because I want > > to see a text representation of some arbitrary bytestring (in order to > > display it inside another piece of text, for example). > > In other words, the purpose of hex is precisely to give a textual > > display of non-textual data. > > Or I want to encode binary data in a non-binary-safe protocol, in > which case I probably want bytes. In this case you would probably choose a more space-efficient representation, such as base64 or base85. Which is why I think the purpose of hex is mostly for textual representation. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
Le mercredi 09 juin 2010 10:41:29, M.-A. Lemburg a écrit : > No, .transform() and .untransform() will be interface to same-type > codecs, i.e. ones that convert bytes to bytes or str to str. As with > .encode()/.decode() these helper methods also implement type safety > of the return type. What about buffer compatible objects like array.array(), memoryview(), etc.? Should we use codecs.encode() / codecs.decode() for these types? -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
Victor Stinner wrote: > Le mercredi 09 juin 2010 10:41:29, M.-A. Lemburg a écrit : >> No, .transform() and .untransform() will be interface to same-type >> codecs, i.e. ones that convert bytes to bytes or str to str. As with >> .encode()/.decode() these helper methods also implement type safety >> of the return type. > > What about buffer compatible objects like array.array(), memoryview(), etc.? > Should we use codecs.encode() / codecs.decode() for these types? Yes, or call the encoders/decoders directly by first fetching them via codecs.lookup(). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 09 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2010-07-19: EuroPython 2010, Birmingham, UK39 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
On 09/06/10 22:18, Victor Stinner wrote: Le mercredi 09 juin 2010 10:41:29, M.-A. Lemburg a écrit : No, .transform() and .untransform() will be interface to same-type codecs, i.e. ones that convert bytes to bytes or str to str. As with .encode()/.decode() these helper methods also implement type safety of the return type. What about buffer compatible objects like array.array(), memoryview(), etc.? Should we use codecs.encode() / codecs.decode() for these types? There are probably enough subtleties that this is all worth specifying in a PEP: - which codecs from 2.x are to be restored - the domain each codec operates in (binary data or text)* - review behaviour of codecs.encode and codecs.decode - behaviour of the new str, bytes and bytearray (un)transform methods - whether to add helper methods for reverse codecs (like base64) The PEP would also serve as a reference back to both this discussion and the previous one (which was long enough ago that I've forgotten most of it). *Some are obvious, such as rot13 being text only, and bz2 being binary data only, but others are less clear. hex could be either str->str or bytes->bytes, since ''.join(map(chr, seq)) and b''.join(map(ord, seq)) allow each of them to be implemented trivially in terms of the other. As Antoine pointed out, base64 is really a reverse codec (encode from bytes->str, decode from str->bytes), so it still wouldn't be covered by the new transformation helper methods. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Wed, Jun 9, 2010 at 8:58 AM, Paul Moore wrote: > On that basis I'm +1 on Alexandre's proposal. A 3rd party planning on > working on a 2.8 release (not that I think such a party currently > exists) can step up and extract the relevant tickets for their later > reference if they feel the need. Let's not stop moving forward for the > convenience of a hypothetical 2.8 development team. Yes, closing the tickets as "won't fix" and tagging them as "will-never-happen-in-2.x" or something, is the best combination of both worlds: it will clean the tracker and ease further developments, and will allow anybody to pick up those tickets later. (I'm +1 too to Alexandre's proposal, btw) -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
Paul Moore wrote: > On 9 June 2010 07:26, Chris McDonough wrote: >> On Wed, 2010-06-09 at 01:15 -0400, Fred Drake wrote: >>> On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran >>> wrote: it would still be a good idea to introduce some of them in minor releases in 2.7. I know, this deviating from the process, but it could be an option considering that 2.7 is the last of 2.x release. >>> I disagree. >>> >>> If there are going to be features going into *any* post 2.7.0 version, >>> there's no reason not to increment the revision number to 2.8, >>> >>> Since there's also a well-advertised decision that 2.7 will be the >>> last 2.x, such a 2.8 isn't planned. But there's no reason to violate >>> the no-features-in-bugfix-releases policy. We've seen violations >>> cause trouble and confusion, but we've not seen it be successful. >>> >>> The policy wasn't arbitrary; let's stick to it. >> It might be useful to copy the identifiers and URLs of all the backport >> request tickets into some other repository, or to create some unique >> state in roundup for these. Rationale: it's almost certain that if the >> existing Python core maintainers won't evolve Python 2.X past 2.7, some >> other group will, and losing existing context for that would kinda suck. > > Personally, as a user of Python, I'm already getting tired of the "we > won't let Python 2.x die" arguments. Unless and until some other group > comes along and says they definitely plan to pick up Python 2.x > development (and set up or agree shared usage of all the relevant > infrastructure, bug tracker, developers list, VCS, etc) I see the core > developers' decision as made. 2.7 is the last Python 2.x release, and > all further development will be on 3.x. > > On that basis I'm +1 on Alexandre's proposal. A 3rd party planning on > working on a 2.8 release (not that I think such a party currently > exists) can step up and extract the relevant tickets for their later > reference if they feel the need. Let's not stop moving forward for the > convenience of a hypothetical 2.8 development team. > How does throwing away information represent "moving forward"? I have to say I am surprised by the current lack of momentum behind 3.x, but I do know users who consider that their current investment in the 2.x series is unlikely to migrate to 3.x in the next five years, and it would be strange if they didn't continue to develop 2.x (including backporting some 3.x features). I don't see why we have to make such work harder than it need be. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ "All I want for my birthday is another birthday" - Ian Dury, 1942-2000 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On 09/06/2010 13:56, Steve Holden wrote: Paul Moore wrote: On 9 June 2010 07:26, Chris McDonough wrote: On Wed, 2010-06-09 at 01:15 -0400, Fred Drake wrote: On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran wrote: it would still be a good idea to introduce some of them in minor releases in 2.7. I know, this deviating from the process, but it could be an option considering that 2.7 is the last of 2.x release. I disagree. If there are going to be features going into *any* post 2.7.0 version, there's no reason not to increment the revision number to 2.8, Since there's also a well-advertised decision that 2.7 will be the last 2.x, such a 2.8 isn't planned. But there's no reason to violate the no-features-in-bugfix-releases policy. We've seen violations cause trouble and confusion, but we've not seen it be successful. The policy wasn't arbitrary; let's stick to it. It might be useful to copy the identifiers and URLs of all the backport request tickets into some other repository, or to create some unique state in roundup for these. Rationale: it's almost certain that if the existing Python core maintainers won't evolve Python 2.X past 2.7, some other group will, and losing existing context for that would kinda suck. Personally, as a user of Python, I'm already getting tired of the "we won't let Python 2.x die" arguments. Unless and until some other group comes along and says they definitely plan to pick up Python 2.x development (and set up or agree shared usage of all the relevant infrastructure, bug tracker, developers list, VCS, etc) I see the core developers' decision as made. 2.7 is the last Python 2.x release, and all further development will be on 3.x. On that basis I'm +1 on Alexandre's proposal. A 3rd party planning on working on a 2.8 release (not that I think such a party currently exists) can step up and extract the relevant tickets for their later reference if they feel the need. Let's not stop moving forward for the convenience of a hypothetical 2.8 development team. How does throwing away information represent "moving forward"? I'm inclined to agree. There is no *need* to close these tickets now. I have to say I am surprised by the current lack of momentum behind 3.x, but I do know users who consider that their current investment in the 2.x series is unlikely to migrate to 3.x in the next five years, and it would be strange if they didn't continue to develop 2.x (including backporting some 3.x features). Who is the 'they' in your last sentence here? It seems to imply the 'users'... Certainly no-one specific (neither individual nor group) have stepped up and said they will continue to develop Python 2.x. Even if they did it is not clear that they would use the python.org infrastructure to do it. The Python core developers (basically) *have* moved on and are unlikely to further develop 2.x. We'll see though, it's all speculation at the moment. All the best, Michael I don't see why we have to make such work harder than it need be. regards Steve -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Jun 09, 2010, at 01:15 AM, Fred Drake wrote: >On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran wrote: >> it would still be a good idea to >> introduce some of them in minor releases in 2.7. I know, this >> deviating from the process, but it could be an option considering that >> 2.7 is the last of 2.x release. > >I disagree. > >If there are going to be features going into *any* post 2.7.0 version, >there's no reason not to increment the revision number to 2.8, > >Since there's also a well-advertised decision that 2.7 will be the >last 2.x, such a 2.8 isn't planned. But there's no reason to violate >the no-features-in-bugfix-releases policy. We've seen violations >cause trouble and confusion, but we've not seen it be successful. > >The policy wasn't arbitrary; let's stick to it. I completely agree with Fred. New features in point releases will cause many more headaches than opening up a 2.8, which I still hope we don't do. I'd rather see all that pent up energy focussed on doing whatever we can to help people transition to Python 3. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
Le mercredi 09 juin 2010 14:47:22, Nick Coghlan a écrit :
> *Some are obvious, such as rot13 being text only,
Should rot13 shift any unicode character, or just a-z and A-Z?
Python2 only changes characters a-z and A-Z, and use ISO-8859-1 to encode
unicode to byte string.
>>> u"abc é".encode("rot13")
'nop \xe9'
>>> u"abc \u2c01".encode("rot13")
Traceback (most recent call last):
...
UnicodeEncodeError: 'charmap' codec can't encode character u'\u2c01' in
position 4: character maps to
--
Victor Stinner
http://www.haypocalc.com/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
Michael Foord wrote: >> How does throwing away information represent "moving forward"? > > I'm inclined to agree. There is no *need* to close these tickets now. > >> I have to say I am surprised by the current lack of momentum behind 3.x, >> but I do know users who consider that their current investment in the >> 2.x series is unlikely to migrate to 3.x in the next five years, and it >> would be strange if they didn't continue to develop 2.x (including >> backporting some 3.x features). >> > > Who is the 'they' in your last sentence here? It seems to imply the > 'users'... Certainly no-one specific (neither individual nor group) have > stepped up and said they will continue to develop Python 2.x. Even if > they did it is not clear that they would use the python.org > infrastructure to do it. The Python core developers (basically) *have* > moved on and are unlikely to further develop 2.x. We'll see though, it's > all speculation at the moment. I think it also depends on which core developers you ask :-) Many of them are not keen on having to maintain Python2 for much longer, but some of them may have assets codified in Python2 or interests based Python2 that they'll want to keep for more than just another 5 years. E.g. we still have customers that are on Python 2.3 and have just recently considered moving to Python 2.5. Depending on where you look, motivations are rather diverse. It's certainly not fair to require all core developers to continue working on Python2, but it would also be unfair to cancel out that possibility for a subset of interested devs. Even more so, since it doesn't really create any extra work for those that have no interest. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 09 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2010-07-19: EuroPython 2010, Birmingham, UK39 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Jun 09, 2010, at 04:42 PM, M.-A. Lemburg wrote: >Many of them are not keen on having to maintain Python2 for much >longer, but some of them may have assets codified in Python2 >or interests based Python2 that they'll want to keep for >more than just another 5 years. > >E.g. we still have customers that are on Python 2.3 and have >just recently considered moving to Python 2.5. Depending on where >you look, motivations are rather diverse. > >It's certainly not fair to require all core developers to >continue working on Python2, but it would also be unfair to >cancel out that possibility for a subset of interested devs. >Even more so, since it doesn't really create any extra work >for those that have no interest. Note that Python 2.7 will be *maintained* for a very long time, which should satisfy those folks who still require Python 2. Anybody on older (and currently unmaintained) versions of Python 2 will not care about new features so a Python 2.8 wouldn't help them anyway. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
Antoine Pitrou wrote:
> Le mercredi 09 juin 2010 à 12:38 +0100, Michael Foord a écrit :
> > On 09/06/2010 12:35, Antoine Pitrou wrote:
> > > On Wed, 09 Jun 2010 10:41:29 +0200
> > > "M.-A. Lemburg" wrote:
> > >
> > >> The above example will read:
> > >>
> > >> >>> b'abc'.transform("hex")
> > >> b'616263'
> > >> >>> b'616263'.untranform("hex")
> > >> b'abc'
> > >>
> > > This doesn't look right to me. Hex-encoded "data" is really text (it's
> > > a textual representation of binary, and isn't often used as an opaque
> > > binary transport encoding).
> > > Of course, this is not necessarily so for all codecs. For
> > > base64-encoded data, for example, it is debatable whether you want it
> > > as ASCII bytes or unicode text.
> > >
> >
> > But in both cases you probably want bytes -> bytes and str -> str. If
> > you want text out then put text in, if you want bytes out then put bytes in.
>
> No, I don't think so. If I'm using hex "encoding", it's because I want
> to see a text representation of some arbitrary bytestring (in order to
> display it inside another piece of text, for example).
> In other words, the purpose of hex is precisely to give a textual
> display of non-textual data.
Yes. And base64, and quoted-printable, etc.
Bill
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
Barry Warsaw wrote: > On Jun 09, 2010, at 04:42 PM, M.-A. Lemburg wrote: > > >Many of them are not keen on having to maintain Python2 for much > >longer, but some of them may have assets codified in Python2 > >or interests based Python2 that they'll want to keep for > >more than just another 5 years. > > > >E.g. we still have customers that are on Python 2.3 and have > >just recently considered moving to Python 2.5. Depending on where > >you look, motivations are rather diverse. > > > >It's certainly not fair to require all core developers to > >continue working on Python2, but it would also be unfair to > >cancel out that possibility for a subset of interested devs. > >Even more so, since it doesn't really create any extra work > >for those that have no interest. > > Note that Python 2.7 will be *maintained* for a very long time, which > should satisfy those folks who still require Python 2. Anybody on > older (and currently unmaintained) versions of Python 2 will not care > about new features so a Python 2.8 wouldn't help them anyway. There are two kinds of new features, though. Those added to improve (or at any rate modify :-) the product, and those added to keep the product relevant to a changing external world (new operating systems, new communication protocols, etc.) I think it would take a pretty strong crystal ball to be able to rule out the latter kind of feature add from the 2.x line. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Jun 09, 2010, at 09:13 AM, Bill Janssen wrote: >Barry Warsaw wrote: > >> Note that Python 2.7 will be *maintained* for a very long time, which >> should satisfy those folks who still require Python 2. Anybody on >> older (and currently unmaintained) versions of Python 2 will not care >> about new features so a Python 2.8 wouldn't help them anyway. > >There are two kinds of new features, though. Those added to improve (or >at any rate modify :-) the product, and those added to keep the product >relevant to a changing external world (new operating systems, new >communication protocols, etc.) I think it would take a pretty strong >crystal ball to be able to rule out the latter kind of feature add from >the 2.x line. The latter should mostly be supported by third party packages available in the Cheeseshop. To the extent that such support can't be effected by add-ons (e.g. new OS support), I think a better approach would be to encourage and allow unofficial ports by utilizing dvcs branches (we *are* moving to Mercurial after Python 2.7 final is released, right?). I think we should plan on 2.7 being the last Python 2, and spend lots of effort to get people onto Python 3, partially by offering big carrots like Unladen Swallow, a better/no GIL, etc. I think it should be part of the PSF's mission to help that happen through directed sponsorship, sprints, and other tools. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Wed, Jun 9, 2010 at 12:32 PM, Barry Warsaw wrote: > On Jun 09, 2010, at 09:13 AM, Bill Janssen wrote: > >>Barry Warsaw wrote: >> >>> Note that Python 2.7 will be *maintained* for a very long time, which >>> should satisfy those folks who still require Python 2. Anybody on >>> older (and currently unmaintained) versions of Python 2 will not care >>> about new features so a Python 2.8 wouldn't help them anyway. >> >>There are two kinds of new features, though. Those added to improve (or >>at any rate modify :-) the product, and those added to keep the product >>relevant to a changing external world (new operating systems, new >>communication protocols, etc.) I think it would take a pretty strong >>crystal ball to be able to rule out the latter kind of feature add from >>the 2.x line. > > The latter should mostly be supported by third party packages available in the > Cheeseshop. To the extent that such support can't be effected by add-ons > (e.g. new OS support), I think a better approach would be to encourage and > allow unofficial ports by utilizing dvcs branches (we *are* moving to > Mercurial after Python 2.7 final is released, right?). > > I think we should plan on 2.7 being the last Python 2, and spend lots of > effort > to get people onto Python 3, partially by offering big carrots like Unladen > Swallow, a better/no GIL, etc. I think it should be part of the PSF's mission > to help that happen through directed sponsorship, sprints, and other tools. > > -Barry +1 fearless FLUFL ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Wed, Jun 9, 2010 at 08:12, Barry Warsaw wrote: > On Jun 09, 2010, at 04:42 PM, M.-A. Lemburg wrote: > >>Many of them are not keen on having to maintain Python2 for much >>longer, but some of them may have assets codified in Python2 >>or interests based Python2 that they'll want to keep for >>more than just another 5 years. >> >>E.g. we still have customers that are on Python 2.3 and have >>just recently considered moving to Python 2.5. Depending on where >>you look, motivations are rather diverse. >> >>It's certainly not fair to require all core developers to >>continue working on Python2, but it would also be unfair to >>cancel out that possibility for a subset of interested devs. >>Even more so, since it doesn't really create any extra work >>for those that have no interest. > > Note that Python 2.7 will be *maintained* for a very long time, which should > satisfy those folks who still require Python 2. Anybody on older (and > currently unmaintained) versions of Python 2 will not care about new features > so a Python 2.8 wouldn't help them anyway. The other point about Alexandre's desire to close the issues is that nothing is really getting deleted; closed issues can still be searched for. Alexandre simply wants to not waste anyone's time who happens to be looking at the tracker with issues that the core team will simply never work on. If some mythical 2.8 fork of Python comes along they can perform a search and find the issues that were closed because they were backports that never happened. So +1 on closing them out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Jun 8, 2010, at 9:13 PM, Benjamin Peterson wrote: > 2010/6/8 Alexandre Vassalotti : >> Is there is any plan for a 2.8 release? If not, I will go through the >> tracker and close outstanding backport requests of 3.x features to >> 2.x. > > Not from the core development team. The current plan is to make 2.7 the last 2.x release. The theory is that this will encourage people to switch to 3.x. In practice, the users will get a say in this and time will tell. When I do polls at conferences, it seems that most participants have briefly tried 3.x but are continuing to develop in 2.x. Raymond___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
On Wed, 09 Jun 2010 16:35:38 +0200, Victor Stinner wrote: > Le mercredi 09 juin 2010 14:47:22, Nick Coghlan a =E9crit : > > *Some are obvious, such as rot13 being text only, > > Should rot13 shift any unicode character, or just a-z and A-Z? The latter, unless you want to do a lot of work: http://unicode.org/mail-arch/unicode-ml/y2007-m12/0047.html -- R. David Murray www.bitdance.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On 6/9/2010 4:07 AM, Stephen J. Turnbull wrote: Chris McDonough writes: > It might be useful to copy the identifiers and URLs of all the backport > request tickets into some other repository, or to create some unique > state in roundup for these. Closed issues are not lost. They can still be searched and the result downloaded. A keyword would do. Please don't add a status or something like that, though. I believe Type: feature request; Version: 2.7; Resolution wont fix should do fine now. I believe Alexander will use the first two to find things to close. Anything else anyone finds could be made to match. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On 6/9/2010 10:42 AM, M.-A. Lemburg wrote: >> Steve Holden wrote How does throwing away information represent "moving forward"? 'Closing' a tracker issue does not 'throw away' information', it *adds* information as to current intention. It's certainly not fair to require all core developers to continue working on Python2, but it would also be unfair to cancel out that possibility for a subset of interested devs. Closing a set of issues does not cancel out that possibility. If such a subset of devs develops, they can easily reopen (or move) particular issues they are interested in working on. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
On 6/9/2010 7:45 AM, M.-A. Lemburg wrote:
Nick Coghlan wrote:
On 09/06/10 18:41, M.-A. Lemburg wrote:
The methods to be used will be .transform() for the encode direction
and .untransform() for the decode direction.
+1, although adding this for 3.2 would need an exception to the
moratorium approved (since it is adding new methods for builtin types).
+1 also. This is neither new syntax, nor, really a new feature.
Good point.
We already discussed these methods in 2008 and Guido
approved them back then, so perhaps that's a good argument
for an exception.
Adding the same-type codecs back even without the helper methods should
be fine though (less useful without the helper methods, obviously, but
still valid).
Agreed.
The new methods would make it easier to port to Python3, though,
since e.g. data.encode('hex') is easier to convert to
data.transform('hex').
That would definitely be a point in favor of getting this in 3.2, with
appropriate additions to 2to3.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
> On 6/9/2010 4:07 AM, Stephen J. Turnbull wrote: > Closed issues are not lost. They can still be searched and the result > downloaded. > >> A keyword would do. Please don't add a status or something like that, >> though. > > I believe Type: feature request; Version: 2.7; Resolution wont fix > should do fine now. I believe Alexander will use the first two to find > things to close. Anything else anyone finds could be made to match. Are there any currently existing issues that match that criteria (feature request, 2.7, won't fix)? I don't have good connectivity here so I can't check. Eric. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
On 6/9/2010 8:17 AM, Antoine Pitrou wrote:
On Wed, 9 Jun 2010 13:57:05 +0200
Dirkjan Ochtman wrote:
On Wed, Jun 9, 2010 at 13:40, Antoine Pitrou wrote:
No, I don't think so. If I'm using hex "encoding", it's because I want
to see a text representation of some arbitrary bytestring (in order to
display it inside another piece of text, for example).
In other words, the purpose of hex is precisely to give a textual
display of non-textual data.
Or I want to encode binary data in a non-binary-safe protocol, in
which case I probably want bytes.
In this case you would probably choose a more space-efficient
representation, such as base64 or base85.
Unless the receiver expects hex.
Please, hextext = str(somebytes.tranform('hex')) is quite easy and
explicit and will work for any bytes to ascii-subset transform, not just
'hex'.
Keep .transform and .untransform simple by *always* going to/from same
type.
Terry Jan Reedy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Wed, Jun 9, 2010 at 12:40, Eric Smith wrote: >> On 6/9/2010 4:07 AM, Stephen J. Turnbull wrote: >> Closed issues are not lost. They can still be searched and the result >> downloaded. >> >>> A keyword would do. Please don't add a status or something like that, >>> though. >> >> I believe Type: feature request; Version: 2.7; Resolution wont fix >> should do fine now. I believe Alexander will use the first two to find >> things to close. Anything else anyone finds could be made to match. > > Are there any currently existing issues that match that criteria (feature > request, 2.7, won't fix)? 2.7, closed, wont fix has 27 issues at the moment, which is obviously small and easy to peruse. -Brett > > I don't have good connectivity here so I can't check. > > Eric. > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
On Wed, 09 Jun 2010 15:45:55 -0400
Terry Reedy wrote:
> On 6/9/2010 8:17 AM, Antoine Pitrou wrote:
> > On Wed, 9 Jun 2010 13:57:05 +0200
> > Dirkjan Ochtman wrote:
> >> On Wed, Jun 9, 2010 at 13:40, Antoine Pitrou wrote:
> >>> No, I don't think so. If I'm using hex "encoding", it's because I want
> >>> to see a text representation of some arbitrary bytestring (in order to
> >>> display it inside another piece of text, for example).
> >>> In other words, the purpose of hex is precisely to give a textual
> >>> display of non-textual data.
> >>
> >> Or I want to encode binary data in a non-binary-safe protocol, in
> >> which case I probably want bytes.
> >
> > In this case you would probably choose a more space-efficient
> > representation, such as base64 or base85.
>
> Unless the receiver expects hex.
In which cases is this true? Hex is rarely used for ASCII-encoding of
binary data, precisely because its efficiency is poor.
> Please, hextext = str(somebytes.tranform('hex')) is quite easy and
> explicit and will work for any bytes to ascii-subset transform, not just
> 'hex'.
It will give you the str representation of a bytes object, which is not
what you want.
Of course, hextext = somebytes.tranform('hex').decode('ascii') is not
very hard either. But I disagree with the overall idea that bytes is
the good output type for hex encoding.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
But in both cases you probably want bytes -> bytes and str -> str. If you want text out then put text in, if you want bytes out then put bytes in. No, I don't think so. If I'm using hex "encoding", it's because I want to see a text representation of some arbitrary bytestring (in order to display it inside another piece of text, for example). In other words, the purpose of hex is precisely to give a textual display of non-textual data. I think this is the way it is for consistency reasons (which I would not lightly wish away). I think you agree that base64 is a bytes->bytes transformation (because you typically use it as a payload on some wire protocol). So: py> binascii.b2a_base64(b'foo') b'Zm9v\n' py> binascii.b2a_hex(b'foo') b'666f6f' Now, I'd admit that "b2a" may be a misnomer (binary -> ASCII), but then it may not because ASCII actually *also* implies "bytes" (it's an encoding). So what would you propose to change: b2a_hex should return a Unicode string? or this future transform method should return a Unicode string, whereas the module returns bytes? Something else? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
It might be useful to copy the identifiers and URLs of all the backport request tickets into some other repository, or to create some unique state in roundup for these. Rationale: it's almost certain that if the existing Python core maintainers won't evolve Python 2.X past 2.7, some other group will, and losing existing context for that would kinda suck. Roundup keeps track of all status changes, see the bottom of an arbitrary issue for an example. So I don't think any additional recording is necessary. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
Am 09.06.2010 05:58, schrieb Alexandre Vassalotti: Is there is any plan for a 2.8 release? If not, I will go through the tracker and close outstanding backport requests of 3.x features to 2.x. Closing the backport requests is fine. For the feature requests, I'd only close them *after* the 2.7 release (after determining that they won't apply to 3.x, of course). There aren't that many backport requests, anyway, are there? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs
On Wed, 09 Jun 2010 22:13:28 +0200 "Martin v. Löwis" wrote: > py> binascii.b2a_base64(b'foo') > b'Zm9v\n' > py> binascii.b2a_hex(b'foo') > b'666f6f' > > Now, I'd admit that "b2a" may be a misnomer (binary -> ASCII), but then > it may not because ASCII actually *also* implies "bytes" (it's an encoding). > > So what would you propose to change: b2a_hex should return a Unicode > string? or this future transform method should return a Unicode string, > whereas the module returns bytes? Something else? Well, I would propose transform return str whereas b2a_hex returns bytes. But I agree the consistency argument with b2a_hex looks quite strong. (speaking of which, the builtin hex() functions returns str, although it's purpose is slightly different) Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
Barry Warsaw wrote: > On Jun 09, 2010, at 09:13 AM, Bill Janssen wrote: > >> Barry Warsaw wrote: >> >>> Note that Python 2.7 will be *maintained* for a very long time, which >>> should satisfy those folks who still require Python 2. Anybody on >>> older (and currently unmaintained) versions of Python 2 will not care >>> about new features so a Python 2.8 wouldn't help them anyway. >> There are two kinds of new features, though. Those added to improve (or >> at any rate modify :-) the product, and those added to keep the product >> relevant to a changing external world (new operating systems, new >> communication protocols, etc.) I think it would take a pretty strong >> crystal ball to be able to rule out the latter kind of feature add from >> the 2.x line. > > The latter should mostly be supported by third party packages available in the > Cheeseshop. To the extent that such support can't be effected by add-ons > (e.g. new OS support), I think a better approach would be to encourage and > allow unofficial ports by utilizing dvcs branches (we *are* moving to > Mercurial after Python 2.7 final is released, right?). > > I think we should plan on 2.7 being the last Python 2, and spend lots of > effort > to get people onto Python 3, partially by offering big carrots like Unladen > Swallow, a better/no GIL, etc. I think it should be part of the PSF's mission > to help that happen through directed sponsorship, sprints, and other tools. > The current stumbling block isn't the language itself, it's the lack of support from third-party libraries. GSoC is addressing some of these issues, but so far we (the PSF, the dev community, anybody else except R. David Murray) haven't really come to grips with intractable problems like the broken state of the email package, and we are not doing well at attracting funds to support it. So I think we need to address a larger issue than just the language. As a development community we decided to change the language. Now we have to do what we can to ensure that the changed language has appropriate support. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ "All I want for my birthday is another birthday" - Ian Dury, 1942-2000 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
Terry Reedy wrote: > On 6/9/2010 10:42 AM, M.-A. Lemburg wrote: > >>> Steve Holden wrote How does throwing away information represent "moving forward"? > > 'Closing' a tracker issue does not 'throw away' information', it *adds* > information as to current intention. > >> It's certainly not fair to require all core developers to >> continue working on Python2, but it would also be unfair to >> cancel out that possibility for a subset of interested devs. > > Closing a set of issues does not cancel out that possibility. If such a > subset of devs develops, they can easily reopen (or move) particular > issues they are interested in working on. > > As long as that's the case I am fine with the change. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ "All I want for my birthday is another birthday" - Ian Dury, 1942-2000 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
Barry Warsaw wrote: > On Jun 09, 2010, at 01:15 AM, Fred Drake wrote: > >> On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran wrote: >>> it would still be a good idea to >>> introduce some of them in minor releases in 2.7. I know, this >>> deviating from the process, but it could be an option considering that >>> 2.7 is the last of 2.x release. >> I disagree. >> >> If there are going to be features going into *any* post 2.7.0 version, >> there's no reason not to increment the revision number to 2.8, >> >> Since there's also a well-advertised decision that 2.7 will be the >> last 2.x, such a 2.8 isn't planned. But there's no reason to violate >> the no-features-in-bugfix-releases policy. We've seen violations >> cause trouble and confusion, but we've not seen it be successful. >> >> The policy wasn't arbitrary; let's stick to it. > > I completely agree with Fred. New features in point releases will cause many > more headaches than opening up a 2.8, which I still hope we don't do. I'd > rather see all that pent up energy focussed on doing whatever we can to help > people transition to Python 3. > Though one might ironically suggest that sticking to the policy actually represents a change in policy :) regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ "All I want for my birthday is another birthday" - Ian Dury, 1942-2000 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Wed, Jun 9, 2010 at 1:23 PM, "Martin v. Löwis" wrote: > Closing the backport requests is fine. For the feature requests, I'd only > close them *after* the 2.7 release (after determining that they won't apply > to 3.x, of course). > > There aren't that many backport requests, anyway, are there? > There is only a few requests (about five). -- Alexandre ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Wed, Jun 9, 2010 at 5:55 AM, Facundo Batista wrote: > Yes, closing the tickets as "won't fix" and tagging them as > "will-never-happen-in-2.x" or something, is the best combination of > both worlds: it will clean the tracker and ease further developments, > and will allow anybody to pick up those tickets later. > The issue I care about are already tagged as 26backport. So, I don't think another keyword is needed. -- Alexandre ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Future of 2.x.
On Thu, Jun 10, 2010 at 6:40 AM, Alexandre Vassalotti wrote: > On Wed, Jun 9, 2010 at 1:23 PM, "Martin v. Löwis" wrote: >> Closing the backport requests is fine. For the feature requests, I'd only >> close them *after* the 2.7 release (after determining that they won't apply >> to 3.x, of course). >> >> There aren't that many backport requests, anyway, are there? >> > > There is only a few requests (about five) I get your point. It is the 'back-ports' that you have tagged. These were designed for 3.x and implemented in 3.x in the first place. I was concerned that there will be policy drawn or a practice that will close any/every existing Feature Request in Python 2.7. There are some cases (in stdlib) which can debated on the lines of feature request vs bug-fix and those will get hurt in the process. Thanks, Senthil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
