Re: [Python-Dev] PEP 553: Built-in debug()

On 2017-09-07 23:00:43 +, Barry Warsaw said: On Sep 7, 2017, at 14:25, Barry Warsaw wrote: I’ll see what it takes to add `header` to pdb.set_trace(), but I’ll do that as a separate PR (i.e. not as part of this PEP). Turns out to be pretty easy.

Re: [Python-Dev] PEP 553: Built-in debug()

On 2017-09-07 00:20:17 +, Barry Warsaw said: Thanks Fernando, this is exactly the kind of feedback from other debuggers that I’m looking for. It certainly sounds like a handy feature; I’ve found myself wanting something like that from pdb from time to time. Glad it's useful, thanks for

Re: [Python-Dev] PEP 553: Built-in debug()

If I may suggest a small API tweak, I think it would be useful if breakpoint() accepted an optional header argument. In IPython, the equivalent for non-postmortem debugging is IPython.embed, which can be given a header. This is useful to provide the user with some information about perhaps

Re: [Python-Dev] What if we didn't have repr?

On Tue, 21 May 2013 06:36:54 -0700, Guido van Rossum wrote: Actually changing __str__ or __repr__ is out of the question, best we can do is discourage makingbthem different. But adding a protocol for pprint (with extra parameters to convey options) is a fair idea. I note that Nick sggested to

Re: [Python-Dev] A panel with Guido/python-dev on scientific uses and Python 3 at Google HQ, March 2nd

On Tue, 21 Feb 2012 07:44:41 +, Fernando Perez wrote: I wanted to point out to you folks, and invite any of you who could make it in person, to a panel discussion we'll be having on Friday March 2nd, at 3pm, during the PyData workshop that will take place at Google's headquarters

[Python-Dev] A panel with Guido/python-dev on scientific uses and Python 3 at Google HQ, March 2nd

Oliphant, Peter Wang, Mark Wiebe, Stefan van der Walt (Numpy, Scipy) - John Hunter (Matplotlib) - Fernando Perez, Brian Granger, Min Ragan-Kelley (IPython) - Dag Sverre Seljebotn (Numpy, Cython) It would be great if as many core Python developers for whom a Bay Area Friday afternoon drive

Re: [Python-Dev] Inconsistent script/console behaviour

On Fri, 23 Sep 2011 16:32:30 -0700, Guido van Rossum wrote: You can't fix this without completely changing the way the interactive console treats blank lines. None that it's not just that a blank line is required after a function definition -- you also *can't* have a blank line *inside* a

Re: [Python-Dev] range objects in 3.x

On Tue, 27 Sep 2011 11:25:48 +1000, Steven D'Aprano wrote: The audience for numpy is a small minority of Python users, and they Certainly, though I'd like to mention that scientific computing is a major success story for Python, so hopefully it's a minority with something to contribute wink

Re: [Python-Dev] range objects in 3.x

On Thu, 29 Sep 2011 11:36:21 +1300, Greg Ewing wrote: I do hope, though, that the chosen name is *not*: - 'interval' - 'interpolate' or similar Would 'subdivide' be acceptable? I'm not great at finding names, and I don't totally love it, but I certainly don't see any problems with

Re: [Python-Dev] range objects in 3.x

