Re: [Python-Dev] gmane.comp.python.devel.3000 has disappeared
On 4/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Terry> For about a week, I have been reading and occasionally posting to > Terry> the new pydev-3000 mailing list via the gmane mirror > Terry> gmane.comp.lang.devel.3000. Today, it has disappeared and was > Terry> still gone after reloading their newsgroup list. Was this > Terry> intentional on the part of the mail list maintainers? (I > Terry> certainly hope not!) Or is it a repairable glitch somewhere > Terry> between the list and gmane? > > Gmane is subscribed. I've sent a message to them. Hopefully they will get > things corrected soon. Yes Gmane is subscribed. I checked if there is a pydev-3000 newsgroup on there server. Python 3000 new group is: http://dir.gmane.org/gmane.comp.python.python-3000.devel I tested it (subscribed) and it works. Try to refresh your subscription list in the news reader. -- bye by Wolfgang ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
On 4/1/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: Greg Ewing wrote:> I find it rather worrying that there could be a> few rare cases in which my generators cause> memory leaks, through no fault of my own and> without my being able to do anything about it. The GC changes PJE is looking at are to make sure you *can* do something aboutit. If the generator hasn't been started, or has already finished, then the GCwon't consider it as needing finalisation. Actually, if a generator has already finished, it no longer holds a suspended frame alive, and there is no cycle (at least not through the generator.) That's why test_generators no longer leaks; explicitly closing the generator breaks the cycle. So the only thing fixing GC would add is cleaning up cycles where a created but not started generator is the only thing keeping the cycle alive. -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
On 4/1/06, Greg Ewing <[EMAIL PROTECTED]> wrote: I'm becoming more and more convinced that wedesperately need something better than __del__methods to do finalisation. A garbage collectorthat can't be relied upon to collect garbageis simply not acceptable. Sure. I don't believe it's too hard, it just means violating some of the premises people have been writing __del__ methods under. For instance, to clean up cycles nicely we might have to set some attributes to None before calling __del__, so you can't rely on attributes being meaningful anymore. However, this is already the case for global names; I've seen many people wonder about their __del__ method raising warnings (since exceptions are ignored) going, say, 'NoneType has no attribute 'registry'' when they try to un-register their class but the global registry has been cleaned up already. While we're at it, I would like for the new __del__ (which would probably have to be a new method) to disallow reviving self, just because it makes it unnecessarily complicated and it's rarely needed. Allowing a partially deleted object (or an object part of a partially deleted reference-cycle) to revive itself is not terribly useful, and there's no way to restore the rest of the cycle. I suggested a __dealloc__ method earlier in the thread to do this. I didn't think of allowing attributes to be cleared before calling the method, but I do believe that is necessary to allow, now that I've thought more about it. An alternative would be to make GC check for a 'cleanup-cycle' method on any of the objects in the cycle, and just feed it the complete cycle of objects, asking it to clean it up itself (or maybe reconnect one of the objects itself.) That would also make debugging uncollectable cycles a lot easier ;-) But I'm not sure whether that will improve things. The generator example, the trigger for this discussion, could solve its cycle by just closing itself, after which the cycle is either broken or reconnected, but I don't know if other typical cycles could be resolved that easily. -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
On 4/1/06, Jim Jewett <[EMAIL PROTECTED]> wrote: Nick Coghlan> A simple Boolean attribute (e.g. __finalized__) should be enough. ...> If it's both present and true, the GC can ignore the finaliser on that instanceThat doesn't really take care of resource release, which needs to be called, and called early.(And the name will sound odd if it holdsresources only sometimes, so that it has to flip the __finalized__attribute.)Well, I don't want to sound too gross, but any such class could store its resources *in* __finalized__, leaving it an empty container when there is no resource to release. D'oh--not-sounding-gross-failed-ly y'rs,-- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference leaks, __del__, and annotations
On 4/1/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: On 4/1/06, Jim Jewett < [EMAIL PROTECTED]> wrote: Nick Coghlan> A simple Boolean attribute (e.g. __finalized__) should be enough. ...> If it's both present and true, the GC can ignore the finaliser on that instanceThat doesn't really take care of resource release, which needs to be called, and called early.(And the name will sound odd if it holdsresources only sometimes, so that it has to flip the __finalized__attribute.)Well, I don't want to sound too gross, but any such class could store its resources *in* __finalized__, leaving it an empty container when there is no resource to release. Eh, that would mean the attribute would have to be called '__notfinalized__' of course ;) -- Thomas Wouters <[EMAIL PROTECTED] >Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] 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
Armin Rigo <[EMAIL PROTECTED]> writes: > 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's actually because somewhere in the bowels of compilation, the file name being compiled gets interned and test_pkg writes out some temporary files and imports them. If this doesn't happen on the trunk, did this feature get lost somewhere? > 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... Something like that would be nice, yes... Cheers, mwh -- GET *BONK* BACK *BONK* IN*BONK* THERE *BONK* -- Naich using the troll hammer in cam.misc ___ Python-Dev mailing list [email protected] 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
"Chris AtLee" <[EMAIL PROTECTED]> writes: > On 3/28/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: >> 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. > > This reminds me of something I've been wanting to ask for a while: > does anybody run python through valgrind on a regular basis? I've > noticed that valgrind complains a lot about invalid reads in > PyObject_Free. I know that valgrind can warn about things that turn > out not to be problems, but would generating a suppresion file and > running all or part of the test suite through valgrind on the > buildbots be useful? Have you read Misc/README.valgrind? I don't know if anyone runs Python under valgrind regularly though. Cheers, mwh -- The ultimate laziness is not using Perl. That saves you so much work you wouldn't believe it if you had never tried it. -- Erik Naggum, comp.lang.lisp ___ Python-Dev mailing list [email protected] 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 Michael, On Sat, Apr 01, 2006 at 02:54:25PM +0100, Michael Hudson wrote: > It's actually because somewhere in the bowels of compilation, the file > name being compiled gets interned and test_pkg writes out some > temporary files and imports them. If this doesn't happen on the > trunk, did this feature get lost somewhere? I guess it's highly non-deterministic. If the new strings happen to take a previously-dummy entry of the interned strings dict, then after they die the entry is dummy again and we don't have an extra refcount. But if they take a fresh entry, then the dummy they become afterwards counts for one ref. A bientot, Armin. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Name for python package repository
On Thu, 30 Mar 2006, Greg Ewing wrote: > I just thought of a possible name for the > Python package repository. We could call > it the PIPE - Python Index of Packages > and Extensions. +1 John ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] line numbers, pass statements, implicit returns
There are several test cases in test_trace that are commented out. We did this when we merged the ast-branch and promised to come back to them. I'm coming back to them now, but the test aren't documented well and the feature they test isn't specified well. The failing tests I've looked at so far involving pass statements and implicit "return None" statements generated by the compiler. The tests seem to verify that 1) if you have a function that ends with an if/else where the body of the else is pass, there is no line number associated with the return 2) if you have a function that ends with a try/except where the body of the except is pass, there is a line number associated with the return. Here's a failing example def ireturn_example(): a = 5 b = 5 if a == b: b = a+1 else: pass The code is traced and test_trace verifies that the return is associated with line 4! In these cases, the ast compiler will always associate a line number with the return. (Technically with the LOAD_CONST preceding the RETURN_VALUE.) This happens pretty much be accident. It always associates a line number with the first opcode generated after a new statement is visited. Since a Pass statement node has no opcode, the return generates the first opcode. Now I could add some special cases to the compiler to preserve the old behavior, the question is: Why bother? It's such an unlikely case (an else that has no effect). Does anyone depend on the current behavior for the ireturn_example()? It seems sensible to me to always generate a line number for the pass + return case, just so you see the control flow as you step through the debugger. The other case that has changed is that the new compiler does not generate code for "while 0:" I don't remember why <0.5 wink>. There are several test cases that verify line numbers for code using this kind of bogus construct. There are no lines anymore, so I would change the tests so that they don't expect the lines in question. But I have no idea what they are trying to test. Does anyone know? Jeremy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] gmane.comp.python.devel.3000 has disappeared
> Yes Gmane is subscribed. > I checked if there is a pydev-3000 newsgroup on there server. I found the renamed group. Prefered the original name since it sorted just after this one in the subscribed groups list. tjr ___ Python-Dev mailing list [email protected] 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 4/1/06, Michael Hudson <[EMAIL PROTECTED]> wrote: > > I don't know if anyone runs Python under valgrind regularly though. I do for some definition of "regularly". It would be better to setup a cron job to truly run it regularly, perhaps once a month. It should run on both HEAD and supported release(s) (ie, 2.4 currently). I've heard of others using valgrind, I have no idea how many people and how often though. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Saving the hash value of tuples
Hello, I've found out that the hash value of tuples isn't saved after it's calculated. With strings it's different: the hash value of a string is calculated only on the first call to hash(string), and saved in the structure for future use. Saving the value makes dict lookup of tuples an operation with an amortized cost of O(1). Saving the hash value means that if an item of the tuple changes its hash value, the hash value of the tuple won't be changed. I think it's ok, since: 1. Hash value of things shouldn't change. 2. Dicts assume that too. I tried the change, and it turned out that I had to change cPickle a tiny bit: it uses a 2-tuple which is allocated when the module initializes to lookup tuples in a dict. I changed it to properly use PyTuple_New and Py_DECREF, and now the complete test suite passes. I run test_cpickle before the change and after it, and it took the same time (0.89 seconds on my computer). What do you think? I see three possibilities: 1. Nothing should be done, everything is as it should be. 2. The cPickle module should be changed to not abuse the tuple, but there's no reason to add an extra word to the tuple structure and break binary backwards compatibility. 3. Both should be changed. I will be happy to send a patch, if someone shows interest. Have a good day, Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Saving the hash value of tuples
On Sat, Apr 01, 2006, Noam Raphael wrote: > > I've found out that the hash value of tuples isn't saved after it's > calculated. With strings it's different: the hash value of a string is > calculated only on the first call to hash(string), and saved in the > structure for future use. Saving the value makes dict lookup of tuples > an operation with an amortized cost of O(1). > [...] > I will be happy to send a patch, if someone shows interest. Regardless of whether anyone shows interest, please submit a patch! Then post the URL back here. That way if someone gets interested in the future, your code is still available. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Look, it's your affair if you want to play with five people, but don't go calling it doubles." --John Cleese anticipates Usenet ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Saving the hash value of tuples
Ok, I uploaded it. Patch no. 1462796: https://sourceforge.net/tracker/index.php?func=detail&aid=1462796&group_id=5470&atid=305470 On 4/1/06, Aahz <[EMAIL PROTECTED]> wrote: > On Sat, Apr 01, 2006, Noam Raphael wrote: > > > > I've found out that the hash value of tuples isn't saved after it's > > calculated. With strings it's different: the hash value of a string is > > calculated only on the first call to hash(string), and saved in the > > structure for future use. Saving the value makes dict lookup of tuples > > an operation with an amortized cost of O(1). > > [...] > > I will be happy to send a patch, if someone shows interest. > > Regardless of whether anyone shows interest, please submit a patch! Then > post the URL back here. That way if someone gets interested in the > future, your code is still available. > -- > Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ > > "Look, it's your affair if you want to play with five people, but don't > go calling it doubles." --John Cleese anticipates Usenet > ___ Python-Dev mailing list [email protected] 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] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py
> Author: walter.doerwald > Date: Sat Apr 1 22:40:23 2006 > New Revision: 43545 > > Modified: >python/trunk/Doc/lib/libcalendar.tex >python/trunk/Lib/calendar.py > Log: > Make firstweekday a simple attribute instead > of hiding it behind a setter and a getter. Walter, what's the purpose of this patch? The first weekday is still an attribute, but instead of being settable and gettable via methods, looks like it's now settable and gettable via module-global functions, and only for the single default instance of Calendar created by the module. If so, then (a) the functionality of the Calendar class is weaker now, and in a backward-incompatible way; and, (b) the new module-global firstweekday() and setfirstweekday() functions are a more obscure way to restore the lost functionality for just one specific instance of a Calendar subclass. I don't see the attraction to any part of this. > --- python/trunk/Lib/calendar.py(original) > +++ python/trunk/Lib/calendar.pySat Apr 1 22:40:23 2006 > @@ -128,25 +128,14 @@ > """ > > def __init__(self, firstweekday=0): > -self._firstweekday = firstweekday # 0 = Monday, 6 = Sunday > - > -def firstweekday(self): > -return self._firstweekday > - > -def setfirstweekday(self, weekday): > -""" > -Set weekday (Monday=0, Sunday=6) to start each week. > -""" > -if not MONDAY <= weekday <= SUNDAY: > -raise IllegalWeekdayError(weekday) > -self._firstweekday = weekday > +self.firstweekday = firstweekday # 0 = Monday, 6 = Sunday Removing those Calendar methods is backward-incompatible, ... > -firstweekday = c.firstweekday > -setfirstweekday = c.setfirstweekday > +def firstweekday(): > +return c.firstweekday > + > +def setfirstweekday(firstweekday): > +if not MONDAY <= firstweekday <= SUNDAY: > +raise IllegalWeekdayError(firstweekday) > +c.firstweekday = firstweekday > + > monthcalendar = c.monthdayscalendar > prweek = c.prweek And here they're obscurely added back again, but work only for the module-global default instance `c` of the TextCalendar subclass. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP to list externally maintained modules and where to report bugs?
I reported some warnings I was getting for ctypes the other day and Martin said I should report it to ctypes. I now get a warning for sqlite on OS X 10.4 about INT32_MIN being redefined (I have stdint.h on my machine and that macro is being redefined in Modules/_sqlite/cursor.c instead of using the C99 version). Anyone else think we need a PEP to point to places where externally maintained code should have bugs or patches reported? I don't want to hunt down a URL for where to do this every time and so it would be nice to have a list of what code needs bugs/patches reported where. Otherwise I am prone to just check my changes into the tree and not get them reported upstream since I want the warnings to go away. =) -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PY_FORMAT_SIZE_T warnings on OS X
I think these are all Tim's fault =) : Objects/object.c: In function '_Py_NegativeRefcount': Objects/object.c:144: warning: format '%d' expects type 'int', but argument 7 has type 'Py_ssize_t' Objects/stringobject.c: In function 'PyString_FromFormatV': Objects/stringobject.c:278: warning: format '%u' expects type 'unsigned int', but argument 3 has type 'size_t' Python/pythonrun.c: In function 'Py_Finalize': Python/pythonrun.c:393: warning: format '%d' expects type 'int', but argument 3 has type 'Py_ssize_t' Python/pythonrun.c: In function 'PyRun_InteractiveLoopFlags': Python/pythonrun.c:683: warning: format '%d' expects type 'int', but argument 3 has type 'Py_ssize_t' Modules/gcmodule.c: In function 'collect': Modules/gcmodule.c:746: warning: format '%d' expects type 'int', but argument 2 has type 'Py_ssize_t' Modules/gcmodule.c:841: warning: format '%d' expects type 'int', but argument 2 has type 'Py_ssize_t' Modules/gcmodule.c:841: warning: format '%d' expects type 'int', but argument 3 has type 'Py_ssize_t' What's odd about them is that that the use of PY_FORMAT_SIZE_T seems to be correct, so I don't know what the problem is. Unfortunately ``gcc -E Include/pyport.h`` is no help since PY_FORMAT_SIZE_T is not showing up defined (possibly because gcc says it can't find pyconfig.h). -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PY_FORMAT_SIZE_T warnings on OS X
[Brett Cannon] > I think these are all Tim's fault =) : No, they're Anthony's fault :-) He added this clause to pyport.h yesterday: # if SIZEOF_SIZE_T == SIZEOF_INT # define PY_FORMAT_SIZE_T "" and that's obviously triggering on your platform. He added this (at my suggestion) to shut up similar gcc warnings on some other box. Before he added it, PY_FORMAT_SIZE_T was "l" on that box (and on yours) If it had remained "l", you wouldn't be getting warnings now, but he still would. On his box, the gripes where about passing a size_t argument to a "%lu" format, but size_t resolved to unsigned int, not to unsigned long. sizeof(int) == sizeof(long) on that box (and on yours), so the warning isn't really helpful. > Objects/object.c: In function '_Py_NegativeRefcount': > Objects/object.c:144: warning: format '%d' expects type 'int', but > argument 7 has type 'Py_ssize_t' And I bet (you should check) that Py_ssize_t resolves to "long" on your box, and that sizeof(long) == sizeof(int) on your box, so that again the warning is just a damned nuisance. > ... [similar complaints] ... > What's odd about them is that that the use of PY_FORMAT_SIZE_T seems > to be correct, so I don't know what the problem is. My best guess is above. gcc appears to be generating type complaints based on "name equivalence" rather than "structure equivalence" here (meaning it's comparing integer types by the names they resolve to rather than to the combination of size and signedness regardless of name). Worming around that would probably require a bunch of poke-and-hope experimenting with various gcc's, of which I have none :-) > Unfortunately ``gcc -E Include/pyport.h`` is no help since PY_FORMAT_SIZE_T > is not showing up defined (possibly because gcc says it can't find > pyconfig.h). You can run on it this part in isolation: #ifndef PY_FORMAT_SIZE_T # if SIZEOF_SIZE_T == SIZEOF_INT # define PY_FORMAT_SIZE_T "" # elif SIZEOF_SIZE_T == SIZEOF_LONG # define PY_FORMAT_SIZE_T "l" # elif defined(MS_WINDOWS) # define PY_FORMAT_SIZE_T "I" # else # error "This platform's pyconfig.h needs to define PY_FORMAT_SIZE_T" # endif #endif after sticking on the right expansions for the SIZEOF_xyz thingies -- but it's clear enough from the error messages that the SIZEOF_INT branch is triggering (it's complaining about format '%d', not format '%ld' or format '%Id'). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PY_FORMAT_SIZE_T warnings on OS X
On 4/1/06, Tim Peters <[EMAIL PROTECTED]> wrote: > [Brett Cannon] > > I think these are all Tim's fault =) : > > No, they're Anthony's fault :-) He added this clause to pyport.h yesterday: > > # if SIZEOF_SIZE_T == SIZEOF_INT > # define PY_FORMAT_SIZE_T "" > > and that's obviously triggering on your platform. He added this (at > my suggestion) to shut up similar gcc warnings on some other box. > Before he added it, PY_FORMAT_SIZE_T was "l" on that box (and on > yours) If it had remained "l", you wouldn't be getting warnings now, > but he still would. > Great, so either Anthony gets warnings or I do. > On his box, the gripes where about passing a size_t argument to a > "%lu" format, but size_t resolved to unsigned int, not to unsigned > long. sizeof(int) == sizeof(long) on that box (and on yours), so the > warning isn't really helpful. > Well that figures. > > Objects/object.c: In function '_Py_NegativeRefcount': > > Objects/object.c:144: warning: format '%d' expects type 'int', but > > argument 7 has type 'Py_ssize_t' > > And I bet (you should check) that Py_ssize_t resolves to "long" on > your box, and that sizeof(long) == sizeof(int) on your box, so that > again the warning is just a damned nuisance. > > > ... [similar complaints] ... > > > What's odd about them is that that the use of PY_FORMAT_SIZE_T seems > > to be correct, so I don't know what the problem is. > > My best guess is above. gcc appears to be generating type complaints > based on "name equivalence" rather than "structure equivalence" here > (meaning it's comparing integer types by the names they resolve to > rather than to the combination of size and signedness regardless of > name). Worming around that would probably require a bunch of > poke-and-hope experimenting with various gcc's, of which I have none > :-) This is just so ridiculous. Is there even a way to do this reasonably? Would we have to detect when Py_ssize_t resolves to either int or long and when the size of both is the same force to the same name on all platforms? > > > Unfortunately ``gcc -E Include/pyport.h`` is no help since PY_FORMAT_SIZE_T > > is not showing up defined (possibly because gcc says it can't find > > pyconfig.h). > > You can run on it this part in isolation: > > #ifndef PY_FORMAT_SIZE_T > # if SIZEOF_SIZE_T == SIZEOF_INT > # define PY_FORMAT_SIZE_T "" > # elif SIZEOF_SIZE_T == SIZEOF_LONG > # define PY_FORMAT_SIZE_T "l" > # elif defined(MS_WINDOWS) > # define PY_FORMAT_SIZE_T "I" > # else > # error "This platform's pyconfig.h needs to define PY_FORMAT_SIZE_T" > # endif > #endif > > after sticking on the right expansions for the SIZEOF_xyz thingies -- > but it's clear enough from the error messages that the SIZEOF_INT > branch is triggering (it's complaining about format '%d', not format > '%ld' or format '%Id'). > OK, so how should we solve this one? Or should we just ignore it and hope gcc eventually wises up and starting using structural equivalence for its printf checks? =) -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PY_FORMAT_SIZE_T warnings on OS X
[Brett Cannon] > ... > This is just so ridiculous. Ya think ;-)? > Is there even a way to do this reasonably? Not really in C89. That's why C99 introduced the "z" printf modifier, and approximately a billion ;-) format macros like PY_FORMAT_SIZE_T (since there's almost nothing portably useful you can say about standard C's billion names for "some kind of integer"). In effect, the PY_FORMAT_SIZE_T case was important enough that C99 moved it directly into the printf format syntax. > Would we have to detect when Py_ssize_t resolves to either int or long It's worse that that: there's no guarantee that sizeof(Py_ssize_t) <= sizeof(long), and it fact it's not on Win64. But Windows is already taken care of here. > OK, so how should we solve this one? Or should we just ignore it and > hope gcc eventually wises up and starting using structural equivalence > for its printf checks? =) For gcc we _could_ solve it in the obvious way, which I guess Martin was hoping to avoid: change Unixish config to detect whether the platform C supports the "z" format modifier (I believe gcc does), and if so arrange to stick #define PY_FORMAT_SIZE_T "z" in the generated pyconfig.h. Note that if pyconfig.h defines PY_FORMAT_SIZE_T, pyport.h believes whatever that says. It's the purpose of "z" to format size_t-ish arguments, so gcc complaints should end then. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PY_FORMAT_SIZE_T warnings on OS X
On 4/1/06, Tim Peters <[EMAIL PROTECTED]> wrote: > [Brett Cannon] > > ... > > This is just so ridiculous. > > Ya think ;-)? > > > Is there even a way to do this reasonably? > > Not really in C89. That's why C99 introduced the "z" printf modifier, > and approximately a billion ;-) format macros like PY_FORMAT_SIZE_T > (since there's almost nothing portably useful you can say about > standard C's billion names for "some kind of integer"). In effect, > the PY_FORMAT_SIZE_T case was important enough that C99 moved it > directly into the printf format syntax. > > > Would we have to detect when Py_ssize_t resolves to either int or long > > It's worse that that: there's no guarantee that sizeof(Py_ssize_t) <= > sizeof(long), and it fact it's not on Win64. But Windows is already > taken care of here. > > > OK, so how should we solve this one? Or should we just ignore it and > > hope gcc eventually wises up and starting using structural equivalence > > for its printf checks? =) > > For gcc we _could_ solve it in the obvious way, which I guess Martin > was hoping to avoid: change Unixish config to detect whether the > platform C supports the "z" format modifier (I believe gcc does), and > if so arrange to stick > > #define PY_FORMAT_SIZE_T "z" > > in the generated pyconfig.h. Note that if pyconfig.h defines > PY_FORMAT_SIZE_T, pyport.h believes whatever that says. It's the > purpose of "z" to format size_t-ish arguments, so gcc complaints > should end then. > I vote we move to C99. =) If that doesn't happen, I guess the above solution is the best. I am probably not the best person to tweak the Makefile for this, but I can if no one gets to it. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Firefox searchbar engine for Python bugs
I've created a searchbar plugin for the firefox search bar that allows you to search bugs. I think someone created one for the sidebar, but this works in the searchbar at the top of the window. I gave up trying to knit the files into the new website builder, and so it can be found here: http://www.python.org/~anthony/searchbar/ If you can think of other useful searchbar plugins (Python Docs, maybe?) let me know and I'll look at creating them. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Firefox searchbar engine for Python bugs
On Sunday 02 April 2006 14:17, Anthony Baxter wrote: > I've created a searchbar plugin for the firefox search bar that > allows you to search bugs. I should clarify - it allows you to pull up a bug by bug ID, using the www.python.org/sf/ redirector. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] line numbers, pass statements, implicit returns
On 4/1/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote: > There are several test cases in test_trace that are commented out. We > did this when we merged the ast-branch and promised to come back to > them. I'm coming back to them now, but the test aren't documented > well and the feature they test isn't specified well. > > The failing tests I've looked at so far involving pass statements and > implicit "return None" statements generated by the compiler. The > tests seem to verify that > > 1) if you have a function that ends with an if/else where the body > of the else is pass, > there is no line number associated with the return > 2) if you have a function that ends with a try/except where the > body of the except is pass, > there is a line number associated with the return. > > Here's a failing example > > def ireturn_example(): > a = 5 > b = 5 > if a == b: > b = a+1 > else: > pass > > The code is traced and test_trace verifies that the return is > associated with line 4! > > In these cases, the ast compiler will always associate a line number > with the return. (Technically with the LOAD_CONST preceding the > RETURN_VALUE.) This happens pretty much be accident. It always > associates a line number with the first opcode generated after a new > statement is visited. Since a Pass statement node has no opcode, the > return generates the first opcode. > > Now I could add some special cases to the compiler to preserve the old > behavior, the question is: Why bother? It's such an unlikely case (an > else that has no effect). Does anyone depend on the current behavior > for the ireturn_example()? It seems sensible to me to always generate > a line number for the pass + return case, just so you see the control > flow as you step through the debugger. Makes sense to me. I can't imagine what this was testing except perhaps a corner case in the algorithm for generating the (insanely complicated) linenumber mapping table. > The other case that has changed is that the new compiler does not > generate code for "while 0:" I don't remember why <0.5 wink>. There > are several test cases that verify line numbers for code using this > kind of bogus construct. There are no lines anymore, so I would > change the tests so that they don't expect the lines in question. But > I have no idea what they are trying to test. Does anyone know? Not me. This is definitely not part of the language spec! :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PY_FORMAT_SIZE_T warnings on OS X
Tim Peters wrote: > For gcc we _could_ solve it in the obvious way, which I guess Martin > was hoping to avoid: change Unixish config to detect whether the > platform C supports the "z" format modifier (I believe gcc does), and > if so arrange to stick > > #define PY_FORMAT_SIZE_T "z" It's not gcc to support "z" (except for the compile-time check); it's the C library (on Unix, the C library is part of the system, not part of the compiler). But yes: if we could detect in configure that the C library supports %zd, then we should use that. Regards, Martin ___ Python-Dev mailing list [email protected] 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] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py
Tim Peters wrote: >> Author: walter.doerwald >> Date: Sat Apr 1 22:40:23 2006 >> New Revision: 43545 >> >> Modified: >>python/trunk/Doc/lib/libcalendar.tex >>python/trunk/Lib/calendar.py >> Log: >> Make firstweekday a simple attribute instead >> of hiding it behind a setter and a getter. > > Walter, what's the purpose of this patch? The first weekday is still > an attribute, but instead of being settable and gettable via methods, > looks like it's now settable and gettable via module-global functions, > and only for the single default instance of Calendar created by the > module. If so, then (a) the functionality of the Calendar class is > weaker now, and in a backward-incompatible way; and, (b) the new > module-global firstweekday() and setfirstweekday() functions are a > more obscure way to restore the lost functionality for just one > specific instance of a Calendar subclass. > > I don't see the attraction to any part of this. > >> --- python/trunk/Lib/calendar.py(original) >> +++ python/trunk/Lib/calendar.pySat Apr 1 22:40:23 2006 >> @@ -128,25 +128,14 @@ >> """ >> >> def __init__(self, firstweekday=0): >> -self._firstweekday = firstweekday # 0 = Monday, 6 = Sunday >> - >> -def firstweekday(self): >> -return self._firstweekday >> - >> -def setfirstweekday(self, weekday): >> -""" >> -Set weekday (Monday=0, Sunday=6) to start each week. >> -""" >> -if not MONDAY <= weekday <= SUNDAY: >> -raise IllegalWeekdayError(weekday) >> -self._firstweekday = weekday >> +self.firstweekday = firstweekday # 0 = Monday, 6 = Sunday > > Removing those Calendar methods is backward-incompatible, Isn't it that the Calendar class was just added and therefore is new to 2.5? >> -firstweekday = c.firstweekday >> -setfirstweekday = c.setfirstweekday >> +def firstweekday(): >> +return c.firstweekday >> + >> +def setfirstweekday(firstweekday): >> +if not MONDAY <= firstweekday <= SUNDAY: >> +raise IllegalWeekdayError(firstweekday) >> +c.firstweekday = firstweekday >> + >> monthcalendar = c.monthdayscalendar >> prweek = c.prweek > > And here they're obscurely added back again, but work only for the > module-global default instance `c` of the TextCalendar subclass. Since the functions are part of the traditional calendar API which cannot be broken. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
