Re: [Python-Dev] segfault (double free?) when '''-string crosses line
Tim Peters wrote: #ifdef __VMS extern char* vms__StdioReadline(FILE *sys_stdin, FILE *sys_stdout, char *prompt); #endif may be (it's apparently not checked in, and Google couldn't find it either). Does anyone still work on the VMS port? If not, screw it ;-) I would have no concerns with breaking the VMS port. If it is broken, we will either receive patches, or it stays broken. 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] segfault (double free?) when '''-string crosses line
Jean-François Piéronne wrote: I (and a few others guys) work on the VMS port,also, HP has publish in the VMS technical journal an article about Python on VMS. What do you need? In the specific case: an answer to Tim Peter's question (where is vms__StdioReadline, and how can its memory allocator be changed, and why is it not checked into the Python source tree?) I would have no concerns with breaking the VMS port. If it is broken, we will either receive patches, or it stays broken. Why, there is world outside Windows, I have concerns with breaking the VMS port, we can send patches but the last one was still on hold. Basically because of lack of maintenance. Can you please remind me what patch is still on hold? Searching for open patches with VMS in their summary gives no matches. Does Python 2.5a1 even build on VMS, out of the box (i.e. without additional patches?) 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] PSF Contributor Agreement for pysqlite
Posting here because I don't know a better place: Federico di Gregorio and me have both faxed PSF contributor agreements to the PSF for integration of pysqlite into Python 2.5. -- Gerhard ___ 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] PSF Contributor Agreement for pysqlite
Gerhard Häring wrote: Posting here because I don't know a better place: Federico di Gregorio and me have both faxed PSF contributor agreements to the PSF for integration of pysqlite into Python 2.5. Thanks! I should make the list of names of people available somewhere which have signed the agreement, so that committers can check each time whether the is available. 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] PSF Contributor Agreement for pysqlite
As far as I know, I've never signed one. I probably should, or is there some grandfathering rule for people who've been contributing from before the new agreement came in? ___ 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] PSF Contributor Agreement for pysqlite
Anthony Baxter wrote: As far as I know, I've never signed one. I probably should, or is there some grandfathering rule for people who've been contributing from before the new agreement came in? No - those people will have to fill out the agreement covering past contributions also: http://www.python.org/psf/contrib-form-python.html And yes, you are right - you haven't filed one, so far. 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] need info for externally maintained modules PEP
Brett Cannon wrote: OK, I am going to write the PEP I proposed a week or so ago, listing all modules and packages within the stdlib that are maintained externally so we have a central place to go for contact info or where to report bugs on issues. This should only apply to modules that want bugs reported outside of the Python tracker and have a separate dev track. People who just use the Python repository as their mainline version can just be left out. For each package I need the name of the module, the name of the maintainer, homepage of the module outside of Python, and where to report bugs. Do people think we need to document the version that has been imported into Python and when that was done as well? Anyway, here is a list of the packages that I think have outside maintenance (or at least have been at some point). Anyone who has info on them that I need, please let me know the details. Also, if I missed any, obviously speak up: - bsddb (still external?) - sqlite - ctypes Maintainer: Thomas Heller Homepage: http://starship.python.net/crew/theller/ctypes/ Where to report bugs: I do not care. I'll try to keep track of both the python bug tracker and the ctypes tracker on the SF pages. 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] PSF Contributor Agreement for pysqlite
On Tuesday 11 April 2006 00:56, Martin v. Löwis wrote: No - those people will have to fill out the agreement covering past contributions also: http://www.python.org/psf/contrib-form-python.html And yes, you are right - you haven't filed one, so far. Righto - I will try to get to this sometime this week. Is it worth sending out emails to as many people as can be found to try to rustle up more of these? It's unclear to me just how important these are to the state of Python. ___ 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 assignedabug/patch
Brett Cannon wrote: Can someone (Martin, Barry?) post this on python.org (I don't think this necessarily needs to be put into svn and I don't have any access but svn) so Fredrik can free up the space on his server? Did I ever respond to that? I put the file on http://svn.python.org/snapshots/ 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] PSF Contributor Agreement for pysqlite
Anthony Baxter wrote: Righto - I will try to get to this sometime this week. Is it worth sending out emails to as many people as can be found to try to rustle up more of these? It's unclear to me just how important these are to the state of Python. I think I twice mailed everybody in Misc/ACKS. In principle, we want to have agreements from everybody who ever contributed, so that we can formally change the license (and so that it is clear to Python users what the legal standing is). Some Python users really begged the PSF to get this process started; they were happy when it did get started. If you want to ping people: sure; I can send you the list of forms received so far. 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] PEP 302 support for traceback, inspect, site, warnings, doctest, and linecache
Here's my plan for implementing PEP 302 support (``__loader__`` sensitivity) for the above modules: * Change all of the ``linecache`` API functions (except ``clearcache()``) to add an optional ``module_globals`` argument, which they will use to obtain the ``__name__`` and ``__loader__`` in the event that the given filename doesn't exist, but appears to be the source file for the given module. (That is, if the basename of the filename is consistent with the last part of the ``__name__`` in the module_globals, if ``sys.modules[__name__].__dict__ is module_globals``, and the ``__loader__`` (if any) in module_globals has a ``get_source()`` method.) * Change ``inspect.getsourcefile()`` to return the source path as long as the object's module has a ``__loader__`` with a ``get_source()`` method. This will ensure that other ``inspect`` functions will still try to load the source code for the object in question, even if it's in a zipfile or loaded by some other import mechanism. * Change ``inspect.findsource()`` to pass the target object's module globals as an extra argument to ``linecache.getlines()`` * Change the ``traceback`` module to supply frame globals to the ``linecache`` APIs it uses. * Change the ``site`` module to not absolutize ``__file__`` attributes of modules with ``__loader__`` attributes; ``__loader__`` objects are responsible for their own ``__file__`` values. (Actually, if this is desirable behavior, the builtin import machinery should be doing it, not site.py!) * Add an optional ``module_globals`` argument to ``warnings.warn_explicit()``, which will be passed through to ``linecache.getlines()`` if the warning is not ignored. (This will prime the line cache in case the warning is to be output.) * Change ``warnings.warn()`` to pass the appropriate globals to ``warn_explicit()``. * Change ``doctest.testfile()`` and ``DocTestSuite`` to use the target module's ``__loader__.get_data()`` method (if available) to load the given doctest file. * Change ``__patched_linecache_getlines()`` in ``doctest`` to accept an optional ``module_globals`` argument, to be passed through to the original ``getlines()`` function. I'm starting work on the above now. If I finish early enough today, I'll follow up with plans for fixing ``pydoc``, which requires slightly more extensive surgery, since it doesn't even support packages with multiple ``__path__`` entries yet, let alone PEP 302. Please let me know if you have any questions or concerns. ___ 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] need info for externally maintained modules PEP
Brett Cannon wrote: OK, I am going to write the PEP I proposed a week or so ago, listing all modules and packages within the stdlib that are maintained externally so we have a central place to go for contact info or where to report bugs on issues. Based on the recent interchange regarding VMS, perhaps you should add port maintainers to that PEP as well. 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
[Python-Dev] DRAFT: python-dev summary for 2006-02-01 to 2006-02-15
Sorry about the delay folks. Here's the summary for the first half of February. I'm going to try to get the ones out for the second half of February and first half of March shortly. Please send me any comments/corrections! = Announcements = - QOTF: Quotes of the Fortnight - We had a plethora (yes, I did just say plethora) of quotable quotes this fortnight. Martin v. Löwis on the `lambda keyword`_: I believe that usage of a keyword with the name of a Greek letter also contributes to people considering something broken. Raymond Hettinger on the `learnability of Python`_: A language suitable for beginners should be easy to learn, but it should not leave them permanently crippled... To misquote Einstein: The language should be as simple as possible, but no simpler. Robert Brewer on `Pythonic syntax`_: Community consensus on syntax is a pipe dream. .. _lambda keyword: http://mail.python.org/pipermail/python-dev/2006-February/060389.html .. _learnability of Python: http://mail.python.org/pipermail/python-dev/2006-February/060420.html .. _Pythonic syntax: http://mail.python.org/pipermail/python-dev/2006-February/060556.html [SJB] Release plan for 2.5 `PEP 356`_ lists the release plan for Python 2.5. Check it out for the latest feature updates and planned release dates. .. _PEP 356: http://www.python.org/dev/peps/pep-0356/ Contributing threads: - `release plan for 2.5 ? http://mail.python.org/pipermail/python-dev/2006-February/060493.html`__ - `2.5 release schedule http://mail.python.org/pipermail/python-dev/2006-February/060982.html`__ - `2.5 PEP http://mail.python.org/pipermail/python-dev/2006-February/060985.html`__ [SJB] lsprof available as cProfile Armin Rigo finished his integration of the lsprof profiler. It's now available as the cProfile module which exposes the same interface as profile. Contributing thread: - `cProfile module http://mail.python.org/pipermail/python-dev/2006-February/060479.html`__ [SJB] - ssize_t branch merged - Martin v. Löwis merged in the ssize_t branch (`PEP 353`_). All you folks on 64 bit machines should now be able to index sequences using your full address space. Enjoy! .. _PEP 353: http://www.python.org/dev/peps/pep-0353/ Contributing threads: - `ssize_t status (Was: release plan for 2.5 ?) http://mail.python.org/pipermail/python-dev/2006-February/060714.html`__ - `ssize_t branch (Was: release plan for 2.5 ?) http://mail.python.org/pipermail/python-dev/2006-February/060810.html`__ - `ssize_t branch merged http://mail.python.org/pipermail/python-dev/2006-February/061073.html`__ [SJB] = Summaries = -- Rumors of lambda's death have been greatly exaggerated -- Guido's finally given in -- the lambda expression will stay in Python 3.0. Of course, this didn't stave off another massively long thread discussing the issue, but Guido finally killed that by providing a pretty exhaustive list of why we should keep lambda as it is: * No purely `syntactic change to lambda`_ is clearly a net gain over the current syntax * It's perfectly fine that Python's lambda is different from Lisp's * Lambda current binding behavior is (correctly) exactly the same as a def statement * Allowing a block inside a lambda is never going to work because of the need to indent the block .. _syntactic change to lambda: http://wiki.python.org/moin/AlternateLambdaSyntax Contributing threads: - `any support for a methodcaller HOF? http://mail.python.org/pipermail/python-dev/2006-February/060341.html`__ - `Let's just *keep* lambda http://mail.python.org/pipermail/python-dev/2006-February/060415.html`__ - `Let's send lambda to the shearing shed (Re: Let's just *keep* lambda) http://mail.python.org/pipermail/python-dev/2006-February/060583.html`__ [SJB] -- The bytes type -- Guido asked for an update to `PEP 332`_, which proposed a ``bytes`` type. This spawned a massive discussion about what the bytes type should look like and how it should interact with strings, especially in Python 3.0 when all strings would be unicode. Pretty much everyone agreed that bytes objects should be mutable sequences of ints in the range(0, 256). Guido and others were also generally against a b'...' literal for bytes, as that would confusingly suggest that bytes objects were text-like, which they wouldn't be. There was a fair bit of haggling over the signature of the bytes constructor, but it seemed towards the end of the discussion that people were coming to an agreement on ``bytes(initializer [,encoding])``, where ``initializer`` could be a sequence of ints or a str or unicode instance, and where ``encoding`` would be an
[Python-Dev] Failing inspect test: test_getargspec_sublistofone
I seem to recall some Python-dev discussion about this particular behavior, but can't find it in Google. Is this test currently known to be failing? If so, why, and what's the plan for it? ___ 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] PSF Contributor Agreement for pysqlite
On Mon, 10 Apr 2006, Martin v. Löwis wrote: I think I twice mailed everybody in Misc/ACKS. In principle, we want to have agreements from everybody who ever contributed, so that we can formally change the license (and so that it is clear to Python users what the legal standing is). [...] Not sure if it's just me, but I'm in that list, and I'm pretty sure I neither received an email nor faxed a contributor agreement (and my email address hasn't changed for years). John___ 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] pdb segfaults in 2.5 trunk?
Is anybody else getting this? Python 2.5a1 (trunk:45237, Apr 10 2006, 15:25:33) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type help, copyright, credits or license for more information. import pdb def x(): ... if 'a' in 'b': ... pass ... pdb.run(x()) string(1)module() (Pdb) s --Call-- stdin(1)x() (Pdb) s stdin(2)x() (Pdb) s Segmentation fault It usually happens within a few 's' operations in pdb. ___ 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] pdb segfaults in 2.5 trunk?
On 4/10/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Is anybody else getting this?
Neal had originally reported that test_trace failed with a segfault,
and it's essentially exercising the same code. I don't see a failure
there or here at the moment. If there is a bug, though, it's likely
to be in the line number table that the new compiler generates.
Python 2.5a1 (trunk:45237, Apr 10 2006, 15:25:33)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type help, copyright, credits or license for more information.
import pdb
def x():
... if 'a' in 'b':
... pass
...
pdb.run(x())
string(1)module()
(Pdb) s
--Call--
stdin(1)x()
(Pdb) s
stdin(2)x()
(Pdb) s
Segmentation fault
It usually happens within a few 's' operations in pdb.
def x():
... if 'a' in 'b':
... pass
...
[34945 refs]
pdb.run('x()')
string(1)module()-None
(Pdb) s
--Call--
stdin(1)x()
(Pdb) s
--Return--
stdin(1)x()-None
(Pdb) s
--Return--
string(1)module()-None
(Pdb) s
[35023 refs]
[35023 refs]
[11168 refs]
Will try with a non-debug build soon.
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] pdb segfaults in 2.5 trunk?
4On 4/10/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
On 4/10/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Is anybody else getting this?
Neal had originally reported that test_trace failed with a segfault,
and it's essentially exercising the same code. I don't see a failure
there or here at the moment. If there is a bug, though, it's likely
to be in the line number table that the new compiler generates.
Python 2.5a1 (trunk:45237, Apr 10 2006, 15:25:33)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type help, copyright, credits or license for more information.
import pdb
def x():
... if 'a' in 'b':
... pass
...
pdb.run(x())
string(1)module()
(Pdb) s
--Call--
stdin(1)x()
(Pdb) s
stdin(2)x()
(Pdb) s
Segmentation fault
It usually happens within a few 's' operations in pdb.
def x():
... if 'a' in 'b':
... pass
...
[34945 refs]
pdb.run('x()')
string(1)module()-None
(Pdb) s
--Call--
stdin(1)x()
(Pdb) s
--Return--
stdin(1)x()-None
(Pdb) s
--Return--
string(1)module()-None
(Pdb) s
[35023 refs]
[35023 refs]
[11168 refs]
Will try with a non-debug build soon.
I don't see it in a non-debug build either.
Python 2.5a1 (trunk:43632M, Apr 10 2006, 15:41:31)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type help, copyright, credits or license for more information.
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] pdb segfaults in 2.5 trunk?
On 4/10/06, Phillip J. Eby [EMAIL PROTECTED] wrote: Is anybody else getting this? stdin(2)x()(Pdb) s Segmentation faultI'm not able to reproduce this in 32bit or 64bit mode (debian unstable.) Does 'make distclean' before configure/compile fix it? If not, can you unlimit coredumpsize and check to see what it crashes on? -- 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] PSF Contributor Agreement for pysqlite
John J Lee wrote: On Mon, 10 Apr 2006, Martin v. Löwis wrote: I think I twice mailed everybody in Misc/ACKS. In principle, we want to have agreements from everybody who ever contributed, so that we can formally change the license (and so that it is clear to Python users what the legal standing is). [...] Not sure if it's just me, but I'm in that list, and I'm pretty sure I neither received an email nor faxed a contributor agreement (and my email address hasn't changed for years). Ah, ok. I misremembered - I only mailed the committers at the time. I *meant* to contact everybody in Misc/ACKS, but never got to do so. 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] pdb segfaults in 2.5 trunk?
Phillip J. Eby wrote: Is anybody else getting this? I can't reproduce this, on Debian, gcc 4.0.3, trunk:45237. 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] pdb segfaults in 2.5 trunk?
At 09:47 PM 4/10/2006 +0200, Thomas Wouters wrote: On 4/10/06, Phillip J. Eby mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote: Is anybody else getting this? stdin(2)x() (Pdb) s Segmentation fault I'm not able to reproduce this in 32bit or 64bit mode (debian unstable.) Does 'make distclean' before configure/compile fix it? Nope. If not, can you unlimit coredumpsize and check to see what it crashes on? #0 0x401bbaa4 in _int_free () from /lib/libc.so.6 #1 0x401baa3c in free () from /lib/libc.so.6 #2 0x080a253e in builtin_raw_input (self=0x0, args=0x4050862c) at Python/bltinmodule.c:1759 It appears the problem is an object/mem mismatch: both PyOS_Readline in pgenmain.c, and PyOS_StdioReadline use PyObject_MALLOC, but bltinmodule.c is freeing the pointer with PyMem_FREE. Just to add to the confusion, by the way, the readline module dynamically sets PyOS_ReadlineFunctionPointer to call_readline, which does its allocation with PyMem_MALLOC... So does anybody know what the protocol should be for readline functions? What about readline implementations that are in the field, so to speak? (e.g. modules that use the readline hook to implement that functionality using something other than GNU readline). ___ 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] pdb segfaults in 2.5 trunk?
On 4/10/06, Phillip J. Eby [EMAIL PROTECTED] wrote: It appears the problem is an object/mem mismatch: both PyOS_Readline in pgenmain.c, and PyOS_StdioReadline use PyObject_MALLOC, but bltinmodule.c is freeing the pointer with PyMem_FREE. This (Readline using PyObject) was due to my recent change to fix Guido's problem last night. I didn't realize anything seeped out. All calls to PyOS_StdioReadline would need to be updated. I can do that tonight. Hmm, that means this will be an API change. I wonder if I should revert my fix and just deal with a second alloc and copy of the data to fix Guido's original problem. 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] pdb segfaults in 2.5 trunk?
[Phillip J. Eby] ... #0 0x401bbaa4 in _int_free () from /lib/libc.so.6 #1 0x401baa3c in free () from /lib/libc.so.6 #2 0x080a253e in builtin_raw_input (self=0x0, args=0x4050862c) at Python/bltinmodule.c:1759 It appears the problem is an object/mem mismatch: both PyOS_Readline in pgenmain.c, and PyOS_StdioReadline use PyObject_MALLOC, That wasn't true yesterday, but Neal changed it while you slept ;-). He changed it to worm around a different case of object/mem mismatch. but bltinmodule.c is freeing the pointer with PyMem_FREE. Just to add to the confusion, by the way, the readline module dynamically sets PyOS_ReadlineFunctionPointer to call_readline, which does its allocation with PyMem_MALLOC... So does anybody know what the protocol should be for readline functions? What about readline implementations that are in the field, so to speak? (e.g. modules that use the readline hook to implement that functionality using something other than GNU readline). It's documented (after a fashion) at the declaration of PyOS_ReadlineFunctionPointer. Yesterday that read: /* By initializing this function pointer, systems embedding Python can override the readline function. Note: Python expects in return a buffer allocated with PyMem_Malloc. */ char *(*PyOS_ReadlineFunctionPointer)(FILE *, FILE *, char *); Overnight, PyMem_Malloc there changed to PyObject_Malloc. It didn't matter in practice before (2.5) because all PyXYZ_ABC ways to spell free the memory resolved to PyObject_Free. Now that PyMem_ and PyObject_ call different things, mismatches are deadly. Since the only docs we had said PyMem_Malloc must be used for the readline function, best to stick with that. It's messy, though (there are a lot of functions that think they're in charge of freeing the memory, and the memory can originally come from a lot of places). ___ 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] updating PyExpat (Was: need info for externally maintained modules PEP)
[Martin v. Loewis wrote] Brett Cannon wrote: - expat Not sure whether you mean the Expat parser proper here, or the pyexpat module: both are externally maintained, also; pyexpat is part of PyXML. OTOH, people can just consider PyXML to be part of Python, and I synchronize the Python sources with the PyXML sources from time to time. I was going to be updating Modules/expat/... to Expat 2.0 relatively soon. Must I then go via the PyXML folks to do this update then or can I checkin to Python's SVN directly? Trent -- Trent Mick [EMAIL PROTECTED] ___ 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] Failing inspect test: test_getargspec_sublistofone
On 4/10/06, Phillip J. Eby [EMAIL PROTECTED] wrote: I seem to recall some Python-dev discussion about this particular behavior, but can't find it in Google. Is this test currently known to be failing? If so, why, and what's the plan for it? Only failing for 2.4 IIRC: http://python.org/sf/1459159 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] pdb segfaults in 2.5 trunk?
On 4/10/06, Tim Peters [EMAIL PROTECTED] wrote: It's documented (after a fashion) at the declaration of PyOS_ReadlineFunctionPointer. Yesterday that read: /* By initializing this function pointer, systems embedding Python can override the readline function. Note: Python expects in return a buffer allocated with PyMem_Malloc. */ char *(*PyOS_ReadlineFunctionPointer)(FILE *, FILE *, char *); Overnight, PyMem_Malloc there changed to PyObject_Malloc. It didn't matter in practice before (2.5) because all PyXYZ_ABC ways to spell free the memory resolved to PyObject_Free. Now that PyMem_ and PyObject_ call different things, mismatches are deadly. Since the only docs we had said PyMem_Malloc must be used for the readline function, best to stick with that. It's messy, though (there are a lot of functions that think they're in charge of freeing the memory, and the memory can originally come from a lot of places). Shouldn't it at least match call_readline() in Modules/readline.c, which uses PyMem_Malloc()? Also, since it's really a char array, I don't see the point of using something with Object in its name. -- --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] updating PyExpat (Was: need info for externally maintained modules PEP)
Trent Mick wrote: I was going to be updating Modules/expat/... to Expat 2.0 relatively soon. Must I then go via the PyXML folks to do this update then or can I checkin to Python's SVN directly? Please check in directly. I'm going to update PyXML some time. 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] pdb segfaults in 2.5 trunk?
[Guido] Shouldn't it at least match call_readline() in Modules/readline.c, which uses PyMem_Malloc()? I'm not sure what it means there, but, like I said, it's messy regardless. That's why we ended up with a large number of mismatches to begin with: there are many allocation and free'ing sites, spread over several modules, and these don't follow nice patterns. call_readline() is just one of the ways the memory might be allocated to begin with, and they can all end up on the same lines of code that try to free memory. Also, since it's really a char array, I don't see the point of using something with Object in its name. The PyObject_ memory family is generally faster and more memory-efficient for small allocations than the PyMem_ memory family. Lines of source code, and encoding strings, are usually small enough to exploit that. The ob in obmalloc.c doesn't really have anything to do with objects either. PyMem_SmallMalloc (etc) may have been better names (although I doubt that ;-)). ___ 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] Who understands _ssl.c on Windows?
[Tim Peters wrote] Trent (and anyone else who wants to play along), what happens if you do this by hand in a current trunk or 2.4 build?: import socket s = socket.socket() s.settimeout(30.0) s.connect((gmail.org, 995)) On my box (when gmail.org:995 responds at all), the connect succeeds in approximately 0.03 seconds, giving 29.97 seconds to spare ;-) C:\trentm\src\python\python\PCbuildpython_d Python 2.5a1 (trunk, Apr 10 2006, 14:48:00) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import socket [25133 refs] s = socket.socket() [25145 refs] s.settimeout(30.0) [25145 refs] s.connect((gmail.org, 995)) [25145 refs] Sorry that I took so long to run this. It is a little unfortunate that with the last build step being clean, I couldn't just cd into the build directory and try to run this. Seems like that was a good thing that I did take so long because it passed in the most recent build :) http://www.python.org/dev/buildbot/trunk/x86%20W2k%20trunk/builds/371/step-test/0 Can you identify a reason for why it times out on the Win2K buildbot? (beats me -- firewall issue, DNS sloth, ...?) It is possible that this was due to network changes that we are doing at work here. We are preparing for an office move in a couple of weeks (http://blogs.activestate.com/activestate/2006/02/free_as_in_will.html). My eyes glaze over whenever the systems dudes mention VPN, SSH, DNS, VMWare, sub-domains and DHCP in the same breath. Trent -- Trent Mick [EMAIL PROTECTED] ___ 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] Who understands _ssl.c on Windows?
On 4/10/06, Trent Mick [EMAIL PROTECTED] wrote: Sorry that I took so long to run this. It is a little unfortunate that with the last build step being clean, I couldn't just cd into the build directory and try to run this. Maybe we should clean before we configure/compile? That would leave the last build in tact until the next run. 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] I'm not getting email from SF when assignedabug/patch
On 4/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Brett Cannon wrote: Can someone (Martin, Barry?) post this on python.org (I don't think this necessarily needs to be put into svn and I don't have any access but svn) so Fredrik can free up the space on his server? Did I ever respond to that? I put the file on Nope. Thanks for doing this. I am in the middle of final projects for school so I probably won't get to writing the rough draft of the call for trackers until after the 23rd. -Brett http://svn.python.org/snapshots/ 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] need info for externally maintained modules PEP
On 4/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Brett Cannon wrote: OK, I am going to write the PEP I proposed a week or so ago, listing all modules and packages within the stdlib that are maintained externally so we have a central place to go for contact info or where to report bugs on issues. Based on the recent interchange regarding VMS, perhaps you should add port maintainers to that PEP as well. I think that should be a separate PEP. But I do agree that it would be good info to have. -Brett ___ 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] Who understands _ssl.c on Windows?
[Neal Norwitz wrote] On 4/10/06, Trent Mick [EMAIL PROTECTED] wrote: Sorry that I took so long to run this. It is a little unfortunate that with the last build step being clean, I couldn't just cd into the build directory and try to run this. Maybe we should clean before we configure/compile? That would leave the last build in tact until the next run. Sure. Have to make sure that it doesn't choke on the bootstrapping problem: the first time there is no Makefile with which to call make clean. Then again, maybe it is a good thing that one is discouraged from poking around in a buildbot build tree (potentially leaving turds that taint future builds). Thoughts? Trent -- Trent Mick [EMAIL PROTECTED] ___ 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] DRAFT: python-dev summary for 2006-03-01 to 2006-03-15
Ok, if I summarize any more of python-dev, my brain's going to explode. ;-) Here's the summaries for the first half of March. Let me know what to fix! = Announcements = --- Webstats for python.org --- Thomas Wouters set up webalizer on dinsdale.python.org and added webstats for all subsites of python.org: * http://www.python.org/webstats/ * http://beta.python.org/webstats/ * http://bugs.python.org/webstats/ * http://planet.python.org/webstats/ * http://docs.python.org/webstats/ * http://svn.python.org/webstats/ Check 'em out if you're interested! Contributing thread: - `Webstats for www.python.org et al. http://mail.python.org/pipermail/python-dev/2006-March/061930.html`__ [SJB] --- Python 2.5 release schedule --- The first releases scheduled for Python 2.5 are quickly approaching. Check `PEP 356`_ for details, but the first alpha is due on April 1st. .. _PEP 356: http://www.python.org/doc/peps/pep-0356/ Contributing thread: - `2.5 release schedule? http://mail.python.org/pipermail/python-dev/2006-March/062185.html`__ [SJB] --- Py3K branch --- Guido has begun work on Py3K, starting a new branch to rip out some stuff like string exceptions and classic classes. He's trying to get a feel for what Python 3.0 will look like, hopefully before his keynote in OSCON. Contributing thread: - `Py3k branch - please stay out :-) http://mail.python.org/pipermail/python-dev/2006-March/062396.html`__ [SJB] --- Deprecated modules going away in Python 2.5 --- A number of deprecated modules will be removed in Python 2.5, including: * reconvert.py * regex (regexmodule.c) * regex_syntax.py * regsub.py and a variety of things from lib-old. These modules have been deprecated for a while now, and will be pulled in the next Python release. Contributing thread: - `Deprecated modules going away in 2.5 http://mail.python.org/pipermail/python-dev/2006-March/062405.html`__ [SJB] = Summaries = --- Maintaining ctypes in SVN trunk --- Thomas Heller put ctypes into the Python SVN repository, and with the help of perky, Neal Norwitz and Thomas Wouters, updated it to take advantage of the new ssize_t feature. Thomas Heller has now moved the official ctypes development to the Python SVN. Contributing threads: - `ctypes is in SVN now. http://mail.python.org/pipermail/python-dev/2006-March/062211.html`__ - `Developing/patching ctypes (was: Re: integrating ctypes into python) http://mail.python.org/pipermail/python-dev/2006-March/062243.html`__ - `Developing/patching ctypes http://mail.python.org/pipermail/python-dev/2006-March/062244.html`__ [SJB] - Windows buildbots - Josiah Carlson had been working on getting a buildbot slave running on a Windows box, but eventually gave up due to crashes caused by VS.NET. Tim Peters fought his way through the setup with a XP box, posting `his lessons`_ to the wiki, and Trent Mick managed to follow a similar route and setup a Win2K buildbot slave. Thanks to all who suffered through the config -- Windows buildbot coverage looks pretty good now! .. _his lessons: http://wiki.python.org/moin/BuildbotOnWindows Contributing threads: - `Another Windows buildbot slave http://mail.python.org/pipermail/python-dev/2006-March/062068.html`__ - `Still looking for volunteer to run Windows buildbot http://mail.python.org/pipermail/python-dev/2006-March/062267.html`__ [SJB] --- Python 3.0: itr.next() or next(itr) --- The end of last fortnight's defaultdict thread turned to discussing the fate of the iterator protocol's .next() method in Python 3.0. Greg Ewing argued that renaming .next() to .__next__() and introducing a builtin function next() would be more consistent with the other magic methods and also more future-proof, since the next() function could be modified if the protocol method needed to change. Raymond Hettinger was very strongly against this proposal, suggesting that trading a Python-level attribute lookup for a Python-level global lookup plus a C-level slot lookup was not a good tradeoff. The discussion then spread out to other protocol method/function pairs -- e.g. len() and __len__() -- and Oleg Broytmann suggested that they could all be replaced with methods, thus saving a lookup and clearing out the builtin namespace. Neil Schemenauer and Michael Chermside argued against such a change, saying that the double-underscore pattern allows new special methods to be introduced without worrying about breaking user code, and that using functions for protocols forces developers to use the same names when the protocols are involved, while using methods could allow some developers to choose different
Re: [Python-Dev] Who understands _ssl.c on Windows?
[Trent] C:\trentm\src\python\python\PCbuildpython_d Python 2.5a1 (trunk, Apr 10 2006, 14:48:00) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import socket [25133 refs] s = socket.socket() [25145 refs] s.settimeout(30.0) [25145 refs] s.connect((gmail.org, 995)) [25145 refs] Sorry that I took so long to run this. It is a little unfortunate that with the last build step being clean, I couldn't just cd into the build directory and try to run this. Seems like that was a good thing that I did take so long because it passed in the most recent build :) http://www.python.org/dev/buildbot/trunk/x86%20W2k%20trunk/builds/371/step-test/0 Excellent! Thanks to the buildbot's blamelist, we can definitely conclude that your Win2K box's problem was cured by Andrew checking in a change to whatsnew25.tex. Works for me :-) ... It is possible that this was due to network changes that we are doing at work here. We are preparing for an office move in a couple of weeks (http://blogs.activestate.com/activestate/2006/02/free_as_in_will.html). My eyes glaze over whenever the systems dudes mention VPN, SSH, DNS, VMWare, sub-domains and DHCP in the same breath. Ya, life will get a lot better if you leave the sysadmins behind ;-) Good luck with the move and the heady wine of corporate independence, BTW -- and be sure to visit the old folks on holidays. ___ 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] Who understands _ssl.c on Windows?
[Neal Norwitz] Maybe we should clean before we configure/compile? That would leave the last build in tact until the next run. It doesn't matter much to me -- I do all changes and checkins from a non-buildbot checkout. The one thing I like about the current scheme is that when I run my daily incremental backup, I don't have to wait on backing up mounds of stale .pyc and .pyd files left from the last buildbot run. In fact, that reminds me I added a delete all the .pyc files step to the Windows buildbot clean.bat precisely so I didn't have to burn time and space backing up 1600 stale files each day. So -0 on changing. ___ 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] Who understands _ssl.c on Windows?
[Tim Peters wrote] In fact, that reminds me I added a delete all the .pyc files step to the Windows buildbot clean.bat precisely so I didn't have to burn time and space backing up 1600 stale files each day. So -0 on changing. Good enough for me. Let's not bother. Trent -- Trent Mick [EMAIL PROTECTED] ___ 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] pdb segfaults in 2.5 trunk?
Tim Peters wrote: The PyObject_ memory family is generally faster and more memory-efficient for small allocations than the PyMem_ memory family. Lines of source code, and encoding strings, are usually small enough to exploit that. The ob in obmalloc.c doesn't really have anything to do with objects either. PyMem_SmallMalloc (etc) may have been better names (although I doubt that ;-)). However, if they're not exclusively for objects, having Object in the name would seem to be highly confusing, perhaps dangerously so. (Person A writes PyObject_Alloc(some_chars), Person B writing the code to free it thinks What??? That can't be right! and uses PyMem_Free.) -- 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] pdb segfaults in 2.5 trunk?
[Greg Ewing]
However, if they're not exclusively for objects,
having Object in the name would seem to be
highly confusing, perhaps dangerously so. (Person
A writes PyObject_Alloc(some_chars), Person B
writing the code to free it thinks What???
That can't be right! and uses PyMem_Free.)
Given that it's been this way since the PyObject_ memory family was
introduced, and a real Person B hasn't posted to complain about being
led into temptation yet, sorry, I don't take this argument seriously.
The comments in objimpl.h tell the truth, and it's really quite
simple:
For allocating objects, use PyObject_{New, NewVar} instead whenever
possible. The PyObject_{Malloc, Realloc, Free} family is exposed
so that you can exploit Python's small-block allocator for non-object
uses. If you must use these routines to allocate object memory, make sure
the object gets initialized via PyObject_{Init, InitVar} after obtaining
the raw memory.
___
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
