Release 1.6.8 (and 1.7 notice)

[henryiii]

We need to make a release fairly soon, while Travis is still able to run Python 2.6. I'd like to make a 1.6.8 release, and then drop Python 2.6 and non-setuptools builds from master. This would start on the 1.7 work; any critical fixes or easy patches could be backported to a 1.6 branch if needed, but 1.7 would not support Python 2.6. This should allow some cleanup as well. If you are using Python 2.6, which people on RHEL6 based systems might be, plumbum would need to be restricted to <1.7.

Todo:

• Check translations
• Fill out changelog
• Evaluate old PRs

[henryiii]

@koreno Let's aim for 1.6.8 at the end of next week (I'm on vacation till Monday). So by the 11th of August, maybe sooner.

[koreno]

sounds great!

[AndydeCleyre]

IMO #245 should be resolved before a new release.

[gsimbr]

Do you think it is feasible that you will make the new release by the end of the week?

[henryiii]

Yes, it should happen. I and my family were sick this weekend, otherwise it would’ve been out yesterday.

[gsimbr]

Any update regarding the release? Is there any PR pending or work to be done where I can assist?

[AndydeCleyre]

@gsimbr I may be alone in my opinion about the importance of #245 being resolved before a release, but if you agree, there's that. But it still requires an author's clarification of the desired behavior.

[henryiii]

I was waiting for @245, will address that next. I've been both sick and traveling, so my schedule has been off. I'll address this, and then I think we are ready for a release.

[henryiii]

My laptop charger died on my last trip, so won't be able to use my computer till I get the charger from my office on Monday. If someone can see if they can fix the failing test, that would help.

[henryiii]

I'll release 1.6.8 in a day or two unless someone brings anything up.

[AndydeCleyre]

I need to check when I'm back at a computer, but I'm not sure all the docs are accurate regarding read, write, and defaulting to bytes vs str.

EDIT: Here's the behavior I'm not sure matches the docs:

In [1]: from plumbum import local      
In [2]: p = local.path('./dev-requirements.txt')                               
In [3]: p.read?

Signature: p.read(encoding=None, mode='r')
Docstring:
returns the contents of this file. By default the data is binary (``bytes``), but you can
specify the encoding, e.g., ``'latin1'`` or ``'utf8'``
File:      ~/Code/plumbum/plumbum/path/local.py
Type:      method

In [4]: type(p.read())                 
Out[4]: str
In [5]: p.write?

Signature: p.write(data, encoding=None, mode=None)
Docstring:
writes the given data to this file. By default the data is expected to be binary (``bytes``),
but you can specify the encoding, e.g., ``'latin1'`` or ``'utf8'``
File:      ~/Code/plumbum/plumbum/path/local.py
Type:      method

In [6]: p.write("this is a string")    
In [7]: p.write(b"these are bytes")

[AndydeCleyre]

Oh, and a reminder that #443 has another doc mismatch, but I don't know what the correct behavior should be there.

[henryiii]

@AndydeCleyre can you make a PR to fix the docs? I'm back after a week trip to see family in CA; but I have a long list of things to catch up on so will be a little while if I have to make the PR. I think otherwise we are ready for release.

[AndydeCleyre]

I can make a PR for the read/write docs tonight (US Eastern), but I can't for #443 because I really don't know the "correct" behavior there.

[AndydeCleyre]

Sorry, things got away from me and I had to do some traveling. I'm looking at read/write behavior, and here's what I see:

read (Linux, Python3)

1. read will return a bytes object if encoding is None and mode is 'rb', otherwise it will return a str.
2. if encoding is not None, mode will be forced to include 'b'.
3. the docstring comes from an abstract method in base.py, which doesn't actually include the mode parameter.

So should that docstring avoid mentioning mode? If mode is not specified (defaults to 'r'), according to (1) and (2) the return type will be str (or there will be a UnicodeDecodeError). Or should a new docstring be added to fully implemented read methods that do accept mode?

If we don't mention mode, would the following be good (true) enough?:

returns the contents of this file as a ``str``. By default the data is read as text, 
but you can specify the encoding, e.g., ``'latin1'`` or ``'utf8'``

Here's a table I made along the way, for read behavior:

Text file
---------

+----------+------+-----------+-------------+
| encoding | mode | open-mode | return type |
+==========+======+===========+=============+
| None     | rb   | rb        | bytes       |
| None     | r    | r         | str         |
| 'utf8'   | rb   | rb        | str         |
| 'utf8'   | r    | rb        | str         |
| 'latin1' | rb   | rb        | str         |
| 'latin1' | r    | rb        | str         |
+----------+------+-----------+-------------+

Image file
----------

+----------+------+-----------+-------------+
| encoding | mode | open-mode | return type |
+==========+======+===========+=============+
| None     | rb   | rb        | bytes       |
| None     | r    | -         | -           |
| 'utf8'   | rb   | -         | -           |
| 'utf8'   | r    | -         | -           |
| 'latin1' | rb   | rb        | str         |
| 'latin1' | r    | rb        | str         |
+----------+------+-----------+-------------+

write (Linux, Python3)

Here's the local path write method:

@_setdoc(Path)
def write(self, data, encoding=None, mode=None):
    if encoding:
        data = data.encode(encoding)
    if mode is None:
        if isinstance(data, six.unicode_type):
            mode = 'w'
        else:
            mode = 'wb'
    with self.open(mode) as f:
        f.write(data)

This looks like encoding is not, as the current docstring suggests, about the input data format, but about converting it on its way to being written. If that's so, is this ok?

writes the given data to this file. By default the data is written as-is 
(either text or binary), but you can specify the encoding, e.g., ``'latin1'`` or ``'utf8'``

[henryiii]

Released.

[koreno]

👏 - Ofer

…

On Wed, Oct 30, 2019 at 11:25 PM Henry Schreiner ***@***.***> wrote: Released. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#445?email_source=notifications&email_token=AABMCRZ4PIDOB4NAF26NN43QRH3UTA5CNFSM4HNGGW4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECV2EEI#issuecomment-548119057>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABMCR7QVJLOEAZIE7PNNW3QRH3UTANCNFSM4HNGGW4A> .