On Sat, 24 Sep 2011 08:13:11 -0700, Guido van Rossum wrote: I expect that to implement a version worthy of the stdlib math module, i.e. that computes values that are correct within 0.5ULP under all circumstances (e.g. lots of steps, or an end point close to the end of the floating point

Re: [Python-Dev] nonlocal keyword in 2.x?

On Thu, 22 Oct 2009 12:32:37 -0300, Fabio Zadrozny wrote: Just as a note, the nonlocal there is not a requirement... You can just create a mutable object there and change that object (so, you don't need to actually rebind the object in the outer scope). E.g.: instead of creating a float

Re: [Python-Dev] PEP 389: argparse - new command line parsing module

On Sun, 27 Sep 2009 14:57:34 -0700, Brett Cannon wrote: I am going to state upfront that I am +1 for this and I encouraged Steven to submit this PEP on the stdlib-SIG. I still remember watching Steven's lightning talk at PyCon 2009 on argparse and being impressed by it (along with the rest of

[Python-Dev] Feedback from numerical/math community on PEP 225

regarding possible new operators in Python (PEP 225) = .. Author: Fernando Perez .. Contact: [EMAIL PROTECTED] .. Time-stamp: 2008-10-28 16:47:52 fperez .. Copyright: this document has been placed in the public domain. .. contents

Re: [Python-Dev] Documentation idea

Raymond Hettinger wrote: Bright idea -- Let's go one step further and do this just about everywhere and instead of putting it in the docs, attach an exec-able string as an attribute to our C functions. Further, those pure python examples should include doctests so that the user

Re: [Python-Dev] Matrix product

Guido van Rossum wrote: On Fri, Jul 25, 2008 at 6:50 PM, Greg Ewing [EMAIL PROTECTED] wrote: Sebastien Loisel wrote: What are the odds of this thing going in? I don't know. Guido has said nothing about it so far this time round, and his is the only opinion that matters in the end. I'd

Re: [Python-Dev] New Developer

Mark Dickinson wrote: Hello all, I've recently been granted commit privileges; so, following the usual protocol, here's a quick introduction. I'm a mathematician by day; my degree is in number theory, but five summers of Fortran 77 programming and two semesters of teaching numerical

Re: [Python-Dev] Pydoc Improvements / Rewrite

Ron Adam wrote: Laurent Gautier wrote: From the top of my head, there might be ipython (the excellent interactive console) is possibly using pydoc (in any case, I would say that the authors would be interested in developments with pydoc) Certainly :) I'd like to ask whether this

Re: [Python-Dev] inspect.py very slow under 2.5

Nick Coghlan wrote: I've updated the patch on SF, and committed the fix (including PJE's and Neal's comments) to the trunk. I'll backport it tomorrow night (assuming I don't hear any objections in the meantime :). I just wanted to thank you all for taking the time to work on this, even

[Python-Dev] inspect.py very slow under 2.5

Hi all, I know that the 2.5 release is extremely close, so this will probably be 2.5.1 material. I discussed it briefly with Guido at scipy'06, and he asked for some profile-based info, which I've only now had time to gather. I hope this will be of some use, as I think the problem is rather

Re: [Python-Dev] 2.5 and beyond

Thomas Heller wrote: I would like to ask about the possibility to add some improvements to ctypes in Python 2.5, although the feature freeze is now in effect. Hopefully former third-party libraries can have the freeze relaxed somewhat;-). I intend to do these changes, the first is a small

Re: [Python-Dev] Python sprint mechanics

Martin v. Löwis wrote: Tim Peters wrote: Since I hope we see a lot more of these problems in the future, what can be done to ease the pain? I don't know enough about SVN admin to know what might be realistic. Adding a pile of temporary committers comes to mind, but wouldn't really work

Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.

Hi all, Mateusz Rukowicz wrote: I wish to participate in Google Summer of Code as a python developer. I have few ideas, what would be improved and added to python. Since these changes and add-ons would be codded in C, and added to python-core and/or as modules,I am not sure, if you are

Re: [Python-Dev] [Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c

Martin v. Löwis wrote: M.-A. Lemburg wrote: Do you really think module authors do have a choice given that last sentence ? I really do. Most developers will not be confronted with 64-bit systems for several years to come. That current hardware supports a 64-bit mode is only one aspect:

Re: [Python-Dev] When do sets shrink?

Raymond Hettinger wrote: It might be better to give more generic advice that tends to be true across implementations and versions: Dense collections like lists tuples iterate faster than sparse structures like dicts and sets. Whenever repeated iteration starts to dominate application

Re: [Python-Dev] When do sets shrink?

Raymond Hettinger wrote: Was Guido's suggestion of s=set(s) unworkable for some reason? dicts and sets emphasize fast lookups over fast iteration -- apps requiring many iterations over a collection may be better off converting to a list (which has no dummy entries or empty gaps between

Re: [Python-Dev] a quit that actually quits

Walter Dörwald wrote: Alex Martelli wrote: On 12/28/05, Walter Dörwald [EMAIL PROTECTED] wrote: ... We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook? Sure, particularly with Nick's suggestion for a default input hook it would be fine. I'd like the inputhook to

Re: [Python-Dev] a quit that actually quits

Alex Martelli wrote: On Dec 28, 2005, at 3:24 AM, Michael Hudson wrote: The thing that bothers me about it is that the standard way you tell python to do something is call a function -- to me, a special case for exiting the interpreter seems out of proportion. Just brainstorming, but --

Re: [Python-Dev] a quit that actually quits

Steve Holden wrote: Except that if you have iPython installed on Windows you *don't* enter the platform EOF any more, you enter CTRL/D (which threw me for a while). To be fair, that's due to the win32 readline library used by ipython, which modifies console handling. IPython itself doesn't

Re: [Python-Dev] Conclusion: Event loops, PyOS_InputHook, and Tkinter

Michiel Jan Laurens de Hoon wrote: There are several other reasons why the alternative solutions that came up in this discussion are more attractive than IPython: 1) AFAICT, IPython is not intended to work with IDLE. Not so far, but mostly by accident. The necessary changes are fairly easy

Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter

Michiel Jan Laurens de Hoon wrote: For an extension module such as PyGtk, the developers may decide that PyGtk is likely to be run in non-interactive mode only, for which the PyGtk mainloop is sufficient. Did you read my reply? ipython, based on code.py, implements a few simple threading

Re: [Python-Dev] reference counting in Py3K

Josiah Carlson wrote: Fernando Perez [EMAIL PROTECTED] wrote: Would you care to elaborate on the reasons behind the 'ick'? I'm a big fan of weave.inline and have used it very successfully for my own needs, so I'm genuinely curious (as I tend to teach its use, I like to know of potential

Re: [Python-Dev] SWIG and rlcompleter

Michael Hudson wrote: [EMAIL PROTECTED] writes: You don't need something like a buggy SWIG to put non-strings in dir(). class C: pass ... C.__dict__[3] = bad wolf dir(C) [3, '__doc__', '__module__'] This is likely to happen legitimately, for instance in a class that allows x.y and

Re: [Python-Dev] SWIG and rlcompleter

Guido van Rossum wrote: (3) I think a better patch is to use str(word)[:n] instead of word[:n]. Mmh, I'm not so sure that's a good idea, as it leads to this: In [1]: class f: pass ...: In [2]: a=f() In [3]: a.__dict__[1] = 8 In [4]: a.x = 0 In [5]: a.TAB HIT HERE a.1 a.x In [5]: a.1

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

Martin v. Löwis wrote: Fred L. Drake, Jr. wrote: More interestingly, keeping it in a single repository makes it easier to merge projects, or parts of projects, together, without losing the history. This would be useful when developing packages that may be considered for the standard

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

Martin v. Löwis wrote: Fernando Perez wrote: For ipython, which recently went through cvs2svn, I found that moving over to a project/trunk structure was a few minutes worth of work. Since svn has moving commands, it was just a matter of making the extra project/ directory and moving

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

Martin v. Löwis wrote: Converting the CVS Repository = The Python CVS repository contains two modules: distutils and python. Keeping them together will produce quite long repository URLs, so it is more convenient if the Python CVS and the distutils CVS are

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

Tim Peters wrote: [Martin v. Löwis] The conversion should be done using cvs2svn utility, available e.g. in the cvs2svn Debian package. The command for converting the Python repository is [...] I'm sending this to Jim Fulton because he did the conversion of Zope Corp's code base to SVN.

[Python-Dev] A bug in pyconfig.h under Linux?

Hi all, sorry for posting to this list, but I'm not even 100% sure this is a bug. If it is, I'll gladly post it to SF if you folks want it there. I use scipy a lot, and the weave.inline component in there allows dynamic inclusion of C/C++ code in Python sources. In particular, it supports

Re: [Python-Dev] A bug in pyconfig.h under Linux?

Martin v. Lwis wrote: Fernando Perez wrote: sorry for posting to this list, but I'm not even 100% sure this is a bug. If it is, I'll gladly post it to SF if you folks want it there. This is not a bug. Most likely, sc_weave.cpp fails to meet the requirement documented in http

Re: [Python-Dev] Thoughts on stdlib evolvement

Josiah Carlson wrote: Fernando Perez wrote: I've wondered if it wouldn't be better if the std lib were all stuffed into its own namespace: from std import urllib If a more structured approach is desired, it could be from std.www import urllib This generally brings up

[Python-Dev] Re: Re: Re: Re: Patch review: [ 1094542 ] add Bunch type to collections module

Steven Bethard wrote: That sounds reasonable to me. I'll fix update to be a staticmethod. If people want other methods, I'll make sure they're staticmethods too.[1] Steve [1] In all the cases I can think of, staticmethod is sufficient -- the methods don't need to access any attributes

[Python-Dev] Re: Re: Patch review: [ 1094542 ] add Bunch type to collections module

Steven Bethard wrote: Fernando Perez [EMAIL PROTECTED] wrote: My feeling about this is that if the name of the attribute is held in a variable, you should be using a dict, not a Bunch/Struct. If you have a Bunch/Struct and decide you want a dict instead, you can just use vars: py b