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:
[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
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
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
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.
>
>
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
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
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
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
___
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
* 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/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
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
[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
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
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 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
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.
>>
>
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
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
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
> 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 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
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
>
> "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
> "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
[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
27 matches
Mail list logo
