Re: [Python-3000] Can someone please make py3k* checkins go to the python-3000-checkins mailing list?
On 5/4/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I don't know how the filters for checkin emails are set up, but this > seems wrong: mail related to the p3yk branch goes to > python-3000-checkins, but mail related to the py3k-unistr branch goes > to python-checkins. There are a bunch of branches of relevance to py3k > now; these should all go to the python-3000-checkins list. I suggest > to filter on branches that start with either py3k or with p3yk. I've done that (more or less). Here is the regex. Please (re)name your branches appropriately. ^python/branches/(p3yk/|py3k).* n ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] failing tests
There are 3* failing tests: test_compiler test_doctest test_transformer * plus a few more when running on a 64-bit platform These failures occurred before and after xrange checkin. Do other people see these failures? Any ideas when they started? The doctest failures are due to no space at the end of the line (print behavior change). Not sure what to do about that now that we prevent blanks at the end of lines from being checked in. :-) n ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] new io (pep 3116)
my original idea about the new i/o foundation was more elaborate than the pep, but i have to admit the pep is more feasible and compact. some comments though: writeline - TextIOBase should grow a writeline() method, to be symmetrical with readline(). the reason is simple -- the newline char is configurable in the constructor, so it's not necessarily "\n". so instead of adding the configurable newline char manually, the user should call writeline() which would append the appropriate newline automatically. sockets - iirc, SocketIO is a layer that wraps an underlying socket object. that's a good distinction -- to separate the underlying socket from the RawIO interface -- but don't forget socket objects, by themselves, need a cleanup too. for instance, there's no point in UDP sockets having listen(), or send() or getpeername() -- with UDP you only ever use sendto and recvfrom. on the other hand, TCP sockets make no use of sendto(). and even with TCP sockets, listeners never use send() or recv(), while connected sockets never use listen() or connect(). moreover, the current socket interface simply mimics the BSD interface. setsockopt, getsockopt, et al, are very unpythonic by nature -- the ought to be exposed as properties or methods of the socket. all in all, the current socket model is very low level with no high level design. some time ago i was working on a sketch for a new socket module (called sock2) which had a clear distinction between connected sockets, listener sockets and datagram sockets. each protocol was implemented as a subclass of one of these base classes, and exposed only the relevant methods. socket options were added as properties and methods, and a new DNS module was added for dns-related queries. you can see it here -- http://sebulba.wikispaces.com/project+sock2 i know it's late already, but i can write a PEP over the weekend, or if someone else wants to carry on with the idea, that's fine with me. non-blocking IO - the pep says "In order to put an object in object in non-blocking mode, the user must extract the fileno and do it by hand." but i think it would only lead to trouble. as the entire IO library is being rethought from the grounds up, non-blocking IO should be taken into account. non-blocking IO depends greatly on the platform -- and this is exactly why a cross-platform language should standardized that as part of the new IO layer. saying "let's keep it for later" would only require more work at some later stage. it's true that SyncIO and AsyncIO don't mingle well with the same interfaces. that's why i think they should be two distinct classes. the class hierarchy should be something like: class RawIO: def fileno() def close() class SyncIO(RawIO): def read(count) def write(data) class AsyncIO(RawIO): def read(count, timeout) def write(data, timeout) def bgread(count, callback) def bgwrite(data, callback) or something similar. there's no point to add both sync and async operations to the RawIO level -- it just won't work together. we need to keep the two distinct. buffering should only support SyncIO -- i also don't see much point in having buffered async IO. it's mostly used for sockets and devices, which are most likely to work with binary data structures rather than text, and if you *require* non-blocking mode, buffering will only get in your way. if you really want a buffered AsyncIO stream, you could write a compatibility layer that makes the underlying AsyncIO object appear synchronous. records - another addition to the PEP that seems useful to me would be a RecordIOBase/Wrapper. records are fixed-length binary data structures, defined as format strings of the struct-module. class RecordIOWrapper: def __init__(self, buffer, format) def read(self) -> tuple of fields def write(self, *fields) another cool feature i can think of is "multiplexing", or working with the same underlying stream in different ways by having multiple wrappers over it. for example, to implement a type-length-value stream, which is very common in communication protocols, one could do something like class MultiplexedIO: def __init__(self, *streams): self.streams = itertools.cycle(streams) def read(self, *args): """read from the next stream each time it's called""" return self.streams.next().read(*args) sock = BufferedRW(SocketIO(...)) tlrec = Record(sock, "!BL") tlv = MultiplexedIO(tvrec, sock) type, length = tlv.read() value = tlv.read(length) you can also build higher-level state machines with that -- for instance, if the type was "int", the next call to read() would decode the value as an integer, and so on. you could write parsers right on top of the IO layer. just an idea. i'm not sure if that's proper design or just a silly idea, but we'll leave that to the programmer. -tomer _
Re: [Python-3000] the future of the GIL
[Talin] > Note that Jython and IronPython don't have the same restrictions in this > regard as CPython. Both VMs are able to run in multiprocessing > environments. (I don't know whether or not Jython/IronPython even have a > GIL or not.) they don't. they rely on jvm/clr for GC, and probably per-thread locking when they touch global data. [Giovanni Bajo] > You seem to believe that the only way to parallelize your programs is to use > threads. IMHO, threads is just the most common and absolutely the worst, under > many points of views. not at all. personally i hate threads, but there are many place where you can use them properly to distribute workload -- without mutual dependencies or shard state. this makes them essentially like light-weight processes, using background workers and queues, etc., only without the overhead of multiple processes. there could be a stdlib threading module that would provide you with all kinds of queues, schedulers, locks, and decorators, so you wouldn't have to manually lock things every time. -tomer ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] new io (pep 3116)
On 5/7/07, tomer filiba <[EMAIL PROTECTED]> wrote: > for instance, there's no point in UDP sockets having listen(), or send() > or getpeername() -- with UDP you only ever use sendto and recvfrom. > on the other hand, Actually, you can connect() UDP sockets, and then you can use send(), recv(), and getpeername(). > TCP sockets make no use of sendto(). and even with > TCP sockets, listeners never use send() or recv(), while connected > sockets never use listen() or connect(). Agreed. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] failing tests
Thanks for checking in xrange! Woot! test_compiler and test_transformer are waiting for someone to clean up the compiler package (I forget what it doesn't support, perhapes only nonlocal needs to be added.) Looks like you diagnosed the doctest failure correctly. This is probably because, when print changed into print(), lines ending in spaces are generated in some cases: # Py 2 code, writes "42\n" print 42, print # Py3k automatically translated, writes "42 \n" print(42, end=" ") print() I'm afraid we'll have to track down the places where this affects the doctest and fix them. (Fixing the doctest is possible too, though less elegant: just add \n\ to the end of the line.) --Guido On 5/7/07, Neal Norwitz <[EMAIL PROTECTED]> wrote: > There are 3* failing tests: > test_compiler test_doctest test_transformer > * plus a few more when running on a 64-bit platform > > These failures occurred before and after xrange checkin. > > Do other people see these failures? Any ideas when they started? > > The doctest failures are due to no space at the end of the line (print > behavior change). Not sure what to do about that now that we prevent > blanks at the end of lines from being checked in. :-) > > n > ___ > Python-3000 mailing list > Python-3000@python.org > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] updated PEP3126: Remove Implicit String Concatenation
Rewritten -- please tell me if there are any concerns I have missed.
And of course, please tell me if you have a suggestion for the open
issue -- how to better support external internationalization tools, or
at least xgettext in particular.
-jJ
---
PEP: 3126
Title: Remove Implicit String Concatenation
Version: $Revision$
Last-Modified: $Date$
Author: Jim J. Jewett <[EMAIL PROTECTED]>,
Raymond D. Hettinger
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 29-Apr-2007
Post-History: 29-Apr-2007, 30-Apr-2007, 07-May-2007
Abstract
Python inherited many of its parsing rules from C. While this has
been generally useful, there are some individual rules which are less
useful for python, and should be eliminated.
This PEP proposes to eliminate implicit string concatenation based
only on the adjacency of literals.
Instead of::
"abc" "def" == "abcdef"
authors will need to be explicit, and either add the strings::
"abc" + "def" == "abcdef"
or join them::
"".join(["abc", "def"]) == "abcdef"
Motivation
==
One goal for Python 3000 should be to simplify the language by
removing unnecessary features. Implicit string concatenation should
be dropped in favor of existing techniques. This will simplify the
grammar and simplify a user's mental picture of Python. The latter is
important for letting the language "fit in your head". A large group
of current users do not even know about implicit concatenation. Of
those who do know about it, a large portion never use it or habitually
avoid it. Of those who both know about it and use it, very few could
state with confidence the implicit operator precedence and under what
circumstances it is computed when the definition is compiled versus
when it is run.
History or Future
-
Many Python parsing rules are intentionally compatible with C. This
is a useful default, but Special Cases need to be justified based on
their utility in Python. We should no longer assume that python
programmers will also be familiar with C, so compatibility between
languages should be treated as a tie-breaker, rather than a
justification.
In C, implicit concatenation is the only way to join strings without
using a (run-time) function call to store into a variable. In Python,
the strings can be joined (and still recognized as immutable) using
more standard Python idioms, such ``+`` or ``"".join``.
Problem
---
Implicit String concatentation leads to tuples and lists which are
shorter than they appear; this is turn can lead to confusing, or even
silent, errors. For example, given a function which accepts several
parameters, but offers a default value for some of them::
def f(fmt, *args):
print fmt % args
This looks like a valid call, but isn't::
>>> f("User %s got a message %s",
"Bob"
"Time for dinner")
Traceback (most recent call last):
File "", line 2, in
"Bob"
File "", line 2, in f
print fmt % args
TypeError: not enough arguments for format string
Calls to this function can silently do the wrong thing::
def g(arg1, arg2=None):
...
# silently transformed into the possibly very different
# g("arg1 on this linearg2 on this line", None)
g("arg1 on this line"
"arg2 on this line")
To quote Jason Orendorff [#Orendorff]
Oh. I just realized this happens a lot out here. Where I work,
we use scons, and each SConscript has a long list of filenames::
sourceFiles = [
'foo.c'
'bar.c',
#...many lines omitted...
'q1000x.c']
It's a common mistake to leave off a comma, and then scons
complains that it can't find 'foo.cbar.c'. This is pretty
bewildering behavior even if you *are* a Python programmer,
and not everyone here is.
Solution
In Python, strings are objects and they support the __add__ operator,
so it is possible to write::
"abc" + "def"
Because these are literals, this addition can still be optimized away
by the compiler; the CPython compiler already does so.
[#rcn-constantfold]_
Other existing alternatives include multiline (triple-quoted) strings,
and the join method::
"""This string
extends across
multiple lines, but you may want to use something like
Textwrap.dedent
to clear out the leading spaces
and/or reformat.
"""
>>> "".join(["empty", "string", "joiner"]) == "emptystringjoiner"
True
>>> " ".join(["space", "string", "joiner"]) == "space string joiner"
>>> "\n".join(["multiple", "lines"]) == "multiple\nlines" == (
"""multiple
lines""")
True
Concerns
Operator Precedence
---
Guido indicated [#rcn-constantfold]_ that this change should be
handled by PEP, because there were a few edge cases with other string
operators, such as the %. (Assuming that str % stays --
[Python-3000] PEP: Eliminate __del__
FWIW and in light of the thread on removing __del__ from the language, I just posted Yet Another Recipe for automatic finalization: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/519621 It allows writing a finalizer as a single __finalize__ method, at the cost of explicitly calling an enable_finalizer() method with the list of attributes to keep alive on the "ghost object". Antoine. ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] failing tests
Guido van Rossum wrote: > Thanks for checking in xrange! Woot! > > test_compiler and test_transformer are waiting for someone to clean up > the compiler package (I forget what it doesn't support, perhapes only > nonlocal needs to be added.) It's definitely lagging on set comprehensions as well. I'm also pretty sure those two tests broke before nonlocal was added, as they were already broken when I started helping Georg in looking at the setcomp updates. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] PEP 3129: Class Decorators
Can I go ahead and mark PEP 3129 as "accepted"? ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] new io (pep 3116)
On 5/7/07, tomer filiba <[EMAIL PROTECTED]> wrote: > some time ago i was working on a sketch for a new socket module > (called sock2) which had a clear distinction between connected sockets, > listener sockets and datagram sockets. each protocol was implemented > as a subclass of one of these base classes, and exposed only the > relevant methods. socket options were added as properties and > methods, and a new DNS module was added for dns-related queries. > > you can see it here -- http://sebulba.wikispaces.com/project+sock2 > i know it's late already, but i can write a PEP over the weekend, It's not too late for standard library PEPs, only PEPs that change the core language. Since your proposal here would presumably replace the socket module, I assume it counts as a stdlib change. STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3132: Extended Iterable Unpacking
On 5/4/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote: > On 5/4/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > > I don't think that returning the type given is a goal > > that should be attempted, because it can only ever work > > for a fixed set of known types. Given an arbitrary > > sequence type, there is no way of knowing how to > > create a new instance of it with specified contents. > > For objects that support the sequence protocol, how about specifying that: > > a, *b = container_object > > must be equivalent to: > > a, b = container_object[0], container_object[1:] > > That way, b is assigned whatever container_object's getslice method > returns. A list will return a list, a tuple will return a tuple, and > widgets (or BLists...) can return whatever makes sense for them. And what do you return when it doesn't support the container protocol? Think about the use cases. It seems that *your* use case is some kind of (car, cdr) splitting known from Lisp and from functional languages (Haskell is built out of this idiom it seems from the examples). But in Python, if you want to loop over one of those things, you ought to use a for-loop; and if you really want a car/cdr split, explicitly using the syntax you show above (x[0], x[1:]) is fine. The important use case in Python for the proposed semantics is when you have a variable-length record, the first few items of which are interesting, and the rest of which is less so, but not unimportant. (If you wanted to throw the rest away, you'd just write a, b, c = x[:3] instead of a, b, c, *d = x.) It is much more convenient for this use case if the type of d is fixed by the operation, so you can count on its behavior. There's a bug in the design of filter() in Python 2 (which will be fixed in 3.0 by turning it into an iterator BTW): if the input is a tuple, the output is a tuple too, but if the input is a list *or anything else*, the output is a list. That's a totally insane signature, since it means that you can't count on the result being a list, *nor* on it being a tuple -- if you need it to be one or the other, you have to convert it to one, which is a waste of time and space. Please let's not repeat this design bug. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] [Python-Dev] Byte literals (was Re: [Python-checkins] Changing string constants to byte arrays ( r55119 - in python/branches/py3k-struni/Lib: codecs.py test/test_codecs.py ))
[+python-3000; replies please remove python-dev]
On 5/5/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Fred L. Drake, Jr." <[EMAIL PROTECTED]> wrote:
> >
> > On Saturday 05 May 2007, Aahz wrote:
> > > I'm with MAL and Fred on making literals immutable -- that's safe and
> > > lots of newbies will need to use byte literals early in their Python
> > > experience if they pick up Python to operate on network data.
> >
> > Yes; there are lots of places where bytes literals will be used the way str
> > literals are today. buffer(b'...') might be good enough, but it seems more
> > than a little idiomatic, and doesn't seem particularly readable.
> >
> > I'm not suggesting that /all/ literals result in constants, but bytes
> > literals
> > seem like a case where what's wanted is the value. If b'...' results in a
> > new object on every reference, that's a lot of overhead for a network
> > protocol implementation, where the data is just going to be written to a
> > socket or concatenated with other data. An immutable bytes type would be
> > very useful as a dictionary key as well, and more space-efficient than
> > tuple(b'...').
>
> I was saying the exact same thing last summer. See my discussion with
> Martin about parsing/unmarshaling. What I expect will happen with bytes
> as dictionary keys is that people will end up subclassing dictionaries
> (with varying amounts of success and correctness) to do something like
> the following...
>
> class bytesKeys(dict):
> ...
> def __setitem__(self, key, value):
> if isinstance(key, bytes):
> key = key.decode('latin-1')
> else:
> raise KeyError("only bytes can be used as keys")
> dict.__setitem__(self, key, value)
> ...
>
> Is it optimal? No. Would it be nice to have immtable bytes? Yes. Do
> I think it will really be a problem in parsing/unmarshaling? I don't
> know, but the fact that there now exists a reasonable literal syntax b'...'
> rather than the previous bytes([1, 2, 3, ...]) means that we are coming
> much closer to having what really is about the best way to handle this;
> Python 2.x str.
I don't know how this will work out yet. I'm not convinced that having
both mutable and immutable bytes is the right thing to do; but I'm
also not convinced of the opposite. I am slowly working on the
string/unicode unification, and so far, unfortunately, it is quite
daunting to get rid of 8-bit strings even at the Python level let
alone at the C level.
I suggest that the following exercise, to be carried out in the
py3k-struni branch, might be helpful: (1) change the socket module to
return bytes instead of strings (it already takes bytes, by virtue of
the buffer protocol); (2) change its makefile() method so that it uses
the new io.py library, in particular the SocketIO wrapper there; (3)
fix up the httplib module and perhaps other similar ones. Take copious
notes while doing this. Anyone up for this? I will listen! (I'd do it
myself but I don't know where I'd find the time).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3112
On 5/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > I just read PEP 3112, and I believe it contains a > flaw/underspecification. > > It says > > # Each shortstringchar or longstringchar must be a character between 1 > # and 127 inclusive, regardless of any encoding declaration [2] in the > # source file. > > What does that mean? In particular, what is "a character between 1 and > 127"? > > Assuming this refers to ordinal values in some encoding: what encoding? > It's particularly puzzling that it says "regardless of any encoding > declaration of the source file". > > I fear (but hope that I'm wrong) that this was meant to mean "use the > bytes as they are stored on disk in the source file". If so: is the > attached file valid Python? In case your editor can't render it: it > reads > > #! -*- coding: iso-2022-jp -*- > a = b"Питон" > > But if you look at the file with a hex editor, you see it contains > only bytes between 1 and 127. > > I would hope that this code is indeed ill-formed (i.e. that > the byte representation on disk is irrelevant, and only the > Unicode ordinals of the source characters matter) > > If so, can the specification please be updated to clarify that > 1. in Grammar changes: Each shortstringchar or longstringchar must >be a character whose Unicode ordinal value is between 1 and >127 inclusive. > 2. in Semantics: The bytes in the new object are obtained as if >encoding a string literal with "iso-8859-1" Sounds like a good fix to me; I agree that bytes literals, like Unicode literals, should not vary depending on the source encoding. In step 2, can't you use "ascii" as the encoding? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] comments
On 5/6/07, tomer filiba <[EMAIL PROTECTED]> wrote: > i finished reading almost all of the new peps, so to prevent cluttering > i'll post all my comments in a single message. Please don't do that -- it leads to multiple discussions going on in the same email thread, and that's really hard to keep track of (as I learned after posting my "PEP parade" email). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] the future of the GIL
On 5/5/07, tomer filiba <[EMAIL PROTECTED]> wrote: > i have to admit i've been neglecting the list in the past few months, > and i don't know whether the issue i want to bring up has been > settled already. It's been settled by default -- nobody submitted a PEP to kill the GIL in time for the April 30 deadline, and I won't accept one now. > as you all may have noticed, multicore processors are becoming > more and more common in all kinds of machines, from desktops > to servers, and will surely become more prevalent with time, > as all major CPU vendors plan to ship 8-core processors > by mid-2008. > > back in the day of uniprocessor machines, having the GIL really > made life simpler and the sacrifice was negligible. > > however, running a threaded python script over an 8-core > machine, where you can utilize at most 12.5% of the horsepower, > seems like too large a sacrifice to me. > > the only way to overcome this with cpython is to Kill The GIL (TM), > and since it's a very big architectural change, it ought to happen > soon. pushing it further than version 3.0 means all library authors > would have to adapt their code twice (once to make it compatible > with 3.0, and then again to make it thread safe). Here's something I wrote recently to someone (a respected researcher) who has a specific design in mind to kill the GIL (rather than an agenda without a plan). """ Briefly, the reason why it's so hard to get rid of the GIL is that this Python implementation uses reference counting as its primary GC approach (there's a cycle-traversing GC algorithm bolted on the side, but most objects are reclaimed by refcounting). In Python, everything is an object (even small integers and characters), and many objects are conceptually immutable, allowing free sharing of objects as values between threads. There is no marking of objects as "local to a thread" or "local to a frame" -- that would be a totally alien concept. All objects have a refcount field (a long at the front of the object structure) and this sees a lot of traffic. As C doesn't have an atomic increment nor an atomic decrement-and-test, the INCREF and DECREF macros sprinkled throughout the code (many thousands of them) must be protected by some lock. Around '99 Greg Stein and Mark Hammond tried to get rid of the GIL. They removed most of the global mutable data structures, added explicit locks to the remaining ones and to individual mutable objects, and actually got the whole thing working. Unfortunately even on the system with the fastest locking primitives (Windows at the time) they measured a 2x slow-down on a single CPU due to all the extra locking operations going on. Good luck fixing this! My personal view on it is that it's not worth it. If you want to run Python on a multiprocessor, you're much better off finding a way to break the application off into multiple processes each running a single CPU-bound thread and any number of I/O-bound threads; alternatively, if you cannot resist the urge for multiple CPU-bound threads, you can use one of the Python implementations built on inherently multi-threading frameworks, i.e. Jython or IronPython. But I'd be happy to be proven wrong, if only because this certainly is a recurring heckle whenever I give a talk about Python anywhere. """ -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] updated PEP3126: Remove Implicit String Concatenation
Committed revision 55172. For the record, I'm more and more -1 on this (and on its companion to remove \ line continuation). These seem pretty harmless features that serve a purpose; those of us who don't like them can avoid them. --Guido On 5/7/07, Jim Jewett <[EMAIL PROTECTED]> wrote: > Rewritten -- please tell me if there are any concerns I have missed. > > And of course, please tell me if you have a suggestion for the open > issue -- how to better support external internationalization tools, or > at least xgettext in particular. > > -jJ > > --- > > PEP: 3126 > Title: Remove Implicit String Concatenation > Version: $Revision$ > Last-Modified: $Date$ > Author: Jim J. Jewett <[EMAIL PROTECTED]>, > Raymond D. Hettinger -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] failing tests
On 5/7/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > Thanks for checking in xrange! Woot! > > > > test_compiler and test_transformer are waiting for someone to clean up > > the compiler package (I forget what it doesn't support, perhapes only > > nonlocal needs to be added.) > > It's definitely lagging on set comprehensions as well. I'm also pretty > sure those two tests broke before nonlocal was added, as they were > already broken when I started helping Georg in looking at the setcomp > updates. I just fixed the doctest failures; but for the compiler package I need help. Would you have the time? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3129: Class Decorators
On 5/7/07, Collin Winter <[EMAIL PROTECTED]> wrote: > Can I go ahead and mark PEP 3129 as "accepted"? Almost. I'm ok with it, but I think that to follow the procedure you ought to post the full text at least once on python-3000, so you can add the date to the "Post-History" header. In the mean time, I think it would be fine to start on the implementation! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3132: Extended Iterable Unpacking
On 5/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > And what do you return when it doesn't support the container protocol? Assign the iterator object with the remaining items to d. > Think about the use cases. It seems that *your* use case is some kind > of (car, cdr) splitting known from Lisp and from functional languages > (Haskell is built out of this idiom it seems from the examples). But > in Python, if you want to loop over one of those things, you ought to > use a for-loop; and if you really want a car/cdr split, explicitly > using the syntax you show above (x[0], x[1:]) is fine. The use came I'm thinking of is this: A container type or an iterable where the first few entries contain one type of information, and the rest of the entries are something that will either be discard or run through for-loop. I encounter this frequently when reading text files where the first few lines are some kind of header with a known format and the rest of the file is data. > The important use case in Python for the proposed semantics is when > you have a variable-length record, the first few items of which are > interesting, and the rest of which is less so, but not unimportant. > (If you wanted to throw the rest away, you'd just write a, b, c = > x[:3] instead of a, b, c, *d = x.) That doesn't work if x is an iterable that doesn't support getslice (such as a file object). > It is much more convenient for this > use case if the type of d is fixed by the operation, so you can count > on its behavior. > There's a bug in the design of filter() in Python 2 (which will be > fixed in 3.0 by turning it into an iterator BTW): if the input is a > tuple, the output is a tuple too, but if the input is a list *or > anything else*, the output is a list. That's a totally insane > signature, since it means that you can't count on the result being a > list, *nor* on it being a tuple -- if you need it to be one or the > other, you have to convert it to one, which is a waste of time and > space. Please let's not repeat this design bug. I agree that's broken, because it carves out a weird exception for tuples. I disagree that it's analogous because I'm not suggesting carving out an exception. I'm suggesting, that: - lists return lists - tuples return tuples - XYZ containers return XYZ containers - non-container iterables return iterators. It's a consistent rule, albeit a different consistent rule than always returning the same type. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] the future of the GIL
On 5/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > It's been settled by default -- nobody submitted a PEP to kill the GIL > in time for the April 30 deadline, and I won't accept one now. oh, i didn't mean to submit a PEP about that -- i don't have the time or the brainpower to do that. i was just wondering if there were any plans to do that in py3k, or if that's at all desired. but as you said, it's been settled by default. -tomer ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] PEP 3129: Class Decorators
Guido pointed out that this PEP hadn't been sent to the list yet. Abstract This PEP proposes class decorators, an extension to the function and method decorators introduced in PEP 318. Rationale = When function decorators were originally debated for inclusion in Python 2.4, class decorators were seen as obscure and unnecessary [#obscure]_ thanks to metaclasses. After several years' experience with the Python 2.4.x series of releases and an increasing familiarity with function decorators and their uses, the BDFL and the community re-evaluated class decorators and recommended their inclusion in Python 3.0 [#approval]_. The motivating use-case was to make certain constructs more easily expressed and less reliant on implementation details of the CPython interpreter. While it is possible to express class decorator-like functionality using metaclasses, the results are generally unpleasant and the implementation highly fragile [#motivation]_. In addition, metaclasses are inherited, whereas class decorators are not, making metaclasses unsuitable for some, single class-specific uses of class decorators. The fact that large-scale Python projects like Zope were going through these wild contortions to achieve something like class decorators won over the BDFL. Semantics = The semantics and design goals of class decorators are the same as for function decorators ([#semantics]_, [#goals]_); the only difference is that you're decorating a class instead of a function. The following two snippets are semantically identical: :: class A: pass A = foo(bar(A)) @foo @bar class A: pass For a detailed examination of decorators, please refer to PEP 318. Implementation == Adapating Python's grammar to support class decorators requires modifying two rules and adding a new rule :: funcdef: [decorators] 'def' NAME parameters ['->' test] ':' suite compound_stmt: if_stmt | while_stmt | for_stmt | try_stmt | with_stmt | funcdef | classdef need to be changed to :: decorated: decorators (classdef | funcdef) funcdef: 'def' NAME parameters ['->' test] ':' suite compound_stmt: if_stmt | while_stmt | for_stmt | try_stmt | with_stmt | funcdef | classdef | decorated Adding ``decorated`` is necessary to avoid an ambiguity in the grammar. The Python AST and bytecode must be modified accordingly. A reference implementation [#implementation]_ has been provided by Jack Diederich. References == .. [#obscure] http://www.python.org/dev/peps/pep-0318/#motivation .. [#approval] http://mail.python.org/pipermail/python-dev/2006-March/062942.html .. [#motivation] http://mail.python.org/pipermail/python-dev/2006-March/062888.html .. [#semantics] http://www.python.org/dev/peps/pep-0318/#current-syntax .. [#goals] http://www.python.org/dev/peps/pep-0318/#design-goals .. [#implementation] http://python.org/sf/1671208 ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] new io (pep 3116)
On 5/7/07, tomer filiba <[EMAIL PROTECTED]> wrote: > my original idea about the new i/o foundation was more elaborate > than the pep, but i have to admit the pep is more feasible and > compact. some comments though: > > writeline > - > TextIOBase should grow a writeline() method, to be symmetrical > with readline(). the reason is simple -- the newline char is > configurable in the constructor, so it's not necessarily "\n". > so instead of adding the configurable newline char manually, > the user should call writeline() which would append the > appropriate newline automatically. That's not symmetric. readline() returns a string that includes a trailing \n even if the actual file contained \r or \r\n. write() already is supposed to translate \n anywhere (not just at the end of the line) into the specified or platform-default (os.sep) separator. A method writeline() that *appended* a separator would be totally new to the I/O library. Even writelines() doesn't do that. > sockets > - > iirc, SocketIO is a layer that wraps an underlying socket object. > that's a good distinction -- to separate the underlying socket from > the RawIO interface -- but don't forget socket objects, > by themselves, need a cleanup too. But that's out of the scope of the PEP. The main change I intend to make is to return bytes instead of strings. > for instance, there's no point in UDP sockets having listen(), or send() > or getpeername() -- with UDP you only ever use sendto and recvfrom. > on the other hand, TCP sockets make no use of sendto(). and even with > TCP sockets, listeners never use send() or recv(), while connected > sockets never use listen() or connect(). > > moreover, the current socket interface simply mimics the BSD > interface. setsockopt, getsockopt, et al, are very unpythonic by nature -- > the ought to be exposed as properties or methods of the socket. > all in all, the current socket model is very low level with no high > level design. That's all out of scope for the PEP. Also I happen to think that there's nothing particularly wrong with sockets -- they generally get wrapped in higher layers like httplib. > some time ago i was working on a sketch for a new socket module > (called sock2) which had a clear distinction between connected sockets, > listener sockets and datagram sockets. each protocol was implemented > as a subclass of one of these base classes, and exposed only the > relevant methods. socket options were added as properties and > methods, and a new DNS module was added for dns-related queries. > > you can see it here -- http://sebulba.wikispaces.com/project+sock2 > i know it's late already, but i can write a PEP over the weekend, > or if someone else wants to carry on with the idea, that's fine > with me. Sorry, too late. We're putting serious pressue already on authors who posted draft PEPs before the deadline but haven't submitted their text to Subversion yet. At this point we have a definite list of PEPs that were either checked in or promised on time for the deadline. New proposals will have to wait until after 3.0a1 is released (hopefully end of June). Also note that the whole stdlib reorg is planned to happen after that release. > non-blocking IO > - > the pep says "In order to put an object in object in non-blocking > mode, the user must extract the fileno and do it by hand." > but i think it would only lead to trouble. as the entire IO library > is being rethought from the grounds up, non-blocking IO > should be taken into account. Why? Non-blocking I/O makes most of the proposed API useless. Non-blocking I/O is highly specialized and hard to code against. I'm all for a standard non-blocking I/O library but this one isn't it. > non-blocking IO depends greatly on the platform -- and this is > exactly why a cross-platform language should standardized that > as part of the new IO layer. saying "let's keep it for later" would only > require more work at some later stage. Actually there are only two things platform-specific: how to turn it on (or off) and how to tell the difference between "this operation would block" and "there was an error". > it's true that SyncIO and AsyncIO don't mingle well with the same > interfaces. that's why i think they should be two distinct classes. > the class hierarchy should be something like: > > class RawIO: > def fileno() > def close() > > class SyncIO(RawIO): > def read(count) > def write(data) > > class AsyncIO(RawIO): > def read(count, timeout) > def write(data, timeout) > def bgread(count, callback) > def bgwrite(data, callback) > > or something similar. there's no point to add both sync and async > operations to the RawIO level -- it just won't work together. > we need to keep the two distinct. I'd rather cut out all support for async I/O from this library and leave it for someone else to invent. I don't need it. People who use as
Re: [Python-3000] PEP 3129: Class Decorators
On 5/7/07, Collin Winter <[EMAIL PROTECTED]> wrote: [...] > This PEP proposes class decorators, an extension to the function > and method decorators introduced in PEP 318. [...] > The semantics and design goals of class decorators are the same as > for function decorators ([#semantics]_, [#goals]_); the only > difference is that you're decorating a class instead of a function. > The following two snippets are semantically identical: :: > > class A: > pass > A = foo(bar(A)) > > > @foo > @bar > class A: > pass I'm +1 on this PEP. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3132: Extended Iterable Unpacking
On 5/7/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote: > On 5/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > And what do you return when it doesn't support the container protocol? > > Assign the iterator object with the remaining items to d. > > > Think about the use cases. It seems that *your* use case is some kind > > of (car, cdr) splitting known from Lisp and from functional languages > > (Haskell is built out of this idiom it seems from the examples). But > > in Python, if you want to loop over one of those things, you ought to > > use a for-loop; and if you really want a car/cdr split, explicitly > > using the syntax you show above (x[0], x[1:]) is fine. > > The use came I'm thinking of is this: > > A container type or an iterable where the first few entries contain > one type of information, and the rest of the entries are something > that will either be discard or run through for-loop. > > I encounter this frequently when reading text files where the first > few lines are some kind of header with a known format and the rest of > the file is data. This sounds like a parsing problem. IMO it's better to treat it as such. > > The important use case in Python for the proposed semantics is when > > you have a variable-length record, the first few items of which are > > interesting, and the rest of which is less so, but not unimportant. > > > (If you wanted to throw the rest away, you'd just write a, b, c = > > x[:3] instead of a, b, c, *d = x.) > > That doesn't work if x is an iterable that doesn't support getslice > (such as a file object). > > > It is much more convenient for this > > use case if the type of d is fixed by the operation, so you can count > > on its behavior. > > > There's a bug in the design of filter() in Python 2 (which will be > > fixed in 3.0 by turning it into an iterator BTW): if the input is a > > tuple, the output is a tuple too, but if the input is a list *or > > anything else*, the output is a list. That's a totally insane > > signature, since it means that you can't count on the result being a > > list, *nor* on it being a tuple -- if you need it to be one or the > > other, you have to convert it to one, which is a waste of time and > > space. Please let's not repeat this design bug. > > I agree that's broken, because it carves out a weird exception for > tuples. I disagree that it's analogous because I'm not suggesting > carving out an exception. > > I'm suggesting, that: > > - lists return lists > - tuples return tuples > - XYZ containers return XYZ containers > - non-container iterables return iterators. > > It's a consistent rule, albeit a different consistent rule than always > returning the same type. But I expect less useful. It won't support "a, *b, c = " either. From an implementation POV, if you have an unknown object on the RHS, you have to try slicing it before you try iterating over it; this may cause problems e.g. if the object happens to be a defaultdict -- since x[3:] is implemented as x[slice(None, 3, None)], the defaultdict will give you its default value. I'd much rather define this in terms of iterating over the object until it is exhausted, which can be optimized for certain known types like lists and tuples. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] new io (pep 3116)
On 5/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> That's not symmetric. readline() returns a string that includes a
> trailing \n even if the actual file contained \r or \r\n. write()
> already is supposed to translate \n anywhere (not just at the end of
> the line) into the specified or platform-default (os.sep) separator.
well, if write() is meant to do that anyway, writeline() is not required.
> > moreover, the current socket interface simply mimics the BSD
> > interface. setsockopt, getsockopt, et al, are very unpythonic by nature --
> > the ought to be exposed as properties or methods of the socket.
> > all in all, the current socket model is very low level with no high
> > level design.
>
> That's all out of scope for the PEP. Also I happen to think that
> there's nothing particularly wrong with sockets -- they generally get
> wrapped in higher layers like httplib.
first, when i first brought this up a year ago, you were in favor
http://mail.python.org/pipermail/python-3000/2006-April/001497.html
still, there's much code that handles sockets. the client side is
mostly standard: connect, do something, quit. but on the server side
it's another story, and i have had many long battles with man pages
to make sockets behave as expected. not all protocols are based
on http, after all, and the fellas that write modules like httplib have
a lot of black magic to do.
a better design of the socket module could help a lot, as well as
making small, repeated tasks easier/more logical. compare
import socket
s = socket.socket()
s.connect(("foobar", 1234))
to
from socket import TcpStream
s = TcpStream("foobar", 1234)
> > you can see it here -- http://sebulba.wikispaces.com/project+sock2
> > i know it's late already, but i can write a PEP over the weekend,
> > or if someone else wants to carry on with the idea, that's fine
> > with me.
>
> Sorry, too late. We're putting serious pressue already on authors who
> posted draft PEPs before the deadline but haven't submitted their text
> to Subversion yet. At this point we have a definite list of PEPs that
> were either checked in or promised on time for the deadline. New
> proposals will have to wait until after 3.0a1 is released (hopefully
> end of June). Also note that the whole stdlib reorg is planned to
> happen after that release.
well, my code is pure python, and can just replace the existing socket.py
module. the _socket module remains in tact. it can surely wait for the
stdlib reorg though, there's no need to rush into it now. i'll submit the
PEP in the near future.
> > non-blocking IO depends greatly on the platform -- and this is
> > exactly why a cross-platform language should standardized that
> > as part of the new IO layer. saying "let's keep it for later" would only
> > require more work at some later stage.
>
> Actually there are only two things platform-specific: how to turn it
> on (or off) and how to tell the difference between "this operation
> would block" and "there was an error".
well, the way i see it, that's exactly why this calls for standardization.
> The struct module has the means to build that out of lower-level reads
> and writes already. If you think a library module to support this is
> needed, write one and make it available as a third party module and
> see how many customers you get. Personally I haven't had the need for
> files containing of fixed-length records of the same type since the
> mid '80s.
not all of us are that lucky :)
there's still lots of protocols ugly protocols and file formats for
us programmers to handle. and TLV structures happen to the be
one of the pretty ones.
> I don't think the new I/O library is the place to put in a bunch of
> new, essentially untried ideas. Instead, we should aim for a flexible
> implementation of APIs that we know work and are needed. I think the
> current stack is pretty flexible in that it supports streams and
> random access, unidirectional and bidirectional, raw and buffered,
> bytes and text. Applications can do a lot with those.
yeah, it was more like a wild idea really. it should be placed in a
different module.
-tomer
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3112
>> 1. in Grammar changes: Each shortstringchar or longstringchar must >>be a character whose Unicode ordinal value is between 1 and >>127 inclusive. > > Sounds like a good fix to me; I agree that bytes literals, like > Unicode literals, should not vary depending on the source encoding. In > step 2, can't you use "ascii" as the encoding? Sure. Technically, ASCII might include \0 (depending on definition), but that is ruled out as a character in Python source code, anyway. So: "must be an ASCII character" is just as clear, and much shorter. I guess Jason associated "ASCII character" with "single byte", so it can't be simultaneously both ASCII and Unicode, hence he chose the more elaborate wording. Of course, if one views ASCII as a character set (rather than an coded character set), a Unicode character may or may not simultaneously be an ASCII character. Regards, Martin ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] PEP 3132: Extended Iterable Unpacking
Daniel Stutzbach wrote: > The use came I'm thinking of is this: > > A container type or an iterable where the first few entries contain > one type of information, and the rest of the entries are something > that will either be discard or run through for-loop. If you know you're dealing with an iterator x, then after a, b, c, *d = x, d would simply be x, so all you really need is a function to get the first n items from x. > I'm suggesting, that: > > - lists return lists > - tuples return tuples > - XYZ containers return XYZ containers > - non-container iterables return iterators. How do you propose to distinguish between the last two cases? Attempting to slice it and catching an exception is not acceptable, IMO, as it can too easily mask bugs. -- Greg ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] PEP 3125 -- a modest proposal
Yes, I have read Swift :-) And in that spirit, I don't know whether to take this proposal seriously because it's kind of radical. Nevertheless, here goes... It has occurred to me that as Python stands today, an indent always begins with a colon. So in principle, we could define anything that looks like an indent but doesn't begin with a colon as a continuation. So the idea would be that you can continue a statement onto as many lines as you wish, provided that Each line after the first is indented strictly more than the first line (but not necessarily more than the remaining lines in the statement), and If there is a colon that will precede an indent, it is the last token of the last line, in which case the line after the colon must be indented strictly more than the first line (but not necessarily more than the remaining lines in the statement). For example: "abc" + "def" # second line with more whitespace than the first -- continuation "abc" + "def" # attempt to apply unary + to string literal "abc" + "def" + "ghi" # OK -- this line is indented more than "abc" This proposal has the advantage of being entirely lexical -- it doesn't even rely on counting parentheses or brackets, so unlike the current Python rule, it can be implemented entirely as a regular expression. It has the disadvantage of being a change, and may have its own pitfalls: if foo # Oops, I forgot the colon + bar # which makes this line a continuation Of course, when "if" isn't followed eventually by a colon, the code won't compile. However... x = 3, 4# x = (3, 4) x = 3, # x = (3,) 4# evaluate 4 and throw it away So it may be that this proposed rule is too tricky to use. However, it does have the merit of being even simpler than the current rule. Just a thought... ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] failing tests
Guido van Rossum wrote: > On 5/7/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> Guido van Rossum wrote: >> > Thanks for checking in xrange! Woot! >> > >> > test_compiler and test_transformer are waiting for someone to clean up >> > the compiler package (I forget what it doesn't support, perhapes only >> > nonlocal needs to be added.) >> >> It's definitely lagging on set comprehensions as well. I'm also pretty >> sure those two tests broke before nonlocal was added, as they were >> already broken when I started helping Georg in looking at the setcomp >> updates. > > I just fixed the doctest failures; but for the compiler package I > need help. Would you have the time? I don't really know the compiler package at all. I'll have a look, but it's going to take me a while to even figure out where the fixes need to go, let alone what they will actually look like. So if someone more familiar with the package beats me to fixing it, I won't be the least bit upset ;) Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
Re: [Python-3000] failing tests
On 5/7/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > I just fixed the doctest failures; but for the compiler package I > > need help. Would you have the time? > > I don't really know the compiler package at all. I'll have a look, but > it's going to take me a while to even figure out where the fixes need to > go, let alone what they will actually look like. > > So if someone more familiar with the package beats me to fixing it, I > won't be the least bit upset ;) Same boat I'm in. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
[Python-3000] ref counts
I'm starting up a continuous build of sorts on the PSF machine for the 3k branch. Right now the failures will only go to me. I've excluded the two tests that are known to currently fail. This will help us find new failures (including ref leaks). Probably in a week or so I'll send the results to python-3000-checkins. Since it's just running on a single machine (every 12 hours), this should be pretty stable. It has been for the trunk and 2.5 branch. I just wanted to point out some data points wrt ref counts. At the end of a test run on trunk with 298 tests the total ref count is: [482838 refs] When starting a new process (like during the subprocess tests): [7323 refs] With 3k and 302 tests: [615279 refs] and: [10457 refs] I don't think these are problematic. I expect that these ~30% increases in total ref counts are primarily the result of new-style classes. n ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
