On Wed, 2010-06-09 at 01:15 -0400, Fred Drake wrote:
On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran orsent...@gmail.com 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
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.
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
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).
On Wed, 09 Jun 2010 10:41:29 +0200
M.-A. Lemburg m...@egenix.com 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,
On 09/06/2010 12:35, Antoine Pitrou wrote:
On Wed, 09 Jun 2010 10:41:29 +0200
M.-A. Lemburgm...@egenix.com 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
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. Lemburgm...@egenix.com wrote:
The above example will read:
b'abc'.transform(hex)
b'616263'
On Wed, 09 Jun 2010 21:14:33 +1000, Nick Coghlan ncogh...@gmail.com 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
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
Antoine Pitrou wrote:
On Wed, 09 Jun 2010 10:41:29 +0200
M.-A. Lemburg m...@egenix.com 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
On Wed, Jun 9, 2010 at 13:40, Antoine Pitrou solip...@pitrou.net 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
On 9 June 2010 07:26, Chris McDonough chr...@plope.com wrote:
On Wed, 2010-06-09 at 01:15 -0400, Fred Drake wrote:
On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran orsent...@gmail.com wrote:
it would still be a good idea to
introduce some of them in minor releases in 2.7. I know, this
On Wed, 9 Jun 2010 13:57:05 +0200
Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Wed, Jun 9, 2010 at 13:40, Antoine Pitrou solip...@pitrou.net 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
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
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
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
On Wed, Jun 9, 2010 at 8:58 AM, Paul Moore p.f.mo...@gmail.com 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
Paul Moore wrote:
On 9 June 2010 07:26, Chris McDonough chr...@plope.com wrote:
On Wed, 2010-06-09 at 01:15 -0400, Fred Drake wrote:
On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran orsent...@gmail.com
wrote:
it would still be a good idea to
introduce some of them in minor releases in 2.7.
On 09/06/2010 13:56, Steve Holden wrote:
Paul Moore wrote:
On 9 June 2010 07:26, Chris McDonoughchr...@plope.com wrote:
On Wed, 2010-06-09 at 01:15 -0400, Fred Drake wrote:
On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaranorsent...@gmail.com wrote:
it would still
On Jun 09, 2010, at 01:15 AM, Fred Drake wrote:
On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran orsent...@gmail.com 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
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.
uabc é.encode(rot13)
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
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
Antoine Pitrou solip...@pitrou.net 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. Lemburgm...@egenix.com wrote:
The above example will read:
Barry Warsaw ba...@python.org 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
On Jun 09, 2010, at 09:13 AM, Bill Janssen wrote:
Barry Warsaw ba...@python.org 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
On Wed, Jun 9, 2010 at 12:32 PM, Barry Warsaw ba...@python.org wrote:
On Jun 09, 2010, at 09:13 AM, Bill Janssen wrote:
Barry Warsaw ba...@python.org 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
On Wed, Jun 9, 2010 at 08:12, Barry Warsaw ba...@python.org 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
On Jun 8, 2010, at 9:13 PM, Benjamin Peterson wrote:
2010/6/8 Alexandre Vassalotti alexan...@peadrop.com:
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
On Wed, 09 Jun 2010 16:35:38 +0200, Victor Stinner
victor.stin...@haypocalc.com 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
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
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
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
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
On 6/9/2010 8:17 AM, Antoine Pitrou wrote:
On Wed, 9 Jun 2010 13:57:05 +0200
Dirkjan Ochtmandirk...@ochtman.nl wrote:
On Wed, Jun 9, 2010 at 13:40, Antoine Pitrousolip...@pitrou.net wrote:
No, I don't think so. If I'm using hex encoding, it's because I want
to see a text representation of
On Wed, Jun 9, 2010 at 12:40, Eric Smith e...@trueblade.com 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
On Wed, 09 Jun 2010 15:45:55 -0400
Terry Reedy tjre...@udel.edu wrote:
On 6/9/2010 8:17 AM, Antoine Pitrou wrote:
On Wed, 9 Jun 2010 13:57:05 +0200
Dirkjan Ochtmandirk...@ochtman.nl wrote:
On Wed, Jun 9, 2010 at 13:40, Antoine Pitrousolip...@pitrou.net wrote:
No, I don't think so. If
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 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
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
On Wed, 09 Jun 2010 22:13:28 +0200
Martin v. Löwis mar...@v.loewis.de 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
Barry Warsaw wrote:
On Jun 09, 2010, at 09:13 AM, Bill Janssen wrote:
Barry Warsaw ba...@python.org 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
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
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 orsent...@gmail.com 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
On Wed, Jun 9, 2010 at 1:23 PM, Martin v. Löwis mar...@v.loewis.de 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,
On Wed, Jun 9, 2010 at 5:55 AM, Facundo Batista
facundobati...@gmail.com 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
46 matches
Mail list logo
