Re: [Python-Dev] pdb mini-sprint report and questions
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 you can debug from the current point of execution -- just like in gdb. However, there were apparently issues with some of the buildbots when the patch was applied for a short time. I also don't know how and if it works on Windows, so I'd need some helpful people testing it. For whatever it's worth, it worked for me with python trunk (2.x) on Vista, when I tried it manually. But I don't know how to implement the unit test there (subprocess module doesn't support sending SIGINT programmatically on windows either). So the test_pdb2 test does not check signal behavior on Windows platforms. Buildbot failures are still a total mystery for me ;-): the failures were happening elsewhere and seemed to be unrelated to test_pdb2. Is there any other way to apply the patch and run the tests on failing platforms? Ilya Another question is about a feature of pdb++ that I personally would like, but imagine would make others unhappy: one-letter abbreviations of commands such as c(ontinue) or l(ist) are also often-used variable names, so they are frequently typed without the required ! or print that would distinguish them from the command, and the command is actually executed. The feature in question would default to printing the variable in cases where one exists -- handy enough or too inconsistent? Also, are there any other features you would like to see? One feature of pdb++ that is general enough and has no dependencies would be watch expressions... Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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/ilya.sandler%40gmail.com ___ 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] Ctrl-C handling in pdb
I have used pdb for several years and have always wanted a gdb-like Ctrl-C handling: in gdb pressing Ctrl-C interrupts the program but the execution can be resumed later by the user (while pdb will terminate the program and throw you into postmortem debugging with no ability to resume the execution). So I implemented this functionality as http://bugs.python.org/issue7245. The patch is very simple: install a SIGINT handler and when SIGINT arrives, set the tracing. The signal handler is only activated when pdb is run as a script. I cann't think of any disadvantages. If this functionality 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: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
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 start an extension, but marks a file as hidden. It's not at all clear that current behaviour should be considered a bug . e.g, I think it's reasonable to expect that splitext( a+. + b) == (a, .b ) for any a,b which have no dots in them... The patch will break this assumption for empty a So, I'd classify dot files as a border case (either behaviour could be viewed as wrong/correct).. In which case backward compatibility should be the primary consideration IMHO Ilya Greetings, Hans ___ 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/ilya%40bluefir.net ___ 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] Encouraging developers
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: yes this feature is desirable might be of considerable value as it's likely to increase chances that some other developer will decide to spend time on the patch Similarly, some bug reports are for border cases. A confirmation by a core developer: yes, that needs fixing might encourage someone else to submit a patch... I'd also suggest that request for test cases/docs comes after (or together with) suggestion that a feature is desirable in the first place. Ilya 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/ilya%40bluefir.net ___ 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] remote debugging with pdb
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 anyone thinks that it's worthwhile...
I just looked at it, and yes, it's a good idea.
Ok, I'll look into it and submit as a new SF item (probably within 2-3
weeks)...
A question though: the patch will touch the code in many places and so
is likely to break other pdb patches which are in SF (e.g 1393667( restart
patch by rockyb) and 1267629('until' patch by me)). Any chance of getting
those accepted/rejected before remote debugging patch?
Thanks
Ilya
___
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] Proposal: defaultdict
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 think
'd is a dictionary', and then 'oh, but it has a default factory', as
opposed to d is a dict with a factory in one thought.
Also, class method would mean less typing (esp if dictionary name
happens to be longer than a couple of characters ;-)
But I'd like to suggest a different name:
d = dict.with_default( list)
Ilya
___
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] remote debugging with pdb
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 it answer some of your concerns (eg remote debugging)? The patch probably will not apply to the current code, but I guess, I could revive it if anyone thinks that it's worthwhile... What do you think? Ilya ___ 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] an alternative suggestion, Re: pdb: should next command be extended?
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 current frame before stopping, That would differ from gdb's next n, which does next n times. It would be confusing if pdb accepted the same command, but it meant something different. So, would implementing gdb's until command instead of next N be a better idea? In its simplest form (without arguments) until advances to the next (textually) source line... This would solve the original problem of getting over list comprehensions... There is a bit of a problem with abbreviation of until: gdb abbreviates it as u, while in pdb u means up...It might be a 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 SF bug report #1248119 about this behavior. On Sun, 7 Aug 2005, Ilya Sandler wrote: 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 current frame before stopping, [...] What do you think? That would differ from gdb's next n, which does next n times. It would be confusing if pdb accepted the same command, but it meant something different. But as far as I can tell, pdb's next is already different from gdb's next! gdb's next seem to always go to the different source line, while pdb's next may stay on the current line. The problem with next n meaning repeat next n times is that it seems to be less useful that the original suggestion. Any alternative suggestions to allow to step over list comprehensions and such? (SF 1248119) Plus, there is always a chance that current line+n is never reached, which would also be confusing. That should not be a problem, returning from the current frame should be treated as a stopping condition (similarly to the current next behaviour)... Ilya So I'm -1 here. 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/ilya%40bluefir.net ___ 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: should next command be extended?
At OSCON, Anthony Baxter made the point that pdb is currently one of the more unPythonic modules. What is unpythonic about pdb? Is this part of Anthony's presentation online? (Google found a summary and slides from presentation but they don't say anything about pdb's deficiencies) 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 events) should be skipped in the current frame before stopping, At OSCON, Anthony Baxter made the point that pdb is currently one of the more unPythonic modules. If you're feeling a lot of energy about this, rewriting pdb might be more productive. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. ___ 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] a few SF bugs which can (probably) be closed
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 like a dup of 1178872 [ 415492 ] Compiler generates relative filenames seems to have been fixed at some point. I could not reproduce it with python2.4 [ 751612 ] smtplib crashes Windows Kernal. Seems like an obvious Windows bug (not python's bug) and seems to be unreproducible Ilya ___ 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] an idea for improving struct.unpack api
I will try to respond to all comments at once.
But first a clarification:
-I am not trying to design a high-level API on top of existing
struct.unpack and
-I am not trying to design a replacement for struct.unpack
(If I were to replace struct.unpack(), then I would probably go along
the lines of StructReader suggested by Raymond)
I view struct module as a low-level (un)packing library on top on which
a more complex stuff can be built and I am simply suggesting a way to
improve this low level functionality...
We could have an optional offset argument for
unpack(format, buffer, offset=None)
the offset argument is an object which contains a single integer field
which gets incremented inside unpack() to point to the next byte.
As for passing offset implies the length is calcsize(fmt) sub-concept,
I find that slightly more controversial. It's convenient,
but somewhat ambiguous; in other cases (e.g. string methods) passing a
start/offset and no end/length means to go to the end.
I am not sure I agree: in most cases starting offset and no
length/end just means: start whatever you are doing at this offset and
stop it whenever you are happy..
At least that's the way I was alway thinking about functions like
string.find() and friends
Suggested struct.unpack() change seems to fit this mental model very well
the offset argument is an object which contains a single integer field
which gets incremented inside unpack() to point to the next byte.
I find this just too magical.
Why would it be magical? There is no guessing of user intentions involved.
The function simply returns/uses an extra piece of information if the user
asks for it. And the function already computes this piece of
information..
It's only useful when you're specifically unpacking data bytes that are
compactly back to back (no filler e.g. for alignment purposes)
Yes, but it's a very common case when dealing with binary files formats.
Eg. I just looked at xdrlib.py code and it seems that almost every
invocation of struct._unpack would shrink from 3 lines to 1 line of code
(i = self.__pos
self.__pos = j = i+4
data = self.__buf[i:j]
return struct.unpack('l', data)[0]
would become:
return struct.unpack('l', self.__buf, self.__pos)[0]
)
There are probably other places in stdlib which would benefit from this
api and stdlib does not deal with binary files that much..
and pays some conceptual price -- introducing a new specialized type
to play the role of mutable int
but the user does not have to pay anything if he does not need it! The
change is backward compatible. (Note that just supporting int offsets
would eliminate slicing, but it would not eliminate other annoyances,
and it's possible to support both Offset and int args, is it worth the
hassle?)
and having an argument mutated, which is not usual in Python's library.
Actually, it's so common that we simply stop noticing it :-)
Eg. when we call a superclass's method:
SuperClass.__init__(self)
So, while I agree that there is an element of unusualness in the
suggested unpack() API, this element seems pretty small to me
All in all, I suspect that something like.
hdrsize = struct.calcsize(hdr_fmt)
itemsize = struct.calcsize(item_fmt)
reclen = length_of_each_record
rec = binfile.read(reclen)
hdr = struct.unpack(hdr_fmt, rec, 0, hdrsize)
for offs in itertools.islice(xrange(hdrsize, reclen, itemsize),
hdr[0]):
item = struct.unpack(item_fmt, rec, offs, itemsize)
# process item
might be a better compromise
I think I again disagree: your example is almost as verbose as the current
unpack() api and you still need to call calcsize() explicitly and I
don't think there is any chance of gaining any noticeable
perfomance benefit. Too little gain to bother with any changes...
struct.pack/struct.unpack is already one of my least-favourite parts
of the stdlib. Of the modules I use regularly, I pretty much only ever
have to go back and re-read the struct (and re) documentation because
they just won't fit in my brain. Adding additional complexity to them
seems like a net loss to me.
Net loss to the end programmer? But if he does not need new
functionality he doesnot have to use it! In fact, I started with providing
an example of how new api makes client code simpler
I'd much rather specify the format as something like a tuple of values -
(INT, UINT, INT, STRING) (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 wrote:
[Ilya Sandler]
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
Re: [Python-Dev] an idea for improving struct.unpack api
How about making offset a standard integer, and change the signature to return tuple when it is used: item, offset = unpack(format, rec, offset) # Partial unpacking Well, it would work well when unpack results are assigned to individual vars: x,y,offset=unpack( ii, rec, offset) but it gets more complicated if you have something like: coords=unpack(10i, rec) How would you pass/return offsets here? As an extra element in coords? coords=unpack(10i, rec, offset) offset=coords.pop() But that would be counterintuitive and somewhat 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 = unpack(format, rec) # Full unpacking offset = 0 item, offset = unpack(format, rec, offset) # Partial unpacking The second item in the returned tuple being the offset of the first byte after the end of the unpacked item. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ 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/ilya%40bluefir.net ___ 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
