Re: [Python-Dev] int vs ssize_t in unicode
Neal Norwitz wrote: In Include/ucnhash.h I notice some integers and wonder if those should be Py_ssize_t. It looks like they are just names so they should be pretty short. Right: int size is below 100; the name length of a Unicode character is below 40 (I believe). OTOH, changing them to Py_ssize_t wouldn't hurt, either. 235: assert(lengthINT_MAX); unicode-length = (int)length; Right: I just changed it. It may date back to a version of the patch where I only changed the signatures of the functions, but not the object layout. 376, 404: int i; Right, changed. 1366: (seems like this could be a 64-bit value) int nneeded; Right; also, the safe downcast can go away. (i stopped at this point, there are probably more) I looked through the entire file, and fixed all I could find. Modules/unicodedata.c (lots of ints, not sure if they are a problem) Most of them are not, since most functions deal only with Unicode characters, character names, and character numbers (which are below 2**21). 494: isize = PyUnicode_GET_SIZE(input); This is a problem, though; I fixed it. 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] int vs ssize_t in unicode
On 4/12/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
235:
assert(lengthINT_MAX);
unicode-length = (int)length;
Right: I just changed it. It may date back to a version of the patch
where I only changed the signatures of the functions, but not the
object layout.
I just grepped for INT_MAX and there's a ton of them still (well 83 in
*/*.c). Some aren't an issue like posixmodule.c, those are
_SC_INT_MAX. marshal is probably ok, but all uses should be verified.
Really all uses of {INT,LONG}_{MIN,MAX} should be verified and
converted to PY_SSIZE_T_{MIN,MAX} as appropriate.
There are only a few {INT,LONG}_MIN and 22 LONG_MAX.
I'll try to review these soon unless someone beats me to it.
n
___
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] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
Tim Peters wrote: [georg.brandl] Author: georg.brandl Date: Wed Apr 12 23:14:09 2006 New Revision: 45321 Modified: python/trunk/Lib/test/test_traceback.py python/trunk/Lib/traceback.py python/trunk/Misc/NEWS Log: Patch #860326: traceback.format_exception_only() now prepends the exception's module name to non-builtin exceptions, like the interpreter itself does. And all the trunk buildbot runs have failed since, in at least test_decimal, test_doctest and test_unpack. Please run tests before checking in. Well, it's tempting to let the buildbots run the tests for you wink Honestly, I didn't realize that doctest relies on traceback. Running the test suite takes over half an hour on this box, so I decided to take a chance. The 2.4 backport of this patch should be reverted, since it changes visible behavior (for example, all the 2.4 branch buildbot runs also fail now). Right. That's too much of a behavior change. Fine by me if we change the failing tests on the trunk to pass (noting that should have been done before checking in). I'm not the one to decide, but at some time the traceback module should be rewritten to match the interpreter behavior. Cheers, Georg ___ 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] Any reason that any()/all() do not take a predicate argument?
Hi, sorry if this came up before, but I tried searching the archives and found nothing. It would be really nice if new builtin truth functions in 2.5 took a predicate argument(defaults to bool), so one could write, for example: seq = [1,2,3,4,5] if any(seq, lambda x: x==5): ... which is clearly more readable than reduce(seq, lambda x,y: x or y==5, False) IIRC, something like that is called junctions in Perl 6. ___ 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] int vs ssize_t in unicode
Neal Norwitz wrote:
I just grepped for INT_MAX and there's a ton of them still (well 83 in
*/*.c). Some aren't an issue like posixmodule.c, those are
_SC_INT_MAX. marshal is probably ok, but all uses should be verified.
Really all uses of {INT,LONG}_{MIN,MAX} should be verified and
converted to PY_SSIZE_T_{MIN,MAX} as appropriate.
I replaced all the trivial ones; the remaining ones are (IMO) more
involved, or correct. In particular:
- collectionsmodule: deque is still restricted to 2GiB elements
- cPickle: pickling does not support huge strings (and probably
shouldn't); likewise marshal
- _sre is still limited to INT_MAX completely
- not sure why the mbcs codec is restricted to INT_MAX; somebody
should check the Win64 API whether the restriction can be
removed (most likely, it can)
- PyObject_CallFunction must be duplicated for PY_SSIZE_T_CLEAN,
then exceptions.c can be extended.
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] Any reason that any()/all() do not take a predicate argument?
Mikhail Glushenkov wrote: Hi, sorry if this came up before, but I tried searching the archives and found nothing. It would be really nice if new builtin truth functions in 2.5 took a predicate argument(defaults to bool), so one could write, for example: seq = [1,2,3,4,5] if any(seq, lambda x: x==5): ... Well, does if any(x == 5 for x in seq) meet your needs? Georg ___ 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] Request for review
Tim Peters wrote: [Georg Brandl] Hm. This broke a few doctests. I can fix them, but I wonder if doctest should accept a bare exception name if the exception is defined in the current module. No. Or should it ignore the module name altogether? No. doctest strives to be magic-free WYSIWYG. If someone _intends_ the module name to be optional in a doctest, they should explicitly use doctest's ELLIPSIS option. There's already a little bit of magic in the way doctest handles exceptions. I always use doctest.IGNORE_EXCEPTION_DETAIL so that everything after the first colon on the last line gets ignored when matching exceptions. That allows me to include the text of the exception in the documentation so its clear what the associated problem is, without worrying about spurious failures due to variations in the exact wording of the error message. Using an ellipsis instead would get essentially the same effect from a test point of view, but would result in less effective documentation. Given that the option exists, I assume I'm not the only who thinks that way. To get back to the original question of ignoring module names, I wonder if doctext should actually try to be a bit cleverer about the way it matches exceptions when the ignore exception detail flag is in effect. At the moment, documenting something as raising ZeroDivisionError in a doctest, but then actually raising a differently named subclass (such as decimal.DivisionByZero) in the code will result in a failed test. IMO, this is a spurious failure if I've told the doctest engine that I don't care about the details of exceptions raised - there's nothing wrong with the documentation, as the following relationship holds: Py issubclass(decimal.DivisionByZero, ZeroDivisionError) True The fact that what the call raises is technically an instance of a subclass rather than of the listed class is really an implementation detail, just like the text in the associated error message. The important point is that an except clause covering the documented exception type will catch the raised exception. The doctest machinery has access to both the expected exception name, the actual exception raised, and the dictionary used to execute the test, so something like issubclass(exc_type, eval(expected_exc_name, test_globs)) should do the trick (with a bit of work to extract the expected exception name, naturally). 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] unicode vs buffer (array) design issue can crash interpreter
Neal Norwitz wrote:
On 3/31/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Martin v. Löwis wrote:
Neal Norwitz wrote:
See http://python.org/sf/1454485 for the gory details. Basically if
you create a unicode array (array.array('u')) and try to append an
8-bit string (ie, not unicode), you can crash the interpreter.
The problem is that the string is converted without question to a
unicode buffer. Within unicode, it assumes the data to be valid, but
this isn't necessarily the case. We wind up accessing an array with a
negative index and boom.
There are several problems combined here, which might need discussion:
- why does the 'u#' converter use the buffer interface if available?
it should just support Unicode objects. The buffer object makes
no promise that the buffer actually is meaningful UCS-2/UCS-4, so
u# shouldn't guess that it is.
(FWIW, it currently truncates the buffer size to the next-smaller
multiple of sizeof(Py_UNICODE), and silently so)
I think that part should just go: u# should be restricted to unicode
objects.
'u#' is intended to match 's#' which also uses the buffer
interface. It expects the buffer returned by the object
to a be a Py_UNICODE* buffer, hence the calculation of the
length.
However, we already have 'es#' which is a lot safer to use
in this respect: you can explicity define the encoding you
want to see, e.g. 'unicode-internal' and the associated
codec also takes care of range checks, etc.
So, I'm +1 on restricting 'u#' to Unicode objects.
Note: 2.5 no longer crashes, 2.4 does.
Does this mean you would like to see this patch checked in to 2.5?
Yes.
What should we do about 2.4?
Perhaps you could add a warning that is displayed when
using u# with non-Unicode objects ?!
Index: Python/getargs.c
===
--- Python/getargs.c(revision 45333)
+++ Python/getargs.c(working copy)
@@ -1042,11 +1042,8 @@
STORE_SIZE(PyUnicode_GET_SIZE(arg));
}
else {
- char *buf;
- Py_ssize_t count = convertbuffer(arg, p, buf);
- if (count 0)
- return converterr(buf, arg, msgbuf, bufsize);
- STORE_SIZE(count/(sizeof(Py_UNICODE)));
+ return converterr(cannot convert raw
buffers,
+ arg, msgbuf, bufsize);
}
format++;
} else {
- should Python guarantee that all characters in a Unicode object
are between 0 and sys.maxunicode? Currently, it is possible to
create Unicode strings with either negative or very large Py_UNICODE
elements.
- if the answer to the last question is no (i.e. if it is intentional
that a unicode object can contain arbitrary Py_UNICODE values): should
Python then guarantee that Py_UNICODE is an unsigned type?
Py_UNICODE must always be unsigned. The whole implementation
relies on this and has been designed with this in mind (see
PEP 100). AFAICT, the configure does check that Py_UNICODE
is always unsigned.
Martin fixed the crashing problem in 2.5 by making wchar_t unsigned
which was a bug. (A configure test was reversed IIRC.) Can this
change to wchar_t be made in 2.4? That technically changes all the
interfaces even though it was a mistake. What should be done for 2.4?
If users want to interface from wchar_t to Python's Unicode
type they have to go through the PyUnicode_FromWideChar()
and PyUnicode_AsWideChar() interfaces. Assuming that Py_UNICODE
is the same as wchar_t is simply wrong (and always was).
I also think that changing the type from signed to unsigned
by backporting the configure fix will only make things safer
for the user, since extensions will probably not even be aware
of the fact that Py_UNICODE could be signed (it has always been
documented to be unsigned).
So +1 on backporting the configure test fix to 2.4.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Apr 13 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] building with C++
Jeremy == Jeremy Hylton [EMAIL PROTECTED] writes: Jeremy Looks good to me. Why don't you check it in. I did, but it broke the C build, so I reverted it and reopened the patch. I'll try to take a look at it more later today. Skip ___ 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] building with C++
[EMAIL PROTECTED] wrote: Jeremy Looks good to me. Why don't you check it in. I did, but it broke the C build, so I reverted it and reopened the patch. I'll try to take a look at it more later today. I took a different approach, introducing a second kind of sequence. Since most accesses go through macros, they are already typed correctly as long as the field have the same names (templates in C :-). 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] TODO Wiki (was: Preserving the blamelist)
On Wed, Apr 12, 2006 at 11:23:51PM -0400, Tim Peters wrote: Not the same thing, but I just added: http://wiki.python.org/moin/SimpleTodo I added a list of the Demo directories so that people know which ones need updating. --amk ___ 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] Any reason that any()/all() do not take a predicateargument?
sorry if this came up before, but I tried searching the archives and found nothing. It would be really nice if new builtin truth functions in 2.5 took a predicate argument(defaults to bool), so one could write, for example: seq = [1,2,3,4,5] if any(seq, lambda x: x==5): ... which is clearly more readable than reduce(seq, lambda x,y: x or y==5, False) How about this? if any(x==5 for x in seq): ___ 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] Exceptions doctest Re: Request for review
[Tim] ... doctest strives to be magic-free WYSIWYG. If someone _intends_ the module name to be optional in a doctest, they should explicitly use doctest's ELLIPSIS option. [Nick Coghlan] There's already a little bit of magic in the way doctest handles exceptions. I always use doctest.IGNORE_EXCEPTION_DETAIL so that everything after the first colon on the last line gets ignored when matching exceptions. Explicitly specifiying IGNORE_EXCEPTION_DETAIL isn't magic -- it's explicitly asking for something. That allows me to include the text of the exception in the documentation so its clear what the associated problem is, without worrying about spurious failures due to variations in the exact wording of the error message. Which is the documented purpose of IGNORE_EXCEPTION_DETAIL, for tests that want it. I rarely use it myself, but not never ;-) Using an ellipsis instead would get essentially the same effect from a test point of view, but would result in less effective documentation. Given that the option exists, I assume I'm not the only who thinks that way. The reason ELLIPSIS isn't always suitable for this purpose is explained in the IGNORE_EXCEPTION_DETAIL docs: Note that a similar effect can be obtained using ELLIPSIS, and IGNORE_EXCEPTION_DETAIL may go away when Python releases prior to 2.4 become uninteresting. Until then, IGNORE_EXCEPTION_DETAIL is the only clear way to write a doctest that doesn't care about the exception detail yet continues to pass under Python releases prior to 2.4 (doctest directives appear to be comments to them). For example, [ see the docs for the example] To get back to the original question of ignoring module names, I wonder if doctext should actually try to be a bit cleverer about the way it matches exceptions when the ignore exception detail flag is in effect. No. At the moment, documenting something as raising ZeroDivisionError in a doctest, but then actually raising a differently named subclass (such as decimal.DivisionByZero) in the code will result in a failed test. Perfect: the doctest is lying in such a case, and should fail. WYSIWYG rules for doctest. IMO, this is a spurious failure if I've told the doctest engine that I don't care about the details of exceptions raised This is a doc problem that's my fault: you're reading exception detail as a vague catch-all description, which is reasonable enough. I intended to use it as a technical term, referring specifically to str() of the exception object (the thing bound to an `except` statement's second parameter). For example, as in (among other places) Lib/ctypes/test/test_bitfields.py's except Exception, detail: Maybe I'm hallucinating, but I believe that was standard usage of the term way back when. If so, terminology probably changed when exceptions no longer needed to be strings, and I didn't notice. Regardless, the doctest docs are almost 0.5 wink clear enough about what it intends here. - there's nothing wrong with the documentation, as the following relationship holds: Py issubclass(decimal.DivisionByZero, ZeroDivisionError) True The fact that what the call raises is technically an instance of a subclass rather than of the listed class is really an implementation detail, just like the text in the associated error message. The important point is that an except clause covering the documented exception type will catch the raised exception. The doctest machinery has access to both the expected exception name, the actual exception raised, and the dictionary used to execute the test, so something like issubclass(exc_type, eval(expected_exc_name, test_globs)) should do the trick (with a bit of work to extract the expected exception name, naturally). Sorry, but it's horridly un-doctest-like to make inferences by magic. If you want to add an explicit ACCEPT_EXCEPTION_SUBCLASS doctest option, that's a different story. I would question the need, since I've never got close to needing it, and never heard anyone else bring it up. Is this something that happens to you often enough to be an irritation, or is it just that your brain tells you it's a cool idea? One reason I have to ask is that I'm pretty sure the example you gave is one that never bit you in real life. ___ 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] Is test_sundry really expected to succeed on Windows?
I've just managed to get Python built using the free MS compiler and tools (yay! full instructions to follow somewhere - probably the wiki and maybe as a patch to PCBuild\readme.txt) There's one thing that puzzled me - test_sundry is marked as an unexpected skip. As it imports tty, which imports termios, which doesn't exist on Windows, I'd imagine that this is an expected skip. Is this just something people are used to ignoring, or have I got a build issue I missed? Thanks, Paul. ___ 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] Is test_sundry really expected to succeed on Windows?
[Paul Moore] I've just managed to get Python built using the free MS compiler and tools (yay! full instructions to follow somewhere - probably the wiki and maybe as a patch to PCBuild\readme.txt) There's one thing that puzzled me - test_sundry is marked as an unexpected skip. As it imports tty, which imports termios, which doesn't exist on Windows, I'd imagine that this is an expected skip. Is this just something people are used to ignoring, or have I got a build issue I missed? You didn't say from where, or when, you got the Python source code. Someone recently added a bare import tty to test_sundry on the trunk, without realizing that would cause test_sundry to get skipped on Windows. I repaired that on the trunk about 12 hours ago, in revision 45332. ___ 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] Is test_sundry really expected to succeed on Windows?
On 4/13/06, Tim Peters [EMAIL PROTECTED] wrote: [Paul Moore] You didn't say from where, or when, you got the Python source code. Someone recently added a bare import tty to test_sundry on the trunk, without realizing that would cause test_sundry to get skipped on Windows. I repaired that on the trunk about 12 hours ago, in revision 45332. Sorry, it's a trunk checkout, but I'm currently working on a machine without svn access, so my checkout is from last night (before your checkin). So that's the issue. Apologies - I should have checked the svn logs first. Paul. ___ 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] PEP 359: The make Statement
I know 2.5's not out yet, but since I now have a PEP number, I'm going
to go ahead and post this for discussion. Currently, the target
version is Python 2.6. You can also see the PEP at:
http://www.python.org/dev/peps/pep-0359/
Thanks in advance for the feedback!
PEP: 359
Title: The make Statement
Version: $Revision: 45366 $
Last-Modified: $Date: 2006-04-13 07:36:24 -0600 (Thu, 13 Apr 2006) $
Author: Steven Bethard [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 05-Apr-2006
Python-Version: 2.6
Post-History: 05-Apr-2006, 06-Apr-2006
Abstract
This PEP proposes a generalization of the class-declaration syntax,
the ``make`` statement. The proposed syntax and semantics parallel
the syntax for class definition, and so::
make callable name tuple:
block
is translated into the assignment::
name = callable(name, tuple, namespace)
where ``namespace`` is the dict created by executing ``block``.
The PEP is based on a suggestion [1]_ from Michele Simionato on the
python-dev list.
Motivation
==
Class statements provide two nice facilities to Python:
(1) They are the standard Python means of creating a namespace. All
statements within a class body are executed, and the resulting
local name bindings are passed as a dict to the metaclass.
(2) They encourage DRY (don't repeat yourself) by allowing the class
being created to know the name it is being assigned.
Thus in a simple class statement like::
class C(object):
x = 1
def foo(self):
return 'bar'
the metaclass (``type``) gets called with something like::
C = type('C', (object,), {'x':1, 'foo':function foo at ...})
The class statement is just syntactic sugar for the above assignment
statement, but clearly a very useful sort of syntactic sugar. It
avoids not only the repetition of ``C``, but also simplifies the
creation of the dict by allowing it to be expressed as a series of
statements.
Historically, type instances (a.k.a. class objects) have been the only
objects blessed with this sort of syntactic support. But other sorts
of objects could benefit from such support. For example, property
objects take three function arguments, but because the property type
cannot be passed a namespace, these functions, though relevant only to
the property, must be declared before it and then passed as arguments
to the property call, e.g.::
class C(object):
...
def get_x(self):
...
def set_x(self):
...
x = property(get_x, set_x, ...)
There have been a few recipes [2]_ trying to work around this
behavior, but with the new make statement (and an appropriate
definition of property), the getter and setter functions can be
defined in the property's namespace like::
class C(object):
...
make property x:
def get(self):
...
def set(self):
...
The definition of such a property callable could be as simple as::
def property(name, args, namespace):
fget = namespace.get('get')
fset = namespace.get('set')
fdel = namespace.get('delete')
doc = namespace.get('__doc__')
return __builtin__.property(fget, fset, fdel, doc)
Of course, properties are only one of the many possible uses of the
make statement. The make statement is useful in essentially any
situation where a name is associated with a namespace. So, for
example, namespaces could be created as simply as::
make namespace ns:
This creates a namespace named ns with a badger attribute
and a spam function
badger = 42
def spam():
...
And if Python acquires interfaces, given an appropriately defined
``interface`` callable, the make statement can support interface
creation through the syntax::
make interface C(...):
...
This would mean that interface systems like that of Zope would no
longer have to abuse the class syntax to create proper interface
instances.
Specification
=
Python will translate a make statement::
make callable name tuple:
block
into the assignment::
name = callable(name, tuple, namespace)
where ``namespace`` is the dict created by executing ``block``.
The ``tuple`` expression is optional; if not present, an empty tuple
will be assumed.
A patch is available implementing these semantics [3]_.
The make statement introduces a new keyword, ``make``. Thus in Python
2.6, the make statement will have to be enabled using ``from
__future__ import make_statement``.
Open Issues
===
Does the ``make`` keyword break too much code? Originally, the make
statement used the keyword ``create`` (a suggestion due to Nick
Coghlan). However, investigations into the standard library [4]_ and
Zope+Plone code [5]_ revealed that ``create`` would break a lot more
code, so ``make`` was adopted as the keyword
Re: [Python-Dev] Is test_sundry really expected to succeed on Windows?
Paul Moore wrote: Sorry, it's a trunk checkout, but I'm currently working on a machine without svn access, so my checkout is from last night (before your checkin). So that's the issue. Apologies - I should have checked the svn logs first. I find this kind of mistake (working on old sources) quite natural, so no need to apologize (of course, apologizing can't hurt except yourself...) 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] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
Tim Peters wrote: [Georg Brandl] Well, it's tempting to let the buildbots run the tests for you wink Honestly, I didn't realize that doctest relies on traceback. Running the test suite takes over half an hour on this box, so I decided to take a chance. Nobody ever expects that a checkin will break tests, so merely expecting that a checkin won't break tests is not sufficient reason to skip running tests. You made a checkin that broke every buildbot slave we have, and I suggest you're taking a wrong lesson from that ;-) No objection, mylord ;) Do release-build tests without -uall take over half an hour on your box? Running that much is good enough precaution. Even (on boxes with makefiles) running make quicktest is mounds better than doing no testing. All the cases of massive buildbot test breakage we've seen this week would have been caught by doing just that much before checkin. Until now, I've always run with -uall. Running make quicktest is fine, but if the buildbots starts failing with -uall afterwards, no one will accept that as an excuse ;) When previously-passing buildbots start failing, it at least stops me cold, and (I hope) stops others too. Sometimes it's unavoidable. For example, I spent almost all my Python time Monday repairing a variety of new test failures unique to the OpenBSD buildbot (that platform is apparently unique in assigning addresses with the sign bit set, which broke all sorts of tests after someone changed id() to always return a positive value). That's fine -- it happens. It's the seemingly routine practice this week of checking in changes that break the tests everywhere that destroys productivity without good cause. I see, and I'm sorry I was part of it. Relatedly, if someone makes a checkin and sees that it breaks lots of buildbot runs, they should revert the patch themself instead of waiting for someone else to get so frustrated that they do it. Reverting is very easy with svn, but people are reluctant to revert someone else's checkin. The buildbot system is useless so long as the tests fail, and having the tests pass isn't optional. For excuse, I posted here immediately after I saw that the tests failed, asking whether to change doctest or revert my change. I'm not the one to decide, but at some time the traceback module should be rewritten to match the interpreter behavior. No argument from me about that. Fine. There's another one, python.org/sf/1326077, which looks suspicious to me too. Georg ___ 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] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
Tim Peters wrote: I'm not the one to decide, but at some time the traceback module should be rewritten to match the interpreter behavior. No argument from me about that. I also think the traceback module should be corrected, and the test cases updated, despite the objections that it may break other people's doctest test cases. 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] PEP 359: The make Statement
Steven Bethard wrote: I know 2.5's not out yet, but since I now have a PEP number, I'm going to go ahead and post this for discussion. Currently, the target version is Python 2.6. You can also see the PEP at: http://www.python.org/dev/peps/pep-0359/ Thanks in advance for the feedback! I generally like the idea. A different name would be better. Here's a list of approximate synonyms that might work (ordered by my preference...) induce compose realize furnish produce And others I found in no particular order... invent originate organize build author generate construct erect concoct coin establish instigate trigger offer ___ 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] Is test_sundry really expected to succeed on Windows?
[Paul Moore] Sorry, it's a trunk checkout, but I'm currently working on a machine without svn access, so my checkout is from last night (before your checkin). So that's the issue. Apologies - I should have checked the svn logs first. [Martin v. Löwis] I find this kind of mistake (working on old sources) quite natural, so no need to apologize (of course, apologizing can't hurt except yourself...) Yup, I sure didn't take offense -- and I'd think there's something wrong with Paul if he took time to scour SVN logs for obscure Windows bugs ;-) ___ 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] PEP 359: The make Statement
Steven Bethard wrote: I know 2.5's not out yet, but since I now have a PEP number, I'm going to go ahead and post this for discussion. Currently, the target version is Python 2.6. You can also see the PEP at: http://www.python.org/dev/peps/pep-0359/ Thanks in advance for the feedback! Interesting! Sometimes, people want the ability to refer to the namespace already in the block, or have the namespace control execution of the block. For example, sometimes people what to get the class object while the class is being defined. It's not there yet, of course. In other cases (also properties) they want the name to be bound not the one of the get method, but instead the name of the property (of course, the make statement solves this problem already in a different way). Would it be possible/useful to have a pre-block hook to the callable, which would provide the dictionary; this dictionary might not be a proper dictionary (but only some mapping), or it might be pre-initialized. 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
[Python-Dev] Checkin 45232: Patch #1429775
Building SVN trunk with --enable-shared has been broken on Mac OS X Intel since rev. 45232 a couple of days ago. I can't say if this is the case anywhere else as well. What happens is simply that ld can't find the file to link the shared mods against. //Simon ___ 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] [Python-checkins] r45334 - python/trunk/Lib/test/leakers/test_gen1.py python/trunk/Lib/test/leakers/test_generator_cycle.py python/trunk/Lib/test/leakers/test_tee.py
[neal.norwitz] Author: neal.norwitz Date: Thu Apr 13 06:35:36 2006 New Revision: 45334 Added: python/trunk/Lib/test/leakers/test_gen1.py (contents, props changed) Removed: python/trunk/Lib/test/leakers/test_generator_cycle.py python/trunk/Lib/test/leakers/test_tee.py Log: Remove tests that no longer leak. There is still one leaking generator test [Jim Jewett] Should these really be removed, or just added to the regular tests -- to ensure that the leakage doesn't get worse. I was going to ask much the same: bugs that have been fixed have a delightful way of reappearing a release or two (or ...) later, perhaps because they traversed unusually delicate code paths to begin with. Rather than delete a leak test, perhaps we could simply move it into a new old-leaking-tests subdirectory? Likewise for crash tests. When the bug reappears, it's helfpul to have the focussed (whittled-down) old test that provoked it handy. ___ 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] ia64 debian buildbot
[Please let me know if this should go to the machine owner instead] Why does the ia64 debian buildbot now complain about unaligned accesses, and how can we find out where they occur? http://www.python.org/dev/buildbot/trunk/ia64%20Debian%20unstable%20trunk/builds/123/step-test/0 Thanks, Thomas ___ 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] Exceptions doctest Re: Request for review
Tim Peters wrote: Sorry, but it's horridly un-doctest-like to make inferences by magic. If you want to add an explicit ACCEPT_EXCEPTION_SUBCLASS doctest option, that's a different story. I would question the need, since I've never got close to needing it, and never heard anyone else bring it up. Is this something that happens to you often enough to be an irritation, or is it just that your brain tells you it's a cool idea? One reason I have to ask is that I'm pretty sure the example you gave is one that never bit you in real life. You'd be guessing right - and the explanation of how you meant the term makes a lot of sense, too. Consider my crazy idea withdrawn :) A real limitation I *have* encountered is that doctest doesn't like the idea of a single statement that triggers normal output followed by an exception (it expects one or the other). However, the case where I wanted that was rather esoteric and easy enough to deal with by using a custom result checker. 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] PEP 359: The make Statement
On 4/13/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Steven Bethard wrote: I know 2.5's not out yet, but since I now have a PEP number, I'm going to go ahead and post this for discussion. Currently, the target version is Python 2.6. You can also see the PEP at: http://www.python.org/dev/peps/pep-0359/ Thanks in advance for the feedback! [snip] Would it be possible/useful to have a pre-block hook to the callable, which would provide the dictionary; this dictionary might not be a proper dictionary (but only some mapping), or it might be pre-initialized. Yeah, something along these lines came up in dicussing using the make statement for XML generation. You might want to write something like: make Element html: make Element head: ... make Element body: ... however, this doesn't work with the current semantics because: (1) dict's are unordered (2) dict's can't have the same name (key) twice and so you can only generate XML/HTML where the order of elements doesn't matter and you never have repeated elements. That's not really XML/HTML anymore. You could probably solve this if you could supply a different type of dict-like object for the block to be executed in. Then we'd have to have a translation from something like:: make callable name tuple in mapping: block to something like:: name = callable(name, tuple, namespace) where namespace is created by executing the statements of block in the mapping object. Skipping the syntax discussion for the moment, I guess I have two problems with this: (1) It complicates the statement semantics pretty substantially (2) It breaks the parallel with the class statement since you can't supply an alternate mapping type for class bodies to be executed in (3) It adds some degree of coupling between the mapping type and the callable. For the example above, I expect I'd have to do something like:: make Element html in ElementDict(): make Element head in ElementDict(): ... make Element body in ElementDict(): ... where I'd expect that ElementDict was really only useful if you were making Elements. It also seems a little inelegant to have to create a new ElementDict each time. To avoid this latter problem, I guess we could allow Element to supply a __getmapping__ hook which would be called to get the mapping to execute the block in, but then simple functions would not have access to the full functionality of the make statement. I guess I'm willing to consider the idea, but only if someone else presents a concrete proposal for the additional semantics (that's better than the one above) and a few use-cases showing how it would improve some code. 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] PEP 359: The make Statement
At 12:05 PM 4/13/2006 -0600, Steven Bethard wrote: On 4/13/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Steven Bethard wrote: I know 2.5's not out yet, but since I now have a PEP number, I'm going to go ahead and post this for discussion. Currently, the target version is Python 2.6. You can also see the PEP at: http://www.python.org/dev/peps/pep-0359/ Thanks in advance for the feedback! [snip] Would it be possible/useful to have a pre-block hook to the callable, which would provide the dictionary; this dictionary might not be a proper dictionary (but only some mapping), or it might be pre-initialized. Yeah, something along these lines came up in dicussing using the make statement for XML generation. You might want to write something like: make Element html: make Element head: ... make Element body: ... however, this doesn't work with the current semantics because: (1) dict's are unordered (2) dict's can't have the same name (key) twice Why not just use 'with' statements for this? The context gets invoked before and after, so it can track any local bindings that occur -- including the 'as' binding. with maker(...) as foo: blah blah While it's true that frame-locals hacking isn't especially portable, you can at least use it to develop your actual use cases for this stuff, and then show why the syntax is awkward or doesn't support something. ___ 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] Preserving the blamelist
On Wed, Apr 12, 2006 at 01:16:04AM -0400, Tim Peters wrote: I'd whine about not checking buildbot health after a code change, except that it's much more tempting to point out that Thomas couldn't have run the test suite successfully on his own box in this case :-) Not with -uall, yes. Without -uall it ran fine (by chance, I admit.) I didn't feel like running the rather lengthy -uall test on my box right before bedtime; I won't be skipping that again anytime soon ;) -- 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] [Python-3000] Removing 'self' from method definitions
(Cc to python dev, as my question is really about 2.x) On 4/13/06, Ian Bicking [EMAIL PROTECTED] wrote: ... the self in the signature (and the miscount of arguments in TypeError exceptions) ... Even in the 2.x line, the TypeError messages should be improved. # No syntax errors when creating m() class C: def m(): pass but the method can't actually be called, and won't quite say why. # This message is good C.m() Traceback (most recent call last): File pyshell#101, line 1, in -toplevel- C.m() TypeError: unbound method m() must be called with C instance as first argument (got nothing instead) but the obvious fix of using an instance is just confusing C().m() Traceback (most recent call last): File pyshell#102, line 1, in -toplevel- C().m() TypeError: m() takes no arguments (1 given) Could it at least say something like (1 given, including self)? I suppose the argument might be named something other than self, particularly in C code, but ... that strikes me as a smaller problem than the mysteriously appearing invisible argument. -jJ ___ 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] PEP 359: The make Statement
I guess I fail to see how this syntax is a significant improvement over metaclasses (though __metaclass__ = xyz may not be the most aesthetic construct.) -- Ian D. Bollinger ___ 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] ia64 debian buildbot
Thomas Heller wrote: Why does the ia64 debian buildbot now complain about unaligned accesses, and how can we find out where they occur? I don't know why they started show up suddenly; on Debian-Itanium, it is a configuration option (even per process, through prctl(1)) whether they just produce a log message, or a signal, or nothing; if they produce a log message, this also goes to the process' terminal. These unaligned access must have been there for some time now; perhaps something on the machine has changed. Matthias? Finding where they originate from is really hard. You need to set the process into the signal unaligned access mode, and then run it under a debugger, so you know where it crashes. This requires shell access to the machine. I have tried to reproduce it on my Itanium machine, and found that that they come from the AST compiler's arena (I /knew/ it was wrong to implement your own memory management algorithms :-): it was returning memory blocks that were only 4-aligned, so the the pointers in the ASDL sequences were all unaligned; hence the errors. I changed that to always guarantee 8-alignment for all blocks returned from the arena; that seems to help. 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] PEP 359: The make Statement
On 4/13/06, Ian D. Bollinger [EMAIL PROTECTED] wrote:
I guess I fail to see how this syntax is a significant improvement over
metaclasses (though __metaclass__ = xyz may not be the most aesthetic
construct.)
It doesn't seem strange to you to have to use a *class* statement and
a __meta*class*__ hook to create something that's not a class at all?
Consider
def get_dict(name, args, kwargs):
... return kwargs
...
class C(object):
... __metaclass__ = get_dict
... x = 1
... y = 2
...
C
{'y': 2, 'x': 1, '__module__': '__main__', '__metaclass__':
function get_dict at 0x00DB9F70}
When I read a class statement, even if it specifies __metaclass__, I
assume that it will create a class object. I believe the average
reader of Python code will make similar assumptions. Sure, we can
abuse class/__metaclass__ to do something similar[1], but is that
really a good idea?
[1] Minor issue - you have to be okay with the class statement adding
__module__ and __metaclass__ to your dict.
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] PEP 359: The make Statement
On 4/13/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 12:05 PM 4/13/2006 -0600, Steven Bethard wrote: On 4/13/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Steven Bethard wrote: I know 2.5's not out yet, but since I now have a PEP number, I'm going to go ahead and post this for discussion. Currently, the target version is Python 2.6. You can also see the PEP at: http://www.python.org/dev/peps/pep-0359/ Thanks in advance for the feedback! [snip] Would it be possible/useful to have a pre-block hook to the callable, which would provide the dictionary; this dictionary might not be a proper dictionary (but only some mapping), or it might be pre-initialized. Yeah, something along these lines came up in dicussing using the make statement for XML generation. You might want to write something like: make Element html: make Element head: ... make Element body: ... however, this doesn't work with the current semantics because: (1) dict's are unordered (2) dict's can't have the same name (key) twice Why not just use 'with' statements for this? The context gets invoked before and after, so it can track any local bindings that occur -- including the 'as' binding. with maker(...) as foo: blah blah While it's true that frame-locals hacking isn't especially portable, you can at least use it to develop your actual use cases for this stuff, and then show why the syntax is awkward or doesn't support something. Sorry, I'm not clear on exactly what you're suggesting. Are you suggesting I try to implement the make-statement using context managers? Or that I use a context manager to address Martin's problem? 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] ia64 debian buildbot
Martin v. Löwis wrote: Thomas Heller wrote: Why does the ia64 debian buildbot now complain about unaligned accesses, and how can we find out where they occur? I don't know why they started show up suddenly; on Debian-Itanium, it is a configuration option (even per process, through prctl(1)) whether they just produce a log message, or a signal, or nothing; if they produce a log message, this also goes to the process' terminal. These unaligned access must have been there for some time now; perhaps something on the machine has changed. Matthias? Finding where they originate from is really hard. You need to set the process into the signal unaligned access mode, and then run it under a debugger, so you know where it crashes. This requires shell access to the machine. I have tried to reproduce it on my Itanium machine, and found that that they come from the AST compiler's arena (I /knew/ it was wrong to implement your own memory management algorithms :-): it was returning memory blocks that were only 4-aligned, so the the pointers in the ASDL sequences were all unaligned; hence the errors. I changed that to always guarantee 8-alignment for all blocks returned from the arena; that seems to help. Cool - thanks. I'm anxiously waiting until the buildbot runs the ctypes-test ;-). Thomas ___ 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] PEP 359: The make Statement
At 01:51 PM 4/13/2006 -0600, Steven Bethard wrote: Sorry, I'm not clear on exactly what you're suggesting. Are you suggesting I try to implement the make-statement using context managers? Or that I use a context manager to address Martin's problem? Yes. :) Both. Or neither. What I'm suggesting is that you implement the *use cases* for the make statement using 'with' and a bit of getframe hackery. Then, your PEP can be clearer as to whether there's actually any significant advantage to having a make statement. IOW, if make isn't anything more than yet another way to spell class decorators, metaclasses, or with statements, it's probably not a good idea to add it to the language. ___ 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] PEP 359: The make Statement
On 4/13/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 01:51 PM 4/13/2006 -0600, Steven Bethard wrote: Sorry, I'm not clear on exactly what you're suggesting. Are you suggesting I try to implement the make-statement using context managers? Or that I use a context manager to address Martin's problem? Yes. :) Both. Or neither. What I'm suggesting is that you implement the *use cases* for the make statement using 'with' and a bit of getframe hackery. Then, your PEP can be clearer as to whether there's actually any significant advantage to having a make statement. IOW, if make isn't anything more than yet another way to spell class decorators, metaclasses, or with statements, it's probably not a good idea to add it to the language. I'm against using anything with getframe hackery but here are the use cases written with the class/__metaclass__ abuse: class C(object): ... class x: __metaclass__ = property def get(self): ... def set(self): class ns: This creates a namespace named ns with a badger attribute and a spam function __metaclass__ = namespace badger = 42 def spam(): ... class C(...): __metaclass__ = iterface ... Those should be mostly equivalent[1], except that all of the namespaces created will have additional __metaclass__ and __module__ attributes. The question is, is the intent still clear? When reading these, especially for the namespace example, I expect the result to be a class. The fact that it's not will be thoroughly confusing for anyone who doesn't know that metaclasses don't have to create class objects, and at least mildly misleading even for those who do understand metaclasses. Generally, the make statement has the advantage of not totally confusing your reader when your class statement creates something which is not a class at all. ;-) [1] So you don't have to check the PEP, here's what the make-statement versions look like: class C(object): ... make property x: def get(self): ... def set(self): ... make namespace ns: This creates a namespace named ns with a badger attribute and a spam function badger = 42 def spam(): ... make interface C(...): ... 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] [Python-3000] Removing 'self' from methoddefinitions
Jim Jewett [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] # No syntax errors when creating m() class C: def m(): pass but the method can't actually be called Unless it is wrapped as a staticmethod ;-) ... C().m() Traceback (most recent call last): File pyshell#102, line 1, in -toplevel- C().m() TypeError: m() takes no arguments (1 given) Could it at least say something like (1 given, including self)? or perhaps '(self + 0 given' or '(instance + 0 more given)' Terry Jan Reedy ___ 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] PEP 359: The make Statement
At 02:21 PM 4/13/2006 -0600, Steven Bethard wrote: On 4/13/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 01:51 PM 4/13/2006 -0600, Steven Bethard wrote: Sorry, I'm not clear on exactly what you're suggesting. Are you suggesting I try to implement the make-statement using context managers? Or that I use a context manager to address Martin's problem? Yes. :) Both. Or neither. What I'm suggesting is that you implement the *use cases* for the make statement using 'with' and a bit of getframe hackery. Then, your PEP can be clearer as to whether there's actually any significant advantage to having a make statement. IOW, if make isn't anything more than yet another way to spell class decorators, metaclasses, or with statements, it's probably not a good idea to add it to the language. I'm against using anything with getframe hackery That's irrelevant; the point is that your PEP should show why a statement is *better*, either by showing the hackery isn't possible, isn't practical, or at least is hacky. but here are the use cases written with the class/__metaclass__ abuse: How is it *abuse* to use a language feature as it's designed? The question is, is the intent still clear? Depends on your use case. I'm just saying that the PEP would be tons clearer if it started out by saying right up front that its goal is to provide a prominent form of syntax sugar for __metaclass__ uses in cases where the thing being create isn't particularly class-like. At the moment, that's not particularly clear from the PEP, which talks about generalizing the class declaration syntax -- something that's already sufficiently general, for classes. The PEP also doesn't explain why, for example, it shouldn't simply allow 'callable' to be an arbitrary expression, invoked with 'callable(name,namespace)'. I'd presume this is to allow backward compatibility with metaclasses... except the statement is for making things that *aren't* classes, so why is compatibility needed? The PEP also doesn't explain why the particular syntax order is chosen. Why is it make callable name(tuple): and not, say, make name(tuple) from callable: or name = callable(tuple): (which doesn't require a new keyword). ___ 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] Building Python with the free MS Toolkit compiler
I've just added some instructions on how to build Python on Windows with the free MS Toolkit C++ compiler. They are at http://wiki.python.org/moin/Building_Python_with_the_free_MS_C_Toolkit. Most of the credit for this goes to David Murmann, whose posting on the subject to python-list pointed out the existence of Nant, a free tool which will read Visual Studio solution files, and inspired me to see if I could get the process to work. If anyone finds any problems with the instructions given there, feel free to let me know (or better still, update the page with your correction!) Paul. ___ 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] PEP 359: The make Statement
Steven Bethard wrote: On 4/13/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Steven Bethard wrote: I know 2.5's not out yet, but since I now have a PEP number, I'm going to go ahead and post this for discussion. Currently, the target version is Python 2.6. You can also see the PEP at: http://www.python.org/dev/peps/pep-0359/ Thanks in advance for the feedback! [snip] Would it be possible/useful to have a pre-block hook to the callable, which would provide the dictionary; this dictionary might not be a proper dictionary (but only some mapping), or it might be pre-initialized. Yeah, something along these lines came up in dicussing using the make statement for XML generation. You might want to write something like: make Element html: make Element head: ... make Element body: ... however, this doesn't work with the current semantics because: (1) dict's are unordered (2) dict's can't have the same name (key) twice Is the body of the make statement going to work like the body of a class statement? I would assume so, in which case (2) would be a given. That is, if you can do: make Element html: title_text = 'foo' make Element title: content = title_text del title_text Then you really can't have multiple keys with the same name unless you give up the ability to refer in the body of the make statement to things defined earlier in that same body. Unless items that were rebound were hidden, but still somehow accessible to Element. and so you can only generate XML/HTML where the order of elements doesn't matter and you never have repeated elements. That's not really XML/HTML anymore. You could probably solve this if you could supply a different type of dict-like object for the block to be executed in. Then we'd have to have a translation from something like:: make callable name tuple in mapping: block to something like:: name = callable(name, tuple, namespace) where namespace is created by executing the statements of block in the mapping object. Skipping the syntax discussion for the moment, I guess I have two problems with this: (1) It complicates the statement semantics pretty substantially (2) It breaks the parallel with the class statement since you can't supply an alternate mapping type for class bodies to be executed in (3) It adds some degree of coupling between the mapping type and the callable. For the example above, I expect I'd have to do something like:: make Element html in ElementDict(): make Element head in ElementDict(): ... make Element body in ElementDict(): ... Maybe Element.__make_dict__ could be ElementDict. This doesn't feel that unclean if you are also using Element.__make__ instead of Element.__call__; though there is a hidden cleverness factor (maybe in a bad way). -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.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] PEP 359: The make Statement
On 4/13/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 02:21 PM 4/13/2006 -0600, Steven Bethard wrote: [snip examples using class/__metaclass__ statements to create non-types] The question is, is the intent still clear? Depends on your use case. I'm just saying that the PEP would be tons clearer if it started out by saying right up front that its goal is to provide a prominent form of syntax sugar for __metaclass__ uses in cases where the thing being create isn't particularly class-like. Good point. I'll try to elaborate on that a bunch. The PEP also doesn't explain why, for example, it shouldn't simply allow 'callable' to be an arbitrary expression, invoked with 'callable(name,namespace)'. I'd presume this is to allow backward compatibility with metaclasses... except the statement is for making things that *aren't* classes, so why is compatibility needed? The PEP also doesn't explain why the particular syntax order is chosen. Why is it make callable name(tuple): and not, say, make name(tuple) from callable: or name = callable(tuple): (which doesn't require a new keyword). Thanks for the feedback. I'll put that into the PEP too, but in short the answer is that the particular syntax follows the class syntax exactly except that class is replaced by make callable. There have been a lot of other proposals that try to introduce dramatically new syntax for these sorts of things, e.g. `Nick Coghlan's suggestion`_ to allow ** to indicate that keyword arguments would be supplied on the following block, e.g.:: options = dict(**): def option1(*args, **kwds): # Do option 1 def option2(*args, **kwds): # Do option 2 (Nick's doesn't solve the DRY issue when you need to know the name of the thing being created, but I'll ignore that for the moment.) Basically, I was trying to be as un-creative syntactically as possible, hoping that Python programmers would be able to translate their knowledge of how the class statement works into knowledge of how the make statement works. .. _Nick Coghlan's suggestion: http://mail.python.org/pipermail/python-3000/2006-April/000689.html 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
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 383 open ( -8) / 3156 closed (+14) / 3539 total ( +6) Bugs: 886 open (-12) / 5759 closed (+28) / 6645 total (+16) RFE : 210 open ( -5) / 212 closed ( +5) / 422 total ( +0) New / Reopened Patches __ socket.py: remove misleading comment (2006-04-08) CLOSED http://python.org/sf/1466993 opened by John J Lee Many functions in socket module are not thread safe (2006-04-09) http://python.org/sf/1467080 opened by Maxim Sobolev fix double free with tqs in standard build (2006-04-09) CLOSED http://python.org/sf/1467512 opened by Neal Norwitz add Popen objects to _active only in __del__, (2006-04-10) CLOSED http://python.org/sf/1467770 opened by cheops tkFont: simple fix to error at shutdown (2006-04-11) CLOSED http://python.org/sf/1468808 opened by Russell Owen Make -tt the default (2006-04-12) http://python.org/sf/1469190 opened by Thomas Wouters PyErrr_Display and traceback.format_exception_only behaviour (2003-12-15) CLOSED http://python.org/sf/860326 reopened by tim_one Alternative to rev 45325 (2006-04-12) http://python.org/sf/1469594 opened by Skip Montanaro Alternative to rev 45325 (2006-04-12) http://python.org/sf/1469594 reopened by montanaro Patches Closed __ socket.py: remove misleading comment (2006-04-08) http://python.org/sf/1466993 closed by gbrandl Use dlopen() to load extensions on Darwin, where possible (2006-03-21) http://python.org/sf/1454844 closed by anthonybaxter Improved generator finalization (2006-04-03) http://python.org/sf/1463867 closed by pje const int was truncated to char (2006-03-31) http://python.org/sf/1461822 closed by ocean-city Mutable Iterators PEP (03/26/06) http://python.org/sf/1459011 closed by sf-robot fix double free with tqs in standard build (2006-04-09) http://python.org/sf/1467512 closed by nnorwitz clean up new calendar locale usage (2006-04-03) http://python.org/sf/1463288 closed by doerwalter Functioning Tix.Grid (2006-03-31) http://python.org/sf/146 closed by loewis Link Python modules to libpython on linux if --enable-shared (2006-02-11) http://python.org/sf/1429775 closed by loewis add Popen objects to _active only in __del__, (2006-04-10) http://python.org/sf/1467770 closed by loewis subprocess: optional auto-reaping fixing os.wait() lossage (2005-04-21) http://python.org/sf/1187312 closed by loewis tkFont: simple fix to error at shutdown (2006-04-11) http://python.org/sf/1468808 closed by gbrandl PEP 343 draft documentation (2005-07-07) http://python.org/sf/1234057 closed by ncoghlan PyErrr_Display and traceback.format_exception_only behaviour (2003-12-15) http://python.org/sf/860326 closed by gbrandl Alternative to rev 45325 (2006-04-12) http://python.org/sf/1469594 closed by montanaro 832799 proposed changes (2003-11-25) http://python.org/sf/849262 closed by loewis Updated Demo\parser\unpack.py (2006-03-02) http://python.org/sf/1441452 closed by loewis New / Reopened Bugs ___ size_t warnings on OSX 10.3 (2006-04-09) http://python.org/sf/1467201 opened by Anthony Baxter open should default to binary mode on windows (2006-04-09) CLOSED http://python.org/sf/1467309 opened by Adam Hupp test_ctypes fails on OSX 10.3 (2006-04-10) http://python.org/sf/1467450 opened by Anthony Baxter Header.decode_header eats up spaces (2006-04-10) http://python.org/sf/1467619 opened by Mathieu Goutelle %-formatting and dicts (2006-04-10) http://python.org/sf/1467929 opened by M.-A. Lemburg os.listdir on Linux returns empty list on some errors (2006-04-10) CLOSED http://python.org/sf/1467952 opened by Gary Stiehr re incompatibility in sre (2000-09-11) http://python.org/sf/214033 reopened by tmick Hitting CTRL-C while in a loop closes IDLE on cygwin (2006-04-11) http://python.org/sf/1468223 opened by Miki Tebeka test_grp test_pwd fail on Linux (2006-04-11) CLOSED http://python.org/sf/1468231 opened by Miki Tebeka Possible Integer overflow (2006-04-11) CLOSED http://python.org/sf/1468727 opened by ekellinis SimpleXMLRPCServer doesn't work anymore on Windows (2006-04-12) CLOSED http://python.org/sf/1469163 opened by kadeko Exception when handling http response (2006-04-12) CLOSED http://python.org/sf/1469498 opened by Richard Kasperski Build requires already built Python (2006-04-12) CLOSED http://python.org/sf/1469548 opened by Stephan R.A. Deibel FTP modue functions are not re-entrant,give odd exceptions (2006-04-12) http://python.org/sf/1469557 opened by Bruce __dict__ (2006-04-13) http://python.org/sf/1469629 opened by Dobes V distutils.core: link to list of Trove classifiers (2006-04-13)
Re: [Python-Dev] [Python-checkins] r45321 - in pyt hon/trunk: Lib/test/test_traceback.py Lib/tracebac k.py Misc/NEWS
On Friday 14 April 2006 02:31, Martin v. Löwis wrote: Tim Peters wrote: I'm not the one to decide, but at some time the traceback module should be rewritten to match the interpreter behavior. No argument from me about that. I also think the traceback module should be corrected, and the test cases updated, despite the objections that it may break other people's doctest test cases. I don't mind one way or the other, but with the number of people working actively on the code at the moment, I think reverting broken patches that don't have trivial test fixes is the way to go. The buildbot system is useless, otherwise. And yes, I'm working on the existing broken buildslaves trying to fix them. For instance - on ia64, sqlite is failing because of a bug in gcc - compiled with -O2 or higher, sqlite itself is broken. Yay! Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] PEP 302 support for pydoc, runpy, etc.
Okay, so I've spent a bit more time thinking this through, and I think I have a plan that can work, and deals with all the weird little corner issues, including overlapping code with pkg_resources (a new module that's to-be-added by setuptools). My basic idea is as follows: 1. Move the support code from runpy to pkgutil and expose most of it as actual APIs. 2. Move additional code from pkg_resources to pkgutil and merge with the stuff brought over from runpy, fleshing it out enough so that pydoc can use it to find modules, subpackages, etc., and so that pkg_resources' other code uses pkgutil instead of having that stuff in-house. 3. Write up docs for the expanded pkgutil 4. Add find_loader([path]), get_loader(module), and get_importer(string[,path_hooks]) functions to the 'imp' module, with pure-Python versions in pkgutil that kick in if the C ones are missing. (See next item for why.) 5. Distribute the Python 2.5 'pkgutil' module with setuptools releases for older Python versions, so that setuptools won't have to keep duplicates of the code I pulled out in item #2 above. Part of what would be being copied to pkgutil from pkg_resources is the resource provider API, that allows you to treat a module, package, or sys.path entry as a kind of virtual filesystem. pydoc needs this in order to be able to document with zipped packages, and to find modules or packages on sys.path that are in zipfiles. (E.g. to document a zipped standard library package or module.) pkg_resources has been out there for almost a year now, and is widely used as part of easy_install and the egg runtime facilities, but it's a very large module and contains lots of other code besides the virtual filesystem stuff. So, this seems like the simplest way to share the virtual filesystem code between pydoc and setuptools, without making the former depend on the latter. It does also mean creating an addition to PEP 302: an optional method on importers and loaders that would allow obtaining a virtual filesystem for that path location or package. I believe this and the setuptools checkin can be completed by Monday evening, although the documentation might not be fancy at that point. I don't know when the documentation cutoff for alpha 2 is, but I assume I'd have time to finish fleshing it out, at least for the pkgutil bit and the PEP update. Anybody have any thoughts, comments, or questions? ___ 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] Procedure for sandbox branches in SVN?
I'd like to create a branch for maintaining the setuptools 0.6 line through its beta and final release, while new work proceeds on the trunk for integration with Python 2.5 and beginning the 0.7 line. Is there any special procedure I should follow, or can I just make a 'setuptools-0.6' branch under sandbox/branches? ___ 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] Procedure for sandbox branches in SVN?
[Phillip J. Eby] I'd like to create a branch for maintaining the setuptools 0.6 line through its beta and final release, while new work proceeds on the trunk for integration with Python 2.5 and beginning the 0.7 line. Is there any special procedure I should follow, or can I just make a 'setuptools-0.6' branch under sandbox/branches? Just do it. Branches under SVN are cheap, go fast, and are pretty easy to work with. Even better, because a branch is just another named directory in SVN's virtual file system, you can svn remove it when you're done with it (just like any other directory). BTW, if you're not already familiar with it, read about the `--stop-on-copy` option to SVN's `log` command. ___ 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] unicode vs buffer (array) design issue can crash interpreter
On 4/13/06, M.-A. Lemburg [EMAIL PROTECTED] wrote: Does this mean you would like to see this patch checked in to 2.5? Yes. Ok, I checked this in to 2.5 (minus the syntax error). I also think that changing the type from signed to unsigned by backporting the configure fix will only make things safer for the user, since extensions will probably not even be aware of the fact that Py_UNICODE could be signed (it has always been documented to be unsigned). So +1 on backporting the configure test fix to 2.4. I'll leave this decision to Martin or someone else, since I'm not familiar with the ramifications. Since it was documented as unsigned, I think it's reasonable to consider changing. Though it could create signed-ness warnings in other modules. I'm not sure but it's possible it could create problems for C++ compilers since they are pickier. n ___ 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
