[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
> "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 r
> "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,
Gr
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
>
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
>>> binding for the loop variable on each iteratio
> Michael Chermside wrote:
>> The next() method of iterators was an interesting
>> object lesson. ... Since it was sometimes invoked by name
>> and sometimes by special mechanism, the choice was to use the
>> unadorned name, but later experience showed that it would have been
>> better the other wa
On 2/24/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > Michael Chermside wrote:
> >> The next() method of iterators was an interesting
> >> object lesson. ... Since it was sometimes invoked by name
> >> and sometimes by special mechanism, the choice was to use the
> >> unadorned name, but lat
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.
The Python 2.5 installer will present a warning message on the
Neal Norwitz wrote:
> 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.
>
> The Python 2.5 installer will
Georg Brandl wrote:
> Neal Norwitz wrote:
>
>> 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.
>>
>
On Fri, Feb 24, 2006, Michael Foord wrote:
> Georg Brandl wrote:
>> Neal Norwitz wrote:
>>
>>> 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 Pyth
On Fri, 24 Feb 2006 10:29:27 -0800, Aahz wrote:
> DOS has some actual utility for low-grade devices and is overall a
> simpler platform to deliver code for. At the standard 18-month release
> cycle, it will be beginning of 2008 for the release of 2.6, which is ten
> years after Win98.
The last W
On 2/24/06, Michael Foord <[EMAIL PROTECTED]> wrote:
> A lot of people are still using Windows 98. But I guess if noone is
> volunteering to maintain the code...
Agreed. If they're so keen on using an antiquated OS, perhaps they
would be perfectly happy using a matching Python version... Somehow
[Neal Norwitz wrote]
> 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.
Are there specific code areas in
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: http://www.taniquetil
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-lo
* 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 l
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 sh
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 defi
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
On 2/24/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> 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.
>
>
Neil Schemenauer wrote:
> 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
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:
There is no sane meaning th
[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 q
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:
27 matches
Mail list logo
