Thomas Wouters wrote:
> I added webstats for all subsites of python.org:
>
> http://www.python.org/webstats/
what's that "Java/1.4.2_03" user agent doing? (it's responsible for
10% of all hits in january/february, and 20% of the hits today...)
___
Fredrik Lundh schrieb:
>should we perhaps switch to (careful use of) C++ in 3.0 ?
>
>
>
I can't see many advantages in moving to C++, but a lot of disadvantages:
- Size increase, especially when we start using templates
- Performance decrease
- Problems with name mangling together with dynamic
"Thomas Wouters" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I added webstats for all subsites of python.org:
>
> http://www.python.org/webstats/
> http://beta.python.org/webstats/
> http://bugs.python.org/webstats/
> http://planet.python.org/webstats/
> http://docs.python.org/w
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> And you don't think there are many different
> types of iterables? You might as well argue
> that we don't need len() because it "only
> applies to sequences".
Since you mention it..., many people *have* asked on c.l.p wh
[Alex Martelli]
>> We stole list comprehensions and genexps from Haskell
[Greg Ewing]
> The idea predates Haskell, I think. I first saw it in
> Miranda, and it may have come from something even
> earlier -- SETL, maybe?
Haskell indeed took list comprehensions from SETL. SETL in turn
adopted them
[Alex Martelli]
>> We stole list comprehensions and genexps from Haskell
[Greg Ewing]
> The idea predates Haskell, I think. I first saw it in
> Miranda, and it may have come from something even
> earlier -- SETL, maybe?
Haskell indeed took list comprehensions from SETL. SETL in turn took
them fr
I finally took the time to set up webalizer on dinsdale.python.org,
after the move of the web content from creosote.python.org to
dinsdale.python.org last October or November. The apache logs on
dinsdale don't go back farther than 25 December, looks like, though.
None of my backups have 'em either.
These .py and .txt files don't have the svn:eol-style property set.
I'm not sure they all _should_, though. Some of them are particularly
bizarre, e.g. Lib\email\test\data\msg_26.txt has the svn:mime-type
property set to application/octet-stream (WTF?), and then svn refuses
to set the eol-style p
test test_pep352 failed -- Traceback (most recent call last):
File "C:\Code\python\lib\test\test_pep352.py", line 54, in test_inheritance
self.fail("%s not a built-in exception" % exc_name)
AssertionError: WindowsError (Windows) not a built-in exception
___
>> -1 on the silly renaming to __next__ and adding __builtin__.next().
>> We have len() because it applies to many different object types.
>> In contrast, next() would apply only to iterables.
[Greg Ewing]
> And you don't think there are many different
> types of iterables?
Um, I meant iterators
Raymond Hettinger wrote:
> -1 on the silly renaming to __next__ and adding __builtin__.next().
> We have len() because it applies to many different object types.
> In contrast, next() would apply only to iterables.
And you don't think there are many different
types of iterables? You might as well
Fredrik Lundh wrote:
> should we perhaps switch to (careful use of) C++ in 3.0 ?
I worry that if the Python core becomes dependent
on C++, it will force all extensions to be written
in C++, too.
Not only is this inconvenient for people who don't
know C++ or prefer not to use it, but I suspect
th
Guido van Rossum wrote:
> Recent versions of GCC appear
> to be implementing C98 by default -- at least I didn't get complaints
> about declarations placed after non-declarations in the same block
> from any of the buildbot hosts...
As long as it doesn't complain when I *do* put all
my declaratio
Bill Janssen wrote:
> Well, I can certainly understand the bytes->base64->bytes side of
> thing too. The "text" produced is specified as using "a 65-character
> subset of US-ASCII", so that's really bytes.
But it then goes on to say that these same characters
are also a subset of EBCDIC. So it s
> As for the question of whether to switch to C++ in 3.0, I'd say
> probably not, as it's much harder to interface with C++ from other
> languages than to C.
An excellent point, and to my mind conclusive.
Bill
___
Python-Dev mailing list
Python-Dev@
On Feb 28, 2006, at 6:14 PM, Guido van Rossum wrote:
> On 2/28/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Fredrik Lundh wrote:
>>
My personal goal in life right now is to stay as
far away from C++ as I can get.
>>>
>>> so what C compiler are you using ?
>>
>> Gcc, mostly. I don't mind
Guido van Rossum wrote:
> > Fredrik Lundh wrote:
> >
> > > > My personal goal in life right now is to stay as
> > > > far away from C++ as I can get.
> > >
> > > so what C compiler are you using ?
> >
> > Gcc, mostly. I don't mind if it's capable of
> > compiling C++, as long as I can choose not t
[Greg Ewing]
> I'd still like to see next(x) / x.__next__() in
> some form in 3.0 for the sake of consistency,
> though.
+1 on modifying next() in Py3.0 to accept the send argument.
-1 on the silly renaming to __next__ and adding __builtin__.next().
We have len() because it applies to many differ
Greg Ewing wrote:
> Bill Janssen wrote:
>
> > bytes -> base64 -> text
> > text -> de-base64 -> bytes
>
> It's nice to hear I'm not out of step with
> the entire world on this. :-)
Well, I can certainly understand the bytes->base64->bytes side of
thing too. The "text" produced is specified as us
On 2/28/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Bill Janssen wrote:
>
> > bytes -> base64 -> text
> > text -> de-base64 -> bytes
>
> It's nice to hear I'm not out of step with
> the entire world on this. :-)
What Bill proposes makes sense to me.
--
--Guido van Rossum (home page: http://www.py
On 2/28/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
>
> > > My personal goal in life right now is to stay as
> > > far away from C++ as I can get.
> >
> > so what C compiler are you using ?
>
> Gcc, mostly. I don't mind if it's capable of
> compiling C++, as long as I can choos
Fredrik Lundh wrote:
> > My personal goal in life right now is to stay as
> > far away from C++ as I can get.
>
> so what C compiler are you using ?
Gcc, mostly. I don't mind if it's capable of
compiling C++, as long as I can choose not to
write any.
--
Greg Ewing, Computer Science Dept, +
Bill Janssen wrote:
> bytes -> base64 -> text
> text -> de-base64 -> bytes
It's nice to hear I'm not out of step with
the entire world on this. :-)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam!
Guido van Rossum wrote:
> On 2/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> > PEP 342 opted to extend the generator API instead (using "send") and leave
> > the
> > iterator protocol alone for the time being.
>
> One of the main reasons for this was the backwards compatibility
> problems at
On 2/28/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Notice that these semantics break some of the PEP examples. For
> example, the 'locked' and 'nested' classes now suppress exceptions,
> and it took a non-trivial study of their code to determine
> this. This seems to suggest that making supp
At 04:01 PM 2/28/2006, Guido van Rossum wrote:
>On 2/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> > > I just realized that there's a bug in the with-statement as currently
> > > checked in. __exit__ is supposed to re-raise the exception if there
> > > was one; if it
Guido van Rossum wrote:
>> If you changed your mind along the way, that should probably be explained in
>> the PEP somewhere :)
>
> I don't know that PEPs benefit from too much "on the one hand, on the
> other hand, on the third hand" or "and then I changed my mind, and
> then I changed it back, a
On 2/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I just realized that there's a bug in the with-statement as currently
> > checked in. __exit__ is supposed to re-raise the exception if there
> > was one; if it returns normally, the finally clause is NOT to re-raise
Guido van Rossum wrote:
> I just realized that there's a bug in the with-statement as currently
> checked in. __exit__ is supposed to re-raise the exception if there
> was one; if it returns normally, the finally clause is NOT to re-raise
> it. The fix is relatively simple (I believe) but requires
On 2/28/06, Mike Bland <[EMAIL PROTECTED]> wrote:
> On 2/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 2/28/06, Mike Bland <[EMAIL PROTECTED]> wrote:
> > > On 2/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > > I just realized that there's a bug in the with-statement as current
On 2/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/28/06, Mike Bland <[EMAIL PROTECTED]> wrote:
> > On 2/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I just realized that there's a bug in the with-statement as currently
> > > checked in. __exit__ is supposed to re-raise the
On 2/28/06, Mike Bland <[EMAIL PROTECTED]> wrote:
> On 2/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I just realized that there's a bug in the with-statement as currently
> > checked in. __exit__ is supposed to re-raise the exception if there
> > was one; if it returns normally, the fina
On 2/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I just realized that there's a bug in the with-statement as currently
> checked in. __exit__ is supposed to re-raise the exception if there
> was one; if it returns normally, the finally clause is NOT to re-raise
> it. The fix is relatively
I just realized that there's a bug in the with-statement as currently
checked in. __exit__ is supposed to re-raise the exception if there
was one; if it returns normally, the finally clause is NOT to re-raise
it. The fix is relatively simple (I believe) but requires updating
lots of unit tests. It'
On 2/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
> > Nick Coghlan wrote:
> >
> >> I wouldn't mind seeing one of the early ideas from PEP 340 being
> >> resurrected some day, such that the signature for the special method
> >> was "__next__(self, input)" and for the builtin "n
So I'm planning a 2.4.3c1 around the 22nd-23rd of March, with a 2.4.3
final a week later. This will be the first release since the svn
cutover, which should make things exciting.
This is to get things cleared out before we start the cycle of pain -
ahem - the 2.5 release cycle. A 2.4.4 would t
Neal Norwitz wrote:
> PEP 263 states that in Phase 2 the default encoding will be set to
> ASCII. Although the PEP is marked final, this isn't actually
> implemented. The warning about using non-ASCII characters started in
> 2.3. Does anyone think we shouldn't enforce the default being ASCII?
>
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> I wouldn't mind seeing one of the early ideas from PEP 340 being
>> resurrected some day, such that the signature for the special method
>> was "__next__(self, input)" and for the builtin "next(iterator,
>> input=None)"
>
> Aren't we getting an argu
38 matches
Mail list logo
