[Python-Dev] Arena-freeing obmalloc ready for testing

[Tim Peters]

I spent most of my PyCon sprint time so far working on Evan Jones's
arena-freeing obmalloc patch:

http://www.python.org/sf/1123430

It's ready to test now!  The work is on a branch:

svn+ssh://svn.python.org/python/branches/tim-obmalloc

Only obmalloc.c is changed in that branch, and you can get it directly from:




You should be able to drop it into a current trunk checkout without problems.

Why it's still on a branch:  obmalloc has heroically optimized "hot
paths" covering the most frequent cases, and Evan's patch kindly ;-)
avoided slowing those paths directly.  So I wasn't much worried about
speed.  However, "head review" revealed that the extremely hot-path
Py_ADDRESS_IN_RANGE() macro was no longer correct in all cases (in the
presence of free()'ing arenas), and I couldn't repair that without
adding an additional test+branch to the macro's expansion.  That means
the jury is out on speed implications, and anyone who cares about that
(including me) gets about a week to measure it (I don't want to drag
this out beyond that).

I'm optimistic, because the new test compares a quantity already being
tested by the macro, a second time against 0, and it's hard to get
cheaper than that.  However, the new branch isn't predictable, so who
knows?

Other info:  the debug "pymalloc stats" output is expanded, to track
and report the current # of arenas allocated, the highwater mark
(largest value ever seen) for the current # of arenas allocated, the
total # of times an arena was allocated, and the total # of times an
arena was free'd.

Here's output from the end of a -uall debug-build test run(*) w/ the
PYTHONMALLOCSTATS
envar set, showing that arenas do get reclaimed:

# times object malloc called   =  138,387,107
# arenas allocated total   =1,841
# arenas reclaimed =1,733
# arenas highwater mark=  212
# arenas allocated current =  108

(*) The branch was created before the sprints started, so this
   doesn't reflect the current trunk tests.

   test_subprocess was excluded, because it hangs with
   PYTHONMALLOCSTATS set (the debug output gets written
   to stderr, and at least one of the test_subprocess tests
   doesn't expect anything in the spawned process's stderr,
   the pipe it sets up for stderr fills, and both processes
   deadlock).

For simpler fun, run this silly little program, and look at memory
consumption at the prompts:

"""
x = []
for i in xrange(100):
   x.append([])
raw_input("full ")
del x[:]
raw_input("empty ")
"""

For example, in a release build on WinXP, VM size is about 48MB at the
"full" prompt, and drops to 3MB at the "empty" prompt.  In the trunk
(without this patch), VM size falls relatively little from what it is
at the "full" prompt (the contiguous vector holding a million
PyObject* pointers is freed, but the obmalloc arenas holding a
million+1 list objects are never freed).

For more info about the patch, see Evan's slides from _last_ year's PyCon:

http://evanjones.ca/memory-allocator.pdf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Making staticmethod objects callable?

[Nicolas Fleury]

Guido van Rossum wrote:
> In which context did you find a need for defining a static method and
> calling it inside the class definition? I'm guessing that what you're
> playing dubious scoping games.

I'm not.  I almost never use staticmethod actually.  I find them not 
very pythonic, in my humble own definition of pythonic.

But since staticmethod is a standard built-in, I considered valid the 
question of a programmer relatively new to Python (but obviously 
appreciating its dynamic nature) wondering why calling a static method 
inside a class definition doesn't work.  A use case is not hard to 
imagine, especially a private static method called only to build a class 
attribute.

I don't know the philosophy behind making staticmethod a built-in 
(instead of a function in a module only used in specific occasions), but 
my guess was that what is normal scoping/regrouping in Java/C++/C# was 
worth common use support in Python.  But your comment about "dubious 
scoping games" makes me think I, again, didn't guess right;)

So yes, I'm proposing something I'll probably never use, but I think 
would make Python more "welcoming".

Regards,
Nicolas

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bytes.from_hex()

[Josiah Carlson]

Greg Ewing <[EMAIL PROTECTED]> wrote:
>u = unicode(b)
>u = unicode(b, 'utf8')
>b = bytes['utf8'](u)
>u = unicode['base64'](b)   # encoding
>b = bytes(u, 'base64') # decoding
>u2 = unicode['piglatin'](u1)   # encoding
>u1 = unicode(u2, 'piglatin')   # decoding

Your provided semantics feel cumbersome and confusing to me, as compared
with str/unicode.encode/decode() .

 - Josiah

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] When will regex really go away?

[Neal Norwitz]

On 1/24/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/24/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > I ran Fredrik's listmodules script in my current sandbox and got a
> > deprecation warning for the regex module.  According to PEP 4 it is already
> > obsolete.  I saw nothing there about the timeframe for actual removal.  Will
> > it ever go away?
>
> ASAP please!
>
> PEP 4 lists these that were already obsolete in 2.0:
>
> addpack, cmp, cmpcache, codehack, dircmp, dump, fmt, lockfile,
> newdir, Para, poly, regex, regsub, tb, timing, util, whatsound,
> tzmod, find, grep, packmail, ni, rand, soundex, cl, sv
>
> of these, regex, regsub, and timing are still importable in 2.4 (I
> don't have a 2.5 handy here at Google, and my home machine seems
> inaccessible). ISTM these last three can safely be dropped now.

I'll do this, except there are some issues:

 * Lib/reconvert.py imports regex.  Ok to move regex,regsub,recovert to lib-old?
 * ./Demo/pdist/rcslib.py & ./Demo/sockets/mcast.py import regsub.  I
don't know how to convert the uses of regsub to re, any volunteers? 
Shall I just add doc that they are broken?
 * A whole mess of Demos and Tools use regex.  What to do about them?
./Demo/tkinter/guido/mbox.py:import regex
./Demo/tkinter/guido/ManPage.py:import regex
./Demo/tkinter/guido/tkman.py:import regex
./Demo/pdist/makechangelog.py:import regex
./Demo/scripts/mboxconvert.py:import regex
./Demo/scripts/ftpstats.py:import regex
./Demo/scripts/eqfix.py:import regex
./Demo/scripts/update.py:import regex
./Tools/scripts/pathfix.py:import regex
./Tools/scripts/fixcid.py:import regex
./Tools/scripts/classfix.py:import regex
./Tools/scripts/objgraph.py:import regex
./Tools/scripts/methfix.py:import regex
./Tools/scripts/pdeps.py:import regex
./Tools/scripts/ifdef.py:import regex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Weekly Python Patch/Bug Summary

[Kurt B. Kaiser]

Patch / Bug Summary
___

Patches :  382 open ( -3) /  3079 closed (+12) /  3461 total ( +9)
Bugs:  880 open (+16) /  5624 closed ( +3) /  6504 total (+19)
RFE :  211 open ( +0) /   201 closed ( +1) /   412 total ( +1)

New / Reopened Patches
__

PEP 357 --- adding nb_index  (2006-02-21)
   http://python.org/sf/1436368  opened by  Travis Oliphant

Test of PEP 357  (2006-02-21)
CLOSED http://python.org/sf/1436377  opened by  Travis Oliphant

Size of time_t changed to 64 bits in MSVC++ 2005 CRT  (2006-02-23)
   http://python.org/sf/1437769  opened by  Atul Varma

dict.getdefault() implementation  (2006-02-24)
CLOSED http://python.org/sf/1438113  opened by  Barry A. Warsaw

PEP 0328 (relative import) implementation  (2006-02-24)
CLOSED http://python.org/sf/1438387  opened by  Thomas Wouters

Patch for bug  1438185: os.renames deletes junction points  (2006-02-26)
   http://python.org/sf/1439312  opened by  Grant Olson

