I have recently been talking to friends/colleagues about their reasons
for not using python for large projects (say from a thousand lines of
code and with at least three people contributing). One of the problems
that comes up time and again is the difficulty in debugging python
code and in particular the simple sounding job of catching typos. One
specific suggestion is the following.
Make variable declaration compulsory. For example.
var foo = 15
[...]
var foo = 10
should return an error.
Similarly
Hey all,
I'd like to announce the newest extension for Flake8 that I've poorly
named flake8-docstrings. flake8-docstrings relies on the excellent
pep257 for checking. Simon André did most of the work to get it
completed (so don't listen to PyPI, he's the real author).
`pip install flake8-docstrings` is all you need to try it out. If you
find any issues or wish to contribute, we would be happy to hear from
you on BitBucket: https://bitbucket.org/icordasc/flake8-docstrings.
--
Ian
Hi there,
On 06 mai 17:40, Sylvain Thénault wrote:
> talking to those who'll attend to the sprint: we have to organize the attendence
> of Logilab people from Paris, and I propose to other to book room for them in the
> same hotel. Just tell me if you're interested and for which nights you need an
> hotel.
I've rather set up a pad to prepare the sprint: http://piratepad.net/oAvsUoGCAC
Those who'll attend should share information there about their travel, hotel and all.
Those who intend to participate online are invited to add their name and avaibility.
Anyone may suggest sprint topic and/or vote for the proposed ones.
--
Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42)
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure: http://www.logilab.fr/services
CubicWeb, the semantic web framework: http://www.cubicweb.org
Hey all,
I've been forwarding (and trying to CC) our list on those messages as
much as possible. In case any of you weren't already subscribed to the
python-ideas list, Guido has proposed that python no longer allow the
following:
foo = ('abc'
'def'
)
Mainly because it can cause confusing TypeErrors for the functions
taking a certain number of arguments. There are a few ideas floating
around that thread, one of which is that we (the code-quality tool
authors) provide warnings or errors when someone does:
foo('a' 'b')
i.e., uses the implicit concatenation on a single line.
I'm personally far more in favor of this (mainly for older versions of
python) + a SyntaxError for newer versions but to allow the multi-line
concatenation to continue.
Some are in favor of adding a new string prefix like `m` or `s`.
All of this aside, we may have to start including support for this in
our tools so I wanted everyone to be well aware of the discussion.
Hopefully people will continue the trend I've tried to start of CC'ing
code-quality but that likely won't happen.
Cheers,
Ian
On Sat, May 11, 2013 at 12:48 PM, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
> On Sun, May 12, 2013 at 2:37 AM, Christian Tismer <tismer(a)stackless.com> wrote:
>
>> So if there was some notation (not specified yet how) that triggers correct
>> indentation at compile time without extra functional hacks, so that
>>
>> long_text = """
>> this text is left justified
>> and this line indents by two spaces
>> """
>>
>> is stripped the leading and trailing \n and indentation is justified,
>> then I think the need for the implicit whitespace operator would be small.
>
> Through participating in this thread, I've realised that the
> distinction between when I use a triple quoted string (with or without
> textwrap.dedent()) and when I use implicit string concatenation is
> whether or not I want the newlines in the result. Often I can avoid
> the issue entirely by splitting a statement into multiple pieces, but
>
> I think Guido's right that if we didn't have implicit string
> concatenation there's no way we would add it ("just use a triple
> quoted string with escaped newlines" or "just use runtime string
> concatenation"), but given that we *do* have it, I don't think it's
> worth the hassle of removing it over a bug that a lint program should
> be able to pick up.
>
> So I'm back to where I started, which is that if this kind of problem
> really bothers anyone, start thinking seriously about the idea of a
> standard library linter.
Really this should be trivial for all of the linters that already
exist. That aside, (and this is not an endorsement for this proposal)
but can you not just do
long_text = """\
this is left justified \
and this is continued on the same line
and this is indented by two spaces
"""
I'm personally in favor of not allowing the concatenation to be on the
same line but allowing it across multiple lines. While linters would
be great for this, why not just introduce the SyntaxError since (as
has already been demonstrated) some of the concatenation already
happens at compile time.
---------- Forwarded message ----------
From: Nick Coghlan <ncoghlan(a)gmail.com>
Date: Sat, May 11, 2013 at 12:48 PM
Subject: Re: [Python-ideas] Implicit string literal concatenation
considered harmful?
To: Christian Tismer <tismer(a)stackless.com>
Cc: Stefan Behnel <stefan_ml(a)behnel.de>, "python-ideas(a)python.org"
<python-ideas(a)python.org>
On Sun, May 12, 2013 at 2:37 AM, Christian Tismer <tismer(a)stackless.com> wrote:
> So if there was some notation (not specified yet how) that triggers correct
> indentation at compile time without extra functional hacks, so that
>
> long_text = """
> this text is left justified
> and this line indents by two spaces
> """
>
> is stripped the leading and trailing \n and indentation is justified,
> then I think the need for the implicit whitespace operator would be small.
Through participating in this thread, I've realised that the
distinction between when I use a triple quoted string (with or without
textwrap.dedent()) and when I use implicit string concatenation is
whether or not I want the newlines in the result. Often I can avoid
the issue entirely by splitting a statement into multiple pieces, but
I think Guido's right that if we didn't have implicit string
concatenation there's no way we would add it ("just use a triple
quoted string with escaped newlines" or "just use runtime string
concatenation"), but given that we *do* have it, I don't think it's
worth the hassle of removing it over a bug that a lint program should
be able to pick up.
So I'm back to where I started, which is that if this kind of problem
really bothers anyone, start thinking seriously about the idea of a
standard library linter.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
_______________________________________________
Python-ideas mailing list
Python-ideas(a)python.org
http://mail.python.org/mailman/listinfo/python-ideas
On May 10, 2013 7:51 PM, "Nick Coghlan" <ncoghlan(a)gmail.com> wrote:
>
>
> On 11 May 2013 04:50, "Guido van Rossum" <guido(a)python.org> wrote:
> >
> > I just spent a few minutes staring at a bug caused by a missing comma
> > -- I got a mysterious argument count error because instead of foo('a',
> > 'b') I had written foo('a' 'b').
> >
> > This is a fairly common mistake, and IIRC at Google we even had a lint
> > rule against this (there was also a Python dialect used for some
> > specific purpose where this was explicitly forbidden).
> >
> > Now, with modern compiler technology, we can (and in fact do) evaluate
> > compile-time string literal concatenation with the '+' operator, so
> > there's really no reason to support 'a' 'b' any more. (The reason was
> > always rather flimsy; I copied it from C but the reason why it's
> > needed there doesn't really apply to Python, as it is mostly useful
> > inside macros.)
> >
> > Would it be reasonable to start deprecating this and eventually remove
> > it from the language?
>
> I could live with it if we get "dedent()" as a string method. I'd be even
happier if constant folding was extended to platform independent method
calls on literals, but I don't believe there's a sane way to maintain the
"platform independent" constraint.
>
> OTOH, it's almost on the scale of "remove string mod formatting".
Shipping at least a basic linting tool in the stdlib would probably be
almost as effective and substantially less disruptive. lib2to3 should
provide some decent infrastructure for that.
I have cc'd the code-quality mailing list since several linger authors are
subscribed there.
Hi there,
first post to the code-quality mailing list. Among others, I've been developping and
maintaining Pylint for the past 10 years with some fellows, and it seems this is now
the place to be for code quality checkers, so here we go.
You may be aware, or not, that things are moving these days on the pylint front.
Two noticeable things:
* pylint development is moving to bitbucket and away from its "parent" (Logilab) [1]
* a pylint sprint will be held in Toulouse (France) from June 17 to 19, with currently
2 or 3 people from Logilab and probably at least 3 from Google [2]
Following the bitbucket move, we're currently discussing about moving Pylint related
discussions from its current mailing-list (python-projects(a)lists.logilab.org) to this
one. You can see from the archives [3] that this is not high traffic, but neither
negligeable compared to this list current traffic. Of course I would like to know
opinion from people here before acting anything.
Last but not least, it would be great if some flake8 fellows would be available to
sprint with us, so we can see how to integrate pylint there and share efforts.
Waiting for your feedbacks, cheers,
[1] http://www.logilab.org/blogentry/129458
[2] http://www.logilab.org/133321
[3] http://lists.logilab.org/pipermail/python-projects/
--
Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42)
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure: http://www.logilab.fr/services
CubicWeb, the semantic web framework: http://www.cubicweb.org
hi, i am currently working on an ide for python, i intended to enable pep8
checking by default but as it turned out, the checker was written
purposefully for the command line making it a bit difficult and untidy to
incorporate into the ide. i will therefore suggest that for future release,
you enable the checker to be usable as a library so that the output can
easily be processed and also the overal build of my ide will be a bit more
compact. thanks.