headers
James Y Knight | 1 Mar 2006 03:00

Re: str.count is slow


On Feb 28, 2006, at 6:14 PM, Guido van Rossum wrote:

> On 2/28/06, Greg Ewing <greg.ewing <at> canterbury.ac.nz> 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 to
>> write any.
>
> That's getting harder and harder though. 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...

I don't know whether you meant "C++98" or "C99" in the above, but the  
default is (mostly) C99, now. If you like, you can still tell it to  
compile in C89 mode, with --std=c89.

C99 contains some of the superficial C++ syntax changes such as //  
comments and declarations after non-declarations which have long been  
implemented as non-standard extensions, anyhow, but it's still  
nothing like C++.

As for the question of whether to switch to C++ in 3.0, I'd say
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bill Janssen | 1 Mar 2006 05:05
Favicon

Re: str.count is slow

> 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 <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Greg Ewing | 1 Mar 2006 05:13
Picon
Picon
Favicon

Re: bytes.from_hex()

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 seems to be
talking about characters as abstract entities here,
not as bit patterns.

Greg
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Greg Ewing | 1 Mar 2006 05:16
Picon
Picon
Favicon

Re: str.count is slow

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 declarations before my non-declarations, I can
live with that. :-)

--
Greg
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Greg Ewing | 1 Mar 2006 05:28
Picon
Picon
Favicon

Re: C++ for CPython 3? (Re: str.count is slow)

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
this would lead to some severe interoperability
problems.

On most platforms, C code will happily link to
just about anything else, but in my experience,
C++ code will only interoperate with other C++
code when it's compiled by exactly the same
compiler and uses the same runtime system.

For another thing, I'm not sure that C++
polymorphism is flexible enough to implement
Python's style of polymorphism. Think of all
the tricks we play with type objects -- allocating
them on the heap, extending them dynamically at
runtime, etc. In C++, classes aren't even available
as program-accessible entities.

So we'd end up implementing our own form of
dynamic dispatch anyway, and it would probably
look a lot like the current C-based type objects.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg Ewing | 1 Mar 2006 05:42
Picon
Picon
Favicon

Re: defaultdict and on_missing()

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 argue
that we don't need len() because it "only
applies to sequences".

There's a practical reason for using the
xxx(obj)/obj.__xxx__() pattern -- it provides
a lot more flexibility when it comes to
future extensions of the protocol. We've
used this to good effect already with iter(),
which uses __iter__ if it's available, else
falls back on another technique.

If we had used this pattern with next() from
the beginning then, for example, there would
have been no problem adding an argument to
next(), since the next() function could just
have been updated to look for __send__ or
something like that, and existing iterators
need not have been affected.

So the reason I'd like to see this changed
in 3.0 is not because of consistency for its
own sake, but because it would provide a
(Continue reading)

Permalink | Reply | 16 comments |
headers
Raymond Hettinger | 1 Mar 2006 06:43
Picon

Re: iterator API in Py3.0

>> -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 and suspect you meant the same -- iow, objects returned by 
iter(x) that are currently guaranteed to support __iter__() and next() methods 
(i.e. generator-iterators, not the generator-functions that create them).

> So the reason I'd like to see this changed
> in 3.0 is not because of consistency for its
> own sake, but because it would provide a
> better basis for future development.

YAGNI.  The hypothetical "future development" benefit is even more specious than 
the appeal for consistency.  Let's try to resist mucking-up this simple, 
elegant, and fast iterface by adding another level of indirection.  I'm 
strongly -1 on this proposal and will likely remain so until shown demonstrable 
benefits for real use cases that are compelling enough to warrant cluttering and 
slowing the iterator interface.

I usually let this sort of thing slide, but the iterator API is too important 
for trivial, incompatible, and damaging changes.   Looking back at Guido's 
original rationale for naming the method next() instead of __next__(), 
http://www.python.org/peps/pep-0234.html , it does not look like any of those 
reasons will cease to apply in Py3.0.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Tim Peters | 1 Mar 2006 07:00
Picon

New test failure on Windows

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
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Tim Peters | 1 Mar 2006 07:17
Picon

.py and .txt files missing svn:eol-style in trunk

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 property.

.\Lib\bsddb\test\test_1413192.py
.\Lib\email\test\data\msg_26.txt
.\Lib\email\test\data\msg_44.txt
.\Lib\encodings\utf_8_sig.py
.\Lib\test\bad_coding2.py
.\Lib\test\outstanding_bugs.py
.\Lib\test\test_defaultdict.py
.\Lib\test\test_exception_variations.py
.\Lib\test\test_pep263.py
.\Lib\test\test_platform.py
.\Lib\test\crashers\coerce.py
.\Lib\test\crashers\dangerous_subclassing.py
.\Lib\test\crashers\infinite_rec_1.py
.\Lib\test\crashers\infinite_rec_2.py
.\Lib\test\crashers\infinite_rec_3.py
.\Lib\test\crashers\infinite_rec_4.py
.\Lib\test\crashers\infinite_rec_5.py
.\Lib\test\crashers\loosing_dict_ref.py
.\Lib\test\crashers\modify_dict_attr.py
.\Lib\test\crashers\recursive_call.py
.\Lib\test\crashers\weakref_in_del.py
.\Lib\test\crashers\xml_parsers.py
.\Lib\xmlcore\etree\cElementTree.py
.\Modules\zlib\algorithm.txt
(Continue reading)

Permalink | Reply | 4 comments |
headers
Thomas Wouters | 1 Mar 2006 07:51
Favicon
Gravatar

www.python.org et al.

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. I didn't bother regenerate the
stats from the logfiles on creosote.python.org because of that, since
there would be a two-month gap. We can still compare the last two
month's of data to whatever we'll be generating once beta.python.org
is final :-) And if anyone happens to have the older dinsdale logs
somewhere, I can still regenerate the main stats.

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/webstats/
http://doc.python.org/webstats/
http://svn.python.org/webstats/

and even

http://www.pythonlabs.com/webstats/ (not working right now, not sure why)
http://www.jpython.org/webstats/ (not working because of the global redirect)

I think I'll merge doc.python.org and docs.python.org tomorrow. (And
maybe add the doc/docs.python.org stats to www.python.org's stats
after prepending '/doc' to all URLs, but that's a fair bit of work.)
I'd also like to add a stats.python.org with direct listings of all
(Continue reading)

Permalink | Reply | 5 comments |

Gmane