On 5/26/21 12:25 AM, Cameron Simpson wrote:
> On 25May2021 19:21, hw <hw@adminart.net> wrote:
>> On 5/25/21 11:38 AM, Cameron Simpson wrote:
>>> On 25May2021 10:23, hw <hw@adminart.net> wrote:
>>>> if status != 'OK':
>>>> print('Login failed')
>>>> exit
>>>
>>> Your "exit" won't do what you want. I expect this code to raise a
>>> NameError exception here (you've not defined "exit"). That _will_ abort
>>> the programme, but in a manner indicating that you're used an unknown
>>> name. You probably want:
>>>
>>> sys.exit(1)
>>>
>>> You'll need to import "sys".
>>
>> Oh ok, it seemed to be fine. Would it be the right way to do it with
>> sys.exit()? Having to import another library just to end a program
>> might not be ideal.
>
> To end a programme early, yes. (sys.exit() actually just raises a
> particular exception, BTW.)
>
> I usually write a distinct main function, so in that case one can just
> "return". After all, what seems an end-of-life circumstance in a
> standalone script like yours is just an "end this function" circumstance
> when viewed as a function, and that also lets you _call_ the main
> programme from some outer thing. Wouldn't want that outer thing
> cancelled, if it exists.
>
> My usual boilerplate for a module with a main programme looks like this:
>
> import sys
> ......
> def main(argv):
> ... main programme, return like any other function ...
> .... other code for the module - functions, classes etc ...
> if __name__ == '__main__':
> sys.exit(main(sys.argv))
>
> which (a) puts main(0 up the top where it can be seen, (b) makes main()
> an ordinary function like any other (c) lets me just import that module
> elsewhere and (d) no globals - everything's local to main().
>
> The __name__ boilerplate at the bottom is the magic which figures out if
> the module was imported (__name__ will be the import module name) or
> invoked from the command line like:
>
> python -m my_module cmd-line-args...
>
> in which case __name__ has the special value '__main__'. A historic
> mechanism which you will convince nobody to change.

Thanks, that seems like good advice.

> You'd be surprised how useful it is to make almost any standalone
> programme a module like this - in the medium term it almost always pays
> off for me. Even just the discipline of shoving all the formerly-global
> variables in the main function brings lower-bugs benefits.

What do you do with it when importing it? Do you somehow design your
programs as modules in some way that makes them usable as some kind of
library funktion?

>>> I've done little with IMAP. What's in msgnums here? Eg:
>>> print(type(msgnums), repr(msgnums))
>>> just so we all know what we're dealing with here.
>>
>> <class 'list'> [b'']
>>
>>>> message_uuids = []
>>>> for number in str(msgnums)[3:-2].split():
>>>
>>> This is very strange. [...]
>> Yes, and I don't understand it. 'print(msgnums)' prints:
>>
>> [b'']
>>
>> when there are no messages and
>>
>> [b'1 2 3 4 5']
>
> Chris has addressed this. msgnums is list of the data components of the
> IMAP response. By going str(msgnums) you're not getting "the message
> numbers as text" you're getting what printing a list prints. Which is
> roughly Python code: the brakcets and the repr() of each list member.

Well, of course I exepect to get message numbers returned from such a
library function, not the raw imap response. What is the library for
when I have to figure it all out by myself anyway.

> Notice that the example code accessed msgnums[0] - that is the first
> data component, a bytes. That you _can_ convert to a string (under
> assumptions about the encoding).

And of course, I don't want to randomly convert bytes into strings ...

> By getting the "str" form of a list, you're forced into the weird [3:-2]
> hack to ttrim the ends. But it is just a hack for a transcription
> mistake, not a sane parse.

Right, thats why I don't like it and is part of what makes it so unwieldy.

>> So I was guessing that it might be an array containing a single a
>> string and that refering to the first element of the array turns into
>> a string with which split() can used. But 'print(msgnums[0].split())'
>> prints
>>
>> [b'1', b'2', b'3', b'4', b'5']
>
> msgnums[0] is bytes. You can do most str things with bytes (because that
> was found to be often useful) but you get bytes back from those
> operations as you'd hope.

As someone unfamiliar with python, I was wondering what this output
means. It could be items of an array that are bytes containing numbers,
like, in binary, 00000001, 00000010, and so on. That's more like what I
would expect and not something I would want to convert into a string.

>> so I can only guess what that's supposed to mean: maybe an array of
>> many bytes? The documentation[1] clearly says: "The message_set
>> options to commands below is a string [...]"
>
> But that is the parameter to the _call_: your '(UID)' parameter.

No, it's not a uid. With library, I haven't found a way to get uids.
The function to call reqires a string, not bytes or an array of bytes.

The included example contradicts the documentation and leaves potential
users of the library to guessing.

>> I also need to work with message uids rather than message numbers
>> because the numbers can easily change. There doesn't seem to be a way
>> to do that with this library in python.
>
> By asking for UIDs you're getting uids. Do they not work in subsequent
> calls?

How do you force the library to give uids instead of message numbers,
and how do you make it do something with a particular message by uid?

>> So it's all guesswork, and I gave up after a while and programmed what
>> I wanted in perl. The documentation of this library sucks, and there
>> are worlds between it and the documentation for the libraries I used
>> with perl.
>
> I think you're better of looking for another Python imap library. The
> imaplib was basic functionality to (a) access the rpotocol in basic form
> and (b) conceal the async stuff, since IMAP is an asynchronous protocol.
>
> You can in fact subclass it to do better things. Other library might do
> thatm or they might have written their own protocol implementations.

I haven't really found a better one.

>> That doesn't mean I don't want to understand why this is so unwieldy.
>> It's all nice and smooth in perl.
>
> But using what library? Something out of CPAN? Those are third party
> libraries, not Perl's presupplied stuff.
The libraries I used with perl all come with Fedora, so they are
presupplied and only need to be installed. You can find them on cpan as
well. It's very convenient.

> The equivalent for Python is
> pypi.org. Look there.

Yes, someone pointed it out, and I did. They have an imap-tools library
which looks most promising at first, and its documentation tells me that
you do can some IMAP operations with messages --- and nothing with
messages themselves, like getting from the server.

So it seems that IMAP support through python is virtually non-existent.

>>> It is just breaking apart data[0] into strings which were separated by
>>> whitespace in the response. And then using those same strings as keys
>>> for the .fecth() call. That doesn't seem complex, and in fact is blind
>>> to the format of the "message numbers" returned. It just takes what it
>>> is handed and uses those to fetch each message.
>>
>> That's not what the documentation says.
>
> The _example code_ is blind to them, whatever the semantics of the docs.
> It just gets the uids and fetches with them. Aside from .split(),
> there's no parsing or deep understanding of the uid.

There is no telling what might happen to the messages when using
functions that randomly convert bytes in weird ways and that contradict
the documentation. Why would I trust this library not to accidentially
delete all my emails or to not do other harmful things?

>>> IMAP's quite complex. Have you read RFC2060?
>>>
>>> https://datatracker.ietf.org/doc/html/rfc2060.html
>>
>> Yes, I referred to it and it didn't become any more clear in
>> combination with the documentation of the python library.
>
> IMAP's like that :-)