Re: [Python-Dev] Inconsistency in 2.4.3 for __repr__() returning unicode
Hye-Shik Chang wrote: > We got an inconsistency for __repr__() returning unicode as > reported in http://python.org/sf/1459029 : > > class s1: > def __repr__(self): > return '\\n' > > class s2: > def __repr__(self): > return u'\\n' > > print repr(s1()), repr(s2()) > > Until 2.4.2: \n \n > 2.4.3: \n \\n > > \\n looks bit weird but it's correct. As once discussed[1] in > python-dev before, if __repr__ returns unicode object, > PyObject_Repr encodes it via unicode-escape codec. So, > non-latin character also could be in repr neutrally. I don't think that using unicode-escape is the right choice for converting a string returned by __repr__ to a string - why would you want to escape a Unicode string that was specifically prepared to provide the representation of an object ? > But our unicode-escape had a bug since when it is introduced. > The bug was that it doesn't escape backslashes. Therefore, > backslashes wasn't escaped in repr while it sholud be escaped > because we used the unicode-escape codec. > > So, fixing the bug made a behavior inconsistency. > How do we resolve the problem? Change PyObject_Repr() to use the default encoding (again) which is also consistent with how PyObject_Str() works. To make repr() conversion more robust, we could have PyObject_Repr() apply the conversion using the 'replace' error strategy - after all, repr() is usually only used for debugging, where it's more important that you do get an output rather than an exception. > Hye-Shik > > > [1] http://mail.python.org/pipermail/python-dev/2000-July/005353.html -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 27 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
[Python-Dev] Next PyPy Sprint: Tokyo 23/4 - 29/4
Tokyo PyPy Sprint: 23rd - 29th April 2006 The next PyPy sprint is scheduled to take place 23rd- 29th April 2006 (Sunday-Saturday) in Akihabara, Tokyo, Japan. We will together with FSIJ (Free Software Initiative of Japan) aim to promote Python and PyPy. We therefor invite Japanese hackers knowledgeable in Python to join our sprint! We'll give newcomer-friendly introductions. To learn more about the new Python-in-Python implementation look here: http://codespeak.net/pypy For this sprint we are particularly interested in meeting and coding on PyPy together with interested Japanese Python hackers. Please register your interest at [EMAIL PROTECTED] as soon as possible and we will help with any questions regarding getting started, pointing to relevant documentation etc. The PyPy team is curious and interested in the experience of hacking code for embedded devices and would love to discuss and get feedback on optimisation efforts and the current state of PyPy. Goals and topics of the sprint -- Possible suggestions for topics are: - Work on gensqueak (our Squeak backend) or possibly other backends. - Implementing Python 2.5 features in PyPy. - Progress further on an 'rctypes' module aiming at letting us use a ctypes implementation of an extension module from the compiled pypy-c. - Writing ctypes implementations of modules to be used by the above tool. - Experimenting and improving performance of our garbage collectors. - Experiment with PyPy flexibility or other aspects of the implementation. - Possibly experiment with writing modules translatable for use both in PyPy and CPython. - Whatever participants want to do with PyPy or particular areas of PyPy (please send suggestions to the mailing list before to allow us to plan and give feedback) Location & Accomodation The sprint will be held at National Institute of AIST (National Institute of Advanced Industrial Science and Technology, http://www.aist.go.jp/index_en.html), Akihahabara (the technical gadget district in Tokyo). Yutaka Niibe is our contact person there, helping with arranging facilities. Niibe is the chairman of FSIJ and they have invited us to sprint in Tokyo and we are very grateful for the help and interest we have recieved so far. The facilities we are sprinting in are located here: http://www.gtrc.aist.go.jp/en/access/index.html#Akihabara The actual address is: Akihabara Dai Bldg , 1-18-13 Sotokanda, Chiyoda-ku, Tokyo 101-0021 Japan Phone: +81-3-5298-4729 Hotel areas - we are recommended to book hotels in Ueno and Asakusa (old town), from those areas there are only two metro stops to Akihabara. Please note that hotelrooms in Tokyo are often very small. http://www.wh-rsv.com/english/akihabara/index.html (nearest hotel to sprint location) http://www.greenhotel.co.jp/ochanomizu_e.html http://www.ohgai.co.jp/index-e.html (Ueno) http://www.toyoko-inn.com/e_hotel/00012/index.html (Asakusa) http://www.hotelnewkanda.com/ (second nearest, but no english page) Here is a url for booking hotels with not too unreasonable rates (see map): http://japan-hotelguide.com/hotels/Japan/Tokyo/index.htm For more general tourist information about travelling to Japan and Tokyo - please see: http://www.jnto.go.jp/eng/ http://www.japantravelinfo.com/ (really useful information regarding airfares, hotels, currency, phones etc etc) Comments on the weather: In end April it is ca 20 degrees Celsius. Exact times --- The public PyPy sprint is held Sunday 23rd - Saturday 29th April 2006. Hours will be from 10:00 until people have had enough. It's a good idea to arrive a day before the sprint starts and leave a day later. Sometimes people cannot stay for the whole sprint - you are welcome even if you can only stay for a day or a few days. Sunday: Starting at 10:00. This day is focused on getting to know PyPy enought to start to participate. We will hold a PyPy tutorial and an architectural overview. Planning meeting for the work to be done during the week and grouping of developers (pairs or groups mixing new participants with core developers). Dinner in the evening (Yutaka will arrange a place for us to go to). Monday-Tuesday: Starting at 10:00 with status meetings. Possible regrouping depending on the interest and progress of the various teams. Wednesday: Breakday (coding is allowed although we recommend taking a break). Thursday-Saturday: Starting at 10:00 with status meetings. Possible regrouping depending on the interest and progress of the various teams. Ending on Saturday with a Closure session - summing of the work and planning work to be done until the next sprint. Network, Food, currency We will have access to WiFi at AIST - please make sure you have wlan capabilities. Electric
Re: [Python-Dev] PySet API
On Sun, 2006-03-26 at 11:43 -0500, Raymond Hettinger wrote: > It was a trick question. Everyone is supposed to be attracted to the _next > version because it is shorter, faster, and takes less ref counting > management. > However, the _next version has a hard-to-find bug. The call to > PyObject_Hash() > can trigger arbitrary Python code and possibly mutate the table, leaving > pointers to invalid memory addresses. It would likely take Armin less than > five > minutes to write a pure Python crasher for the code. And THAT is why > PySet_Next() should never come into being. We're clearly going in circles here, and it's obvious we're not going to agree. The fact that PySet_Next() can be used incorrectly is no reason not to include it. There are /lots/ of things in Python that if you use incorrectly will screw you. So you document them, teach people when not to use them, and teach them how to use them correctly when they /are/ the right thing to use. I don't want to be babied into using inappropriate and cumbersome APIs which, yes, can be a source of their own subtle bugs. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet_Next (Was: PySet API)
On Sun, 2006-03-26 at 19:59 +0200, "Martin v. Löwis" wrote: > If it is similar to PyDict_Next, it will have PyObject** /input/ > variables, which are really meant as PyObject* /output/ variables. Yep, that's exactly what my posted patch does. > For the caller, a clear usage strategy follows from this: either discard > the references before making a potentially-mutating call, or Py_INCREF > the set element before making that mutating call. Yep. Nice and simple. And if you're not making a potentially-mutating call, you don't have to worry about even that. These /are/ valid use cases. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet_Next (Was: PySet API)
On Sun, 2006-03-26 at 13:24 -0500, Raymond Hettinger wrote: > We have a perfectly good way to iterate with PyIter_Next(). It may take a > couple of extra lines, but it is easy to get correct and has no surprises. > It > seems that the only issue is that Barry says that he refuses to use the > iterator > protocol. Heck, just turn it into a list and index directly. There is no > need > to muck-up the set api for this. I just think you have a narrow vision of how Python sets can be used in a C application. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet_Next (Was: PySet API)
On Sun, 2006-03-26 at 21:50 +0200, "Martin v. Löwis" wrote: > I don't know what specific application Barry has in mind, but I'm > sure he can get it right (although it might be an interesting experiment > to test that theory :-) In general, I would expect that people find > it easier to get code involving PyDict_Next right than code dealing > with iterators - primarily because of the error cases you have to > consider. I can't post the code because it's proprietary, but I gave a general feel to the types of things we do in a previous response. Imagine you have application objects that are also PyObjects. They have application specific state and behavior. They can be put in Python sets and they can be iterated over to check that state, invoke that behavior (which won't involve trips into Python), or perhaps add them to other collections. Do this 50 to 60 times in your application and I think you'll start to see why the iterator protocol is incredibly cumbersome to use. > I don't care that much either way, although I would prefer to see an > actual, current use case for PySet_Next, rather than theoretical, > made-up examples. I don't expect to use Python sets in C code at all, > personally. We really, honestly do use PySet_Next in many places. We implemented that API for Python 2.4 exactly because the iterator protocol was way too much overhead. The posted patch is a port to Python 2.5. We obviously can't add this to Python 2.4, but I had really hoped that we wouldn't have to maintain this extension for subsequent versions. I'm frankly astonished to get so much pushback from Raymond about it. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] refleaks in 2.4
Hi Neal, On Sun, Mar 26, 2006 at 11:39:50PM -0800, Neal Norwitz wrote: > test_pkg leaked [10, 10, 10] references This one at least appears to be caused by dummy (deleted) entries in the dictionary of interned strings. So it is not really a leak. It is a pain that it is so hard to figure this out, though. Wouldn't it make sense to find a trick to exclude these dummy entries from the total reference count? E.g. by subtracting the refcount of the dummy object... A bientot, Armin ___ 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] PySet API
Why don't we expose _PySet_Next() for Barry and leave it out of the public API for everyone else. Raymond ___ 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] PySet API
>> Why don't we expose _PySet_Next() for Barry and leave it out of the public >> API >> for everyone else. [Alex] > There are precedents for adding some functionality to the C API but not > documenting it to ensure "non advanced users" don't get hurt -- that's how > we > added the ability to raise exceptions in different threads, in particular. > Not sure if this is the best solution here, but I'm just pointing out that > it's definitely not "unthinkable", procedurally speaking. Thank would be nice. It gives me the ability to keep a clean, sane API while at the same time making sure that my most important customer (Barry) gets his needs met. Raymond ___ 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] TRUNK FREEZE for 2.5a1: 0000 UTC, Thursday 30th
On 3/27/06, Anthony Baxter <[EMAIL PROTECTED]> wrote: > Ok, it's time to rock and roll. > >The SVN trunk is FROZEN for 2.5a1 from 00:00 UTC on >Thursday 30th of March. > > I'll post again once it's open. Note that new features can keep going > in during the alpha cycle, the feature freeze only happens once we > hit beta. And we're not going to hit beta until the features we want > are in. > > Please help in making this release as painless as possible by not > checking in while the trunk is frozen. There's a bug day on Friday. http://wiki.python.org/moin/PythonBugDay It seems a bit senseless to freeze the trunk the day before the bug day. All the bugs I'm planning to work on are important for the alpha. How much inconvenience will it case to delay the freeze until after the bug day? I'd say we should push the alpha a whole week rather than screw up the bug day. Jeremy Jeremy ___ 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] TRUNK FREEZE for 2.5a1: 0000 UTC, Thursday 30th
Jeremy Hylton wrote: > On 3/27/06, Anthony Baxter <[EMAIL PROTECTED]> wrote: >> Ok, it's time to rock and roll. >> >>The SVN trunk is FROZEN for 2.5a1 from 00:00 UTC on >>Thursday 30th of March. >> >> I'll post again once it's open. Note that new features can keep going >> in during the alpha cycle, the feature freeze only happens once we >> hit beta. And we're not going to hit beta until the features we want >> are in. >> >> Please help in making this release as painless as possible by not >> checking in while the trunk is frozen. > > There's a bug day on Friday. > http://wiki.python.org/moin/PythonBugDay > > It seems a bit senseless to freeze the trunk the day before the bug > day. All the bugs I'm planning to work on are important for the > alpha. How much inconvenience will it case to delay the freeze until > after the bug day? I'd say we should push the alpha a whole week > rather than screw up the bug day. As the one who scheduled the bug day, I second that. (I really should have read the freeze message more closely, thanks Jeremy) 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] PySet API
Raymond Hettinger wrote: > Why don't we expose _PySet_Next() for Barry and leave it out of the public > API > for everyone else. That is stupid. If Barry wants a "private" PySet_Next function, he can just implement it himself, no need to include it in the release. It should be included only if it is meant to be public. 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] r43358 - python/trunk/Modules/itertoolsmodule.c
On 3/27/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > Modified:> python/trunk/Modules/itertoolsmodule.c> Log:>> Make itertools.tee and its internal teedataobject participate in GC. This> alone does not solve the leak in test_generators, unfortunately, but it is > part of test_generators' problem and it does solve other cycles.Thanks for getting this in.To get the leak in test_generators, I think you make need to add GC to theteeobject as well as the teedataobject. The teeobject has GC (hence the word 'and' in 'itertools.tee and its internal teedataobject' ;-) The problem with test_generators is that this also leaks:def leak(): def gen(): while True: yield g g = gen()leak()It doesn't leak in 2.4. I'm using a little shell script to work backwards through the 2.5 changes to find out which one introduced this, although I somehow suspect it's the coroutine stuff... ;P -- 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
[Python-Dev] Libref sections to put new modules under?
Any thoughts on where documentation for the new "contextlib" module should go in the library reference? Some candidates: * Program Frameworks (???) * Development Tools (??) * Python Runtime Services (?) * Python Language Services (??) * Miscellaneous Services (??) A similar issue exists for "ctypes" module, although I imagine an argument could easily be made for putting it with "Optional Operating System Services". wsgiref can probably go in "Internet Protocols and Support", while ElementTree obviously goes under "Structured Markup Processing Tools". What other new modules do we have going in 2.5 that haven't found a home in the documentation yet? I seem to recall some discussion about a decorator library or functools or something of that sort. ___ 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] r43358 - python/trunk/Modules/itertoolsmodule.c
On 3/27/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > The teeobject has GC (hence the word 'and' in 'itertools.tee and its > internal teedataobject' ;-) The problem with test_generators is that this > also leaks: > > def leak(): > def gen(): > while True: > yield g > g = gen() > > leak() Please add a test for this to the leakers and remove the tee test in leakers if that no longer leaks. Thanks, 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] Libref sections to put new modules under?
On 3/27/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > Any thoughts on where documentation for the new "contextlib" module should > go in the library reference? > > Some candidates: > > * Program Frameworks (???) > * Development Tools (??) > * Python Runtime Services (?) > * Python Language Services (??) > * Miscellaneous Services (??) Runtime Services is by far the best candidate. The Language services are more for code that reads/writes Python source code or bytecode. The others are even less likely matches. (What's development tools?) > A similar issue exists for "ctypes" module, although I imagine an argument > could easily be made for putting it with "Optional Operating System Services". +1 > wsgiref can probably go in "Internet Protocols and Support", while > ElementTree obviously goes under "Structured Markup Processing Tools". +1 > What other new modules do we have going in 2.5 that haven't found a home in > the documentation yet? I seem to recall some discussion about a decorator > library or functools or something of that sort. Is the with statement documented yet? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Libref sections to put new modules under?
On Monday 27 March 2006 16:26, Phillip J. Eby wrote: > Any thoughts on where documentation for the new "contextlib" module should > go in the library reference? Most definately in "Python Runtime Services." > A similar issue exists for "ctypes" module, although I imagine an argument > could easily be made for putting it with "Optional Operating System > Services". I'm less sure of that one. It could reasonably go in "Python Runtime Services," "Generic Operating System Services," or "Optional Operating System Services." > wsgiref can probably go in "Internet Protocols and Support", while > ElementTree obviously goes under "Structured Markup Processing Tools". Yes to both. -Fred -- Fred L. Drake, Jr. ___ 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] refleaks in 2.4
Neal Norwitz wrote: > test_unicode leaked [7, 7, 7] references This one is lacking this checkin: r41530 | neal.norwitz | 2005-11-24 23:00:56 +0100 (Do, 24 Nov 2005) | 6 lines Geänderte Pfade: M /python/trunk/Lib/test/test_unicode.py Move registration of the codec search function to the module scope so it is only executed once. Otherwise the same search function is repeated added to the codec search path when regrtest is run with -R and leaks are reported. :-) Applying it gets the number of leaked references down to 1. 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] I'm not getting email from SF when assigned a bug/patch
Folks, When you assign a bug/patch to me, somehow SourceForge doesn't send me an email. (Is this understood behavior? Can it be changed?) Since I don't monitor my SF personal page regularly any more, that means that the issue will remain in limbo forever or until someone points me to it. So if you want me to take any particular action (even rejecting something) please send me a separate email! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Libref sections to put new modules under?
At 01:33 PM 3/27/2006 -0800, Guido van Rossum wrote: >Is the with statement documented yet? Sort of. I've added stuff to the language reference, but the "What's New" for it is blank right now. There's nothing in the tutorial, either, and of course contextlib isn't in the libref yet (which is what triggered my question). PEP 342 is also virtually undocumented outside of the "What's New". So far all I've done is correct the part about yield not being allowed in try/finally; apart from that I'm a bit hung up on how to document the new hybrid nature of "yield" in the language reference. It's like "New YIELD! It's a statement! It's an expression! It's an operator! It's... well, we don't know what it is. But it's great!" :) Suggestions on how to handle this appreciated. :) ___ 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] refleaks in 2.4
Neal Norwitz wrote: > test_unicode leaked [7, 7, 7] references And the last one came from r41531 | neal.norwitz | 2005-11-24 23:09:18 +0100 (Do, 24 Nov 2005) | 1 line Geänderte Pfade: M /python/trunk/Python/codecs.c M /python/trunk/Python/compile.c M /python/trunk/Python/symtable.c Fix a few more ref leaks. Backport candidate Only codecs.c backported, so this is what I did. 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] I'm not getting email from SF when assigned a bug/patch
Guido van Rossum wrote: > When you assign a bug/patch to me, somehow SourceForge doesn't send me > an email. (Is this understood behavior? Can it be changed?) I believe it broke at some point, I'm pretty certain it used to work. 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] Cancelled! TRUNK FREEZE for 2.5a1: 0000 UTC, Thursday 30th
On Tuesday 28 March 2006 06:38, Jeremy Hylton wrote: > There's a bug day on Friday. > http://wiki.python.org/moin/PythonBugDay Whoops! I _thought_ there was some vague reason in the back of my head to put it off til next week! Ok, this will be rescheduled for next week (the trunk freeze, not the bug day ) - exact date to follow once the appropriate people are OK with the date. Sorry about that, 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
Re: [Python-Dev] I'm not getting email from SF when assigned a bug/patch
On 3/27/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > When you assign a bug/patch to me, somehow SourceForge doesn't send me > > an email. (Is this understood behavior? Can it be changed?) > > I believe it broke at some point, I'm pretty certain it used to work. More reason to move away from SF ASAP. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF when assigned a bug/patch
On 3/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: Folks,When you assign a bug/patch to me, somehow SourceForge doesn't send mean email. (Is this understood behavior? Can it be changed?) Since Idon't monitor my SF personal page regularly any more, that means that the issue will remain in limbo forever or until someone points me toit. So if you want me to take any particular action (even rejectingsomething) please send me a separate email!Ah, glad to hear I wasn't the only one bitten by that. For a while, I thought I was going senile :-P Speaking of which, perhaps we should designate the running roundup instance on python.org as the issuetracker for py3k ? Gives us a good chance to evaluate, and if it doesn't work out, it wouldn't matter too much.-- 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] PySet API
Barry Warsaw wrote: > We're clearly going in circles here, and it's obvious we're not going to > agree. Would it perhaps help if there were a better API for using the iterator protocol from C code? Something that's as easy to use as the proposed set iterating API, but which uses the general iterator protocol underneath. Greg ___ 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] Expose the array interface in Python 2.5?
Chris Barker wrote: > Can we have both? A defined interface, that existing code can be adapted > to provide, and a new C-Object, that future code can just use. If the > goal is to have as many extension types as possible use the same base > object, the sooner a standard object is provided the better. Having many extension types provide the same *interface* is what I think the main goal should be, not to have them use the same object. So getting the interface defined should be the first priority. > I'd sure like to see indexing and slicing, at at least. The interface itself doesn't need to provide indexing and slicing -- these could be provided by a view object that used the array interface of the underlying object. This would also fit in nicely with the "views" philosophy that seems to be shaping up for Py3k. > Another point is that n-dimensional arrays really are very useful for > all sorts of stuff that have nothing to do with high-performance Numeric > computing. I'm all in favour of including such an object, as long as we keep in mind that this is an orthogonal issue to having an array interface. The discussion still seems to be a bit muddled on this point. Greg ___ 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] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
If you have Numeric or numpy installed try this: #import Numeric as N import numpy as N a = range(10) b = N.arange(10) a.__iadd__(b) print a Result: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9] Contrast the returned output with import numpy as N a = range(10) b = N.arange(10) a += b print a Result: [ 0 2 4 6 8 10 12 14 16 18] Having "a+=b" and "a.__iadd__(b)" do different things seems like an unfortunate bug. It seems to me that the problem is that the INPLACE_ADD and INPLACE_MULTIPLY cases in ceval.c use PyNumber_InPlace instead of trying PySequence_InPlace when the object doesn't support the in-place number protocol. I could submit a patch if there is agreement that this is a problem. -Travis ___ 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] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
On 3/27/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > > If you have Numeric or numpy installed try this: > > #import Numeric as N > import numpy as N > > a = range(10) > b = N.arange(10) > > a.__iadd__(b) > > print a > > Result: > > [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9] > > > Contrast the returned output with > > import numpy as N > > a = range(10) > b = N.arange(10) > > a += b > > print a > > Result: > > [ 0 2 4 6 8 10 12 14 16 18] > > > Having "a+=b" and "a.__iadd__(b)" do different things seems like an > unfortunate bug. > > It seems to me that the problem is that the INPLACE_ADD and > INPLACE_MULTIPLY cases in ceval.c use PyNumber_InPlace instead of > trying PySequence_InPlace when the object doesn't support the > in-place number protocol. > > I could submit a patch if there is agreement that this is a problem. Well how is the interpreter to know whether += meanse numeric add or sequence add in any particular case? Shouldn't it be numpy's responsibility to implement both operations identically? (It's a design bug in Python that the + operation has two implementation slots. But it's difficult to fix that until Python 3000. It *will* be fixed there.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
Greg Ewing canterbury.ac.nz> writes: > > I've just been playing around with metaclasses, and > I think I've stumbled across a reason for having > class decorators as an alternative to metaclasses > for some purposes. There has also been discussion on the IronPython mailing list that class decorators would be a very useful syntax for expressing .NET attributes. http://lists.ironpython.com/pipermail/users-ironpython.com/2006-March/002007.html Mike ___ 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] Class decorators
At 07:20 PM 3/27/2006 +, Mike Krell wrote:
>Greg Ewing canterbury.ac.nz> writes:
>
> >
> > I've just been playing around with metaclasses, and
> > I think I've stumbled across a reason for having
> > class decorators as an alternative to metaclasses
> > for some purposes.
>
>There has also been discussion on the IronPython mailing list that class
>decorators would be a very useful syntax for expressing .NET attributes.
>
>http://lists.ironpython.com/pipermail/users-ironpython.com/2006-March/002007.html
>
>
PyProtocols and the zope.interface package both support inline class
decorators called "class advisors". They don't require any special syntax,
and aren't much more complex than regular decorators. By defining an
advisor like this:
from protocols.advice import addClassAdvisor
def some_advisor(whatever_args):
def callback(cls):
print "I can modify",cls,"or replace it"
return cls
addClassAdvisor(callback)
you can then use it in a class body like so:
class SomeClass:
some_advisor("something")
And the return value from 'callback' will replace SomeClass, just like a
decorator replaces the function it's called on.
The implementation should work with any Python version from 2.2 up. I'm
not sure if it would work with IronPython. But if it doesn't, that would
be a good indication of feature(s) that IronPython is missing. ;)
___
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] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
Guido van Rossum wrote: > On 3/27/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > >>If you have Numeric or numpy installed try this: >> >>#import Numeric as N >>import numpy as N >> >>a = range(10) >>b = N.arange(10) >> >>a.__iadd__(b) >> >>print a >> >>Result: >> >>[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >> >> >>Contrast the returned output with >> >>import numpy as N >> >>a = range(10) >>b = N.arange(10) >> >>a += b >> >>print a >> >>Result: >> >>[ 0 2 4 6 8 10 12 14 16 18] >> >>Having "a+=b" and "a.__iadd__(b)" do different things seems like an >>unfortunate bug. >> >>It seems to me that the problem is that the INPLACE_ADD and >>INPLACE_MULTIPLY cases in ceval.c use PyNumber_InPlace instead of >>trying PySequence_InPlace when the object doesn't support the >>in-place number protocol. >> >>I could submit a patch if there is agreement that this is a problem. > > Well how is the interpreter to know whether += meanse numeric add or > sequence add in any particular case? > > Shouldn't it be numpy's responsibility to implement both operations > identically? "a" is a list object. Travis's question is, "why doesn't the list object implement both operations identically?" I think the answer is, "it never gets a chance to." When a numpy array is on the LHS of an inplace operation, we always want the numeric add. numpy arrays can't be extended inplace like a list, and a lone "+" is always a numeric operation for arrays, never a sequence operation. When numpy arrays are on the LHS of an inplace operation, everything works consistently. The issue seems to arise from the fact that PyNumber_InPlaceAdd tries to coerce the LHS and the RHS to a common numerical type first before trying PySequence_InPlaceConcat. Lists of numbers coerce to numpy arrays just fine, so this code path is taken, and nothing tests for the sq_inplace_concat or sq_concat slots. Personally, I'm willing to just document it in the numpy documentation as a rarely-seen gotcha. This behavior pretty much affects just us. -- Robert Kern [EMAIL PROTECTED] "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ 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] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
Guido van Rossum wrote: > On 3/27/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: >> If you have Numeric or numpy installed try this: >> >> #import Numeric as N >> import numpy as N >> >> a = range(10) >> b = N.arange(10) >> >> a.__iadd__(b) >> >> print a >> >> Result: >> >> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >> >> >> Contrast the returned output with >> >> import numpy as N >> >> a = range(10) >> b = N.arange(10) >> >> a += b >> >> print a >> >> Result: >> >> [ 0 2 4 6 8 10 12 14 16 18] >> >> >> Having "a+=b" and "a.__iadd__(b)" do different things seems like an >> unfortunate bug. >> >> It seems to me that the problem is that the INPLACE_ADD and >> INPLACE_MULTIPLY cases in ceval.c use PyNumber_InPlace instead of >> trying PySequence_InPlace when the object doesn't support the >> in-place number protocol. >> >> I could submit a patch if there is agreement that this is a problem. > > Well how is the interpreter to know whether += meanse numeric add or > sequence add in any particular case? > I can see that '+' (and '*') having two different implementation slots is a design bug. However, it seems prudent that both += and .__iadd__ should have identical behavior regardless. Whatever mechanism is used to resolve the conflict for __iadd__, the same mechanism should be used for for +=. I don't think this is a NumPy-only issue. Any object that defines addition that works with lists will have similar problems. I think this can be fixed easily by first checking the sequence slot for a sq_concat function before calling PyNumber_InPlaceAdd. All I'm asking for is that a += b have the same behavior as a.__iadd__(b). That seems like desireable behavior to me. -Travis ___ 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] PySet API
On Sat, 2006-03-25 at 22:05 -0500, Raymond Hettinger wrote:
> Still, PyObject_Clear(s) would be better.
Although not ideal, in the interest of compromise, I could support this
option. There's a problem with this though: I don't think you want to
be able to clear a frozen set. My PySet_Clear() raises a SystemError
and returns -1 when the object is a frozen set.
If PyObject_Clear() is implemented something like
int PyObject_Clear(PyObject *o)
{
return (o->ob_type->tp_clear ? o->ob_type->tp_clear(o) : -1);
}
then you /would/ be able to clear a frozen set. For that matter, it
would be the case that any immutable collection would be clearable if it
had a tp_clear (which it probably would). That isn't the semantics I'd
expect though. That may not be solvable unless you make
PyObject_Clear() an alias for PyObject_CallMethod("clear").
Although I'm sure you'll disagree, I think this is less than ideal. For
one thing, you're requiring objects that work with PyObject_Clear() to
implement an exact Python-level protocol (it must have a method, it must
be called "clear" and it must take zero arguments). You also have to
implement PyObject_Clear() with a hasattr test, because I don't think
you want PyObject_Clear() raising AttributeErrors. That raises the
constant overhead cost, which can make clearing small sets more
expensive.
> Better still would be to examine the
> actual uses in the app. I suspect that most code that clears a set and then
> rebuilds it would be better-off starting with a new empty set (and because of
> freelisting, that is a very fast operation).
That may not be possible. Imagine a complex application where the set
is passed through many layers of calls. The set hangs off of other
application level objects which you don't have access to at the point
where you're deciding whether to clear the set or not. You can't create
a new set because you have no way to pass the new set back to the
several application level objects that would need to get their pointers
updated. So the most obvious, simple approach is to just clear the set
you have right there.
> Likewise, it only takes a one-line header to define BarrySet_Update(s). I do
> not want that part of the C API exposed yet. It is still under development
> and
> may eventually become a function with a variable length argument list.
Really? That would be odd and not at all parallel with established
convention (e.g. PyDict_Update()). I would think that a vararg update
should be named something different in order to preserve the principle
of least surprise.
> If you're dead-set against using the iterator API, then maybe there is
> something
> wrong with the API. You should probably start a new thread on why you detest
> the iterator API and see if there are ways to improve it.
I'm not saying there's anything wrong with the iterator API, I'm saying
that it's not always appropriate. It's the nail/hammer argument. But I
ran out of clever when I tried to propose the simplest, most direct fix
for our most pressing issues, so I'm not going to take the bait.
> > You talk about duck typing, but I don't care about that here.
>
> It's one of the virtues of Python that gets reflected in the abstract API.
> IMO,
> it's nice that PyObject_Dir(o) corresponds to "dir(o)" and the same for
> hash(o),
> repr(o), etc. I just hope that by hardwiring data types in stone, that your
> app
> doesn't become rigid and impossible to change. I certainly do not recommend
> that other people adopt this coding style (avoidance of iterators,
> duplication
> of abstact api functions in concrete form, etc.) If you're experiencing
> debugging pain, it may be that avoidance of abstraction is the root cause.
Trust me Raymond, it's not the cause. I keep trying to explain this but
I must be completely inept because you're just not getting it. Let me
try this way: we're using Python's collection types (sets, lists, dicts)
as our fundamental collection data structures internally in our
application. There's no duck typing going on. There's no need for
abstraction because we know exactly what we have and there's no chance
we'll have something that smells like a set that isn't exactly a PySet.
As I've said many times, I'm all for an abstract API because it's darn
useful in many applications. It's the lack of a concrete API that is
limiting.
> > I wouldn't object to that, but it wouldn't change my mind about
> > PySet_Clear().
>
> This is plain evidence that something is wrong with your approach. While
> possibly necessary in your environment, the rest of mankind should not have
> to
> stomach this kind of API clutter.
Please, that's a bit extreme. I haven't heard anybody scream about the
PyDict's API clutter and I don't see my PySet proposal as being any
different.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@
Re: [Python-Dev] PySet API
On Mon, 2006-03-27 at 10:20 -0500, Raymond Hettinger wrote: > Why don't we expose _PySet_Next() for Barry and leave it out of the public > API > for everyone else. Just so I understand exactly what you mean by "leave it out of the public API", let me ask: are you saying you don't want to document the function? Do you not want to include it in setobject.h? No tests for it? If all you're suggesting is to stick an underscore in front of the name to indicate "it's something special", I could live with that, although I don't see much benefit. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet API
On Mon, 2006-03-27 at 23:21 +0200, "Martin v. Löwis" wrote: > Raymond Hettinger wrote: > > Why don't we expose _PySet_Next() for Barry and leave it out of the public > > API > > for everyone else. > > That is stupid. If Barry wants a "private" PySet_Next function, he can > just implement it himself, no need to include it in the release. It > should be included only if it is meant to be public. The one thing I'm trying to avoid is requiring us to patch Python when we move to 2.5. The most obvious and straightforward implementation of the 3 API calls are very simple wrappers around static functions defined in setobject.c (see the patch I posted). So if the patch gets rejected, then implementing them as a hack on standard Python 2.5 will require patching setobject.c or cracking open the PySet structure and /really/ violating the principle of data hiding. Neither option is very appealing. That's why I said in a previous message that I could live with this as a compromise, although I agree with your (Martin's) sentiment. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
On 3/27/06, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > On 3/27/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > >> If you have Numeric or numpy installed try this: > >> > >> #import Numeric as N > >> import numpy as N > >> > >> a = range(10) > >> b = N.arange(10) > >> > >> a.__iadd__(b) > >> > >> print a > >> > >> Result: > >> > >> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9] > >> > >> > >> Contrast the returned output with > >> > >> import numpy as N > >> > >> a = range(10) > >> b = N.arange(10) > >> > >> a += b > >> > >> print a > >> > >> Result: > >> > >> [ 0 2 4 6 8 10 12 14 16 18] > >> > >> > >> Having "a+=b" and "a.__iadd__(b)" do different things seems like an > >> unfortunate bug. > >> > >> It seems to me that the problem is that the INPLACE_ADD and > >> INPLACE_MULTIPLY cases in ceval.c use PyNumber_InPlace instead of > >> trying PySequence_InPlace when the object doesn't support the > >> in-place number protocol. > >> > >> I could submit a patch if there is agreement that this is a problem. > > > > Well how is the interpreter to know whether += meanse numeric add or > > sequence add in any particular case? > > I can see that '+' (and '*') having two different implementation slots > is a design bug. However, it seems prudent that both += and .__iadd__ > should have identical behavior regardless. Whatever mechanism is used > to resolve the conflict for __iadd__, the same mechanism should be used > for for +=. > > I don't think this is a NumPy-only issue. Any object that defines > addition that works with lists will have similar problems. > > I think this can be fixed easily by first checking the sequence slot for > a sq_concat function before calling PyNumber_InPlaceAdd. > > All I'm asking for is that a += b have the same behavior as > a.__iadd__(b). That seems like desireable behavior to me. Correct. Robert Kern's analysis is correct: when you make the call explicitly, a.__iadd__(b) invokes the list.__iadd__ method; this is effectively an alias for list.extend. I take back whatever I said about numpy. So for consistency we want a += b to also execute a.__iadd__. The opcode calls PyNumber_InplaceAdd; I think that PyNumber_InplaceAdd (and PySequence_InplaceConcat, if it exists) should test for both the numeric and the sequence augmented slot of the left argument first; then they should try both the numeric and sequence non-augmented slot of the left argument; and then the numeric non-augmented slot of the right argument. Coercion should not be attempted at all. The question is, can we do this in 2.5 without breaking backwards compatibility? Someone else with more time should look into the details of that. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I'm not getting email from SF when assigned a bug/patch
>> When you assign a bug/patch to me, somehow SourceForge doesn't send >> me an email. (Is this understood behavior? Can it be changed?) Martin> I believe it broke at some point, I'm pretty certain it used to Martin> work. I would expect that if it broke for Guido it broke for everybody. While we consider him to be the BDFL I suspect the accolades are lost on the SF folks. 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] Class decorators
On 3/27/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> PyProtocols and the zope.interface package both support inline class
> decorators called "class advisors". They don't require any special syntax,
> and aren't much more complex than regular decorators. By defining an
> advisor like this:
>
> from protocols.advice import addClassAdvisor
>
> def some_advisor(whatever_args):
> def callback(cls):
> print "I can modify",cls,"or replace it"
> return cls
> addClassAdvisor(callback)
>
> you can then use it in a class body like so:
>
> class SomeClass:
> some_advisor("something")
>
> And the return value from 'callback' will replace SomeClass, just like a
> decorator replaces the function it's called on.
>
> The implementation should work with any Python version from 2.2 up. I'm
> not sure if it would work with IronPython. But if it doesn't, that would
> be a good indication of feature(s) that IronPython is missing. ;)
Just curious (and lazy): what magic is the implementation using that
makes this work without a custom metaclass?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Class decorators
At 08:02 PM 3/27/2006 -0800, Guido van Rossum wrote: >Just curious (and lazy): what magic is the implementation using that >makes this work without a custom metaclass? It registers a function as the __metaclass__ by poking it into the f_locals of the frame that's defining the class. This function has two attributes that denote 1) the callback to be invoked, and 2) the previous metaclass, forming a linked list of callbacks. When the class is created, this dummy metaclass function invokes the previous metaclass (or metaclass function) in the chain, then calls its callback on the result and returns that value, thus recursively unwinding the chain of advisors in the right order. (i.e., the same order as the advisors were called in the class body). The only part of the code that's even mildly complex is simulating Python's builtin rules for determining the default metaclass, so that when the recursion bottoms out you end up with an actual class with the right metaclass. And that's not so much complex as tedious. Anyway, the mechanism is orthogonal to the chosen metaclass, and thus can be used with classic classes or even ExtensionClasses if you're sufficiently masochistic. :) And AFAIK it's been in use by Zope 3 for some years now; in fact I think you were still working at Zope Corp. when Steve Alexander came up with the basic idea and I made the first practical implementation. ___ 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] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
Travis E. Oliphant wrote: > I think this can be fixed easily by first checking the sequence slot for > a sq_concat function before calling PyNumber_InPlaceAdd. However, if this *is* fixed, it looks like it's going to break NumPy, in the sense that it will no longer be able to force an arithmetic interpretation for "+" when adding a sequence to an array. Greg ___ 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] PySet API
Barry Warsaw wrote:
> My PySet_Clear() raises a SystemError
> and returns -1 when the object is a frozen set.
Isn't SystemError a bit drastic? TypeError would be
sufficient here, surely.
>
> If PyObject_Clear() is implemented something like
>
> int PyObject_Clear(PyObject *o)
> {
> return (o->ob_type->tp_clear ? o->ob_type->tp_clear(o) : -1);
> }
>
> then you /would/ be able to clear a frozen set.
Hmmm, the problem here, I think, is that tp_clear is
really only designed for use by the garbage collector.
Giving anything else access to it is probably wrong.
Clearability is not a general feature in Python land --
a few types have a clear() method, but this is an
ad hoc feature of the type concerned. I don't think
it makes sense to have a general PyObject_Clear
function at all.
--
Greg
___
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] Class decorators
Phillip J. Eby wrote: > It registers a function as the __metaclass__ by poking it into the f_locals > of the frame that's defining the class. That is stunningly brilliant! I'd nominate it for Hack of the Year if there were such an award. It's far too magical for me to feel like actually using it, though. Class decorators would be so much more straightforward and explicit. Greg ___ 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] I'm not getting email from SF when assigned a bug/patch
[EMAIL PROTECTED] wrote: > Martin> I believe it broke at some point, I'm pretty certain it used to > Martin> work. > > I would expect that if it broke for Guido it broke for everybody. While we > consider him to be the BDFL I suspect the accolades are lost on the SF > folks. Indeed, it broke for me as well. I didn't notice until Guido's post that this is what happened - I had assumed I had filtered out/deleted these messages. 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] PySet API
Greg Ewing wrote: > Hmmm, the problem here, I think, is that tp_clear is > really only designed for use by the garbage collector. > Giving anything else access to it is probably wrong. > > Clearability is not a general feature in Python land -- > a few types have a clear() method, but this is an > ad hoc feature of the type concerned. I don't think > it makes sense to have a general PyObject_Clear > function at all. I agree. Barry's PySet_Clear and Raymond's PyObject_Clear would be two completely unrelated functions (one invoking the "clear" method, the other invoking tp_clear). 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] Inconsistency in 2.4.3 for __repr__() returning unicode
On Monday 27 March 2006 21:14, M.-A. Lemburg wrote:
> Change PyObject_Repr() to use the default encoding (again)
> which is also consistent with how PyObject_Str() works.
For 2.4.3, I plan to just revert the following patch (and supply a
test case)
Index: Objects/object.c
===
--- Objects/object.c(revision 16197)
+++ Objects/object.c(revision 16198)
@@ -267,7 +267,7 @@
return NULL;
if (PyUnicode_Check(res)) {
PyObject* str;
- str = PyUnicode_AsEncodedString(res, NULL,
NULL);
+ str = PyUnicode_AsUnicodeEscapeString(res);
Py_DECREF(res);
if (str)
res = str;
Does anyone have any objections to this? The test suite passes with
this (including the new test) as do various random tests I could
string together.
I need to apply this in the next short while, so if you have an issue
with it, please speak up now!
Thanks,
Anthony
> To make repr() conversion more robust, we could have
> PyObject_Repr() apply the conversion using the 'replace'
> error strategy - after all, repr() is usually only
> used for debugging, where it's more important that
> you do get an output rather than an exception.
--
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] improving quality
We've made a lot of improvement with testing over the years. Recently, we've gotten even more serious with the buildbot, Coverity, and coverage (http://coverage.livinglogic.de). However, in order to improve quality even further, we need to do a little more work. This is especially important with the upcoming 2.5. Python 2.5 is the most fundamental set of changes to Python since 2.2. If we're to make this release work, we need to be very careful about it. In order to do the best possible job and avoid silly errors, there shouldn't be any checkins which could change behaviour that do not include a test. I'm not talking about updating comments or string constants. But even trivial changes can cause regressions or incompatible changes. Just like failing tests, code checked in without tests is fair game for being reverted if there is anything questionable. If you really can't figure out any way to test the change, please describe why in your checkin message. Just make sure it's true. It would be quite embarrassing to have your whole theory trashed when Uncle Timmy comes along 5 minutes later and checks in the test you just claimed was impossible. :-) Cheers, 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
[Python-Dev] pysqlite for 2.5?
This came up before (back in October 2004!) but didn't go anywhere since, AFAICR. Do we want to consider including pysqlite in Python 2.5? It's the only DB adaptor that I'd really consider suitable for shipping with the distribution, because it's self-contained. What's people's thoughts? 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
Re: [Python-Dev] improving quality
On Tuesday 28 March 2006 17:53, Neal Norwitz wrote: > In order to do the best possible job and avoid silly errors, there > shouldn't be any checkins which could change behaviour that do not > include a test. I'm not talking about updating comments or string > constants. But even trivial changes can cause regressions or > incompatible changes. Just like failing tests, code checked in > without tests is fair game for being reverted if there is anything > questionable. +1 from me. Anyone disagree? 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
Re: [Python-Dev] improving quality
[Neal Norwitz] ... > If you really can't figure out any way to test the change, please > describe why in your checkin message. Just make sure it's true. It > would be quite embarrassing to have your whole theory trashed when > Uncle Timmy comes along 5 minutes later and checks in the test you > just claimed was impossible. :-) And I, for one, find that especially embarrassing when Uncle Timmy did the original checkin ;-) BTW, I just noticed that the Mac buildbot died with a segfault on the 2.4 branch, a few tests after test_capi "finished". I'll backport the fix for that from the trunk now. BTW2, has anyone tested their favorite extension module on the trunk with a release build? If you don't start reporting horrible problems, I'm not going to revert the patch that causes them :-) ___ 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] Libref sections to put new modules under?
Fred L. Drake, Jr. wrote: > On Monday 27 March 2006 16:26, Phillip J. Eby wrote: > > Any thoughts on where documentation for the new "contextlib" module should > > go in the library reference? > > Most definately in "Python Runtime Services." > > > A similar issue exists for "ctypes" module, although I imagine an argument > > could easily be made for putting it with "Optional Operating System > > Services". > > I'm less sure of that one. It could reasonably go in "Python Runtime > Services," "Generic Operating System Services," or "Optional Operating System > Services." > I had the same thought as Philip. For a preview of what it could look like, see http://starship.python.net/crew/theller/python-docs/html/lib/ , especially http://starship.python.net/crew/theller/python-docs/html/lib/module-ctypes.html . 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] INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
Greg Ewing wrote: > Travis E. Oliphant wrote: > >> I think this can be fixed easily by first checking the sequence slot for >> a sq_concat function before calling PyNumber_InPlaceAdd. > > However, if this *is* fixed, it looks like it's going to > break NumPy, in the sense that it will no longer be able > to force an arithmetic interpretation for "+" when adding > a sequence to an array. Well, it won't break any "documented" behavior of NumPy which does not use the sq_concat (or sq_concat_inplace) slot at all. I can't imaging anybody relying on an in-place operations to return a "different" object, but we could make the change and run all the NumPy/SciPy tests to see what happens. But, you are right that w = [1,2,3,4] w += array([1,2,3,4]) would no longer make w equal to array([2,4,6,8]). But, this seems like a very good thing to me, as such behavior is actually quite hard to explain except as "its a bug" -Travis ___ 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] Inconsistency in 2.4.3 for __repr__() returning unicode
Never mind. For 2.4.3, I reverted perky's patch for the unicode-escape, and reverted the old patch for PyObject_Repr on the trunk. After talking to perky and Neal, this seemed like the safest option for 2.4.3. Anthony ___ 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] pysqlite for 2.5?
Anthony Baxter wrote: > This came up before (back in October 2004!) but didn't go anywhere > since, AFAICR. Do we want to consider including pysqlite in Python > 2.5? It's the only DB adaptor that I'd really consider suitable for > shipping with the distribution, because it's self-contained. > > What's people's thoughts? OTOH, +1 for a simple DB wrapper that makes it easy to start with DB-enabled applications. The trouble with it can't be worse than the BSDDB issues ;) OTOH, pysqlite2 seems to have had a fairly rapid sequence of releases in the past. I don't know whether it is now bug-free (the website claims that the 2.1 branch should be stable, and the 2.0 branch has proven stable). There also have been some API changes in the 2.0.x line, like the introduction of executemany() which broke e.g. SQLObject. Anyway, almost all popular web frameworks rely on PySQLite and seem to work well with it. Of course, speaking with Gerhard will be the way to find out more. 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] PySet API
>> Thank would be nice. It gives me the ability to keep a clean, sane API >> while >> at >> the same time making sure that my most important customer (Barry) gets his >> needs >> met. > I'm having a hard time deciphering whether you're being condescending or > trying to be funny. I'm going to go with the latter. Good one! :) Neither. I was serious. You are a principal customer for setobjects. It seems that you make extensive use of them in your code. While I don't favor the proposed API, I think is essential that you not be left hanging without good options. Raymond ___ 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
