On Fri, Feb 1, 2013 at 1:38 PM, Keshav Kini wrote:
> Robert Bradshaw writes:
>> (4) Perhaps I could configure things differently, but littering my
>> directory with reject files when things don't apply cleanly vs. git's
>> inline
>>
>> << OLD
>> ...
>>
>> ...
NEW
>>
>> is so
So we're now vastly off-topic from Python 3 formatting, but... :)
On Fri, 01 Feb 2013 at 03:50PM -0600, William Stein wrote:
> I greatly prefer the incredibly simple and straightforward merge
> markup with git to using any of the several sophisticated 3-way merge
> tools that I've used (in OS X a
On Fri, Feb 1, 2013 at 3:38 PM, Keshav Kini wrote:
> Robert Bradshaw writes:
>> (4) Perhaps I could configure things differently, but littering my
>> directory with reject files when things don't apply cleanly vs. git's
>> inline
>>
>> << OLD
>> ...
>>
>> ...
NEW
>>
>> is so
Robert Bradshaw writes:
> (4) Perhaps I could configure things differently, but littering my
> directory with reject files when things don't apply cleanly vs. git's
> inline
>
> << OLD
> ...
>
> ...
>>> NEW
>
> is so much easier to deal with (as well as being a lot safer in making
On Thu, Jan 31, 2013 at 11:04 PM, Jeroen Demeyer wrote:
> On 2013-02-01 00:17, Robert Bradshaw wrote:
>> On Thu, Jan 31, 2013 at 12:11 PM, Jeroen Demeyer
>> wrote:
>>> On 2013-01-31 20:42, Robert Bradshaw wrote:
I think this will be much easier to do once we've moved to git
>>> Why? What h
On 2013-02-01 00:17, Robert Bradshaw wrote:
> On Thu, Jan 31, 2013 at 12:11 PM, Jeroen Demeyer
> wrote:
>> On 2013-01-31 20:42, Robert Bradshaw wrote:
>>> I think this will be much easier to do once we've moved to git
>> Why? What has git to do with this?
>
> Well, really moving to a proper rev
Harald Schilly writes:
> On Thu, Jan 31, 2013 at 11:00 AM, Jeroen Demeyer <
> jdeme...@cage.ugent.be> wrote:
>
> On 2013-01-31 10:58, Volker Braun wrote:
> > commit hook
> What's that?
>
>
> For an hg/git commit, a script is called prior to actually doing the
> commit. if its exit code
On Thu, Jan 31, 2013 at 12:11 PM, Jeroen Demeyer wrote:
> On 2013-01-31 20:42, Robert Bradshaw wrote:
>> I think this will be much easier to do once we've moved to git
> Why? What has git to do with this?
Well, really moving to a proper revision control workflow, as dealing
with broken patches a
On 2013-01-31 20:42, Robert Bradshaw wrote:
> I think this will be much easier to do once we've moved to git
Why? What has git to do with this?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emai
On Thu, Jan 31, 2013 at 10:39 AM, Harald Schilly
wrote:
>
> On Thu, Jan 31, 2013 at 7:32 PM, Johannes wrote:
>>
>> some of those errors should be fixable by a little sed script like most
>> of the whitespace warnings and '<>'.
>
>
> No need to do this, autopep8 has a "--select=..." parameter, wh
On Thu, Jan 31, 2013 at 7:32 PM, Johannes wrote:
> some of those errors should be fixable by a little sed script like most
> of the whitespace warnings and '<>'.
>
No need to do this, autopep8 has a "--select=..." parameter, where you can
say which one of those E-numbers you want to have fixed.
some of those errors should be fixable by a little sed script like most
of the whitespace warnings and '<>'.
greatz Johannes
On 31.01.2013 12:17, Jeroen Demeyer wrote:
> $ pep8 -qq --statistics sage
> 869 E111 indentation is not a multiple of four
> 189 E121 continuation line indentation
On Thu, Jan 31, 2013 at 2:36 AM, Volker Braun wrote:
> On Thursday, January 31, 2013 10:31:16 AM UTC, Jeroen Demeyer wrote:
>>
>> I'd like to mention that in the release management script, there are a
>> few things that I check for, such as:
>>
>> * no bare "except:" without exception class
>> * n
$ pyflakes sage 2>/dev/null |grep 'undefined name '
sage/symbolic/expression_conversions.py:748: undefined name 'QQ'
sage/symbolic/integration/external.py:58: undefined name 'dvar'
sage/server/introspect.py:38: undefined name 'get_docstring_last'
sage/server/introspect.py:41: undefined name 'get_so
$ pep8 -qq --statistics sage
869 E111 indentation is not a multiple of four
189 E121 continuation line indentation is not a multiple of four
28 E122 continuation line missing indentation or outdented
66 E123 closing bracket does not match indentation of opening
bracket's line
33
On Thursday, January 31, 2013 11:59:08 AM UTC+1, Volker Braun wrote:
>
> Btw did you try other code analysis tools besides pep8?
>
no, thank's for the pointer to flake8 :-)
h
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe fro
Btw did you try other code analysis tools besides pep8?
There is http://pypi.python.org/pypi/flake8 which is a wrapper around pep8
and two other analyzers. This might be a useful starting point for making
our own customizations...
On Thursday, January 31, 2013 9:37:18 AM UTC, Harald Schilly
On Thu, Jan 31, 2013 at 11:31 AM, Jeroen Demeyer wrote:
> Also, I personally don't
> agree with everything that is said in PEP 8.
>
yes, we could agree on a list of exceptions, with pep8, it's
the --ignore=E[number] switch which would disable a selected list of errors.
H
--
You received this
Well at this point in time there is not much point in writing mercurial
scripts. But its something that should be integrated in the git workflow.
Also there isn't a dedicated hg qrefresh-hook as there is for commits,
though that can be hacked around...
On Thursday, January 31, 2013 10:42:25 A
On 2013-01-31 11:36, Volker Braun wrote:
> On Thursday, January 31, 2013 10:31:16 AM UTC, Jeroen Demeyer wrote:
>
> I'd like to mention that in the release management script, there are a
> few things that I check for, such as:
>
> * no bare "except:" without exception class
> * no
On Thursday, January 31, 2013 10:31:16 AM UTC, Jeroen Demeyer wrote:
> I'd like to mention that in the release management script, there are a
> few things that I check for, such as:
>
> * no bare "except:" without exception class
> * no TABs
> * no use of AssertionError ("assert" is fine, but
On 2013-01-31 10:58, Volker Braun wrote:
> We definitely should have some lint-type tool that we put into the
> commit hook to automatically show errors/warning.
But it's very important to check only newly added code, as there is so
much code which doesn't conform to PEP 8. Also, I personally don
On Thu, Jan 31, 2013 at 11:00 AM, Jeroen Demeyer wrote:
> On 2013-01-31 10:58, Volker Braun wrote:
> > commit hook
> What's that?
For an hg/git commit, a script is called prior to actually doing the
commit. if its exit code is != 0, no commit happens.
H
--
You received this message because yo
Le 31/01/2013 11:00, Jeroen Demeyer a écrit :
On 2013-01-31 10:58, Volker Braun wrote:
commit hook
What's that?
Some piece of code which gets triggered on every commit, used for
example to :
- reject it if it doesn't pass some tests ;
- send a mail to the maintainer about it if it wasn't co
On 2013-01-31 10:58, Volker Braun wrote:
> commit hook
What's that?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To pos
We definitely should have some lint-type tool that we put into the commit
hook to automatically show errors/warning. I'm not sure which one is best
suited for our purpose, ideally something with some flexibility to adapt it
to our needs.
On Thursday, January 31, 2013 9:37:18 AM UTC, Harald
On Wednesday, January 30, 2013 7:10:46 PM UTC+1, Travis Scrimshaw wrote:
>
>Should we be encouraging (or enforce) new code to be python 3
> compliant? In particular, not using removed syntax such as exceptions as
> `raise ExceptionType, args` or `<>` comparisons?
>
Are there any intentions t
William Stein writes:
> I remember adding code that used "with" to Sage back in I think 2008
> when working on generators for the coercion model. We've been using
> with for a long time.
Sure. In general the newer pieces of code in Sage do tend to use more
modern Python than older pieces of code
On Wed, Jan 30, 2013 at 11:04 AM, Keshav Kini wrote:
> Travis Scrimshaw writes:
>> Hey everyone,
>>Should we be encouraging (or enforce) new code to be python 3
>> compliant? In particular, not using removed syntax such as exceptions
>> as `raise ExceptionType, args` or `<>` comparisons?
>
>
Travis Scrimshaw writes:
> Hey everyone,
>Should we be encouraging (or enforce) new code to be python 3
> compliant? In particular, not using removed syntax such as exceptions
> as `raise ExceptionType, args` or `<>` comparisons?
Encouraging, yes; enforcing, I'd say no. I don't think a Python
I'd say everybody is encouraged to use py3-compatible syntax. Reading
through the list of whats new is a good start. Lacking py3-versions of all
libraries we can't really enforce anything yet in an automatted way, though
that should soon change.
On Wednesday, January 30, 2013 6:10:46 PM UTC, T
31 matches
Mail list logo