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 understo
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).
Ad
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 bi
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 r
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'
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
> morato
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 me
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 (
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 pre
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,
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
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 ab
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
>>
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
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. L
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
d
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
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 las
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("rot
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 inv
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 custom
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
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 y
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
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 curre
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
>>mo
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
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:
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 s
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 developer
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 ap
> 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
> sho
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
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:
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 wan
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
displ
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" 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 enco
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 P
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
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 consi
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?
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 tho
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)
46 matches
Mail list logo
