On Fri, Apr 26, 2019 at 12:17:57AM -0400, Terry Reedy wrote:
> On 4/25/2019 7:12 PM, Greg Ewing wrote:
> >Steven D'Aprano wrote:
> >>I too often forget that reverse() returns an iterator,
>
> I presume you mean reversed(). list.reverse() is a list
Yes, I meant reversed(), not list.reverse() whic
On Fri, Apr 26, 2019 at 11:12:51AM +1200, Greg Ewing wrote:
> Steven D'Aprano wrote:
> >I too often forget that reverse() returns an iterator,
>
> That seems like a mistake. Shouldn't it return a view?
I don't know what it "should" or "shouldn't" it return, but it actually
does return an iterato
On 4/25/2019 7:12 PM, Greg Ewing wrote:
Steven D'Aprano wrote:
I too often forget that reverse() returns an iterator,
I presume you mean reversed(). list.reverse() is a list
That seems like a mistake. Shouldn't it return a view?
RL = reversed(somelist) is already partly view-like. The nt
> On 26 Apr 2019, at 05:47, Ram Rachum wrote:
>
> Ah, I thought about it now and Ned is right. This would require modifications
> to ceval.c and others.
Pity!
> The question is... Does anyone else think it's a good idea?
I do. It seems to me that coverage is a very useful tool that shouldn
On Thu, Apr 25, 2019 at 1:51 PM Ivan Levkivskyi
wrote:
> TBH, I don't think it is so bad that it requires a new syntax. But I am
> not strongly against it either. What I would like to add here is that if we
> will go with the replacement:
>
> Callable[[X, Y], Z] becomes (X, Y) -> Z
>
> then we sh
> On 26 Apr 2019, at 00:41, Peter O'Connor wrote:
>
> - Defaults are defined in multiple places, which very easily leads to bugs
> (I'm aware of **kwargs but it obfuscates function interfaces and usually does
> more harm than good)
> - Types are defined in multiple places
> - Documentation is
Ah, I thought about it now and Ned is right. This would require
modifications to ceval.c and others.
The question is... Does anyone else think it's a good idea?
On Fri, Apr 26, 2019 at 12:31 AM Ned Batchelder
wrote:
> It wouldn't be difficult to have a list of trace functions, so that every
> l
Ivan Levkivskyi wrote:
> Callable[[X, Y], Z] becomes (X, Y) -> Z
> Union[X, Y] becomes X | Y
> Tuple[X, Y] becomes (X, Y)
> Optional[X] becomes X?
> (Intersection[X, Y] when added becomes X & Y)
>
I really like this idea, but I could also see this getting a bit confusing
because the syntax prece
On Thu, Apr 25, 2019 at 6:42 PM Peter O'Connor
wrote:
> Despite the general beauty of Python, I find myself constantly violating
> the "don't repeat yourself" maxim when trying to write clear, fully
> documented code. Take the following example:
>
You do know that OPTIONAL type annotations are
Guido van Rossum wrote:
Also, some groups of people would like to see a more concise notation
for lambdas, and maybe they'd want to write
x = (a, b) -> a + b
We probably can't have both,
I think we could if we wanted to. In an annotation, -> could be treated
as sugar for Callable[], and in o
Steven D'Aprano wrote:
I too often forget that reverse() returns an iterator,
That seems like a mistake. Shouldn't it return a view?
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Steven D'Aprano wrote:
But having the opening bracket auto-added is a small satisfaction, and
if you're using the REPL for actual calculations and not just help(),
the benefit probably outweighs the annoyance
The completer could detect the help( as well and leave out
the opening paren in that
Looks like a more complicated way to say :
def f(x:'int : which does stuff' = 5, y:'int : which does more stuffs')
The code reading the annotations (like the linter) might then parse it
simply using .split.
robertvandeneynde.be
Le ven. 26 avr. 2019 à 00:41, Peter O'Connor a
écrit :
> Dear all
On Fri, Apr 26, 2019 at 8:42 AM Peter O'Connor
wrote:
>
> Dear all,
>
> Despite the general beauty of Python, I find myself constantly violating the
> "don't repeat yourself" maxim when trying to write clear, fully documented
> code. Take the following example:
>
> def func_1(a: int = 1, b:
Dear all,
Despite the general beauty of Python, I find myself constantly violating
the "don't repeat yourself" maxim when trying to write clear, fully
documented code. Take the following example:
def func_1(a: int = 1, b: float = 2.5) -> float:
"""
Something about func_1
It wouldn't be difficult to have a list of trace functions, so that
every line of "real" Python executed, would invoke all the trace
functions. But Ram has asked for something more: when the first trace
function is executing, its line should themselves be traced by the
remaining trace function
TBH, I don't think it is so bad that it requires a new syntax. But I am not
strongly against it either. What I would like to add here is that if we
will go with the replacement:
Callable[[X, Y], Z] becomes (X, Y) -> Z
then we should also go with
Union[X, Y] becomes X | Y
Tuple[X, Y] becomes (X,
Well, it would trigger the top level chaining trace function, but they should
be able to decide when to call the sub-trace functions. Hmm... Maybe :)
> On 25 Apr 2019, at 19:16, Ned Batchelder wrote:
>
> Perhaps I misunderstand what's implied by "simple(!) monkeypatch of
> sys.settrace", but t
To clarify, I meant that each trace function would manually call any trace
functions that were registered below it, instead of using the trampoline in
cpython. Does that solve the problem you raised?
On Thu, Apr 25, 2019, 20:20 Ned Batchelder wrote:
> Perhaps I misunderstand what's implied by "s
Perhaps I misunderstand what's implied by "simple(!) monkeypatch of
sys.settrace", but the trickiest part of Ram's proposal is that the body
of one trace function would still trigger the remaining trace
functions. That to me sounds like it's going to require changes to ceval.c
--Ned.
On 4/25
Hmm, looks like, for this to work, you'll need the existing tracer to be
cooperative. Right now there are existing tracers, for example coverage's
tracer and Wing IDE's tracer, and I would need to modify them for your idea
to work, right?
If I understand your idea correctly, the first tracer would
Oh wow, I didn't even consider that. I think you're right, I'll do more
thinking about this. Thanks Anders!
On Thu, Apr 25, 2019 at 6:10 PM Anders Hovmöller
wrote:
> Can't this be implemented today by a simple monkey patch of sys.settrace?
>
> On 25 Apr 2019, at 16:51, Ram Rachum wrote:
>
> Hi,
Can't this be implemented today by a simple monkey patch of sys.settrace?
> On 25 Apr 2019, at 16:51, Ram Rachum wrote:
>
> Hi,
>
> Here's something I want in Python: Multiple levels of tracers working on top
> of each other, instead of just one.
>
> I'm talking about the tracer that one can
Hi,
Here's something I want in Python: Multiple levels of tracers working on
top of each other, instead of just one.
I'm talking about the tracer that one can set by calling sys.settrace.
I've recently released PySnooper: https://github.com/cool-RR/PySnooper/
One of the difficulties I have, is
My two cents as well.
I also find the open parenthesis very annoying. For me, it's asymmetry
with PyCharm behavior, and inconsistency with bash.
PyCharm adds the parenthesis, but also adds the end parenthesis, so
the whole use of parentheses is consistent: the user has not to worry
about them.
Bas
This is an interesting thread. Here's my two cents worth. (Colloquial US
English for a low-value opinion.)
I'm in favour of sensible defaults (of course). In this situation, perhaps
this means defaults that work well for those who would find it difficult to
select a different default. Put enough w
On 25/04/2019 12:27, Stephen J. Turnbull wrote:
Steven D'Aprano writes:
> But having the opening bracket auto-added is a small satisfaction,
I'm not going to weigh in on this feature: I can see it either way.
What I don't get is why we don't go full metal Emacs, by adding the
corresponding en
Steven D'Aprano writes:
> But having the opening bracket auto-added is a small satisfaction,
I'm not going to weigh in on this feature: I can see it either way.
What I don't get is why we don't go full metal Emacs, by adding the
corresponding end delimiter, and backspace. In each line below the
On Fri, Apr 19, 2019 at 05:12:06PM -0300, Danilo J. S. Bellini wrote:
> I'm not aware if that was already discussed, but something I find quite
> annoying is the REPL auto-complete that also includes the open parenthesis
> symbol. I think it shouldn't be included in TAB completion. At least twice
On Fri, Apr 19, 2019 at 09:49:54PM +0200, Sebastian M. Ernst wrote:
> Hi everyone,
>
> many methods in `os` have a `dir_fd` parameter, for instance `unlink` [1]:
> ```python
> os.unlink(path, *, dir_fd=None)
> ```
>
> The `dir_fd` parameter [2] allows it to describe paths relative to
> directory
On Wed, Apr 24, 2019 at 01:50:48AM +0800, Thautwarm Zhao wrote:
> However, the reason why we don't need list.rindex but do for str.rindex is
> simple I'd say: str is immutable and has no O(1) reverse method.
>
> On the other hand, when it comes to list, you can use list.index after
> list.reverse
31 matches
Mail list logo
