Re: [sage-devel] Re: Python 3 formatting
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 much easier to deal with (as well as being a lot safer in making >> sure nothing was omitted). > > I agree that this is better, but IMHO a nicer solution than either of > these is using an actual three-way merge resolution tool such as kdiff3 > or vimdiff or meld or whatever. You can do this with `git mergetool` and > a little configuration in ~/.gitconfig . While I have occasionally found such tools useful for visualizing a complicated merge, I actually prefer git's markup in an editor of my choice. > Of course there's similar > functionality in Mercurial as well, though you need to do a little more > configuration to get it to work, in my experience. Yes, but we don't do merges in our current workflow, so it's just a patch that (sometimes partially) fails to apply (though I'm sure there's some graphical tool that would make the rebase less painful, assuming you can pinpoint the point in time (and necessary dependencies) where the patch applied cleanly). - Robert -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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 and linux, at least until 2008). This > is probably partly because I get to use the editor of my choice > (emacs) to do the actual work, rather than having to use some > graphical merge client. You do use ediff, right? It's a lot like the graphical merge clients, but, you know, emacs-y. https://encrypted.google.com/search?q=emacs+ediff Dan -- --- Dan Drake - http://math.pugetsound.edu/~ddrake --- signature.asc Description: Digital signature
Re: [sage-devel] Re: Python 3 formatting
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 much easier to deal with (as well as being a lot safer in making >> sure nothing was omitted). > > I agree that this is better, but IMHO a nicer solution than either of > these is using an actual three-way merge resolution tool such as kdiff3 > or vimdiff or meld or whatever. You can do this with `git mergetool` and > a little configuration in ~/.gitconfig . Of course there's similar > functionality in Mercurial as well, though you need to do a little more > configuration to get it to work, in my experience. 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 and linux, at least until 2008). This is probably partly because I get to use the editor of my choice (emacs) to do the actual work, rather than having to use some graphical merge client. << OLD ... ... > NEW > > I completely agree with the rest of your mail, though. > > -Keshav > > -- > 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 post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Python 3 formatting
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 > sure nothing was omitted). I agree that this is better, but IMHO a nicer solution than either of these is using an actual three-way merge resolution tool such as kdiff3 or vimdiff or meld or whatever. You can do this with `git mergetool` and a little configuration in ~/.gitconfig . Of course there's similar functionality in Mercurial as well, though you need to do a little more configuration to get it to work, in my experience. I completely agree with the rest of your mail, though. -Keshav -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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 has git to do with this? >> >> Well, really moving to a proper revision control workflow, as dealing >> with broken patches and re-basing patches when trivial things like >> whitespace changes is way more painful in the current setup. > Are you saying that git automagically rebases patches for you when a > patch conflicts due to whitespace? If yes, that's very cool and perhaps > another plus for git. If no, then I don't see why rebasing conflicting > patches would be easier under the git workflow. For whitespace specifically, there's git merge -s ignore-all-space. But for all sorts of changes I think that (1) Having an integrated repository means that it'll be *much* easier to do development at head, as well as on top of as-yet unmerged tickets (or for that matter both simultaneously). (2) There's no longer the manual tracking of which revision of Sage a given patch (should) cleanly apply to. (3) The process will be "git checkout ticket; git merge master; [manual conflict resolution]; git push ticket" rather than a messy copy-url, qimport, [manual conflict resolution] export, manually upload the patch with a note about where it applies (and also loosing history), and (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 sure nothing was omitted). Now there are cases where the [manual conflict resolution] is non-trivial, and it won't help there (assuming parity of git and mercurial's merge algorithms), but for big re-formatting efforts it's usually a trivial semantic merge surrounded by a bunch of manual labor that'll get easier. - Robert -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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 revision control workflow, as dealing > with broken patches and re-basing patches when trivial things like > whitespace changes is way more painful in the current setup. Are you saying that git automagically rebases patches for you when a patch conflicts due to whitespace? If yes, that's very cool and perhaps another plus for git. If no, then I don't see why rebasing conflicting patches would be easier under the git workflow. -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Python 3 formatting
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 is != 0, no commit happens. And, of course, a nice message is printed explaining to the person who tried to commit the reason why the commit did not succeed, and often providing some easy command with which to fix the problem. Since we are not using commits right now, only patches, this doesn't make much sense currently. Once we switch to git we might discuss having some commit hooks shipped with our git repository in the Sage tarball. The user can of course disable them. -Keshav -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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 and re-basing patches when trivial things like whitespace changes is way more painful in the current setup. - Robert -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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 emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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, where you can > say which one of those E-numbers you want to have fixed. The problem is, > it's hard to make such a patch across so many files. I think this will be much easier to do once we've moved to git, just like fixing all the trailing whitespace. - Robert -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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. The problem is, it's hard to make such a patch across so many files. H -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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 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 E124 closing bracket does not match visual indentation
> 145 E125 continuation line does not distinguish itself from next
> logical line
> 281 E126 continuation line over-indented for hanging indent
> 774 E127 continuation line over-indented for visual indent
> 1134E128 continuation line under-indented for visual indent
> 2942E201 whitespace after '['
> 2629E202 whitespace before ']'
> 1104E203 whitespace before ':'
> 45 E211 whitespace before '('
> 586 E221 multiple spaces before operator
> 657 E222 multiple spaces after operator
> 8741E225 missing whitespace around operator
> 23360 E231 missing whitespace after ','
> 5992E251 no spaces around keyword / parameter equals
> 1261E261 at least two spaces before inline comment
> 564 E262 inline comment should start with '# '
> 156 E271 multiple spaces after keyword
> 564 E272 multiple spaces before keyword
> 192 E301 expected 1 blank line, found 0
> 4050E302 expected 2 blank lines, found 1
> 2200E303 too many blank lines (3)
> 1 E304 blank lines found after function decorator
> 72 E401 multiple imports on one line
> 37135 E501 line too long (163 > 79 characters)
> 775 E502 the backslash is redundant between brackets
> 1078E701 multiple statements on one line (colon)
> 163 E702 multiple statements on one line (semicolon)
> 158 E703 statement ends with a semicolon
> 338 E711 comparison to None should be 'if cond is None:'
> 150 E712 comparison to True should be 'if cond is True:' or 'if cond:'
> 11 E721 do not compare types, use 'isinstance()'
> 10811 W291 trailing whitespace
> 3 W292 no newline at end of file
> 38415 W293 blank line contains whitespace
> 440 W391 blank line at end of file
> 322 W601 .has_key() is deprecated, use 'in'
> 3822W602 deprecated form of raising exception
> 33 W603 '<>' is deprecated, use '!='
> 8 W604 backticks are deprecated, use 'repr()'
>
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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
>> * no TABs
>> * no use of AssertionError ("assert" is fine, but not "except
>> AssertionError" for example)
>
>
> And thats great, but its the wrong place to check. The patch author should
> be immediately notified if his/her patch fails the automated checks, not
> weeks or months later.
+1
I'm all for commit hooks, but that that's a developer convenience and
may not be set up on every client. It would also be really easy to add
a patchbot plugin to check for this (and it's also easy to look at a
diff of the result, to ease us into it before all code is compliant
http://patchbot.sagemath.org/log/10716/Fedora/18/x86_64/3.7.2-201.fc18.x86_64/volker-desktop.stp.dias.ie/2013-01-31%2014:11:19%20+?plugin=plugins.coverage&diff=/log/0/Fedora/18/x86_64/3.7.2-201.fc18.x86_64/volker-desktop.stp.dias.ie/2013-01-31%2010%3A38%3A07%20%2B&ticket=10716&base=5.7.beta2
). I'd be happy to do this once we decide on a standard and have an
(optional?) linter spkg.
- Robert
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
$ 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_source_code' sage/server/introspect.py:43: undefined name 'get_source_code' sage/server/introspect.py:46: undefined name 'get_docstring' sage/server/introspect.py:48: undefined name 'get_docstring' sage/server/introspect.py:49: undefined name 'get_completions' sage/server/introspect.py:57: undefined name 'word_wrap' sage/server/introspect.py:57: undefined name 'numcols' sage/server/simple/twist.py:204: undefined name 'notebook_twist' sage/server/simple/twist.py:210: undefined name 'notebook_twist' sage/server/simple/twist.py:218: undefined name 'SEP' sage/server/simple/twist.py:231: undefined name 'SEP' sage/server/simple/twist.py:242: undefined name 'SEP' sage/server/simple/twist.py:253: undefined name 'SEP' sage/server/simple/twist.py:282: undefined name 'SEP' sage/server/simple/twist.py:319: undefined name 'SEP' sage/server/notebook/twist.py:114: undefined name 'last_save_time' sage/server/notebook/twist.py:114: undefined name 'save_interval' sage/server/notebook/twist.py:121: undefined name 'last_idle_time' sage/server/notebook/twist.py:121: undefined name 'idle_interval' sage/server/notebook/twist.py:650: undefined name 'filename' sage/server/notebook/twist.py:1584: undefined name 'TrashCan' sage/server/notebook/twist.py:1663: undefined name 'W' sage/server/notebook/twist.py:2256: undefined name 'oldpass' sage/server/notebook/notebook.py:1012: undefined name 'MAX_HISTORY_LENGTH' sage/server/notebook/cell.py:1690: undefined name 'time' sage/server/notebook/cell.py:1699: undefined name 'time' sage/server/notebook/cell.py:1703: undefined name 'time' sage/server/notebook/avatars.py:231: undefined name 'kernel' sage/server/notebook/avatars.py:232: undefined name 'resources' sage/schemes/plane_curves/projective_curve.py:159: undefined name 'PolynomialRing' sage/schemes/plane_conics/con_field.py:1096: undefined name 'matrix' sage/schemes/generic/spec.py:365: undefined name 'new_base' sage/schemes/generic/divisor.py:316: undefined name 'DivisorGroup' sage/schemes/elliptic_curves/padics.py:1001: undefined name 'prec' sage/schemes/elliptic_curves/padic_lseries.py:1354: undefined name 'floor' sage/schemes/elliptic_curves/gal_reps.py:954: undefined name 'prime_range' sage/schemes/elliptic_curves/gal_reps.py:1048: undefined name 'nonsplit_str' sage/schemes/elliptic_curves/gal_reps.py:1102: undefined name 'nonsplit_str' sage/schemes/elliptic_curves/ell_rational_field.py:1375: undefined name 'E' sage/schemes/elliptic_curves/ell_point.py:2626: undefined name 'QQ' sage/schemes/elliptic_curves/ell_point.py:2998: undefined name 'prec_words_to_bits' sage/schemes/elliptic_curves/ell_point.py:3089: undefined name 'precision' sage/schemes/elliptic_curves/ell_curve_isogeny.py:1000: undefined name 'InputError' sage/schemes/elliptic_curves/ell_curve_isogeny.py:1491: undefined name 'InputError' sage/rings/invariant_theory.py:1769: undefined name 'kwds' sage/rings/rational_field.py:434: undefined name 'sage' sage/rings/qqbar.py:1140: undefined name 'QQbar_I' sage/rings/qqbar.py:1156: undefined name 'QQbar_I' sage/rings/qqbar.py:1207: undefined name 'QQ_1' sage/rings/qqbar.py:1207: undefined name 'QQ_1' sage/rings/qqbar.py:2529: undefined name 'QQbar_I_generator' sage/rings/qqbar.py:2550: undefined name 'QQbar_I_generator' sage/rings/qqbar.py:3033: undefined name 'QQbar_I_generator' sage/rings/qqbar.py:3033: undefined name 'QQbar_I_nf' sage/rings/qqbar.py:3058: undefined name 'QQ_1_4' sage/rings/qqbar.py:3060: undefined name 'QQbar_I_generator' sage/rings/qqbar.py:3268: undefined name 'AA_hash_offset' sage/rings/qqbar.py:3270: undefined name 'QQbar_hash_offset' sage/rings/qqbar.py:3899: undefined name 'QQ_1_2' sage/rings/qqbar.py:3937: undefined name 'RR_1_10' sage/rings/qqbar.py:3937: undefined name 'RR_1_10' sage/rings/qqbar.py:4570: undefined name 'AA_0' sage/rings/qqbar.py:5157: undefined name 'QQbar_I_nf' sage/rings/qqbar.py:5173: undefined name 'QQ_0' sage/rings/qqbar.py:5306: undefined name 'QQ_1_4' sage/rings/qqbar.py:5332: undefined name 'QQ_1_4' sage/rings/qqbar.py:5347: undefined name 'QQ_1_4' sage/rings/qqbar.py:5490: undefined name 'QQ_1_2' sage/rings/qqbar.py:5505: undefined name 'QQ_1_2' sage/rings/qqbar.py:5548: undefined name 'QQ_1_2' sage/rings/qqbar.py:5563: undefined name 'QQ_1_4' sage/rings/qqbar.py:5564: undefined name 'QQbar_I_nf' sage/rings/qqbar.py:5564: undefined name 'QQbar_I_nf' sage/rings/qqbar.py:6614: undefined name 'QQ_1' sage/rings/qqbar.py:6632: undefined name 'QQbar_I_generator' sage/rings/qqbar.py:6633: undefined name 'QQ_1_4' sage/rings/qqbar.py:6697: undefined name 'QQbar_I_generator' sage/rings/qqbar.py:6745: undefined name 'QQbar_I_generator' sage/rings/qqbar.py:7011: undefined name 'QQbar_I_generat
Re: [sage-devel] Re: Python 3 formatting
$ 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 E124 closing bracket does not match visual indentation
145 E125 continuation line does not distinguish itself from next
logical line
281 E126 continuation line over-indented for hanging indent
774 E127 continuation line over-indented for visual indent
1134E128 continuation line under-indented for visual indent
2942E201 whitespace after '['
2629E202 whitespace before ']'
1104E203 whitespace before ':'
45 E211 whitespace before '('
586 E221 multiple spaces before operator
657 E222 multiple spaces after operator
8741E225 missing whitespace around operator
23360 E231 missing whitespace after ','
5992E251 no spaces around keyword / parameter equals
1261E261 at least two spaces before inline comment
564 E262 inline comment should start with '# '
156 E271 multiple spaces after keyword
564 E272 multiple spaces before keyword
192 E301 expected 1 blank line, found 0
4050E302 expected 2 blank lines, found 1
2200E303 too many blank lines (3)
1 E304 blank lines found after function decorator
72 E401 multiple imports on one line
37135 E501 line too long (163 > 79 characters)
775 E502 the backslash is redundant between brackets
1078E701 multiple statements on one line (colon)
163 E702 multiple statements on one line (semicolon)
158 E703 statement ends with a semicolon
338 E711 comparison to None should be 'if cond is None:'
150 E712 comparison to True should be 'if cond is True:' or 'if cond:'
11 E721 do not compare types, use 'isinstance()'
10811 W291 trailing whitespace
3 W292 no newline at end of file
38415 W293 blank line contains whitespace
440 W391 blank line at end of file
322 W601 .has_key() is deprecated, use 'in'
3822W602 deprecated form of raising exception
33 W603 '<>' is deprecated, use '!='
8 W604 backticks are deprecated, use 'repr()'
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Python 3 formatting
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 from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Python 3 formatting
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 wrote: > > 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 to use Python's "pep8" to sanitize Sage code? For > other projects, I started to use pep8 and autopep8 to format the code. It > has a very long list of rules and checks them for the source code files. > For the entire Sage library this might be not a good idea, but file-by-file > we might try to use it to spot these irregular code lines. I know, that > pep8 complains about "<>" and other things, e.g. "is not" vs. "!=" and so > on. I don't know about the raise/except thing, once could try it … > > H > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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 AM UTC, Jeroen Demeyer wrote:
>
> 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 TABs
> > * no use of AssertionError ("assert" is fine, but not "except
> > AssertionError" for example)
> >
> >
> > And thats great, but its the wrong place to check. The patch author
> > should be immediately notified if his/her patch fails the automated
> > checks, not weeks or months later.
> Fair enough, if you know how to implement such a "commit hook", feel
> free to do so...
>
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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 TABs
> * no use of AssertionError ("assert" is fine, but not "except
> AssertionError" for example)
>
>
> And thats great, but its the wrong place to check. The patch author
> should be immediately notified if his/her patch fails the automated
> checks, not weeks or months later.
Fair enough, if you know how to implement such a "commit hook", feel
free to do so...
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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 not "except
> AssertionError" for example)
>
And thats great, but its the wrong place to check. The patch author should
be immediately notified if his/her patch fails the automated checks, not
weeks or months later.
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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't
agree with everything that is said in PEP 8.
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 not "except
AssertionError" for example)
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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 committed by said maintainer ; - more generally notify on irc/jabber that something was committed Snark on #sagemath -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Python 3 formatting
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 Schilly wrote: > > 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 to use Python's "pep8" to sanitize Sage code? For > other projects, I started to use pep8 and autopep8 to format the code. It > has a very long list of rules and checks them for the source code files. > For the entire Sage library this might be not a good idea, but file-by-file > we might try to use it to spot these irregular code lines. I know, that > pep8 complains about "<>" and other things, e.g. "is not" vs. "!=" and so > on. I don't know about the raise/except thing, once could try it … > > H > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Python 3 formatting
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 to use Python's "pep8" to sanitize Sage code? For other projects, I started to use pep8 and autopep8 to format the code. It has a very long list of rules and checks them for the source code files. For the entire Sage library this might be not a good idea, but file-by-file we might try to use it to spot these irregular code lines. I know, that pep8 complains about "<>" and other things, e.g. "is not" vs. "!=" and so on. I don't know about the raise/except thing, once could try it … H -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Python 3 formatting
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, as far as I've seen - it's not like our code as a whole is stuck in the past or anything. But naturally code that hasn't been touched for many years is apt to have old coding styles. -Keshav -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Python 3 formatting
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? > > Encouraging, yes; enforcing, I'd say no. I don't think a Python 3 > transition for Sage is even on the horizon at this point. That said, I was enthusiastic about switching from trying out Python3 a little for fun... however, when I actually tried to use Python3 for a brand new project involved web development (something independent from Sage), it was pretty annoying still, and I was forced back to python2. That's worrisome. So at this point your assertion "a Python 3 transition for Sage is not on the horizon" is about right. > there is plenty of "old-style" Python code in Sage which could at least > be updated to 2.7 standards anyway. That old exception raising syntax > you mentioned is one example. There are probably places where we could > make use of `with` clauses and are not. We should be using the > subprocess module instead of os.system (PEP 324). Etc 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. > -Keshav > > -- > 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 post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Python 3 formatting
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 3 transition for Sage is even on the horizon at this point. That said, there is plenty of "old-style" Python code in Sage which could at least be updated to 2.7 standards anyway. That old exception raising syntax you mentioned is one example. There are probably places where we could make use of `with` clauses and are not. We should be using the subprocess module instead of os.system (PEP 324). Etc -Keshav -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Python 3 formatting
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, Travis Scrimshaw wrote: > > 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? > > Thanks, > Travis > > http://docs.python.org/3.0/whatsnew/3.0.html > > -- 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 post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
