Change indentation to four spaces

[jmcgeheeiv]

Contrary to PEP-8, pyfakefs currently uses two space indentation. There's plenty more contrary to PEP-8, but that's a topic for another day.

Perhaps using a tool like the formatter in PyDev:

• Change only the white space to realize four space indentation and perhaps some other spacing or indentation goal
• Do it in as few commits as possible, preferably a single squashed commit

[mrbean-bremen]

I did this now while no PR was open and no-one working overseas to avoid any merge problems (national holiday here, so I got the time...).
Please check if this can be closed.

[jmcgeheeiv]

Magnificent. Thank you.

Regarding committers, it's just you and me, Kid. Where are you, by the way?

[mrbean-bremen]

Ah, the quote sounded familiar, but I had to look it up... I'm in Bremen, as you could have guessed by my nick :) Which for some Americans, I have to explain as "the city where Becks is made" - but I guess I don't have to for you :P
Meaning that I'm 9 hours ahead of you, if you on the West Coast (or 7 hours behind while you are in Japan). I still lack some kind of communication channel on GitHub not issue-related, but I will just add comments to random issues like this one.
Thanks for getting out the pypi release - I understand that you didn't release 2.8 accidentally, as I was still waiting for that...

On another note:
Now that the release is out, I would propose to remove Python 3.2 from the travis tests - as it does not have the u literal for unicode like 3.3, some string related tests are quite awkward to write. Most of the encoding tests I did only for Python 3 for this reason, though they also should work for Python 2.6 and 2.7. Removing 3.2 from the tests does not remove 3.2 support, it would only mean that the tests could not be run under 3.2 (also, 3.2 is propably not used anymore). And we could add 3.6 (aka nightly) to travis.
I'm not so sure about 2.6 - it is end of life now more than 4 years, but I'm not sure if it is still used somewhere (and still will be with a new pyfakefs version). Would be nice to remove some 2.6 related workarounds to go ahead for better python 3 support.

And a final note, before this turns into a novel - even if it's just you and me, I will not go ahead and add changes (apart from some fixes) without discussing it with you.

[jmcgeheeiv]

I know Bremen suffered heavy bombing during WWII. I believe there is a Japanese children's song about Bremen. I think the children's song leaves out the air raids.

Red Hat Enterprise Linux 6 uses Python 2.6. I do not know about RHEL 7. Dropping Python 3.2 sounds relatively harmless, especially if it is getting in the way.

[mrbean-bremen]

Interesting - I bet the song is about the Town Musicians of Bremen. So, no air raids expected there.

RHEL 7 uses Python 2.7, but I agree - let that wait until a later release. I added a PR with the other change (-3.2), also fixed a bug there in the new encoding stuff that surfaced after I enabled the tests for Python 2. The test for 3.6 failed as it could not find mox3 - I may check this later (or do you have an idea?)

[jmcgeheeiv]

I have no idea about mox3 for Python 3.6. Earlier I was tempted to grab just the little piece I am using, but then we would have to maintain it.

Note that earlier I removed mox and replaced it with mock, which comes standard with Python. It was a disaster so I had to move back to mox.

[jmcgeheeiv]

You are very observant, @mrbean-bremen , so I hope you noticed that pyfakefs.org will take you to this project. It's a handy shortcut.

[mrbean-bremen]

Yes, I noticed your change in setup.py and tried it out. How does that work?

[jmcgeheeiv]

I just bought the domain and pointed it at the project. I make no personal claim to pyfakefs.org--I am just the custodian.

[mrbean-bremen]

And now for something completely different - I had a look at the remaining issues (with the increased responsibility of a collaborator :P), there are only 4 left that are not fixed.
The scandir one shall be easy (it's practically a performance enhanced listdir), I could have a go at this if you don't mind.
The pathlib is a larger thing, I never used it and have no idea how heavily it is used at all and if it's worth it at all.
The "path is stubbed out to aggressively" maybe some configuration issue - as I understand it, you either can stub out uses of "from os import path" like it is now, or you don't do that so you can have your own path module. Maybe add the possibility to configure this?
The remaining one with pytest I haven't really looked into - never used pytest so far.

Any thoughts?

[mrbean-bremen]

Great (about the bought domain)!

[jmcgeheeiv]

I would wait for more votes on pathlib. Like you, I have never used it.

The "path is stubbed out to aggressively" is easy for the user to work around, and I think supporting from os import path is more important. Your idea of a configuration option is good.

In principle, PyTest is important, but I gave it a go when the issue first came up, and it was too gnarly. A developer with decent PyTest experience would be the ideal candidate to fix this. You and I, with our lack of PyTest experience, not so much. Maybe we wait for a PyTest savior to save us. That's what saviors do, after all.

[mrbean-bremen]

Ok :) I will have a go at the scandir one somewhere this week, and maybe later at the configuration issue with the path import.