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.
https://bugs.python.org/issue31389
https
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
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 wher
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
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'
nel, including:
- Travis 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
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
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 probl
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
> te
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 ra
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 f
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
===
Discussion 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 pu
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 us
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
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 an
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 whe
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
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 seri
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
"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 re
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 wi
"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
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 run
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 en
Nick Coghlan wrote:
> As Fernando pointed out, anything else means we'd be well on our way to
> re-inventing IPython (although I'd be interested to know if sys.inputhook
> would have made IPython easier to write).
[sorry if this drifts off-topic for python-dev. I'll try to provide useful info
on
Fredrik Lundh wrote:
> Fernando Perez wrote:
>
>> In [1]: x='hello'
>>
>> In [2]: x?
> /.../
>> Docstring:
>> str(object) -> string
>>
>> Return a nice string representation of the object.
>> If the argument is a
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 lik
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
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 brainstorm
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
Josiah Carlson wrote:
> Or heck, if you are really lazy, people can use a plot() calls, but
> until an update_plot() is called, the plot isn't updated.
I really recommend that those interested in all these issues have a look at
matplotlib. All of this has been dealt with there already, a long ti
Michiel Jan Laurens de Hoon wrote:
> Fernando Perez wrote:
>>Did you read my reply? ipython, based on code.py, implements a few simple
>>threading tricks (they _are_ simple, since I know next to nothing about
>>threading) and gives you interactive use of PyGTK, WXPython an
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 tr
Jim Jewett wrote:
> (6) Mark Hammond suggests that it might be easier to
> replace the interactive portions of python based on the
> "code" module. matplotlib suggests using ipython
> instead of standard python for similar reasons.
>
> If that is really the simplest answer (and telling users
>
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
Josiah Carlson wrote:
> Here's a perspective "from the trenches" as it were.
>
> I've been writing quite a bit of code, initially all in Python (27k
> lines in the last year or so). It worked reasonably well and fast. It
> wasn't fast enough. I needed a 25x increase in performance, which would
>
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.
a.1 a.x
In [5]: a.1
-
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
Guido van Rossum wrote:
> (1) Please use the SF patch manager.
>
> (2) Please don't propose adding more bare "except:" clauses to the
> standard library.
>
> (3) I think a better patch is to use str(word)[:n] instead of word[:n].
Sorry to jump in, but this same patch was proposed for ipython, a
"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 makin
"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
>> sta
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
"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
"Martin v. Löwis" 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 fail
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 Blitz
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
>
Skip Montanaro wrote:
> I wouldn't mind a stdlib that defined a set of top-level packages (some of
> which might be wholly unpopulated by modules in the standard distribution)
> It might, for example, define a gui package and gui.Tkinter and gui._tkinter
> modules, leaving the remainder of gui nam
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 attr
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 c
Steven Bethard wrote:
> Fernando Perez wrote:
>> Steven Bethard wrote:
>> > I'm probably not willing to budge much on adding dict-style methods --
>> > if you want a dict, use a dict. But if people think they're
>> > necessary, there are a
Hi all,
Steven Bethard wrote:
> Alan Green <[EMAIL PROTECTED]> wrote:
>> Steven Bethard is proposing a new collection class named Bunch. I had
>> a few suggestions which I attached as comments to the patch - but what
>> is really required is a bit more work on the draft PEP, and then
>> discussio
52 matches
Mail list logo
