PEP 8 refactoring

[Jonathan Peirce]

OK, so several people are keen for a push for a cosmetic refactoring of
the code base to be more in line with PEP 8
https://groups.google.com/forum/#!topic/psychopy-dev/ds843ckNtrw

The refactoring will break the history on a lot of files, and create
merge conflicts for any code in development branches that haven't been
merged beforehand so I want it to occur only once, for a short period,
with a known start/end time. I'd also suggest a fair amount of work on
adding test coverage before the refactoring takes place. It would be
good to know how far we are from Python3 compatibility afterwards too.

After the refactoring occurs I will be urging contributors more strongly
to focus on things that benefit the users and rejecting cosmetic changes.

I'm drawing the line at switching from CamelCase to snake_case. Sorry to
those that like that, but it will upset too many people for the pleasure
of a few.

With those caveats in mind, do the refactoring folk have a time they'd
like to do this so I can make sure I don't touch any code at the same
time (I'll probably get angry and upset)? Would some week in late Jan be
about right?

best wishes
Jon



--
Dr. Jonathan Peirce
Nottingham Visual Neuroscience
School of Psychology
University of Nottingham

+44 (0)115 8467176 (tel)

http://www.peirce.org.uk/





This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment. Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

[Jeremy Gray]

This sounds really good as a plan for big things that will affect many lines of code. Depending on Sol's schedule, possibly early February might work better than late January, in order to have adequate ioHub-related discussion and preparation. Or Jon, perhaps you would be okay if iohub/* refactoring had its own (different) timetable? That would be quite helpful, in order to spread out the work so as to keep it as short as possible a disruption for a given section of PsychoPy (iohub, non-iohub).

Big things (that would touch a lot of code widely throughout the project):

- run autopep8 for whitespace adjustment, review by hand. 

- reduce long lines

Small things:

I am hoping that some small refactoring can happen in the meantime to get these out of the way at a more leisurely pace. This would target things that touch relatively few lines of code, and code that other people are not likely to change in their forks. Some of these are necessary for python3 migration:

- a standard heading in each file (shebang, coding, license, future imports)

- no mutable default parameters, new style classes, reduce use of exec, no bare excepts

Test coverage is about 50%, in terms of lines, much less in terms of testing all possible pathways through the code. I'll get a code coverage report, and as a separate discussion we can try to prioritize things to test, based on importance, likelihood of breaking during refactoring, and ease of writing a test.

--Jeremy

--
You received this message because you are subscribed to the Google Groups "psychopy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to psychopy-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeremy Gray]

Perhaps we can organize a virtual code-sprint in late Jan or early Feb, targeting the PEP-8 stuff, to get it done as quickly and also carefully as possible.

--Jeremy

[Jon Peirce]

I liked the idea that different pieces could be done in turn, as long as people know what is being done when. You mentioned iohub being separate, but it seems you could also separate the app code from the library if you wanted
Jon

-- 
Jon Peirce
http://www.peirce.org.uk

[Jon Peirce]

For the question of the code sprint, I'm personally planning to avoid coding until the dust has settled!

[Jeremy Gray]

Thanks Jon. All sounds good. I probably won't do much or discuss much for a week or so (on vacation now).

--Jeremy

[Jeremy Gray]

Hi all,

Happy new year!

To work off some technical debt and set the stage for further awesomeness, I'd like to refactor PsychoPy's codebase to be more consistent with the wider developer community's expectations for scientific open-source code. As discussed earlier in this thread, the plan is to bring whitespace and line lengths to be more (but not perfectly) in line with PEP 8 (for details see https://github.com/psychopy/psychopy/issues/1056). Variable names will not be changed, and readability is more important than character counts in line-lengths. There are other changes that are sort of style-related (and sort of functional, e.g., to smooth the way towards python 3 compatibility) that I also hope to do at the same time, but might not be able to, depending on how easily the other work goes. 

The whitespace and line length refactoring will touch a great many lines of code throughout the project. To avoid massive merge conflicts, the hope is to get it over and done with within a narrow window of time. People should consider the codebase "frozen" during that window, and should have any current work in progress wrapped up and pulled in before the refactoring starts. So far, no one except Jon has voiced any concerns. If you have them, now is the time to do so! In particular, if you are working on something that you will want Jon to merge into PsychoPy/master, let us know asap and we'll work with it.

Here's a proposed timeline of activity. Hopefully each of the first two items will only take a week to bring to a stable state (for whitespace and line-length).

1. refactor everything within psychopy/app/  -- start Jan 29th, commit on or before Feb 5

2. refactor everything else, except for psychopy/iohub/ -- start Feb 5, commit on or before Feb 12

3. refactor psychopy/iohub/ -- later in Feb, working with Sol as his schedule permits

If anyone wants to help with this, let me know. I'll use autopep8 to do the whitespace (quick, easy, safe), and commit that to a branch in my fork. You can then pull that branch, work on line-lengths, and ask me to pull those into my branch. At the end of the week I'll squash all that work into my master branch, and ask Jon to pull that into upstream master. 

Please share concerns, questions, etc. 

--Jeremy

[Jon Peirce]

Sounds good Jeremy. Those two weeks are in my diary. :-)

[Richard Höchenberger]

Hi Jeremy,
I am going to be busy until (including) Jan 31, but will happily start
working on the refactoring after that! Looking forward!

Cheers,

Richard

[Jeremy Gray]

Sounds good Jeremy. Those two weeks are in my diary. :-)

Cool. I'll try to do the copyright year and a few other updates (like new-style classes) this week. Also, I can skip sound.py for the time being, I know that is currently going through some evolution.

--Jeremy

[Jeremy Gray]

I am going to be busy until (including) Jan 31, but will happily start
working on the refactoring after that! Looking forward!

Awesome. I'll be in touch, off list.

--Jeremy

 

Cheers,

    Richard