issue syntax warning for with becoming a keyword  (2006-02-27)
CLOSED http://python.org/sf/1439917  opened by  Neal Norwitz

Add col information to parse & ast nodes  (2006-02-28)
CLOSED http://python.org/sf/1440601  opened by  John Ehresman

asdl generation changes  (2006-02-28)
CLOSED http://python.org/sf/1440620  opened by  John Ehresman

Stop help() crashing with incorrect privileges  (2006-03-01)
   http://python.org/sf/1440660  opened by  splitscreen

Inconsistency in os' function naming  (2006-03-01)
   http://python.org/sf/1440928  opened by  Frederik 'Freso' S. Olesen

Updated Demo\parser\unpack.py  (2006-03-02)
   http://python.org/sf/1441452  opened by  John Ehresman

Patches Closed
__

Implement PEP 357 for real  (2006-02-11)
   http://python.org/sf/1429591  deleted by  teoliphant

Test of PEP 357  (2006-02-21)
   http://python.org/sf/1436377  deleted by  teoliphant

add collections.defaultdict  (2006-02-17)
   http://python.org/sf/1433928  closed by  gvanrossum

dict.getdefault() implementation  (2006-02-24)
   http://python.org/sf/1438113  closed by  gvanrossum

PEP 0328 (relative import) implementation  (2006-02-24)
   http://python.org/sf/1438387  closed by  nnorwitz

PyThreadState_Delete doesnt' clean autoTLSkey  (2006-01-23)
   http://python.org/sf/1413181  closed by  tim_one

issue syntax warning for with becoming a keyword  (2006-02-27)
   http://python.org/sf/1439917  closed by  nnorwitz

PEP 343 with statement  (2006-02-21)
   http://python.org/sf/1435715  closed by  gvanrossum

Inline Lambda patch  (2006-02-18)
   http://python.org/sf/1434008  closed by  loewis

More easily extensible logging module  (2006-01-22)
   http://python.org/sf/1412054  closed by  vsajip

Add col information to parse & ast nodes  (2006-02-28)
   http://python.org/sf/1440601  closed by  loewis

asdl generation changes  (2006-02-28)
   http://python.org/sf/1440620  closed by  jpe

new-style exceptions  (2005-01-18)
   http://python.org/sf/1104669  closed by  bcannon

unknown locale: lt_LT (patch)  (2005-02-08)
   http://python.org/sf/1118341  closed by  nerijus

New / Reopened Bugs
___

urllib has trouble with Windows filenames  (2006-02-21)
   http://python.org/sf/1436428  opened by  Donovan Eastman

length of unicode string changes print behaviour  (2006-02-22)
   http://python.org/sf/1436532  opened by  James

urllib.py overwrite HTTPError code with 200  (2005-04-06)
   http://python.org/sf/1178141  reopened by  gbrandl

Problem parsing cmdline parameter quoted with a trailing \  (2006-02-22)
CLOSED http://python.org/sf/1436900  opened by  Wai Yip Tung

"continue" in .pdbrc has no effect  (2006-02-22)
   http://python.org/sf/1437051  opened by  Coolheads Consulting

can't send files via ftp on my MacOS X 10.3.9  (2006-02-23)
   http://python.org/sf/1437614  opened by  Li Quid

robotparser crashes if robots.txt contains non-ASCII  (2006-02-23)
   http://python.org/sf/1437699  opened by  osvenskan

Problems w/ expat 1.95.7 vs. Python 2.4  (2006-02-23)
   http://python.org/sf/1437785  opened by  Skip Montanaro

os.renames() crashes NTFS junctions  (2006-02-24)
   http://python.org/sf/1438185  opened by  Daniel Rohlfing

shutil.move raises OSError when copystat fails  (2006-02-25)
   http://python.org/sf/1438480  opened by  Joe Wreschnig

modules search in help() crashes on insufficient file perms  (2006-02-25)
   http://python.org/sf/1438537  opened by  A. Coder

test -e is not portable (Solaris 2.7)  (2006-02-27)
   http://python.org/sf/1439538  opened by  HÃ¥vard Tveite

file to store pickled object should be opened in binary mode  (2006-02-27)
   http://python.org/sf/1439659  opened by  Raghuram Devarakonda

email.Generator is not idempotent  (2006-02-28)
   http://python.org/sf/1440472  opened by  WonderClown

UnicodeWriter: "utf-8" hardcoded instead of self.encoding  (2006-03-01)
   http://

[Python-Dev] DRAFT: python-dev Summary for 2006-01-16 through 2005-01-31

[Tony Meyer]

Here's the draft for the second half of January.  First half of
February on its way soon.  Any
suggestions/corrections/additions/comments welcome.  Thanks!  -TAM

=
Announcements
=

-
Google summer internships
-

Google is looking to fill an unprecedented number of `student intern
positions`_ this (US) summer, at several US locations (Mountain View,
Santa Monica, Kirkland (Wash.), and New York).  The perks are
incredible, and Google is not just looking for software development
interns - there are also product management positions, and UI design
and usability analyst positions.

Contributing thread:

 - `Know anyone interested in a Google internship?
`__

 .. _student intern positions: http://www.google.com/jobs/intern.html

[TAM]

---
Possible Summer of PyPy
---

Armin Rigo announced the possibility of a "Summer of PyPy", which
would follow the style of Google's "Summer of Code" in funding
students to work on various aspects of PyPy.  The possibility has not
been confirmed yet, but we'll let you know when there's more info.

Contributing thread:

 - `Summer of PyPy
`__

[SJB]

=
Summaries
=

---
Integers and strings in different bases
---

Alex Martelli requested the inverse of ``int(, )`` that
would convert an int into a string with digits in the appropriate
base. There was a lot of discussion of exactly where such
functionality should go. Among the suggested locations were:

* The str constructor, e.g. ``str(, )``
* A str classmethod, e.g. ``str.from_int(, )``
* An encoding method, e.g. ``str().encode("base")``
* A method on ints, e.g. ``.to_base()``
* A format code, e.g. ``"%b" % ``
* A builtin function, e.g. ``base(, )``
* A function in the math module, e.g. ``math.base(, )``

People seemed generally to like the builtin function or math module
function options, though there was some debate as to the best name for
the function.  Guido suggested letting the proposal sit for a week or
two to see if anyone could come up with a better name or suggest a
better location for the function.  (However, he seemed generally in
favor of the proposal, suggesting that hex() and oct() should be
deprecated and removed in a future version of Python.)  No decisions
had been made at the time this summary was written.

Contributing threads:

 - `str with base
`__

[SJB]


PEP 355: Path - Object oriented filesystem paths


Björn Lindqvist resuscitated the idea of incorporating a Path class
based on Jason Ordenorff's path module to the standard library by
creating `PEP 355`_.  There was some general discussion (and
corresponding PEP changes), with much discussion centred on the use of
"/" as a join-with-separator operator, which was eventually dropped
from the PEP.

More discussion considered whether Path should subclass string or not.
 Subclassing string provides the advantage that Paths can be used in
the majority of places where strings are currently used, without
modification.  However, there are many methods of strings that do not
seem appropriate for Path objects.  Jason Orendorff would prefer for
Paths to not subclass strings, and a new format specifier (e.g. for
PyArg_ParseTuple()) be created for use with Paths.

There was general agreement that the utility of the module would be
highest when Path objects could be seamlessly used where string paths
were previous used.  The debate centred on whether subclassing string
was the best way to do this or not.  Path objects clearly are not
string objects (e.g. __iter__ and join() are nonsensical with paths). 
Changing the C API so that Paths are accepted where necessary was the
suggested solution, although the PEP (at the time of writing the
summary) still subclasses Path from string.

