[Python-Dev] (try-except) conditional expression similar to (if-else) conditional (PEP 308)
I took a look at the options 1 and 2:
x = float(string) except float('nan') if ValueError
y = float(string) except ValueError: float('nan')
and I think this can be done just as easily with existing syntax:
x = try_1(float, string, except_ = float('nan'), if_ = ValueError)
y = try_2(float, string, { ValueError: float('nan') })
Here's the full example:
- example starts -
def try_1(func, *args, except_ = None, if_ = None):
try:
return func(*args)
except if_ as e:
return except_
def try_2(func, *args):
'The last argument is a dictionary {exception type: return value}.'
dic = args[-1]
try:
return func(*args[:-1])
except Exception as e:
for k,v in dic.items():
if isinstance(e, k):
return v
raise
for string in ['5', 'five']:
# x = float(string) except float('nan') if ValueError
x = try_1(float, string, except_ = float('nan'), if_ = ValueError)
# y = float(string) except ValueError: float('nan')
y = try_2(float, string, { ValueError: float('nan') })
print(x, y)
- example ends -
As a side note, if I just subscribed to python-dev, is it possible to
quote an old email? Below is my manual cut-and-paste quote:
-- my quote --
Nick Coghlan wrote:
> P.J. Eby wrote:
>> At 05:59 PM 8/5/2009 -0700, Raymond Hettinger wrote:
>>> [Jeffrey E. McAninch, PhD]
I very often want something like a try-except conditional expression
similar
to the if-else conditional.
An example of the proposed syntax might be:
x = float(string) except float('nan')
or possibly
x = float(string) except ValueError float('nan')
>>> +1 I've long wanted something like this.
>>> One possible spelling is:
>>>
>>> x = float(string) except ValueError else float('nan')
>> I think 'as' would be better than 'else', since 'else' has a different
>> meaning in try/except statements, e.g.:
>>
>>x = float(string) except ValueError, TypeError as float('nan')
>>
>> Of course, this is a different meaning of 'as', too, but it's not "as"
>> contradictory, IMO... ;-)
>
> (We're probably well into python-ideas territory at this point, but I'll
> keep things where the thread started for now)
>
> The basic idea appears sound to me as well. I suspect finding an
> acceptable syntax is going to be the sticking point.
>
> Breaking the problem down, we have three things we want to separate:
>
> 1. The expression that may raise the exception
> 2. The expression defining the exceptions to be caught
> 3. The expression to be used if the exception actually is caught
>
>>From there it is possible to come up with all sorts of variants.
>
> Option 1:
>
> Change the relative order of the clauses by putting the exception
> definition last:
>
> x = float(string) except float('nan') if ValueError
> op(float(string) except float('nan') if ValueError)
>
> I actually like this one (that's why I listed it first). It gets the
> clauses out of order relative to the statement, but the meaning still
> seems pretty obvious to me.
>
A further extension (if we need it):
result = foo(arg) except float('inf') if ZeroDivisionError else
float('nan')
The 'else' part handles any other exceptions (not necessarily a good idea!).
or:
result = foo(arg) except float('inf') if ZeroDivisionError else
float('nan') if ValueError
Handles a number of different exceptions.
> Option 2:
>
> Follow the lamba model and allow a colon inside this form of expression:
>
> x = float(string) except ValueError: float('nan')
> op(float(string) except ValueError: float('nan'))
>
> This has the virtue of closely matching the statement syntax, but
> embedding colons inside expressions is somewhat ugly. Yes, lambda
> already does it, but lambda can hardly be put forward as a paragon of
> beauty.
>
A colon is also used in a dict literal.
> Option 3a/3b:
>
> Raymond's except-else suggestion:
>
> x = float(string) except ValueError else float('nan')
> op(float(string) except ValueError else float('nan'))
>
[snip]
-1
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (try-except) conditional expression similar to (if-else) conditional (PEP 308)
I believe people now discuss this both on python-dev and python-ideas,
though since I'm new to both lists, I can't really tell where this
belongs.
I played a little with this syntax, my try_ function and @catch
decorator (which are at http://mit.edu/~unknot/www/try_cond.py):
# x = float(string) except float('nan') if ValueError
x = try_(float, string, except_ = float('nan'), if_ = ValueError)
@catch(ValueError = float('nan'))
def x1(): return float(string)
# y = float(string) except ValueError: float('nan')
y = try_(float, string, { ValueError: float('nan') })
@catch({ValueError: float('nan')})
def y1(): return float(string)
# try:
# z = open(string, 'r')
# except IOError as e:
# if e.errno == 2:
# z = 'not_exist'
# else:
# raise
#
z = try_(open, string, 'r', iocatcher({2: 'no file!'}))
@catch(iocatcher({2: 'nothing!'}))
def z1(): return open(string, 'r')
Here are my overall feelings:
(1) it would be interesting to come up with syntax for except/if
clause, but it's not obvious how to make one and this fact itself may
kill the idea.
(2) the more reasonable approach to things like this is by defining a
separate block and then performing a "catch" operation with it.
Unfortunately, this looks very clumsy as currently this can only be
done by defining a separate function. I think code blocks are a good
direction to explore.
2009/8/7 Kristján Valur Jónsson :
> Unless I am very much mistaken, this is the approach Ruby takes.
> Everything is an expression. For example, the value of a block is the value
> of
> The last expression in the block.
>
> I've never understood the need to have a distinction betwen statements and
> expressions, not when expressions can have side effects. It's like that
> differentce between procedures and functions in pascal that only serves to
> confuse
>
> K
>> -Original Message-
>> From: [email protected]
>> [mailto:[email protected]] On Behalf
>> Of Xavier Morel
>> Sent: 6. ágúst 2009 10:25
>> To: [email protected]
>> Subject: Re: [Python-Dev] (try-except) conditional expression similar
>> to (if-else) conditional (PEP 308)
>
>
>> Wouldn't it be smarter to fix the issue once and for all by looking
>> into making Python's compound statements (or even all statements
>> without restrictions) expressions that can return values in the first
>> place? Now I don't know if it's actually possible, but if it is the
>> problem becomes solved not just for try:except: (and twice so for
>> if:else:) but also for while:, for: (though that one's already served
>> pretty well by comprehensions) and with:.
>>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ilya.nikokoshev%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Concurrent.futures: no type discovery for PyCharm
I am using concurrent.futures to parallelize independent tasks on multiple cores once in a while. Each time I have a difficulty remembering the specific syntax and have to look it up in old code or google. I would much prefer to be able to find the source through the PyCharm and have autocompletion. It takes adding two lines to the __init__.py of concurrent.futures: (insert on line 19) from .process import ProcessPoolExecutor from .thread import ThreadPoolExecutor I would also guess that it would make the __getattr__ redundant? Am I missing something or can this change be done this way and would indeed be an improvement? Best Regards, -- Ilya Kamenshchikov ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Concurrent.futures: no type discovery for PyCharm
alright, so would an import under TYPE_CHECKING guard be an option? like: from typing import TYPE_CHECKING if TYPE_CHECKING: from .process import ProcessPoolExecutor from .thread import ThreadPoolExecutor Perhaps we can have both clarity and performance. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Concurrent.futures: no type discovery for PyCharm
How would we answer the same question if it was not a part of stdlib? I am not sure it is fair to expect of Pycharm to parse / execute the __getattr__ on modules, as more elaborate implementation could even contain different types per some condition at the runtime or anything at all. The code: TYPE_CHECKING = False if TYPE_CHECKING: from .process import ProcessPoolExecutor from .thread import ThreadPoolExecutor works for type checking in PyCharm and is fast. This is how stdlib can be an example to how side libraries can be implemented. If we can agree that this is the only clear, performant and sufficient code - then perhaps modifying mypy is a reasonable price to pay. Perhaps this particular case can be just patched locally by PyCharm /JetBrains, but what is a general solution to this class of problems? Best Regards, -- Ilya Kamenshchikov On Tue, Apr 23, 2019 at 7:05 PM Guido van Rossum wrote: > In any case I think this should be filed (by the OP) as an issue against > JetBrains' PyCharm issue tracker. Who knows they may be able to > special-case this in a jiffy. I don't think we should add any clever hacks > to the stdlib for this. > > On Tue, Apr 23, 2019 at 9:59 AM Nathaniel Smith wrote: > >> On Tue, Apr 23, 2019, 05:09 Andrew Svetlov >> wrote: >> >>> I agree that `from typing import TYPE_CHECKING` is not desirable from >>> the import time reduction perspective. >>> >>> From my understanding code completion *can* be based on type hinting >>> to avoid actual code execution. >>> That's why I've mentioned that typeshed already has the correct type >>> information. >>> >>> if TYPE_CHECKING: >>> import ... >>> >>> requires mypy modification. >>> >>> if False: >>> import ... >>> >>> Works right now for stdlib (mypy ignores stdlib code but uses typeshed >>> anyway) but looks a little cryptic. >>> Requires a comprehensive comment at least. >>> >> >> Last time I looked at this, I'm pretty sure `if False` broke at least one >> popular static analysis tool (ie it was clever enough to ignore everything >> inside `if False`) – I think either pylint or jedi? >> >> I'd suggest checking any clever hacks against at least: mypy, >> pylint/astroid, jedi, pyflakes, and pycharm. They all have their own static >> analysis engines, and each one has its own idiosyncratic quirks. >> >> We've struggled with this a *lot* in trio, and eventually ended up giving >> up on all forms of dynamic export cleverness; we've even banned the use of >> __all__ entirely. Static analysis has gotten good enough that users won't >> accept it not working, but it hasn't gotten good enough to handle anything >> but the simplest static exports in a reliable way: >> https://github.com/python-trio/trio/pull/316 >> https://github.com/python-trio/trio/issues/542 >> >> The stdlib has more leeway because when tools don't work on the stdlib >> then they tend to eventually add workarounds. I'm just saying, think twice >> before diving into clever hacks to workaround static analysis limits, and >> if you're going to do it then be careful to be thorough. You're basically >> relying on undocumented bugs, and it gets really messy really quickly. >> >> -n >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > > -- > --Guido van Rossum (python.org/~guido) > *Pronouns: he/him/his **(why is my pronoun here?)* > <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Concurrent.futures: no type discovery for PyCharm
Ok thanks for explaining. I will proceed by trying it with typeshed. Best Regards, -- Ilya Kamenshchikov On Tue, Apr 23, 2019 at 9:44 PM Ivan Levkivskyi wrote: > Mypy doesn't use source code of stlib for analysis and instead uses stub > files from typeshed. IIUC PyCharm can also do that (i.e. use the typeshed > stubs). > The whole idea of typeshed is to avoid changing stlib solely for the sake > of static analysis. Please open an issue on typeshed an/or PyCharm tracker. > > -- > Ivan > > > > On Tue, 23 Apr 2019 at 20:38, Ilya Kamenshchikov > wrote: > >> How would we answer the same question if it was not a part of stdlib? >> I am not sure it is fair to expect of Pycharm to parse / execute the >> __getattr__ on modules, as more elaborate implementation could even contain >> different types per some condition at the runtime or anything at all. >> The code: >> >> TYPE_CHECKING = False >> if TYPE_CHECKING: >> from .process import ProcessPoolExecutor >> from .thread import ThreadPoolExecutor >> >> works for type checking in PyCharm and is fast. >> >> This is how stdlib can be an example to how side libraries can be >> implemented. If we can agree that this is the only clear, performant and >> sufficient code - then perhaps modifying mypy is a reasonable price to pay. >> >> Perhaps this particular case can be just patched locally by PyCharm >> /JetBrains, but what is a general solution to this class of problems? >> >> Best Regards, >> -- >> Ilya Kamenshchikov >> >> >> On Tue, Apr 23, 2019 at 7:05 PM Guido van Rossum >> wrote: >> >>> In any case I think this should be filed (by the OP) as an issue against >>> JetBrains' PyCharm issue tracker. Who knows they may be able to >>> special-case this in a jiffy. I don't think we should add any clever hacks >>> to the stdlib for this. >>> >>> On Tue, Apr 23, 2019 at 9:59 AM Nathaniel Smith wrote: >>> >>>> On Tue, Apr 23, 2019, 05:09 Andrew Svetlov >>>> wrote: >>>> >>>>> I agree that `from typing import TYPE_CHECKING` is not desirable from >>>>> the import time reduction perspective. >>>>> >>>>> From my understanding code completion *can* be based on type hinting >>>>> to avoid actual code execution. >>>>> That's why I've mentioned that typeshed already has the correct type >>>>> information. >>>>> >>>>> if TYPE_CHECKING: >>>>> import ... >>>>> >>>>> requires mypy modification. >>>>> >>>>> if False: >>>>> import ... >>>>> >>>>> Works right now for stdlib (mypy ignores stdlib code but uses typeshed >>>>> anyway) but looks a little cryptic. >>>>> Requires a comprehensive comment at least. >>>>> >>>> >>>> Last time I looked at this, I'm pretty sure `if False` broke at least >>>> one popular static analysis tool (ie it was clever enough to ignore >>>> everything inside `if False`) – I think either pylint or jedi? >>>> >>>> I'd suggest checking any clever hacks against at least: mypy, >>>> pylint/astroid, jedi, pyflakes, and pycharm. They all have their own static >>>> analysis engines, and each one has its own idiosyncratic quirks. >>>> >>>> We've struggled with this a *lot* in trio, and eventually ended up >>>> giving up on all forms of dynamic export cleverness; we've even banned the >>>> use of __all__ entirely. Static analysis has gotten good enough that users >>>> won't accept it not working, but it hasn't gotten good enough to handle >>>> anything but the simplest static exports in a reliable way: >>>> https://github.com/python-trio/trio/pull/316 >>>> https://github.com/python-trio/trio/issues/542 >>>> >>>> The stdlib has more leeway because when tools don't work on the stdlib >>>> then they tend to eventually add workarounds. I'm just saying, think twice >>>> before diving into clever hacks to workaround static analysis limits, and >>>> if you're going to do it then be careful to be thorough. You're basically >>>> relying on undocumented bugs, and it gets really messy really quickly. >>>> >>>> -n >>>> ___ >>>> Python-Dev mailing list >>>> [email protected] >>>> https://mail.python.org/mailman/listinfo/python-dev >>>> Unsubscribe: >>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org >>>> >>> >>> >>> -- >>> --Guido van Rossum (python.org/~guido) >>> *Pronouns: he/him/his **(why is my pronoun here?)* >>> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> >>> >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/levkivskyi%40gmail.com >> > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] unittest.TestResult lacks API to separate subtests
Hello, We're developing Python IDE and integrated it with unittest module using TestResult <https://docs.python.org/3.4/library/unittest.html#unittest.TestResult> inheritor to track test start, end etc. With Py3K, it supports addSubTest method, that is called after all subtests. But there is no method called before and after _each_ subtest (like it is done for regular tests). With out of it I can't fetch each subtest output and display it correctly. I suggest to add subTestStart / subTestEnd methods to help me with my issue and other people with similar issues. I can send patch if you think this is a good idea. Ilya Kazakevich JetBrains <http://www.jetbrains.com/> http://www.jetbrains.com The Drive to Develop ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 3.5 unittest does not support namespace packages for discovering
Hello. I have following layout: \---tests | test_module.py | __init__.py When I launch "python.exe" -m unittest discover -t . -s tests" it works perfectly. But when I remove " __init__.py" it says Start directory is not importable: "tests'" ``loader.py``: if start_dir != top_level_dir: is_not_importable = not os.path.isfile(os.path.join(start_dir, '__init__.py')) I believe ``__init__.py`` does not play any role since Python 3.3, am I right? If so, it seems to be a bug. Should I create an issue? Ilya. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] reversed enumerate
Hi,
I needed reversed(enumerate(x: list)) in my code, and have discovered that
it wound't work. This is disappointing because operation is well defined.
It is also well defined for str type, range, and - in principle, but not
yet in practice - on dictionary iterators - keys(), values(), items() as
dictionaries are ordered now.
It would also be well defined on any user type implementing __iter__,
__len__, __reversed__ - think numpy arrays, some pandas dataframes, tensors.
That's plenty of usecases, therefore I guess it would be quite useful to
avoid hacky / inefficient solutions like described here:
https://code.activestate.com/lists/python-list/706205/.
If deemed useful, I would be interested in implementing this, maybe
together with __reversed__ on dict keys, values, items.
Best Regards,
--
Ilya Kamen
---
p.s.
*Sketch* of what I am proposing:
class reversible_enumerate:
def __init__(self, iterable):
self.iterable = iterable
self.ctr = 0
def __iter__(self):
for e in self.iterable:
yield self.ctr, e
self.ctr += 1
def __reversed__(self):
try:
ri = reversed(self.iterable)
except Exception as e:
raise Exception(
"enumerate can only be reversed if iterable to
enumerate can be reversed and has defined length."
) from e
try:
l = len(self.iterable)
except Exception as e:
raise Exception(
"enumerate can only be reversed if iterable to
enumerate can be reversed and has defined length."
) from e
indexes = range(l-1, -1, -1)
for i, e in zip(indexes, ri):
yield i, e
for i, c in reversed(reversible_enumerate("Hello World")):
print(i, c)
for i, c in reversed(reversible_enumerate([11, 22, 33])):
print(i, c)
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/NDDKDUDHE3J7SR7IPO3QXCVFSGE4BAV4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: reversed enumerate
Re: [email protected] > It isn't really well-defined, since enumerate can operate on infinite > iterators, and you cannot reverse an infinite stream. It is well defined on any iterable that itself is reversible and has defined length. For standard types that's lists, strings, dictionary iterators and some of the collections (deque, dictionary-based counter). Re: [email protected] > Could you please provide evidence that this feature would be quite > useful? How much usecases can you find in the stdlib? I needed this while solving a CS problem https://leetcode.com/problems/container-with-most-water/, which, I agree, does not tell how useful it is in production projects. Couldn't find any usecase in stdlib. I could find a usecase in scikit-learn: https://github.com/scikit-learn/scikit-learn/blob/master/sklearn/pipeline.py#L639 in case file gets changed, here is a copy: for i in reversed(range(len(estimators))): name = names[i] if name in namecount: names[i] += "-%d" % namecount[name] namecount[name] -= 1 It can indeed be that one doesn't have to reverse enumeration very often in practice. It can also be that people just express their ideas differently knowing it doesn't work in straight-forward way. Best Regards, -- Ilya Kamenshchikov ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/W26NX33MDJSDKKEEOWWYFMZN6UKTJUOK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python-Dev Digest, Vol 201, Issue 1
One potentially serious question: what should `enumerate.__reversed__`
> do when given a starting value?
> reversed(enumerate('abc', 1))
> Should that yield...?
> # treat the start value as a start value
> (1, 'c'), (0, 'b'), (-1, 'a')
> # treat the start value as an end value
> (3, 'c'), (2, 'b'), (1, 'a')
> Something else?
> My preference would be to treat the starting value as an ending value.
My idea is largely that as long as any iterable has defined length and
order, it should be reversible, and this should yield the same as if I did
this reverse countdown with some pointer.
It just so happens that `enumerate` depends fully in this regard on the
iterable it enumerates, if it has defined length, then enumerate will also
have defined length. Maybe enumerate should also start defining `len`
whenever underlying iterable supports it.
Regarding the starting value, I think it is important to keep symmetry:
enumerate('abc', 1) is [ (1, 'a'), (2, 'b'), (3, 'c') ], therefore
reversed(enumerate('abc', 1)) should be [(3, 'c'), (2, 'b'), (1, 'a')]
Best Regards,
--
Ilya Kamen
On Thu, Apr 2, 2020 at 5:55 AM wrote:
> Send Python-Dev mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-Dev digest..."
>
> Today's Topics:
>
>1. Re: reversed enumerate (Steven D'Aprano)
>2. Re: [Python-ideas] Re: reversed enumerate (Andrew Barnert)
>3. Re: [Python-ideas] Re: reversed enumerate (Andrew Barnert)
>
>
> --
>
> Date: Thu, 2 Apr 2020 13:20:02 +1100
> From: Steven D'Aprano
> Subject: [Python-Dev] Re: reversed enumerate
> To: [email protected]
> Cc: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Ilya,
>
> I'm not sure that this mailing list (Python-Dev) is the right place for
> this discussion, I think that Python-Ideas (CCed) is the correct place.
>
> For the benefit of Python-Ideas, I have left your entire post below, to
> establish context.
>
> [Ilya]
> > I needed reversed(enumerate(x: list)) in my code, and have discovered
> > that it wound't work. This is disappointing because operation is well
> > defined.
>
> It isn't really well-defined, since enumerate can operate on infinite
> iterators, and you cannot reverse an infinite stream. Consider:
>
> def values():
> while True:
> yield random.random()
>
> a, b = reversed(enumerate(values())
>
> What should the first pair of (a, b) be?
>
> However, having said that, I think that your idea is not unreasonable.
> `enumerate(it)` in the most general case isn't reversable, but if `it`
> is reversable and sized, there's no reason why `enumerate(it)` shouldn't
> be too.
>
> My personal opinion is that this is a fairly obvious and straightforward
> enhancement, one which (hopefully!) shouldn't require much, if any,
> debate. I don't think we need a new class for this, I think enhancing
> enumerate to be reversable if its underlying iterator is reversable
> makes good sense.
>
> But if you can show some concrete use-cases, especially one or two from
> the standard library, that would help your case. Or some other languages
> which offer this functionality as standard.
>
> On the other hand, I think that there is a fairly lightweight work
> around. Define a helper function:
>
> def countdown(n):
> while True:
> yield n
> n -= 1
>
> then call it like this:
>
> # reversed(enumerate(seq))
> zip(countdown(len(seq)-1), reversed(seq)))
>
> So it isn't terribly hard to work around this. But I agree that it would
> be nice if enumerate encapsulated this for the caller.
>
> One potentially serious question: what should `enumerate.__reversed__`
> do when given a starting value?
>
> reversed(enumerate('abc', 1))
>
> Should that yield...?
>
> # treat the start value as a start value
> (1, 'c'), (0, 'b'), (-1, &#
[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 [email protected] 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 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 > [email protected] > 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 [email protected] 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 > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ilya%40bluefir.net > ___ Python-Dev mailing list [email protected] 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 > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ilya%40bluefir.net > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 news reaches interesting places
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 fight -- any ideas?
>
On PR side of the issue one idea would be to avoid using the words
interpreted/intepreter less and use the
words compiler/byte-compilation/virtual machine instead...
On non-PR side of the issue (I do think that python slowness is a real
problem for at least some people/domains): would
bundling of Psyco with Python be a good idea?
Ilya
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] an idea for improving struct.unpack api
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,call struct.calcsize(), etc...
Eg. with a current api unpacking of a record which consists of a
header followed by a variable number of items would go like this
hdr_fmt=""
item_fmt=""
item_size=calcsize(item_fmt)
hdr_size=calcsize(hdr_fmt)
hdr=unpack(hdr_fmt, rec[0:hdr_size]) #rec is the record to unpack
offset=hdr_size
for i in range(hdr[0]): #assume 1st field of header is a counter
item=unpack( item_fmt, rec[ offset: offset+item_size])
offset+=item_size
which is quite inconvenient...
A solution:
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.
so with a new API the above code could be written as
offset=struct.Offset(0)
hdr=unpack("", offset)
for i in range(hdr[0]):
item=unpack( "", rec, offset)
When an offset argument is provided, unpack() should allow some bytes to
be left unpacked at the end of the buffer..
Does this suggestion make sense? Any better ideas?
Ilya
___
Python-Dev mailing list
[email protected]
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,
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
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ilya%40bluefir.net
>
___
Python-Dev mailing list
[email protected]
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
> (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 stream or from a "buffer" (e.g. a string).
Ok, I think it's getting much bigger than what I was initially aiming for
;-)...
One more comment though regarding unpack_at
> Then the definition would be:
>
> def unpack_at(fmt, buf, pos):
> size = calcsize(fmt)
> end = pos + size
> data = buf[pos:end]
> if len(data) < size:
> raise struct.error("not enough data for format")
> ret = unpack(fmt, data)
> ret = ret + (end,)
> return ret
While I see usefulness of this, I think it's a too limited, eg.
result=unpack_at(fmt,buf, offset)
offset=result.pop()
feels quite unnatural...
So my feeling is that adding this new API is not worth the trouble.
Especially if there are plans for anything higher level...
Instead, I would suggest that even a very limited initial
implementation of StructReader() like object suggested by Raymond would
be more useful...
class StructReader: #or maybe call it Unpacker?
def __init__(self, buf):
self._buf=buf
self._offset=0
def unpack(self, format):
"""unpack at current offset, advance internal offset
accordingly"""
size=struct.calcize(format)
self._pos+=size
ret=struct.unpack(format, self._buf[self._pos:self._pos+size)
return ret
#or may be just make _offset public??
def tell(self):
"return current offset"
return self._offset
def seek(self, offset, whence=0):
"set current offset"
self._offset=offset
This solves the original offset tracking problem completely (at least as
far as inconvenience is concerned, improving unpack() perfomance
would require struct reader to be written in C) , while allowing to add
the rest later.
E.g the original "hdr+variable number of data items" code would
look:
buf=StructReader(rec)
hdr=buf.unpack("")
for i in range(hdr[0]):
item=buf.unpack( "")
Ilya
PS with unpack_at() this code would look like:
offset=0
hdr=buf.unpack("", offset)
offset=hdr.pop()
for i in range(hdr[0]):
item=buf.unpack( "",offset)
offset=item.pop()
On Sat, 8 Jan 2005, Guido van Rossum wrote:
> First, let me say two things:
>
> (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 stream or from a "buffer" (e.g. a string).
>
> (b) -1 on Ilya's idea of having a special object that acts as an
> input-output integer; it is too unpythonic (no matter your objection).
>
> [Paul Moore]
> > OTOH, Nick's idea of returning a tuple with the new offset might make
> > your example shorter without sacrificing readability:
> >
> > result, newpos = struct.unpack('>l', self.__buf, self.__pos)
> > self.__pos = newpos # retained "newpos" for readability...
> > return result
>
> This is okay, except I don't want to overload this on unpack() --
> let's pick a different function name like unpack_at().
>
> > A third possibility - rather than "magically" adding an additional
> > return value because you supply a position, you could have a "where am
> > I?" format symbol (say & by analogy with the C "address of" operator).
> > Then you'd say
> >
> > result, newpos = struct.unpack('>l&', self.__buf, self.__pos)
> >
> > Please be aware, I don't have a need myself for this feature - my
> > interest is as a potential reader of others' code...
>
> I think that adding more magical format characters is probably not
> doing the readers of this code a service.
>
> I do like the idea of not introducing an extra level of tuple to
> accommodate the position return value but instead make it the last
> item in the tuple when using unpack_at().
>
> Then the definition would be:
>
> def unpack_at(fmt, buf, pos):
> size = calcsize(fmt)
> end = pos + size
> data = buf[pos:end]
> if len(data) < size:
> raise struct.error("not enough data for format")
> # if data is too long that would be a bug in buf[pos:size] and
> cause an error below
> ret = unpack(fmt, data)
> ret = ret + (end,)
> return ret
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
___
Python-Dev mailing list
[email protected]
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 [email protected] 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
[email protected]
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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] pdb: should next command be extended?
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. 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, i.e "next 5" would mean stop when line>=line_where_next_N_happened+5 is reached. This would allow to easily get over/out of loops in the debugger What do you think? Ilya ___ Python-Dev mailing list [email protected] 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?
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 ", 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 " 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 > +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 [email protected] 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 ", 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 ", 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 " 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 > > +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 > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ilya%40bluefir.net > ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
