Python-Dev September 2001

python-dev@python.org

55 participants
99 discussions

Re: __op__ and __rop__ ([Python-checkins] CVS: python/dist/src PLAN.txt,1.10,1.11)

by M.-A. Lemburg

Guido van Rossum wrote: > > + Treat all binary operators the same way as I just did for rich > + comparison: in a <op> b, if isinstance(b, type(a)), try b.__rop__(a) > + before trying a.__op__(b). Some comments (could be that I'm misunderstanding your note...): - doesn't this cause an incompatibility to classic instances (__rop__ is fallback to __op__ not the other way around) ? - it seems a huge performance loss to first check for __rop__ (in my experience, __rop__ is only rarely implemented) The classic scheme for this is documented in abstract.c: Calling scheme used for binary operations: v w Action ------------------------------------------------------------------- new new v.op(v,w), w.op(v,w) new old v.op(v,w), coerce(v,w), v.op(v,w) old new w.op(v,w), coerce(v,w), v.op(v,w) old old coerce(v,w), v.op(v,w) Legend: ------- * new == new style number * old == old style number * Action indicates the order in which operations are tried until either a valid result is produced or an error occurs. Most (if not all) Python builtin numeric types are new-style numbers. How would your plan fit into this picture ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

20 years

Canned Responses

by Martin von Loewis

I think the Canned Responses are a nice feature. However, being in a non-admin position, I cannot find out what the exact text of the response is. I've used "Missing Upload" myself, so I know what text to expect and when to use it. I can also guess what "RH 7 Compile (LONG_BIT)" is likely going to say (having typed in a similar response quite a few times). What about the others ("Float precision","Feature -> PEP42")? Can somebody please post the text associated with them? Thanks, Martin

20 years

RELEASED: Python 2.2a4 is out!

by barry＠zope.com

We've released Python 2.2a4, the fourth and likely last alpha of Python 2.2, for your erudition, escapism, or enthusiastic epithets. Download it from: http://www.python.org/2.2/ Give it a good try, and report what breaks to the bug tracker: http://sourceforge.net/bugs/?group_id=5470 New features in this release include: - pydoc and inspect are now aware of new-style classes - ExtensionClass modules can now safely be used with Python 2.2 and Zope 2.4.1 now works with Python 2.2. - For new-style classes, what was previously called __getattr__ is now called __getattribute__, since its semantics are different than classic __getattr__. - The builtin file type can now be subclassed. "file" is the name of a builtin type, file() is a builtin constructor, and has the same signature as builtin open(). - More support for iterators in some standard classes. - A new package called "email" has been added; a new module called SimpleXMLRPCServer has been added; the codecs module has grown four new helper APIs; smtplib now supports various authentication and security features; a new module called hmac has been added... - Large file support (LFS) is now automatic when the underlying platform supports it. - Compaq's iPAQ handheld, running the "familiar" Linux distribution (http://familiar.handhelds.org) is supported. As usual, Andrew Kuchling is writing a gentle introduction to the most important changes (currently excluding type/class unification), titled "What's New in Python 2.2": http://www.amk.ca/python/2.2/ There is an introduction to the type/class unification at: http://www.python.org/2.2/descrintro.html Thanks to everybody who contributed to this release, including all the 2.2 alpha 1, 2, and 3 testers! Enjoy! -Barry

20 years

stat return types

by Martin von Loewis

Nich Mathewson has developed a patch that allows to access stat fields by name, rather than by tuple index, while preserving backwards compatibility, see http://sourceforge.net/tracker/?func=detail&atid=305470&aid=462296&group_id… One issue is non-posix stat implementations, which currently live in riscos and mac. Any comments on the patch are appreciated, in particular with regard to the following question: - should we attempt to modify those modules even though we cannot test the modifications, or should we accept that field access will not be possible on these platforms until somebody with platform access fixes them? - should the patch go into 2.2 (personally, I'd like to see it integrated)? Regards, Martin

20 years

[development doc updates]

by Fred L. Drake

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Documentation as released for Python 2.2 alpha 4.

20 years

Python 2.2a4 docs frozen

by Fred L. Drake, Jr.

The documentation for Python 2.2a4 is now frozen; the HTML packages have been pushed to the server and the online version is available on python.org from the Python 2.2 pages. SourceForge will be updated momentarily. The trunk is *not* frozen; updates can continue there. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

20 years

Release 2.2a4 going out tomorrow

by Guido van Rossum

Unless bad things happen, we'll release 2.2a4 tomorrow. I've just created the release branch (r22a4-branch) and will be making some small version-adjusting changes to it next. As before, please don't make checkins to this branch -- if you have something that you'd like to go in, please check it in to the trunk and send an email to python-dev. --Guido van Rossum (home page: http://www.python.org/~guido/)

20 years

SOURCEFORGE.NET UPDATE - 2001-09-26 (fwd)

by Thomas Wouters

For those of you who don't read this thingy they sent out, see the below abridged version. We might need to create a checkins list with a single member, python-checkins(a)python.org :) The same goes for other projects hosted at SF, such as Mailman or whatever your pet project is. ----- Forwarded message from Mailer <noreply(a)sourceforge.net> ----- Date: Wed, 26 Sep 2001 16:26:25 -0700 From: Mailer <noreply(a)sourceforge.net> To: "" <thomas(a)xs4all.net> Subject: SOURCEFORGE.NET UPDATE - 2001-09-26 [ snip ] 5) SF.NET E-MAIL POLICY CHANGES [ snip ] SENDING EMAIL FROM SOURCEFORGE.NET SERVERS SourceForge.net has seen an increase in abuse of site resources by spammers over the past few months. As result, steps are being taken to prevent most SourceForge.net servers from sending e-mail outside the SourceForge.net site; this will compartmentalize any issues which remain present. The following SourceForge.net domains will still be able to receive e-mail from SourceForge.net hosts: - sourceforge.net (also sf.net) - lists.sourceforge.net (lists.sf.net) - users.sourceforge.net (users.sf.net) This policy change has been active on the project shell servers for the past couple of months. In the next month, this change will be implemented on the project CVS servers. If your project currently makes use of syncmail (or similar mechanisms) to send e-mail when CVS commits occur, please take notice of this change. It will be necessary for all e-mail originating from the project CVS servers to be directed to a SourceForge.net user account (username(a)users.sourceforge.net) or to a SourceForge.net-hosted mailing list. [ snip ] ----- End forwarded message ----- -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

20 years

str() vs. unicode()

by M.-A. Lemburg

I'd like to query for the common opinion on an issue which I've run into when trying to resynchronize unicode() and str() in terms on what happens when you pass arbitrary objects to these constructors which happen to implement tp_str (or __str__ for instances). Currenty, str() will accept any object which supports the tp_str interface and revert to tp_repr in case that slot should not be available. unicode() supported strings, character buffers and instances having a __str__ method before yesterdays checkins. Now the goal of the checkins was to make str() and unicode() behave in a more compatible fashion. Both should accept the same kinds of objects and raise exceptions for all others. The path I chose was to fix PyUnicode_FromEncodedObject() to also accept tp_str compatible objects. This API is used by the unicode_new() constructor (which is exposed as unicode() in Python) to create a Unicode object from the input object. str() OTOH uses PyObject_Str() via string_new(). Now there also is a PyObject_Unicode() API which tries to mimic PyObject_Str(). However, it does not support the additional encoding and errors arguments which the unicode() constructor has. The problem which Guido raised about my checkins was that the changes to PyUnicode_FromEncodedObject() are seen not only in unicode(), but also all other instances where this API is used. OTOH, PyUnicode_FromEncodedObject() is the most generic constructor for Unicode objects there currently is in Python. So the questions are - should I revert the change in PyUnicode_FromEncodedObject() and instead extend PyObject_Unicode() to support encodings ? - should we make PyUnicode_Object() use PyUnicode_FromEncodedObject() instead of providing its own implementation ? The overall picture of all this auto-conversion stuff going on in str() and unicode() is very confusing. Perhaps what we really need is first to agree on a common understanding of which auto-conversion should take place and then make str() and unicode() support exactly the same interface ?! PS: Also see patch #446754 by Walter Dörwald: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=446754&group_id… -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

20 years

Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.276,2.277

by Thomas Wouters

On Mon, Sep 24, 2001 at 12:32:03PM -0700, Thomas Wouters wrote: > This fixes SF bugs #463359 and #462937, and possibly other, *very* obscure > bugs with very deeply nested loops that continue the loop and then break out > of it or raise an exception. One thing I didn't do yet was make a test case out of this. Should I, and if so, where should I put it ? BTW, this bug is living proof of Karma. I fix an insignificant little bug, Guido goes ahead and mentions it on the Python conference opening keynote with something like "thomas fixed what I couldn't", and presto, it ends up being a broken fix all along! :) Back-to-safe-obscurity-ly y'rs, -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

20 years

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev September 2001