Hello,
I'm the submitter of the original patch and would like to help with it if I can.
> One issue that's not yet closed is #7245, which adds a (very nice IMO)
> feature: when you press Ctrl-C while the program being debugged runs,
> you will not get a traceback but execution is suspended, and y
ality is indeed useful and I am not missing some
serious side effects, would it be possible to review the patch?
Thanks,
Ilya Sandler
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Tue, 6 Mar 2007, [ISO-8859-1] "Martin v. L?wis" wrote:
> Yet, in all these years, nobody else commented that the patch was incomplete,
> let alone commenting on whether the feature was desirable.
Which actually brings up another point: in many cases even a simple
comment by a core developer
On Tue, 6 Mar 2007, Hans Meine wrote:
> Am Dienstag, 06. M?rz 2007 13:36 schrieb Martin v. L?wis:
> > #1115886 complains that in the file name '.cshrc', the
> > entire file name is treated as an extension, with no
> > root.
>
> The current behavior is clearly a bug, since a leading dot does not
On Mon, 17 Apr 2006, [ISO-8859-1] "Martin v. L?wis" wrote:
> > There is a patch on SourceForge
> > python.org/sf/721464
> > which allows pdb to read/write from/to arbitrary file objects. Would it
> > answer some of your concerns (eg remote debugging)?
> >
> > I guess, I could revive it if anyo
On Fri, 17 Feb 2006, Phillip J. Eby wrote:
> > d = {} # or dict()
> > d.default_factory = list
>
> Why not a classmethod constructor:
>
> d = dict.with_factory(list)
>
> But I'd rather set the default and create the
> dictionary in one operation, since when reading it as two, you first
> One thing PDB needs is a mode that runs as a background thread and
> opens up a socket so that another Python process can talk to it, for
> embedded/remote/GUI debugging.
There is a patch on SourceForge
python.org/sf/721464
which allows pdb to read/write from/to arbitrary file objects. Would
ficiencies)
Ilya
On Mon, 8 Aug 2005, Aahz wrote:
> On Sun, Aug 07, 2005, Ilya Sandler wrote:
> >
> > Solution:
> >
> > Should pdb's next command accept an optional numeric argument? It would
> > specify how many actual lines of code (not "line even
good idea to have the
same abbreviations
Ilya
Problem:
When the code contains list comprehensions (or for that matter any other
looping construct), the only way to get quickly through this code in pdb
is to set a temporary breakpoint on the line after the loop, which is
inconvenient..
There is a
On Sun, 7 Aug 2005, [ISO-8859-1] "Martin v. L?wis" wrote:
> Ilya Sandler wrote:
> > Should pdb's next command accept an optional numeric argument? It would
> > specify how many actual lines of code (not "line events")
> > should be skipped in the c
Problem:
When the code contains list comprehensions (or for that matter any other
looping construct), the only way to get quickly through this code in pdb
is to set a temporary breakpoint on the line after the loop, which is
inconvenient..
There is a SF bug report #1248119 about this behavior.
Good morning/evening/:
Here a few sourceforge bugs which can probably be closed:
[ 1168983 ] : ftplib.py string index out of range
Original poster reports that the problem disappeared after a patch
committed by Raymond
[ 1178863 ] Variable.__init__ uses self.set(), blocking specialization
seems
> (a) A higher-level API can and should be constructed which acts like a
> (binary) stream but has additional methods for reading and writing
> values using struct format codes (or, preferably, somewhat
> higher-level type names, as suggested). Instances of this API should
> be constructable from a
what inconvinient..
Ilya
On Sat, 8 Jan 2005, Nick Coghlan wrote:
> Ilya Sandler wrote:
> > item=unpack( "", rec, offset)
>
> How about making offset a standard integer, and change the signature to
> return a
> tuple when it is used:
>
>item = unp
NG) (where INT &c are objects defined in the
>struct module). This also then allows users to specify their own formats
>if they have a particular need for something
I don't disagree, but I think it's orthogonal to offset issue
Ilya
On Thu, 6 Jan 2005, Raymond Hettinger w
A problem:
The current struct.unpack api works well for unpacking C-structures where
everything is usually unpacked at once, but it
becomes inconvenient when unpacking binary files where things
often have to be unpacked field by field. Then one has to keep track
of offsets, slice the strings,cal
On Wed, 8 Dec 2004, Guido van Rossum wrote:
> One thing that bugs me: the article says 3 or 4 times that Python is
> slow, each time with a refutation ("but it's so flexible", "but it's
> fast enough") but still, they sure seem to harp on the point. This is
> a PR issue that Python needs to figh
17 matches
Mail list logo
