Like everyone else, I am sorry to hear this news, and extend my sympathies.
It's marvellous that you are still able to work on Python at all, still.
Since you have to be careful not to do too much, you will just have to
choose your battles carefully. Thank you for your many contributions to
Python
https://bugs.python.org/issue15248 is about situations like the following:
>>> [(1,2,3)
(4,5,6)]
Traceback (most recent call last):
File "", line 2, in
(4,5,6)]
TypeError: 'tuple' object is not callable
The original poster requested that the error message be augmented with
something
If your primary concern is module clashes between plugins, maybe you
can hack around that:
1) if the plugins are providing copies of any other modules, then you
can simply require them to put them in their own namespace — that is,
a plug-in is a single package, with however many sub modules as it
On 2019-01-24, Terry Reedy wrote:
> Serhiy Storchaka suggested a compiler SyntaxWarning and uploaded a
> proof-of-concept diff that handled the above and many similar cases.
I believe that in general we should give better errors or warnings
if we can do it without huge difficulty. Serhiy's patch
In this case I agree that a SyntaxWarning is a good idea, per Serhiy's
patch. I would be even more conservative, and only warn if the first object
is a tuple -- the case of the missing comma in the original example appears
likely enough, but I don't expect people to write e.g. `[[1, 2], (3, 4)]`
ve
On Thu, Jan 24, 2019 at 04:01:26PM -0600, Neil Schemenauer wrote:
> On 2019-01-24, Terry Reedy wrote:
> > Serhiy Storchaka suggested a compiler SyntaxWarning and uploaded a
> > proof-of-concept diff that handled the above and many similar cases.
>
> I believe that in general we should give better
On Fri, Jan 25, 2019 at 9:42 AM Steven D'Aprano wrote:
> We could say that implementations are allowed to raise errors at compile
> time instead of run time, but aren't required to. Then it becomes a
> matter of "quality of implementation".
>
> For literal ints, strings, None, etc we can tell at c
On Thu, Jan 24, 2019 at 2:55 PM Chris Angelico wrote:
> On Fri, Jan 25, 2019 at 9:42 AM Steven D'Aprano
> wrote:
> > We could say that implementations are allowed to raise errors at compile
> > time instead of run time, but aren't required to. Then it becomes a
> > matter of "quality of implemen
>. There's nothing mysterious about e.g. `TypeError: unsupported operand
type(s) for +: 'int' and 'str'`, unlike the case of the two concatenated
tuples. (Surely people get errors about int+str all the time, and they've
never complained -- unlike the tuple tuple case.)
Well, yes, that particular e
On Thu, Jan 24, 2019 at 3:45 PM Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> >. There's nothing mysterious about e.g. `TypeError: unsupported operand
> type(s) for +: 'int' and 'str'`, unlike the case of the two concatenated
> tuples. (Surely people get errors about int+str all th
On 1/24/2019 6:16 PM, Eric V. Smith wrote:
On 1/24/2019 5:52 PM, Chris Angelico wrote:
+1. If it's something that the peephole optimizer is already allowed
to change (eg "1"+"1" is constant-folded) and there is absolutely no
way that it can ever be changed at run time, then raising at compile
ti
On 1/24/2019 5:52 PM, Chris Angelico wrote:
On Fri, Jan 25, 2019 at 9:42 AM Steven D'Aprano wrote:
We could say that implementations are allowed to raise errors at compile
time instead of run time, but aren't required to. Then it becomes a
matter of "quality of implementation".
For literal int
At the cost of breaking threading a bit, I'm going to reply to a few
different people in one post.
On Fri, Jan 25, 2019 at 09:52:53AM +1100, Chris Angelico wrote:
> On Fri, Jan 25, 2019 at 9:42 AM Steven D'Aprano wrote:
> > We could say that implementations are allowed to raise errors at compile
Chris Barker - NOAA Federal via Python-Dev writes:
> Well, yes, that particular example is pretty clear. But as a rule,
> there are a LOT of errors that can be pretty mysterious to newbies.
Isn't that the very definition of "newbie"? That's half a joke, but I
really don't think that programmer
14 matches
Mail list logo