Changing the methods from the names used by the os module and Jason's
module to ones that conform to PEP 8 was recommended.  Jason explained
that the reason that there is so much cruft in his path module is that
the design is heavily skewed toward people already familiar with the
existing standard library equivalents.  He feels that a standard
library Path class should have different design goals: less
redundancy, fewer methods, and PEP 8 compliant names.

 .. _PEP 355: http://www.python.org/peps/pep-0355.html

Contributing threads:

 - `The path module PEP
`__
 - `/ as path join operator (was: Re: The path module PEP)
`__
 - `/ as path join operator

Re: [Python-Dev] bytes.from_hex()

[Greg Ewing]

Ron Adam wrote:

> 1. We can specify the operation and not be sure of the resulting type.
> 
>*or*
> 
> 2. We can specify the type and not always be sure of the operation.
> 
> maybe there's a way to specify both so it's unambiguous?

Here's another take on the matter. When we're doing
Unicode encoding or decoding, we're performing a
type conversion. The natural way to write a type
conversion in Python is with a constructor. But we
can't just say

   u = unicode(b)

because that doesn't give enough information. We want
to say that b is really of type e.g. "bytes containing
utf8 encoded text":

   u = unicode(b, 'utf8')

Here we're not thinking of the 'utf8' as selecting an
encoder or decoder, but of giving extra information
about the type of b, that isn't carried by b itself.

Now, going in the other direction, we might think to
write

   b = bytes(u, 'utf8')

But that wouldn't be right, because if we interpret this
consistently it would mean we're saying that u contains
utf8-encoded information, which is nonsense. What we
need is a way of saying "construct me something of type
'bytes containing utf8-encoded text'":

   b = bytes['utf8'](u)

Here I've coined the notation t[enc] which
evaluates to a callable object which constructs an
object of type t by encoding its argument according
to enc.

Now let's consider base64. Here, the roles of bytes
and unicode are reversed, because the bytes are just
bytes without any further interpretation, whereas
the unicode is really "unicode containing base64
encoded data". So we write

   u = unicode['base64'](b)   # encoding

   b = bytes(u, 'base64') # decoding

Note that this scheme is reasonably idiot-proof, e.g.

   u = unicode(b, 'base64')

results in a type error, because this specifies
a decoding operation, and the base64 decoder takes
text as input, not bytes.

What happens with transformations where the input and
output types are the same? In this scheme, they're
not really the same any more, because we're providing
extra type information. Suppose we had a code called
'piglatin' which goes from unicode to unicode. The
types involved are really "text" and "piglatin-encoded
text", so we write

   u2 = unicode['piglatin'](u1)   # encoding

   u1 = unicode(u2, 'piglatin')   # decoding

Here you won't get any type error if you get things
backwards, but there's not much that can be done
about that. You just have to keep straight which
of your strings contain piglatin and which don't.

Is this scheme any better than having encode and
decode methods/functions? I'm not sure, but it
shows that a suitably enhanced notion of "data
type" can be used to replace the notions of
encoding and decoding and maybe reduce potential
confusion about which direction is which.

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | Carpe post meridiam! |
Christchurch, New Zealand  | (I'm not a morning person.)  |
[EMAIL PROTECTED]  +--+
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] test_compiler failure

[Guido van Rossum]

Thanks! This was due to a bug in the code for creating the AST for an
expr-less yield.
Fixed in r42772.

On 3/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I just found that test_compiler fails on test_contextlib.py.
> To reproduce the failure, run
>
> from compiler import compileFile
> compileFile("Lib/test/test_contextlib.py")

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] defaultdict and on_missing()

[Greg Ewing]

Guido van Rossum wrote:

> str.join() is an interesting case...

 > Making it a
> string method is arguably the right thing to do, since this operation
> only makes sense for strings. 

 > The type of such a polymorphic function is easily specified:
> join(sequence[T], T) -> T, where T is a string-ish type.

I'd say it makes sense for any type that supports
concatenation (maybe that's what you mean by "string-ish"?)

This looks like a case where the xxx()/__xxx__() pattern
could be of benefit. Suppose there were a function

   def join(seq, sep):
 if hasattr(sep, '__join__'):
   return sep.__join__(seq)
 else:
   # generic implementation

Then you could get nice fast type-specific implementations
for strings, bytes, etc., without being limited to those
types.

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | Carpe post meridiam! |
Christchurch, New Zealand  | (I'm not a morning person.)  |
[EMAIL PROTECTED]  +--+
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bytes.from_hex()

[Ron Adam]

Greg Ewing wrote:
> Ron Adam wrote:
> 
>> While playing around with the example bytes class I noticed code reads 
>> much better when I use methods called tounicode and tostring.
>>
>> b64ustring = b.tounicode('base64')
>> b = bytes(b64ustring, 'base64')
> 
> I don't like that, because it creates a dependency
> (conceptually, at least) between the bytes type and
> the unicode type. And why unicode in particular?
> Why should it have a tounicode() method, but not
> a toint() or tofloat() or tolist() etc.?

I don't think it creates a dependency between the types, but it does 
create a stronger relationship between them when a method that returns a 
fixed type is used.

No reason not to other than avoiding having methods that really aren't 
needed. But if it makes sense to have them, sure.  If a codec isn't 
needed probably using a regular constructor should be used instead.


>> I'm not suggesting we start using to-type everywhere, just where it 
>> might make things clearer over decode and encode.
> 
> Another thing is that it only works if the codec
> transforms between two different types. If you
> have a bytes-to-bytes transformation, for example,
> then
> 
>   b2 = b1.tobytes('some-weird-encoding')
> 
> is ambiguous.

Are you asking if it's decoding or encoding?

   bytes to unicode ->  decoding
   unicode to bytes ->  encoding

   bytes to bytes -> ?

Good point, I think this defines part the difficulty.

1. We can specify the operation and not be sure of the resulting type.

   *or*

2. We can specify the type and not always be sure of the operation.

maybe there's a way to specify both so it's unambiguous?


Ron






___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] defaultdict and on_missing()

[Guido van Rossum]

On 3/1/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> But moving over to more attributes for how we access basic interfaces
> seems great to me.

We shouldn't approach this as "methods good, functions bad" -- nor the
opposite, for that matter.

When all things are equal, I'd much rather do usability studies to
find out what newbies (who haven't been given the OO kool-aid yet)
find easier. For example, math functions are typically written as
sin(x) -- I wouldn't want to switch that to x.sin() and I think most
people would agree.

But often, all things aren't equal. Sometimes, a single algorithm can
be applied to a large set of different types, and then making it a
method is a waste (forcing each type to reimplement the same
algorithm). sin() is actually an example of this (since it applies to
int, long and float). Other times, the same conceptual operation must
be implemented differently for each type, and then a method makes more
sense. I like to think of list.sort() as an example of this -- sorting
algorithms are tightly coupled to internal data representation, and a
generic sort function for mutable sequences would likely be of
theoretical interest only -- in practice it would be much slower than
an implementation that can make use of the internal representation
directly.

Operations with two or more arguments are often better expressed as
function calls -- for example, map() and filter() don't make much
sense as methods on callables or sequences.

str.join() is an interesting case, where usability studies may be
necessary. I've often been asked why this isn't a list method -- but
of course that would be less general, since joining strings applies
equally well to other types of sequeces (and iterables). Making it a
string method is arguably the right thing to do, since this operation
only makes sense for strings. But many people (not me!) find the ",
".join(seq) notation hard to read; some other languages use a built-in
function join(seq, str) instead, which is arguably more readable. The
type of such a polymorphic function is easily specified:
join(sequence[T], T) -> T, where T is a string-ish type. (It should
make sense for T==bytes as well; I'm not so sure about T==list though.
:-)

One problem with the methods approach is that there's less pressure to
use the same API for all object types (especially with duck typing).
For an example of methods gone horribly wrong, look at Java, where you
have .length, String.length(), and Collection.size().
Give me len() any day. I believe Ruby has similar confusing diversity
for looping (each/forEach).

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bytes thoughts

[Greg Ewing]

Baptiste Carvello wrote:

> while manipulating binary data will happen mostly with bytes objects, some 
> operations are better done with ints, like the bit manipulations with the 
> &|~^ 
> operators.

Why not just support bitwise operations directly
on the bytes object?

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | Carpe post meridiam! |
Christchurch, New Zealand  | (I'm not a morning person.)  |
[EMAIL PROTECTED]  +--+
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)

[martin]

Zitat von Michael Urman <[EMAIL PROTECTED]>:

> On 3/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> How would this be accomplished - by a function with a ton of optional
> templated arguments?

That's how I would do it. Actually, I would have PyArg_ParseTuple
overloaded with different numbers of arguments, say 0..64. Each
of them would be a template.

> Only true when the rules are consistent with what smart pointers or
> the like do. When there's more than a single rule, this goes out the
> window because you have to use the correct smart class...

Sure. You have to use PyObject* now, so changing to usage of PyObject_ptr
wouldn't be that bad. Remember, we are talking about extension modules
*to python* here.

> ...and exceptions make it impossible to not use smart classes. Since
> there isn't a nested level of C for each function call in Python, I
> don't see how exceptions in the implementation language would help
> exceptions in Python. Do I misunderstand your point, or is there some
> really cool trick I'm missing?

Instead of checking for a NULL return value on all functions, a Python
exception could be expressed (on the C++ stack) as a C++ exception.

So instead of writing

n = PyString_FromString(name);
if (n == NULL)
return NULL;
for (ml = methods; ml->ml_name != NULL; ml++) {
if ((ml->ml_flags & METH_CLASS) ||
(ml->ml_flags & METH_STATIC)) {
PyErr_SetString(PyExc_ValueError,
"module functions cannot set"
" METH_CLASS or METH_STATIC");
Py_DECREF(n);
return NULL;
}
v = PyCFunction_NewEx(ml, passthrough, n);
if (v == NULL) {
Py_DECREF(n);
return NULL;
}
if (PyDict_SetItemString(d, ml->ml_name, v) != 0) {
Py_DECREF(v);
Py_DECREF(n);
return NULL;
}
Py_DECREF(v);
}

Py_DECREF(n);

you would write

n = PyString_FromString(name);
for (ml = methods; ml->ml_name != NULL; ml++) {
if ((ml->ml_flags & METH_CLASS) ||
(ml->ml_flags & METH_STATIC))
raise new PyExc_ValueError(PyExc_ValueError,
"module functions cannot set"
" METH_CLASS or METH_STATIC");
v = PyCFunction_NewEx(ml, passthrough, n);
PyDict_SetItemString(d, ml->ml_name, v);
}

> (To explain my bias, I'm against the idea of the C++ rewrite as I also
> fail to see the advantages outweighing the disadvantages, especially
> in light of the amount of rewriting necessary to see the "advantages"
> cited so far.)

That's why I'm explaining the advantages to you.

I'm not saying Python 3 should be written in C++, I'm only saying
that doing so would have not just disadvantages.

Regards,
Martin


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bytes.from_hex()

[Michael Urman]

[My apologies Greg; I meant to send this to the whole list. I really
need a list-reply button in GMail. ]

On 3/1/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> I don't like that, because it creates a dependency
> (conceptually, at least) between the bytes type and
> the unicode type.

I only find half of this bothersome. The unicode type has a pretty
clear dependency on the bytestring type: all I/O needs to be done in
bytes. Various APIs may mask this by accepting unicode values and
transparently doing the right thing, but from the theoretical
standpoint we pretend there is no simple serialization of unicode
values. But the reverse is not true: the bytestring type has no
dependency on unicode.

As a practicality vs purity, however, I think it's a good choice to
let the bytestring type have a tie to unicode, much like the str type
implicitly does now. But you're absolutely right that adding a
.tounicode begs the question why not a .tointeger?

To try to step back and summarize the viewpoints I've seen so far,
there are three main requirements.

  1) We want things that are conceptually text to be stored in memory
as unicode values.
  2) We want there to be some unambiguous conversion via codecs
between bytestrings and unicode values. This should help teaching,
learning, and remembering unicode.
  3) We want a way to apply and reverse compressions, encodings,
encryptions, etc., which are not only between bytestrings and unicode
values; they may be between any two arbitrary types. This allows
writing practical programs.

There seems to be little disagreement over 1, provided sufficiently
efficient implementation, or sufficient string powers in the
bytestring type. To satisfy both 2 and 3, there seem to be a couple
options. What other requirements do we have?

For (2):
  a) Restrict the existing helpers to be only bytestring.decode and
unicode.encode, possibly enforcing output types of the opposite kind,
and removing bytestring.encode
  b) Add new methods with these semantics, e.g. bytestring.udecode and
unicode.uencode

For (3):
  c) Create new helpers codecs.encode(obj, encoding, errors) and
codecs.decode(obj, encoding, errors)
  d) [Keep existing bytestring and unicode helper methods as is, and]
require use of codecs.getencoder() and codecs.getdecoder() for
arbitrary starting object types

Obviously 2a and 3d do not work together, but 2b and 3c work with
either complementary option. What other options do we have?

Michael
--
Michael Urman  http://www.tortall.net/mu/blog
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iterator API in Py3.

[Greg Ewing]

Raymond Hettinger wrote:

> [Greg Ewing]
> 
> > And you don't think there are many different
> > types of iterables?
> 
> Um, I meant iterators and suspect you meant the same --

The same comment applies either way. Each type of iterable
usually has its own corresponding type of iterator.

> YAGNI.  The hypothetical "future development" benefit is even more 
> specious than the appeal for consistency.

I've pointed out one possible use that would have
provided a benefit, so rather than YAGNI, I'd say
WACHUI (We Already Could Have Used It).

>  Let's try to resist 
> mucking-up this simple, elegant, and fast iterface by adding another 
> level of indirection.

There's already a level of indirection, because the
type creation machinery adds a descriptor to allow the
type slot to be called via .next() from Python. If there
were a next() function, that descriptor would not be needed.
So the total amount of indirection for built-in iterators
would remain the same.

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

The discussion in that PEP makes no mention of the flexibility
benefits of a next()/.__next__() combination. Mostly it
doesn't even discuss the combination at all, only the idea
of calling the method __next__(). The idea of a next() function
is only mentioned in a parenthetical comment in which the
sole reason for rejecting it is "it's too late, we've already
implemented it".

In 3.0 we will have a rare opportunity to revisit the idea
without the "it's too late" constraint. I'm suggesting we
give it careful consideration, because we probably won't
have another opportunity for quite a long time.

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | Carpe post meridiam! |
Christchurch, New Zealand  | (I'm not a morning person.)  |
[EMAIL PROTECTED]  +--+
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bytes.from_hex()

[Greg Ewing]

Ron Adam wrote:

> While playing around with the example bytes class I noticed code reads 
> much better when I use methods called tounicode and tostring.
> 
> b64ustring = b.tounicode('base64')
> b = bytes(b64ustring, 'base64')

I don't like that, because it creates a dependency
(conceptually, at least) between the bytes type and
the unicode type. And why unicode in particular?
Why should it have a tounicode() method, but not
a toint() or tofloat() or tolist() etc.?

> I'm not suggesting we start using to-type everywhere, just where it 
> might make things clearer over decode and encode.

Another thing is that it only works if the codec
transforms between two different types. If you
have a bytes-to-bytes transformation, for example,
then

   b2 = b1.tobytes('some-weird-encoding')

is ambiguous.

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | Carpe post meridiam! |
Christchurch, New Zealand  | (I'm not a morning person.)  |
[EMAIL PROTECTED]  +--+
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bytes.from_hex()

[Greg Ewing]

Bill Janssen wrote:

> No, once it's in a particular encoding it's bytes, no longer text.

The point at issue is whether the characters produced
by base64 are in a particular encoding. According to
my reading of the RFC, they're not.

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | Carpe post meridiam! |
Christchurch, New Zealand  | (I'm not a morning person.)  |
[EMAIL PROTECTED]  +--+
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)

[Michael Urman]

On 3/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> There are a few advantages, though, mainly:
> - increased type-safety, in particular for API that isn't type-checked
>   at all at the moment (e.g. PyArg_ParseTuple)

How would this be accomplished - by a function with a ton of optional
templated arguments? By some sort of TupleParser(tuple) >> var1 >>
var2 >> TupleParser::done?

> - more reliable reference counting, due to destructors of local
>   variables

Only true when the rules are consistent with what smart pointers or
the like do. When there's more than a single rule, this goes out the
window because you have to use the correct smart class...

> - "native" exception handling, making exceptions both less error-prone
>   and possible more efficient.

...and exceptions make it impossible to not use smart classes. Since
there isn't a nested level of C for each function call in Python, I
don't see how exceptions in the implementation language would help
exceptions in Python. Do I misunderstand your point, or is there some
really cool trick I'm missing?

(To explain my bias, I'm against the idea of the C++ rewrite as I also
fail to see the advantages outweighing the disadvantages, especially
in light of the amount of rewriting necessary to see the "advantages"
cited so far.)

Michael
--
Michael Urman  http://www.tortall.net/mu/blog
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bytes.from_hex()

[Greg Ewing]

Nick Coghlan wrote:

>ascii_bytes = orig_bytes.decode("base64").encode("ascii")
> 
>orig_bytes = ascii_bytes.decode("ascii").encode("base64")
> 
> The only slightly odd aspect is that this inverts the conventional meaning of 
> base64 encoding and decoding,

-1. Whatever we do, we shouldn't design things so
that it's necessary to write anything as
unintuitive as that.

We need to make up our minds whether the .encode()
and .decode() methods are only meant for Unicode
encodings, or whether they are for general
transformations between bytes and characters.

If they're only meant for Unicode, then bytes
should only have .decode(), unicode strings
should only have .encode(), and only Unicode
codecs should be available that way. Things
like base64 would need to have a different
interface.

If they're for general transformations, then
both types should have both methods, with the
return type depending on the codec you're
using, and it's the programmer's responsibility
to use codecs that make sense for what he's
doing.

But if they're for general transformations,
why limit them to just bytes and characters?
Following that through leads to giving *every*
object .encode() and .decode() methods. I
don't think we should go that far, but it's
hard to see where to draw the line. Are
bytes and strings special enough to justify
them having their own peculiar methods for
codec access?

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | Carpe post meridiam! |
Christchurch, New Zealand  | (I'm not a morning person.)  |
[EMAIL PROTECTED]  +--+
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Making staticmethod objects callable?

[Guido van Rossum]

On 3/1/06, Nicolas Fleury <[EMAIL PROTECTED]> wrote:
> The problem is that even after explaining descriptors (which IMHO can be
> a more advanced feature for newbies), you still need a workaround and
> you might end up with (or call __get__):
>
> class A:
>  def foo(): pass
>  bar = foo()
>  foo = staticmethod(foo)
>
> Which I find sad considering all the energy debating @decorators;)

In which context did you find a need for defining a static method and
calling it inside the class definition? I'm guessing that what you're
playing dubious scoping games.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bytes thoughts

[Baptiste Carvello]

some more thoughts about the bytes object:

1) it would be nice to have an trivial way to change a bytes object to an int / 
long, and vice versa.

Rationale:

while manipulating binary data will happen mostly with bytes objects, some 
operations are better done with ints, like the bit manipulations with the &|~^ 
operators. So we should make sure there is no impedance mismatch between those 
2 
ways of editing binary data. Getting an individual byte at a time is not 
sufficient, because the part of the data you want to edit might span over a few 
bytes, or simply fall across a byte boundary.

Toy implementation:

 >>> class bytes(list):
... def from_int(cls, value, length):
... return cls([(value >> 8*i) % 256 for i in range(length)[::-1]])
... from_int=classmethod(from_int)
... def int(self):
... return sum([256**i*n for i,n in enumerate(self[::-1])])
...
 >>>

The length argument to from_int is necessary to create a fixed number of bytes, 
event if those bytes are 0.

Use case:

let's say you have a binary record made of 7 bits of padding and 3x3 bytes of 
unix permissions. You want to change the user permissions, and store the record 
back to a bytes object:

 >>> record=bytes([1,36]) # this could be a slice of a preexisting bytes object
 >>> perms=record.int()
 >>> print oct(perms)
0444
 >>> perms &=~( 7 <<6 )   # clear the bits corresponding to user permissions
 >>> perms |=   6 <<6 # set the bits to the new value
 >>> print oct(perms)
0644
 >>> record=bytes.from_int(perms,2)
 >>>

2) a common case of interactive use is to display a bytes string as a character 
string in order to spot which parts are text. In this case you ignore non-ASCII 
characters, and replace everything that cannot be printed with a space (as some 
hex editors do). So you don't need to care about encodings.

 >>> import string
 >>> def printable(c):
... if not c in string.printable: return ' '
... if c.isspace(): return ' '
... return c
...
 >>> class bytes(list):
... def printable_ascii(self):
... return u"".join([printable(chr(i)) for i in nb])
...
 >>> nb=bytes([48,0,10,12,34,65,66])
 >>> print nb.printable_ascii()
0   "AB
 >>>

by the way, what will chr return in py3k ?

Cheers,
BC

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] test_compiler failure

[martin]

I just found that test_compiler fails on test_contextlib.py.
To reproduce the failure, run

from compiler import compileFile
compileFile("Lib/test/test_contextlib.py")

Regards,
Martin




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Webstats for www.python.org et al.

[Thomas Wouters]

On 3/1/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 01, 2006 Brett Cannon wrote:
> > On 2/28/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > > 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...)
> >
> > Most likely a crawler.
> >
> Youch, if I'm reading it right it consumed fully half of the bandwidth
> for today on python.org.  And what 1.6 million pages did it spider on
> the site last month?  Something smells broken.

Well, here's a hint. The file almost all of them are retrieving is
/topics/xml/dtds/xbel-1.0.dtd. They're all being redirected to
pyxml.sf.net, though. It's a lot of hits, but www.python.org doesn't
serve any actual pages, so the actual load is not that big (at least,
not for us :-) It skewes the statistics somewhat, maybe I should
ignore the whole /topics/xml tree in the stats.

--
Thomas Wouters <[EMAIL PROTECTED]>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slightly OT: Replying to posts

[Aahz]

On Wed, Mar 01, 2006, Talin wrote:
>
> However, I would like to be able to reply to posts in such a way as to 
> have them appear in the appropriate place in the thread hierarchy. Since 
> I don't have the original email, I cannot reply to it directly; instead 
> I have to create a new, non-reply email and send it to the list. Simply 
> editing the subject line to put "Re: subject" would seem to be insufficient.
> 
> Does anyone have a trick for managing this? Or is there a FAQ that 
> someone can point me to that addresses this issue?

If you're a die-hard hacker, you could parse the mailto: link at the top
of the message.  ;-)
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing."  --Alan Perlis
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] wiki as scratchpad

[Aahz]

On Wed, Mar 01, 2006, Jason Orendorff wrote:
>
> 3. I wrote a toy BytesIO class to go with the toy bytes object:
>   http://wiki.python.org/moin/BytesIO
> (I hope this isn't considered wiki abuse -- it seemed as worthy and
> relevant as most of what's in there.)

Au contraire!  This is precisely why a wiki is useful, to serve as a
community notepad.  Perhaps this specific case isn't a "good use", but it
absolutely does not count as abuse, and I encourage other people to make
similar use.


-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing."  --Alan Perlis
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] bytes thoughts

[Jason Orendorff]

1.  Maybe there should be a more obvious way to spell "bytes([0])*N". 
I went through "bytes([0]*N)" and "bytes('\0'*N)" before I realized
there was a memory-efficient way to do it.

1a. Likewise, slice-assignment nicely handles memmove(), but there's
no memset().

2.  Having a plural noun as a type name is awkward.  I wish we could
call it "buffer" (which, conveniently, also tells you that it's
mutable, even if you don't know the word "mutable" :-).  Alas.

3. I wrote a toy BytesIO class to go with the toy bytes object:
  http://wiki.python.org/moin/BytesIO
(I hope this isn't considered wiki abuse -- it seemed as worthy and
relevant as most of what's in there.)

-j
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Webstats for www.python.org et al.

[Jack Diederich]

On Wed, Mar 01, 2006 Brett Cannon wrote:
> On 2/28/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > 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...)
> 
> Most likely a crawler.
> 
Youch, if I'm reading it right it consumed fully half of the bandwidth
for today on python.org.  And what 1.6 million pages did it spider on
the site last month?  Something smells broken.

-Jack
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Making staticmethod objects callable?

[Nicolas Fleury]

Steven Bethard wrote:
> My only (mild) concern is that if staticmethod is going to get a
> __call__, I think classmethod should probably get one too.  Inside a
> class this doesn't make much sense:

I agree, make sense or not, if "@staticmethod def foo()" and a simple 
"def foo(self)" can all be called inside class definition, "@classmethod 
def foo(cls)" should too.

> Anyway, my feeling was that running into this behavior (that
> staticmethod is not callable) is a good oportunity to explain how
> descriptors work.  And once you start playing around with staticmethod
> and classmethod, you're going to need to learn that pretty soon
> anyway.  Hiding it a little bit longer with a __call__ method on
> staticmethod isn't going to help much in the long run.

The problem is that even after explaining descriptors (which IMHO can be 
a more advanced feature for newbies), you still need a workaround and 
you might end up with (or call __get__):

class A:
 def foo(): pass
 bar = foo()
 foo = staticmethod(foo)

Which I find sad considering all the energy debating @decorators;)

Regards,
Nicolas

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slightly OT: Replying to posts

[Terry Reedy]

"Talin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> Just a quick question about the mechanics of replying to this list.
>
> I am a subscriber to the list, however I much prefer readiing the list
> archives on the web instead of having the postings delivered to my email
> account. Because of this, I have delivery turned off in the mailing list
> preferences. I particularly dislike the idea of wasting bandwidth and
> disk space on something that I am not going to read.
>
> However, I would like to be able to reply to posts in such a way as to
> have them appear in the appropriate place in the thread hierarchy. Since
> I don't have the original email, I cannot reply to it directly; instead
> I have to create a new, non-reply email and send it to the list. Simply
> editing the subject line to put "Re: subject" would seem to be 
> insufficient.
>
> Does anyone have a trick for managing this? Or is there a FAQ that
> someone can point me to that addresses this issue?

Another alternative to your mailbox is to read the list as newsgroup 
gmane.comp.python.devel at gmane.news.org (free).  The gateway is 
bidirectional so properly threaded reply is easy, as this response 
indicates.

tjr



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Slightly OT: Replying to posts

[Barry Warsaw]

On Wed, 2006-03-01 at 11:00 -0800, Talin wrote:

> However, I would like to be able to reply to posts in such a way as to 
> have them appear in the appropriate place in the thread hierarchy. Since 
> I don't have the original email, I cannot reply to it directly; instead 
> I have to create a new, non-reply email and send it to the list. Simply 
> editing the subject line to put "Re: subject" would seem to be insufficient.
> 
> Does anyone have a trick for managing this? Or is there a FAQ that 
> someone can point me to that addresses this issue?

Try a newsreader and reading/replying via news.gmane.org

-Barry



signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Webstats for www.python.org et al.

[Brett Cannon]

On 2/28/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> 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...)
>

Most likely a crawler.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] defaultdict and on_missing()

[Brett Cannon]

On 2/28/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "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 why len() is a
> builtin function rather than a method of sequences (and other collections)
> (as .len, not .__len__).  Some have suggested that it should be the latter.
> The answers justifying the status quo have been twofold.
>
> 1.  Before 2.2, not all builtin sequence types had methods (str and tuple),
> so they could not have a .len method.  (This begs the question of why not,
> but that is moot now.)

Well, up until 2.2 you didn't have new-style classes which have a
common base class.  And if you wanted to do the length compilation
only when requested, you needed a method.  But now with object, we
could add extra smarts to __getattr__ or __getattribute__ so that if
``spam.len`` is requested  it calls ``spam.__next__()`` for you,
basically a poor-man's property.  Or, if ``spam.len`` is defined,
return that.

But moving over to more attributes for how we access basic interfaces
seems great to me.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Slightly OT: Replying to posts

[Talin]

Just a quick question about the mechanics of replying to this list.

I am a subscriber to the list, however I much prefer readiing the list 
archives on the web instead of having the postings delivered to my email 
account. Because of this, I have delivery turned off in the mailing list 
preferences. I particularly dislike the idea of wasting bandwidth and 
disk space on something that I am not going to read.

However, I would like to be able to reply to posts in such a way as to 
have them appear in the appropriate place in the thread hierarchy. Since 
I don't have the original email, I cannot reply to it directly; instead 
I have to create a new, non-reply email and send it to the list. Simply 
editing the subject line to put "Re: subject" would seem to be insufficient.

Does anyone have a trick for managing this? Or is there a FAQ that 
someone can point me to that addresses this issue?

-- Talin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bytes.from_hex()

[Michael Chermside]

I wrote:
> ... I will say that if there were no legacy I'd prefer the tounicode()
> and tostring() (but shouldn't itbe 'tobytes()' instead?) names for Python 3.0.

Scott Daniels replied:
> Wouldn't 'tobytes' and 'totext' be better for 3.0 where text == unicode?

Um... yes. Sorry, I'm not completely used to 3.0 yet. I'll need to borrow
the time machine for a little longer before my fingers really pick up on
the 3.0 names and idioms.

-- Michael Chermside

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bytes.from_hex()

[Scott David Daniels]

Chermside, Michael wrote:
> ... I will say that if there were no legacy I'd prefer the tounicode()
> and tostring() (but shouldn't itbe 'tobytes()' instead?) names for Python 3.0.

Wouldn't 'tobytes' and 'totext' be better for 3.0 where text == unicode?

-- 
-- Scott David Daniels
[EMAIL PROTECTED]

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bytes.from_hex()

[Bill Janssen]

> Huh... just joining here but surely you don't mean a text string that
> doesn't use every character available in a particular encoding is
> "really bytes"... it's still a text string...

No, once it's in a particular encoding it's bytes, no longer text.

As you say,
> Keep these two concepts separate and you should be right :-)

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)

[Walter Dörwald]

[EMAIL PROTECTED] wrote:

> Zitat von Ulrich Berning <[EMAIL PROTECTED]>:
> 
>> I can't see many advantages in moving to C++, but a lot of disadvantages:
> 
> There are a few advantages, though, mainly:
> - increased type-safety, in particular for API that isn't type-checked
>   at all at the moment (e.g. PyArg_ParseTuple)
> - more reliable reference counting, due to destructors of local
>   variables

Indeed, smart pointers should get rid of most reference counting problems.

> - "native" exception handling, making exceptions both less error-prone
>   and possible more efficient.

Another advantage might be using inline functions instead of macros with 
do {foo} while(0).

Bye,
Walter Dörwald
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)

[martin]

Zitat von Ulrich Berning <[EMAIL PROTECTED]>:

> I can't see many advantages in moving to C++, but a lot of disadvantages:

There are a few advantages, though, mainly:
- increased type-safety, in particular for API that isn't type-checked
  at all at the moment (e.g. PyArg_ParseTuple)
- more reliable reference counting, due to destructors of local
  variables
- "native" exception handling, making exceptions both less error-prone
  and possible more efficient.

Regards,
Martin


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Making staticmethod objects callable?

[Steven Bethard]

On 3/1/06, Nicolas Fleury <[EMAIL PROTECTED]> wrote:
> Basically, should staticmethods be made callable so that the following
> would not raise an exception:
>
> class A:
>  @staticmethod
>  def foo(): pass
>  bar = foo()
>
> There's workarounds, but it's really just about usability.  staticmethod
> could still return a descriptor, but additionnally callable.  Is there
> something I'm missing?  Is it error-prone in any way?

My only (mild) concern is that if staticmethod is going to get a
__call__, I think classmethod should probably get one too.  Inside a
class this doesn't make much sense:

class A(object):
@classmethod
def foo(cls):
pass
bar = foo(None) # ??

But I guess outside of a class maybe it's okay:

@classmethod
def foo(cls):
pass

class A(object):
pass

foo(A)

Anyway, my feeling was that running into this behavior (that
staticmethod is not callable) is a good oportunity to explain how
descriptors work.  And once you start playing around with staticmethod
and classmethod, you're going to need to learn that pretty soon
anyway.  Hiding it a little bit longer with a __call__ method on
staticmethod isn't going to help much in the long run.

So I guess I'm -0 if classmethod gets a __call__ too.

STeVe
--
Grammar am for people who can't think for myself.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Stateful codecs [Was: str object going in Py3K]

[M.-A. Lemburg]

Walter Dörwald wrote:
> M.-A. Lemburg wrote:
>> Walter Dörwald wrote:
>>> Hye-Shik Chang wrote:
>>>
 On 2/19/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> M.-A. Lemburg wrote:
>> Walter Dörwald wrote:
>>> Anyway, I've started implementing a patch that just adds
>>> codecs.StatefulEncoder/codecs.StatefulDecoder. UTF8, UTF8-Sig,
>>> UTF-16, UTF-16-LE and UTF-16-BE are already working.
>> Nice :-)
> gencodec.py is updated now too. The rest should be manageble too.
> I'll leave updating the CJKV codecs to Hye-Shik though.
 Okay. I'll look whether how CJK codecs can be improved by the
 new protocol soon.  I guess it'll be not so difficult because CJK
 codecs have a their own common stateful framework already.
>>> OK, here's the patch: bugs.python.org/1436130 (assigned to MAL).
>>
>> Thanks. I won't be able to look into it this week though, probably
>> next week.
> 
> Any progress on this? I'd really like to get this into 2.5 and the
> feature freeze is approaching fast!

I'll have a look this week.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 01 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bytes.from_hex()

[Chermside, Michael]

Ron Adam writes:
> While playing around with the example bytes class I noticed code reads

> much better when I use methods called tounicode and tostring.
[...]
> I'm not suggesting we start using to-type everywhere, just where it 
> might make things clearer over decode and encode.

+1

I always find myself slightly confused by encode() and decode()
despite the fact that I understand (I think) the reason for the
choice of those names and by rights ought to have no trouble.

I'm not arguing that it's worth the gratuitous code breakage (I
don't have enough code using encode() and decode() for my opinion
to count in that matter.) But I will say that if there were no
legacy I'd prefer the tounicode() and tostring() (but shouldn't it
be 'tobytes()' instead?) names for Python 3.0.

-- Michael Chermside





*
This email may contain confidential or privileged information. If you believe
 you have received the message in error, please notify the sender and delete 
the message without copying or disclosing it.
*

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Stateful codecs [Was: str object going in Py3K]

[Walter Dörwald]

Anthony Baxter wrote:
> On Thursday 02 March 2006 01:48, Walter Dörwald wrote:
>> Any progress on this? I'd really like to get this into 2.5 and the
>> feature freeze is approaching fast!
> 
> Remember, the feature freeze is as of beta1. Hopefully the major new 
> features are all going to be in before alpha1, but they can continue 
> to be added up until the first beta. Then (barring acts of Guido) we 
> should be in feature-freeze mode. 

OK, it seems I misunderstood PEP 356:

"""
Planned features for 2.5

 Target for inclusion of each feature by March 16.
"""

Bye,
Walter Dörwald

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Stateful codecs [Was: str object going in Py3K]

[Anthony Baxter]

On Thursday 02 March 2006 01:48, Walter Dörwald wrote:
> Any progress on this? I'd really like to get this into 2.5 and the
> feature freeze is approaching fast!

Remember, the feature freeze is as of beta1. Hopefully the major new 
features are all going to be in before alpha1, but they can continue 
to be added up until the first beta. Then (barring acts of Guido) we 
should be in feature-freeze mode. 


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Making staticmethod objects callable?

[Nicolas Fleury]

Hi,

I've posted this question on comp.lang.python, but nobody seems to 
conclude it is a bad idea, so I post it here.
http://groups.google.com/group/comp.lang.python/browse_frm/thread/6082dae1deef9161/88bb8a26750dd8c6?lnk=raot&hl=en#88bb8a26750dd8c6

Basically, should staticmethods be made callable so that the following 
would not raise an exception:

class A:
 @staticmethod
 def foo(): pass
 bar = foo()

There's workarounds, but it's really just about usability.  staticmethod 
could still return a descriptor, but additionnally callable.  Is there 
something I'm missing?  Is it error-prone in any way?

Note that I'm not a big fan of static methods myself, but I understand 
users expecting this work.

Regards,
Nicolas

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bytes.from_hex()

[Ron Adam]

Nick Coghlan wrote:
> All the unicode codecs, on the other hand, use encode to get from characters 
> to bytes and decode to get from bytes to characters.
> 
> So if bytes objects *did* have an encode method, it should still result in a 
> unicode object, just the same as a decode method does (because you are 
> encoding bytes as characters), and unicode objects would acquire a 
> corresponding decode method (that decodes from a character format such as 
> base64 to the original byte sequence).
>
> In the name of TOOWTDI, I'd suggest that we just eat the slight terminology 
> glitch in the rare cases like base64, hex and oct (where the character format 
> is technically the encoded format), and leave it so that there is a single 
> method pair (bytes.decode to go from bytes to characters, and text.encode to 
> go from characters to bytes).

I think you have it pretty straight here.


While playing around with the example bytes class I noticed code reads 
much better when I use methods called tounicode and tostring.

b64ustring = b.tounicode('base64')
b = bytes(b64ustring, 'base64')

The bytes could then *not* ignore the string decode codec but use it for 
string to string decoding.

b64string = b.tostring('base64')
b = bytes(b64string, 'base64')

b = bytes(hexstring, 'hex')
hexstring = b.tostring('hex')

hexstring = b.tounicode('hex')

An exception could be raised if the codec does not support input or 
output type depending on the situation.

This would allow for differnt types of codecs to live together without 
as much confusion I think.

I'm not suggesting we start using to-type everywhere, just where it 
might make things clearer over decode and encode.


Expecting it not to fly, but just maybe it could?
   Ron


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Stateful codecs [Was: str object going in Py3K]

[Walter Dörwald]

M.-A. Lemburg wrote:
> Walter Dörwald wrote:
>> Hye-Shik Chang wrote:
>>
>>> On 2/19/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
 M.-A. Lemburg wrote:
> Walter Dörwald wrote:
>> Anyway, I've started implementing a patch that just adds
>> codecs.StatefulEncoder/codecs.StatefulDecoder. UTF8, UTF8-Sig,
>> UTF-16, UTF-16-LE and UTF-16-BE are already working.
> Nice :-)
 gencodec.py is updated now too. The rest should be manageble too.
 I'll leave updating the CJKV codecs to Hye-Shik though.
>>> Okay. I'll look whether how CJK codecs can be improved by the
>>> new protocol soon.  I guess it'll be not so difficult because CJK
>>> codecs have a their own common stateful framework already.
>> OK, here's the patch: bugs.python.org/1436130 (assigned to MAL).
> 
> Thanks. I won't be able to look into it this week though, probably
> next week.

Any progress on this? I'd really like to get this into 2.5 and the 
feature freeze is approaching fast!

Bye,
Walter Dörwald
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposal: defaultdict

[Gareth McCaughan]

> >>   d.get(key, [], True).append(value)
> > 
> > hmm.  are you sure you didn't just reinvent setdefault ?
> 
> I'm reasonably sure I copied it on purpose, only with a name that isn't 100% 
> misleading as to what it does ;)

Heh. From the original Usenet posting that suggested the capability
that was added in the form of "setdefault":

  | I suggest a minor change: another optional argument to
  | "get" so that
  | 
  | dict.get(item,default,flag)
  | 
  | is equivalent to
  | 
  | if dict.has_key(item):
  |   VALUE IS dict[item]
  | else:
  |   if flag: dict[item] = default<-- This is all that's new
  |   VALUE IS default
  | 
  | but presumably more efficient.

The response was a chorus of people saying "Not a bad idea, but
that flag sucks. It needs a separate method." :-)

-- 
g

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bytes.from_hex()

[Nick Coghlan]

Bill Janssen wrote:
> 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 using "a 65-character
> subset of US-ASCII", so that's really bytes.

If the base64 codec was a text<->bytes codec, and bytes did not have an encode 
method, then if you want to convert your original bytes to ascii bytes, you 
would do:

   ascii_bytes = orig_bytes.decode("base64").encode("ascii")

"Use base64 to convert my byte sequence to characters, then give me the 
corresponding ascii byte sequence"

To reverse the process:

   orig_bytes = ascii_bytes.decode("ascii").encode("base64")

"Use ascii to convert my byte sequence to characters, then use base64 to 
convert those characters back to the original byte sequence"

The only slightly odd aspect is that this inverts the conventional meaning of 
base64 encoding and decoding, where you expect to encode from bytes to 
characters and decode from characters to bytes.

As strings currently have both methods, the existing codec is able to use the 
conventional sense for base64: encode goes from "str-as-bytes" to 
"str-as-text" (giving a longer string with characters that fit in the base64 
subset) and decode goes from "str-as-text" to "str-as-bytes" (giving back the 
original string)

All the unicode codecs, on the other hand, use encode to get from characters 
to bytes and decode to get from bytes to characters.

So if bytes objects *did* have an encode method, it should still result in a 
unicode object, just the same as a decode method does (because you are 
encoding bytes as characters), and unicode objects would acquire a 
corresponding decode method (that decodes from a character format such as 
base64 to the original byte sequence).

In the name of TOOWTDI, I'd suggest that we just eat the slight terminology 
glitch in the rare cases like base64, hex and oct (where the character format 
is technically the encoded format), and leave it so that there is a single 
method pair (bytes.decode to go from bytes to characters, and text.encode to 
go from characters to bytes).

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)

[Barry Warsaw]

On Feb 28, 2006, at 6:26 PM, Fredrik Lundh wrote:

>
> should we perhaps switch to (careful use of) C++ in 3.0 ?

I hope not.  It would make life more difficult for embedded/extended  
users like ourselves because it would force us to link our  
applications as C++ programs.  That introduces lots of headaches on  
certain, shall we say, non-Windows platforms.

-Barry

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bytes.from_hex()

[Donovan Baarda]

On Tue, 2006-02-28 at 15:23 -0800, Bill Janssen wrote:
> 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 using "a 65-character
> subset of US-ASCII", so that's really bytes.

Huh... just joining here but surely you don't mean a text string that
doesn't use every character available in a particular encoding is
"really bytes"... it's still a text string...

If you base64 encode some bytes, you get a string. If you then want to
access that base64 string as if it was a bunch of bytes, cast it to
bytes.

Be careful not to confuse "(type)cast" with "(type)convert"... 

A "convert" transforms the data from one type/class to another,
modifying it to be a valid equivalent instance of the other type/class;
ie int -> float. 

A "cast" does not modify the data in any way, it just changes its
type/class to be the other type, and assumes that the data is a valid
instance of the other type; eg int32 -> bytes[4]. Minor data munging
under the hood to cleanly switch the type/class is acceptable (ie adding
array length info etc) provided you keep to the spirit of the "cast".

Keep these two concepts separate and you should be right :-)

-- 
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] C++ for CPython 3? (Re: str.count is slow)

[Wolfgang Langner]

Hello,

> >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 loading and cross
> module API's
> - Everything has to be build with the same compiler, binaries created
> with different compilers can't interoperate
> - Possibly all extensions modules have to be (re)written in C++
> - Moving to C++ will change Python's well known API substantially

Same opinion. C++ is evil, please don't use it.
You get a lot of new problems and nearly not benefit.

Better go to jython or consider the way of pypy.

--
bye by Wolfgang
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] .py and .txt files missing svn:eol-style in trunk

[Oleg Broytmann]

On Wed, Mar 01, 2006 at 12:17:16AM -0600, Tim Peters wrote:
> These .py and .txt files don't have the svn:eol-style property set. 
> I'm not sure they all _should_, though.

   My experience shows that if the developers use different OSes (our team
uses Linux and Windows) it helps very much to set svn:eol-style to native
for all text files - *.py, *.txt, etc, except for files with special
requirements. So I use the following shell script

#! /bin/sh

svn add "$@"
svn propset svn:eol-style native "$@"
svn propset svn:keywords "Date Rev Id" "$@"

   to add *.py files to the repository. (I don't want to put it in a global
configuration because I have different requirements for different projects.)
   For other text files the same except keywords:

#! /bin/sh

svn add "$@"
svn propset svn:eol-style native "$@"

> test_pepe263 probably should be binary (it contains "funny
> characters").

   It should be text with encoding

$ svn propset svn:mime-type "text/plain; charset=koi8-r" test_pep263

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com