[Neil Schemenauer]
@classmethod
def fromhex(self, data):
data = re.sub(r'\s+', '', data)
return bytes(binascii.unhexlify(data))
[Jason Orendorff]
If it's to be a classmethod, I guess that should be return self(
binascii.unhexlify(data)).
Am I the only one who finds
Ron == Ron Adam [EMAIL PROTECTED] writes:
Ron We could call it transform or translate if needed.
You're still losing the directionality, which is my primary objection
to recode. The absence of directionality is precisely why recode
is used in that sense for i18n work.
There really isn't a
Greg == Greg Ewing [EMAIL PROTECTED] writes:
Greg Stephen J. Turnbull wrote:
No, base64 isn't a wire protocol. It's a family[...].
Greg Yes, and it's up to the programmer to choose those code
Greg units (i.e. pick an encoding for the characters) that will,
Greg in fact,
On Feb 23, 2006, at 4:41 PM, Thomas Wouters wrote:
On Wed, Feb 22, 2006 at 10:29:08PM -0500, Barry Warsaw wrote:
d.getdefault('foo', list).append('bar')
Anyway, I don't think it's an either/or choice with Guido's subclass.
Instead I think they are different use cases. I would add
2006/2/24, Neal Norwitz [EMAIL PROTECTED]:
Martin and I were talking about dropping support for older versions of
Windows (of the non-NT flavor). We both thought that it was
reasonable to stop supporting Win9x (including WinME) in Python 2.6.
+1
.Facundo
Blog:
On 2/24/06, James Y Knight [EMAIL PROTECTED] wrote:
On Feb 24, 2006, at 1:54 AM, Greg Ewing wrote:
Thomas Wouters wrote:
On Thu, Feb 23, 2006 at 05:25:30PM +1300, Greg Ewing wrote:
As an aside, is there any chance that this could be
changed in 3.0? I.e. have the for-loop create a new
* The following reply is a rather longer than I intended explanation of
why codings (and how they differ) like 'rot' aren't the same thing as
pure unicode codecs and probably should be treated differently.
If you already understand that, then I suggest skipping this. But if
you like detailed
On 2/20/06, Jiwon Seo [EMAIL PROTECTED] wrote:
Regarding this Grammar change; (last October)
from argument: [test '=' ] test [gen_for]
to argument: test [gen_for] | test '=' test ['(' gen_for ')']
- to raise error for bar(a = i for i in range(10)) )
I think we should
Michael Hoffman [EMAIL PROTECTED] wrote:
Am I the only one who finds the use of self on a classmethod to be
incredibly confusing? Can we please follow PEP 8 and use cls
instead?
Sorry, using self was an oversight. It should be cls, IMO.
Neil
___
Stephen J. Turnbull wrote:
the kind of text for which Unicode was designed is normally produced
and consumed by people, who wll pt up w/ ll knds f nnsns. Base64
decoders will not put up with the same kinds of nonsense that people
will.
The Python compiler won't put up with that sort of
Raymond Hettinger wrote:
Code that
uses next() is more understandable, friendly, and readable without the
walls of underscores.
There wouldn't be any walls of underscores, because
y = x.next()
would become
y = next(x)
The only time you would need to write underscores is
when
Jeremy Hylton wrote:
The more practical complaint is that list comprehensions use the same
namespace as the block that contains them.
... but I suspect we're stuck with the
current behavior for backwards compatibility reasons.
There will be no backwards compatibility in 3.0,
so perhaps
[Neal Norwitz]
Martin and I were talking about dropping support for older versions of
Windows (of the non-NT flavor). We both thought that it was
reasonable to stop supporting Win9x (including WinME) in Python 2.6.
I updated PEP 11 to reflect this.
It's OK by me, but I have the same question
Neil Schemenauer wrote:
Ron Adam [EMAIL PROTECTED] wrote:
Why was it decided that the unicode encoding argument should be ignored
if the first argument is a string? Wouldn't an exception be better
rather than give the impression it does something when it doesn't?
From the PEP:
14 matches
Mail list logo
