Re: [Python-Dev] __dir__, part 2
No objection on targetting 2.6 if other developers agree. Seems this is well under way. good work! On 11/6/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > tomer filiba wrote: > > cool. first time i build the entire interpreter, 'twas fun :) > > currently i "retained" support for __members__ and __methods__, > > so it doesn't break anything and is compatible with 2.6. > > > > i really hope it will be included in 2.6 as today i'm using ugly hacks > > in RPyC to make remote objects appear like local ones. > > having __dir__ solves all of my problems. > > > > besides, it makes a lot of sense of define __dir__ for classes that > > define __getattr__. i don't think it should be pushed back to py3k. > > > > here's the patch: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1591665&group_id=5470&atid=305470 > > As I noted on the tracker, PyObject_Dir is a public C API function, so it's > behaviour needs to be preserved as well as the behaviour of calling dir() from > Python code. > > So the final form of the patch will likely need to include stronger tests for > that section of the API, as well as updating the documentation in various > places (the dir and PyObject_Dir documentation, obviously, but also the list > of magic methods in the language reference). > > +1 on targeting 2.6, too. > > Cheers, > Nick. > > -- > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > --- > http://www.boredomandlaziness.org > -- --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] Importing .pyc in -O mode and vice versa
On 7Nov 2006, at 12:20 AM, Greg Ewing wrote: Also, if we do our own directory caching, the question is when to invalidate the cache. I think I'd be happy with having to do that explicitly. I expect the vast majority of Python programs don't need to track changes to the set of importable modules during execution. The exceptions would be things like IDEs, and they could do a cache flush before reloading a module, etc. Not only IDE's, also the interactive prompt. It is very convenient that you can currently install an additional module when an import fails and then try the import again (at the python prompt). Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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] __dir__, part 2
On Tuesday 07 November 2006 19:00, Guido van Rossum wrote: > No objection on targetting 2.6 if other developers agree. Seems this > is well under way. good work! Sounds fine to me! Less magic under the hood is less magic, and that's always a good thing. The use case for it seems completely appropriate, too. 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] valgrind
You want to disable the obmalloc module when using valgrind, as I have when using Rational Purify. obmalloc does some evil stuff to recocnize its memory. You also want to disable it so that you get verification on a per-block level. Actually, obmalloc could be improved in this aspect. Similar code that I once wrote computed the block base address, but than looked in its tables to see if it was actually a known block before accessing it. That way you can have blocks that are larger than the virtual memory block of the process. K > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Herman Geza > Sent: 7. nóvember 2006 02:12 > To: [email protected] > Subject: [Python-Dev] valgrind > > Hi! > > I've embedded python into my application. Using valgrind I > got a lot of errors. I understand that "Conditional jump or > move depends on uninitialised value(s)" errors are completely > ok (from Misc/README.valgrind). However, I don't understand > why "Invalid read"'s are legal, like this: > > ==21737== Invalid read of size 4 > ==21737==at 0x408DDDF: PyObject_Free (in > /usr/lib/libpython2.4.so.1.0) > ==21737==by 0x4096F67: (within /usr/lib/libpython2.4.so.1.0) > ==21737==by 0x408A5AC: PyCFunction_Call (in > /usr/lib/libpython2.4.so.1.0) > ==21737==by 0x40C65F8: PyEval_EvalFrame (in > /usr/lib/libpython2.4.so.1.0) > ==21737== Address 0xC02E010 is 32 bytes inside a block of > size 40 free'd > ==21737==at 0x401D139: free (vg_replace_malloc.c:233) > ==21737==by 0x408DE00: PyObject_Free (in > /usr/lib/libpython2.4.so.1.0) > ==21737==by 0x407BB4D: (within /usr/lib/libpython2.4.so.1.0) > ==21737==by 0x407A3D6: (within /usr/lib/libpython2.4.so.1.0) > > Here python reads from an already-freed memory area, right? > (I don't think that Misc/README.valgrind answers this > question). Or is it a false alarm? > > Thanks, > Geza Herman > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/kristjan%40c cpgames.com > ___ 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] valgrind
Neal Norwitz schrieb: > at 0x44FA06: Py_ADDRESS_IN_RANGE (obmalloc.c:1741) > > Note that the free is inside qsort. The memory freed under qsort > should definitely not be the bases which we allocated under > PyType_Ready. I'll file a bug report with valgrind to help determine > if this is a problem in Python or valgrind. > http://bugs.kde.org/show_bug.cgi?id=136989 As Tim explains, a read from Py_ADDRESS_IN_RANGE is fine, and by design. If p is the pointer, we do pool = ((poolp)((Py_uintptr_t)(p) & ~(Py_uintptr_t)((4 * 1024) - 1))); i.e. round down p to the start of the page, to obtain "pool". Then we do f (((pool)->arenaindex < maxarenas && (Py_uintptr_t)(p) - arenas[(pool)->arenaindex].address < (Py_uintptr_t)(256 << 10) && arenas[(pool)->arenaindex].address != 0)) i.e. access pool->arenaindex. If this is our own memory, we really find a valid arena index there. If this is malloc'ed memory, we read garbage - due to the page size, we are guaranteed to read successfully, still. To determine whether it's garbage, we look it up in the arenas array. > One other thing that is weird is that the complaint is about 4 bytes > which should not be possible. All pointers should be 8 bytes AFAIK > since this is amd64. That's because the arenaindex is unsigned int. We could widen it to size_t, if we don't, PyMalloc can "only" manage 1 PiB (with an arena being 256kiB, and 4Gi arena indices being available). > I also ran this on x86. There were 32 errors and all of their > addresses were 0x4...010. That's because we round down to the beginning of the page. 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] valgrind
On Tue, 7 Nov 2006, Tim Peters wrote: > When PyObject_Free is handed an address it doesn't control, the "arena > base address" it derives from that address may point at anything the > system malloc controls, including uninitialized memory, memory the > system malloc has allocated to something, memory the system malloc has > freed, or internal system malloc bookkeeping bytes. The > Py_ADDRESS_IN_RANGE macro has no way to know before reading it up. > > So figure out which line of code valgrind is complaining about > (doesn't valgrind usually produce that?). If it's coming from the > expansion of Py_ADDRESS_IN_RANGE, it's not worth more thought. Hmm. I don't think that way. What if free() does other things? For example if free(addr) sees that the memory block at addr is the last block then it may call brk with a decreased end_data_segment. Or the last block in an mmap'd area - it calls unmap. So when Py_ADDRESS_IN_RANGE tries to read from this freed memory block it gets SIGSEGV. However, I've never got SIGSEGV from python. I don't really think that reading from an already-freed block is ever legal. I asked my original question because I saw that I'm not the only one who sees "Illegal reads" from python. Is valgrind wrong in this case? I just want to be sure that I'll never get SIGSEGV from python. Note that Misc/valgrind-python.supp contains suppressions "Invalid read"'s at Py_ADDRESS_IN_RANGE. Geza Herman ___ 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] __dir__, part 2
okay, everything's fixed. i updated the patch and added a small test to: Lib/test/test_builtins.py::test_dir -tomer On 11/7/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > tomer filiba wrote: > > cool. first time i build the entire interpreter, 'twas fun :) > > currently i "retained" support for __members__ and __methods__, > > so it doesn't break anything and is compatible with 2.6. > > > > i really hope it will be included in 2.6 as today i'm using ugly hacks > > in RPyC to make remote objects appear like local ones. > > having __dir__ solves all of my problems. > > > > besides, it makes a lot of sense of define __dir__ for classes that > > define __getattr__. i don't think it should be pushed back to py3k. > > > > here's the patch: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1591665&group_id=5470&atid=305470 > > As I noted on the tracker, PyObject_Dir is a public C API function, so it's > behaviour needs to be preserved as well as the behaviour of calling dir() from > Python code. > > So the final form of the patch will likely need to include stronger tests for > that section of the API, as well as updating the documentation in various > places (the dir and PyObject_Dir documentation, obviously, but also the list > of magic methods in the language reference). > > +1 on targeting 2.6, too. > > Cheers, > Nick. > > -- > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > --- > http://www.boredomandlaziness.org > ___ 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] __dir__, part 2
> as well as updating the documentation in various > places (the dir and PyObject_Dir documentation, obviously, but also the list > of magic methods in the language reference). oops, i meant everything except that -tomer On 11/7/06, tomer filiba <[EMAIL PROTECTED]> wrote: > okay, everything's fixed. > i updated the patch and added a small test to: > Lib/test/test_builtins.py::test_dir > > > -tomer > > On 11/7/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > tomer filiba wrote: > > > cool. first time i build the entire interpreter, 'twas fun :) > > > currently i "retained" support for __members__ and __methods__, > > > so it doesn't break anything and is compatible with 2.6. > > > > > > i really hope it will be included in 2.6 as today i'm using ugly hacks > > > in RPyC to make remote objects appear like local ones. > > > having __dir__ solves all of my problems. > > > > > > besides, it makes a lot of sense of define __dir__ for classes that > > > define __getattr__. i don't think it should be pushed back to py3k. > > > > > > here's the patch: > > > http://sourceforge.net/tracker/index.php?func=detail&aid=1591665&group_id=5470&atid=305470 > > > > As I noted on the tracker, PyObject_Dir is a public C API function, so it's > > behaviour needs to be preserved as well as the behaviour of calling dir() > > from > > Python code. > > > > So the final form of the patch will likely need to include stronger tests > > for > > that section of the API, as well as updating the documentation in various > > places (the dir and PyObject_Dir documentation, obviously, but also the list > > of magic methods in the language reference). > > > > +1 on targeting 2.6, too. > > > > Cheers, > > Nick. > > > > -- > > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > > --- > > http://www.boredomandlaziness.org > > > ___ 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] Inconvenient filename in sandbox/decimal-c/new_dt
Hi, I'm having problems with updating the sandbox. ilithien:~/Python/sandbox-trunk ronald$ svn cleanup ilithien:~/Python/sandbox-trunk ronald$ svn up Aimport_in_py/mock_importer.py Uimport_in_py/test_importer.py Uimport_in_py/importer.py svn: Failed to add file 'decimal-c/new_dt/rounding.decTest': object of the same name already exists This is on a 10.4.8 box with a recent version of subversion. It turns out this is caused by a testcase file: decimal-c/new_dt contains both remainderNear.decTest and remaindernear.decTest (the filenames differ by case only). It this intentional? This makes it impossible to do a checkout on a system with a case insensitive filesystem. Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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] valgrind
Herman Geza schrieb: >> So figure out which line of code valgrind is complaining about >> (doesn't valgrind usually produce that?). If it's coming from the >> expansion of Py_ADDRESS_IN_RANGE, it's not worth more thought. > > Hmm. I don't think that way. What if free() does other things? It can't, as the hardware won't support it. > For example > if free(addr) sees that the memory block at addr is the last block then it > may call brk with a decreased end_data_segment. It can't. In brk, you can only manage memory in chunks of "one page" (i.e. 4kiB on x86). Since we only access memory on the same page, access is guaranteed to succeed. > Or the last block > in an mmap'd area - it calls unmap. So when Py_ADDRESS_IN_RANGE tries > to read from this freed memory block it gets SIGSEGV. However, I've never > got SIGSEGV from python. Likewise. This is guaranteed to work, by the processor manufacturers. > I don't really think that reading from an already-freed block is ever > legal. Define "legal". There is no law against it; you don't go to jail for doing it. What other penalties would you expect (other than valgrind spitting out error messages, and users complaining from time to time that it's "illegal")? > I asked my original question because I saw that I'm not the only > one who sees "Illegal reads" from python. Is valgrind wrong in this case? If it is this case, then no, valgrind is right. Notice that valgrind doesn't call them "illegal"; it calls them "invalid". > I just want to be sure that I'll never get SIGSEGV from python. You least won't get SIGSEGVs from that part of the code. > Note that Misc/valgrind-python.supp contains suppressions "Invalid read"'s > at Py_ADDRESS_IN_RANGE. Right. This is to tell valgrind that these reads are known to work as designed. 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] Inconvenient filename in sandbox/decimal-c/new_dt
Ronald Oussoren schrieb: > This is on a 10.4.8 box with a recent version of subversion. It turns > out this is caused by a testcase file: decimal-c/new_dt contains both > remainderNear.decTest and remaindernear.decTest (the filenames differ by > case only). It this intentional? I don't think so. The files differed only in the version: field, and remainderNear.decTest is the same as the Python trunk, so I removed remaindernear.decTest as bogus. 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] valgrind
> > For example > > if free(addr) sees that the memory block at addr is the last block then it > > may call brk with a decreased end_data_segment. > > It can't. In brk, you can only manage memory in chunks of "one page" > (i.e. 4kiB on x86). Since we only access memory on the same page, > access is guaranteed to succeed. Yes, I'm aware of it. But logically, it is possible, isn't it? At malloc(), libc recognizes that brk needed, it calls sbrk(4096). Suppose that python releases this very same block immediately. At free(), libc recognizes that sbrk(-4096) could be executed, so the freed block not available anymore (even for reading) > > Or the last block > > in an mmap'd area - it calls unmap. So when Py_ADDRESS_IN_RANGE tries > > to read from this freed memory block it gets SIGSEGV. However, I've never > > got SIGSEGV from python. > > Likewise. This is guaranteed to work, by the processor manufacturers. The same: if the freed block is the last one in the mmap'd area, libc may unmap it, doesn't it? > > I don't really think that reading from an already-freed block is ever > > legal. > > Define "legal". There is no law against it; you don't go to jail for > doing it. What other penalties would you expect (other than valgrind > spitting out error messages, and users complaining from time to time > that it's "illegal")? Ok, sorry about the strong word "legal". > > I asked my original question because I saw that I'm not the only > > one who sees "Illegal reads" from python. Is valgrind wrong in this case? > > If it is this case, then no, valgrind is right. Notice that valgrind > doesn't call them "illegal"; it calls them "invalid". > > > I just want to be sure that I'll never get SIGSEGV from python. > > You least won't get SIGSEGVs from that part of the code. That's what I still don't understand. If valgrind is right then how can python be sure that it can still reach a freed block? > > Note that Misc/valgrind-python.supp contains suppressions "Invalid read"'s > > at Py_ADDRESS_IN_RANGE. > > Right. This is to tell valgrind that these reads are known to work > as designed. Does this mean that python strongly depends on libc? If I want to port python to another platform which uses a totally different malloc, is Py_ADDRESS_IN_RANGE guaranteed to work or do I have to make some changes? (actually I'm porting python to another platfrom that's why I'm asking these questions, not becaue I'm finical or something) Thanks, Geza Herman ___ 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] valgrind
Herman Geza schrieb: >> It can't. In brk, you can only manage memory in chunks of "one page" >> (i.e. 4kiB on x86). Since we only access memory on the same page, >> access is guaranteed to succeed. > Yes, I'm aware of it. But logically, it is possible, isn't it? No, it isn't. > At malloc(), libc recognizes that brk needed, it calls sbrk(4096). > Suppose that python releases this very same block immediately. At free(), > libc recognizes that sbrk(-4096) could be executed, so the freed block not > available anymore (even for reading) That can't happen for a different reason. When this access occurs, we still have a pointer to allocated memory (either allocated through malloc, or obmalloc - we don't know at the pointer where the access is made). The access is "invalid" only if the memory was allocated through malloc. So when the access is made, we have a pointer p, which is allocated through malloc, and access p-3000 (say, assuming that p-3000 is a page boundary). Since p is still allocated, libc *cannot* have made sbrk(p-3000), since that would have released the still-allocated block. > >>> Or the last block >>> in an mmap'd area - it calls unmap. So when Py_ADDRESS_IN_RANGE tries >>> to read from this freed memory block it gets SIGSEGV. However, I've never >>> got SIGSEGV from python. >> Likewise. This is guaranteed to work, by the processor manufacturers. > The same: if the freed block is the last one in the mmap'd area, libc may > unmap it, doesn't it? But it isn't. We still have an allocated block of memory on the same page. The C library can't have released it. >>> I just want to be sure that I'll never get SIGSEGV from python. >> You least won't get SIGSEGVs from that part of the code. > That's what I still don't understand. If valgrind is right then how can > python be sure that it can still reach a freed block? valgrind knows the block is released. We know that the block is still "mapped" to memory by the operating system. These are different properties. To write to memory, you better have allocated it. To read from memory, it ought to be mapped (in most applications, it is also an error to read from released memory, even if the read operation succeeds; valgrind reports this error as "invalid read"). >>> Note that Misc/valgrind-python.supp contains suppressions "Invalid read"'s >>> at Py_ADDRESS_IN_RANGE. >> Right. This is to tell valgrind that these reads are known to work >> as designed. > Does this mean that python strongly depends on libc? No. It strongly depends on a lower estimate of the page size, and that memory is mapped on page boundaries. > If I want to port > python to another platform which uses a totally different malloc, is > Py_ADDRESS_IN_RANGE guaranteed to work or do I have to make some changes? It's rather unimportant how malloc is implemented. The real question is whether you have a flat address space (Python likely won't work at all if you don't have a flat address space), and whether the system either doesn't have virtual memory, or, if it does, whether obmalloc's guess of the page size is either right or an underestimation. If some constraints fail, you can't use obmalloc (you could still port Python, to not use obmalloc). Notice that on a system with limited memory, you probably don't want to use obmalloc, even if it worked. obmalloc uses arenas of 256kiB, which might be expensive on the target system. Out of curiosity: what is your target system? 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] valgrind
Thanks Martin, now everything is clear. Python always reads from the page where the about-to-be-freed block is located (that was the information that I missed) - as such, never causes a SIGSEGV. Geza Herman ___ 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] valgrind
[Kristján V. Jónsson] > ... > Actually, obmalloc could be improved in this aspect. Similar code that I > once wrote > computed the block base address, but than looked in its tables to see if it > was > actually a known block before accessing it. Several such schemes were tried (based on, e.g., binary search and splay trees), but discarded due to measurable sloth. The overwhelming advantage of the current scheme is that it does the check in constant time, independent of how many distinct arenas (whether one or thousands makes no difference) pymalloc is managing. > That way you can have blocks that are larger than the virtual memory block > of the process. If you have a way to do the check in constant time, that would be good. Otherwise speed rules here. ___ 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] valgrind
[Martin v. Löwis] Thanks for explaining all this! One counterpoint: > Notice that on a system with limited memory, you probably don't > want to use obmalloc, even if it worked. obmalloc uses arenas > of 256kiB, which might be expensive on the target system. OTOH, Python allocates a lot of small objects, and one of the reasons for obmalloc's existence is that it typically uses memory more efficiently (less bookkeeping space overhead and less fragmentation) for mounds of small objects than the all-purpose system malloc. In a current (trunk) debug build, simply starting Python hits an arena highwater mark of 9, and doing "python -S" instead hits a highwater mark of 2. Given how much memory Python needs to do nothing ;-), it's doubtful that the system malloc would be doing better. ___ 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] test_ucn fails for trunk on x86 Ubuntu Edgy
One of the Pybots buildslaves running x86 Ubuntu Edgy has been failing the unit test step for the trunk, specifically the test_ucn test. Here's the error: test_ucn test test_ucn failed -- Traceback (most recent call last): File "/home/pybot/pybot/trunk.bear-x86/build/Lib/test/test_ucn.py", line 102, in test_bmp_characters self.assertEqual(unicodedata.lookup(name), char) KeyError: "undefined character name 'EIGHT PETALLED OUTLINED BLACK FLORETTE'" Here's the entire log for the failed step: http://www.python.org/dev/buildbot/community/all/x86%20Ubuntu%20Edgy%20trunk/builds/142/step-test/0 Note that this test passes on all the other plaforms running in the Pybots farm, including an amd64 Ubuntu Edgy machine. Looks like the failure started to happen after this checkin: http://svn.python.org/view?rev=52621&view=rev Grig -- http://agiletesting.blogspot.com ___ 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] Importing .pyc in -O mode and vice versa
Armin Rigo wrote: It would seem good practice to remove all .pycs after checking out a new version of the source, just in case there are other problems such as mismatched timestamps, which can cause the same trouble. > My two > cents is that it would be saner to have two separate concepts: cache > files used internally by the interpreter for speed reasons only, and > bytecode files that can be shipped and imported. That's a possibility. -- Greg ___ 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] Importing .pyc in -O mode and vice versa
Delaney, Timothy (Tim) wrote: > Would it be reasonable to always do a stat() on the directory, > reloading if there's been a change? Would this be reliable across > platforms? To detect a new shadowing you'd have to stat all the directories along sys.path, not just the one you think the file is in. That might wipe out most of the advantage. It would be different on platforms which provide a way of "watching" a directory and getting notified of changes. I think MacOSX, Linux and Windows all provide some way of doing that nowadays, although I'm not familiar with the details. -- Greg ___ 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] Importing .pyc in -O mode and vice versa
On Mon, 6 Nov 2006, Armin Rigo wrote: > I know it's a discussion that comes up and dies out regularly. My two > cents is that it would be saner to have two separate concepts: cache > files used internally by the interpreter for speed reasons only, and > bytecode files that can be shipped and imported. I like this approach. Bringing source code and program behaviour closer together makes debugging easier, and if someone wants to run Python programs without source code, then EIBTI. -- ?!ng ___ 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] Importing .pyc in -O mode and vice versa
Martin v. Löwis wrote: > Currently, you can put a file on disk and import it > immediately; that will stop working. One thing I should add is that if you try to import a module that wasn't there before, the interpreter will notice this and has the opportunity to update its idea of what's on the disk. Likewise, if you delete a module, the interpreter will notice when it tries to open a file that no longer exists. The only change would be if you added a module that shadowed something formerly visible further along sys.path -- in between starting the program and attempting to import it for the first time. So I don't think there would be any visible change as far as most people could tell. -- Greg ___ 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] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 430 open ( -4) / 3447 closed (+17) / 3877 total (+13) Bugs: 922 open ( -7) / 6316 closed (+31) / 7238 total (+24) RFE : 245 open ( +0) / 241 closed ( +1) / 486 total ( +1) New / Reopened Patches __ modulefinder changes for py3k (2006-10-27) CLOSED http://python.org/sf/1585966 opened by Thomas Heller no wraparound for enumerate() (2006-10-28) CLOSED http://python.org/sf/1586315 opened by Georg Brandl missing imports ctypes in documentation examples (2006-09-13) CLOSED http://python.org/sf/1557890 reopened by theller better error msgs for some TypeErrors (2006-10-29) http://python.org/sf/1586791 opened by Georg Brandl cookielib: lock acquire/release try..finally protected (2006-10-30) http://python.org/sf/1587139 opened by kxroberto Patch for #1586414 to avoid fragmentation on Windows (2006-10-31) http://python.org/sf/1587674 opened by Enoch Julias Typo in Mac installer image name (2006-11-01) CLOSED http://python.org/sf/1589013 opened by Humberto Diógenes Typo in Mac image name (2006-11-01) CLOSED http://python.org/sf/1589014 opened by Humberto Diógenes MacPython Build Installer - Typos and Style corrections (2006-11-02) CLOSED http://python.org/sf/1589070 opened by Humberto Diógenes bdist_sunpkg distutils command (2006-11-02) http://python.org/sf/1589266 opened by Holger The "lazy strings" patch (2006-11-04) http://python.org/sf/1590352 opened by Larry Hastings adding __dir__ (2006-11-06) http://python.org/sf/1591665 opened by ganges master `in` for classic object causes segfault (2006-11-07) http://python.org/sf/1591996 opened by Hirokazu Yamamoto PyErr_CheckSignals returns -1 on error, not 1 (2006-11-07) http://python.org/sf/1592072 opened by Gustavo J. A. M. Carneiro Add missing elide argument to Text.search (2006-11-07) http://python.org/sf/1592250 opened by Russell Owen Patches Closed __ Fix for structmember conversion issues (2006-08-30) http://python.org/sf/1549049 closed by loewis Enable SSL for smtplib (2006-09-28) http://python.org/sf/1567274 closed by loewis Mailbox will not lock properly after flush() (2006-10-11) http://python.org/sf/1575506 closed by akuchling urllib2 - Fix line breaks in authorization headers (2006-10-09) http://python.org/sf/1574068 closed by akuchling Tiny patch to stop make spam (2006-06-09) http://python.org/sf/1503717 closed by akuchling modulefinder changes for py3k (2006-10-27) http://python.org/sf/1585966 closed by gvanrossum unparse.py decorator support (2006-09-04) http://python.org/sf/1552024 closed by gbrandl no wraparound for enumerate() (2006-10-28) http://python.org/sf/1586315 closed by rhettinger missing imports ctypes in documentation examples (2006-09-13) http://python.org/sf/1557890 closed by theller missing imports ctypes in documentation examples (2006-09-13) http://python.org/sf/1557890 closed by nnorwitz tarfile.py: better use of TarInfo objects with longnames (2006-10-24) http://python.org/sf/1583880 closed by gbrandl tarfile depends on undocumented behaviour (2006-09-25) http://python.org/sf/1564981 closed by gbrandl Typo in Mac installer image name (2006-11-02) http://python.org/sf/1589013 closed by ronaldoussoren Typo in Mac image name (2006-11-01) http://python.org/sf/1589014 deleted by virtualspirit MacPython Build Installer - Typos and Style corrections (2006-11-02) http://python.org/sf/1589070 closed by ronaldoussoren bdist_rpm not able to compile multiple rpm packages (2004-11-04) http://python.org/sf/1060577 closed by loewis Remove inconsistent behavior between import and zipimport (2005-11-03) http://python.org/sf/1346572 closed by loewis Rational Reference Implementation (2002-10-02) http://python.org/sf/617779 closed by loewis Problem at the end of misformed mailbox (2002-11-03) http://python.org/sf/632934 closed by loewis New / Reopened Bugs ___ csv.reader.line_num missing 'new in 2.5' (2006-10-27) CLOSED http://python.org/sf/1585690 opened by Kent Johnson tarfile.extract() may cause file fragmentation on Windows XP (2006-10-28) http://python.org/sf/1586414 opened by Enoch Julias compiler module dont emit LIST_APPEND w/ list comprehension (2006-10-29) CLOSED http://python.org/sf/1586448 opened by sebastien Martini codecs.open problem with "with" statement (2006-10-28) CLOSED http://python.org/sf/1586513 opened by Shaun Cutts zlib/bz2_codec doesn't support incremental decoding (2006-10-29) CLOSED http://python.org/sf/1586613 opened by Topia hashlib documentation is insuficient (2006-10-29) CLOSED http://python.org/sf/1586773 opened by Marcos Daniel Marado Torres
Re: [Python-Dev] Importing .pyc in -O mode and vice versa
Greg Ewing schrieb: > One thing I should add is that if you try to import > a module that wasn't there before, the interpreter will > notice this and has the opportunity to update its idea > of what's on the disk. How will it notice that it wasn't there before? The interpreter will see that it hasn't imported the module; it can't know whether it was there before while trying to resolve the import: when looking at a directory in sys.path, it needs to decide whether to use the directory cache or not. If the directory is not in the cache, it might be one of three things: a) the directory cache is out of date, and you should re-read the directory b) the module still isn't there, but is available in a later directory on sys.path (which hasn't yet been visited) c) the module isn't there at all, and the import will eventually fail. How can the interpreter determine which of these it is? 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] test_ucn fails for trunk on x86 Ubuntu Edgy
Grig Gheorghiu schrieb: > One of the Pybots buildslaves running x86 Ubuntu Edgy has been failing > the unit test step for the trunk, specifically the test_ucn test. Something is wrong with the machine. I forced a clean rebuild, and now it crashes in test_doctest2: http://www.python.org/dev/buildbot/community/all/x86%20Ubuntu%20Edgy%20trunk/builds/145/step-test/0 So either the compiler or some library has been updated in a strange way, or there is a hardware problem. One would need access to the machine to find out (and analyzing it is likely time-consuming). 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] valgrind
On 11/7/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Neal Norwitz schrieb: > > at 0x44FA06: Py_ADDRESS_IN_RANGE (obmalloc.c:1741) > > > > Note that the free is inside qsort. The memory freed under qsort > > should definitely not be the bases which we allocated under > > PyType_Ready. I'll file a bug report with valgrind to help determine > > if this is a problem in Python or valgrind. > > http://bugs.kde.org/show_bug.cgi?id=136989 > > As Tim explains, a read from Py_ADDRESS_IN_RANGE is fine, and by design. > If p is the pointer, we do Yeah, thanks for going over it again. I was tired and only half paying attention last night. Tonight isn't going much better. :-( I wonder if we can capture any of these exchanges and put into README.valgrind. I'm not about to do it tonight 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
