[issue38825] psutil.disk_usage - Lacking documentation
New submission from Lord Anton Hvornum :
https://docs.python.org/3.8/library/shutil.html#shutil.disk_usage
There's no mention that this helper function simply calls `os.statvfs()` in the
background. Something that is quite troubling when you're trying to get
disk_usage (or disk-information) about a non-mounted drive.
It's clear as day if you see the code:
https://github.com/python/cpython/blob/master/Lib/shutil.py#L1249
But if you're a novice user, this will puzzle your brain.
Because the end result will be that `disk_usage()` returns the same information
for all these cases:
shutil.disk_usage('/dev/sda')
shutil.disk_usage('/dev/sdb')
shutil.disk_usage('/dev/sdc')
Which translates to:
os.statvfs('/dev/sd?')'
--
All I'm asking, is that we add a little note stating:
"On *mounted* filesystems" or a reference to `os.statvfs()` where it's clearly
stated that it runs on mounted filesystems.
Thanks in advance.
------
assignee: docs@python
components: Documentation
messages: 356771
nosy: Lord Anton Hvornum, docs@python
priority: normal
severity: normal
status: open
title: psutil.disk_usage - Lacking documentation
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue38825>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38825] shutil.disk_usage - Lacking documentation
Lord Anton Hvornum added the comment: xtreak: You are correct, that was a typo. My apologies. -- ___ Python tracker <https://bugs.python.org/issue38825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Lord Anton Hvornum added the comment: I agree with Jan-Philip Gehrcke, would have been nice to have had this. Pretty pissed reading through this ancient issue. In regards to how people treat other volunteers: We're all working for free, and I think expectations from people with authoritative powers must have room for accepting a initially lower contribution standard than they themselves claim to produce. Mainly to not crush the will to help and contibute, but also because the attitude could be a lot better towards fellow programmers. It would also allow for a more iterative process in achieving higher standards. Otherwise you limit yourself to a very select few in the contribution process. Not to mention a lot of "grunt work" could be done by people having an idea, but not nessecarily the same "academic background" in terms of producing perfect code. I've seen this across numerous Open Source projects, and quite frankly it deter me from ever contributing. PoC code shouldn't be seen as garbage, but a first step in creating new fresh things. Someone with more knowledge should and could step in and clean up things that are deamed "unfit" for production or help said contributor to understanding why certain things needs to be improved, not just blatently say patches needs to be improved. This whole "It ain't perfect, we don't touch it" is elitism at it's finest. Stop it, and have a meaningful discussion instead. -- nosy: +Lord Anton Hvornum ___ Python tracker <https://bugs.python.org/issue16487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29860] smtplib.py doesn't capitalize EHLO.
New submission from Lord Anton Hvornum:
```
File "mail.py", line 9, in
smtp_server.starttls(context)
File "/usr/lib/python3.6/smtplib.py", line 748, in starttls
self.ehlo_or_helo_if_needed()
File "/usr/lib/python3.6/smtplib.py", line 600, in ehlo_or_helo_if_needed
(code, resp) = self.helo()
File "/usr/lib/python3.6/smtplib.py", line 429, in helo
(code, msg) = self.getreply()
File "/usr/lib/python3.6/smtplib.py", line 393, in getreply
raise SMTPServerDisconnected("Connection unexpectedly closed")
```
This happens due to the server expecting commands (like EHLO, STARTTLS) being
strict upper-case. And when the SMTP command isn't, it drops us.
This is a rare edge case since most mail servers handles shady client data in
numerous different ways (such as gmail never sending QUIT for instance).
I don't know of a work-around for this and the documentation states `EHLO` is
being sent (https://docs.python.org/3/library/smtplib.html), so I guess the lib
assumes that's the case as well.
------
components: Library (Lib)
messages: 289886
nosy: Lord Anton Hvornum
priority: normal
severity: normal
status: open
title: smtplib.py doesn't capitalize EHLO.
versions: Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issue29860>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29860] smtplib.py doesn't capitalize EHLO.
Lord Anton Hvornum added the comment: Turns out, this goes for a lot more commands, such as: ``` Traceback (most recent call last): File "mail.py", line 12, in smtp_server.sendmail(fromaddr, toaddrs, msg) File "/usr/lib/python3.6/smtplib.py", line 866, in sendmail raise SMTPSenderRefused(code, resp, from_addr) ``` The command that the server refused was: mail FROM: size=11 Again, this is mostly because traditionally server commands are upper case (even tho RFC 821 defines that they can be any syntax, such as `mAiL FroM`). But it would be nice if Python could keep consistency in it's syntax IMHO. -- ___ Python tracker <http://bugs.python.org/issue29860> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29860] smtplib.py doesn't capitalize EHLO.
Lord Anton Hvornum added the comment: Seeing as I'm the one who built the server, it sure is out of spec :) I could also quickly correct for this "issue" server-side. So this is more of a "style guideline" change client-side - If no one opposes of keeping commands stylistically the same. -- ___ Python tracker <http://bugs.python.org/issue29860> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31597] ipaddress.hosts() doesn't return anything on a /32 "network"
New submission from Lord Anton Hvornum:
https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv4Network.hosts
I couldn't find anywhere in the documentation mentioning the fact that doing
the following would return nothing:
>>> import ipaddress
>>> net = ipaddress.ip_network('127.0.0.1/32')
>>> list(net.hosts())
[]
For all intense and purposes, that network still contains hosts.
That being one single lonely host of '127.0.0.1'.
It's illogical to not return any hosts if there actually are one or more in
there.
Now the programmer has to do a one-off-check to see if this particular defined
network (of a huge list usually)
happens to end with /32, then it needs to treat the item not as a defined
network (even tho it is with a netmask),
but rather strip the netmask and treat it as a single host entity.. It makes no
sense if you're iterating over a huge list of network infrastructure.
------
components: Library (Lib)
messages: 303063
nosy: Lord Anton Hvornum
priority: normal
severity: normal
status: open
title: ipaddress.hosts() doesn't return anything on a /32 "network"
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue31597>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31597] ipaddress.hosts() doesn't return anything on a /32 "network"
Lord Anton Hvornum added the comment:
This is still a very strange behavior and I can't see why this still
shouldn't return a IP address.
if the broadcast, network and host address are all the same, that should
call for a exceptional behavior from the library.
Because 127.0.0.1/32 is still a usable host address, and it's a way of
isolating a host on a network device for instance, but it's still a host
address in there.. Or am i loosing my marbles?
On Tue, Sep 26, 2017 at 10:08 PM Serhiy Storchaka
wrote:
>
> Serhiy Storchaka added the comment:
>
> This is documented.
>
> hosts()
>
> Returns an iterator over the usable hosts in the network. The usable
> hosts are all the IP addresses that belong to the network, except the
> network address itself and the network broadcast address.
>
> >>> import ipaddress
> >>> ipaddress.ip_network('127.0.0.1/32').network_address
> IPv4Address('127.0.0.1')
> >>> ipaddress.ip_network('127.0.0.1/32').broadcast_address
> IPv4Address('127.0.0.1')
>
> --
> nosy: +serhiy.storchaka
> resolution: -> not a bug
> stage: -> resolved
> status: open -> closed
>
> ___
> Python tracker
> <https://bugs.python.org/issue31597>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue31597>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31597] ipaddress.hosts() doesn't return anything on a /32 "network"
Lord Anton Hvornum added the comment: And this definition is some how immutable? On Tue, Sep 26, 2017 at 10:19 PM Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > Because this is a definition of this method. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue31597> > ___ > -- ___ Python tracker <https://bugs.python.org/issue31597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31597] ipaddress.hosts() doesn't return anything on a /32 "network"
Lord Anton Hvornum added the comment: I was actually just thinking about the same thing, why not just add a optional flag to the already existing function. I get that people are way into backward compatibility, and I won't get into a religious fight over that particular topic as long as there's a fix for this honestly strange behavior. (It's some Windows mentality saying a /32 network doesn't contain any hosts when you come from a network background). Seeing as this is apparently a touchy subject, I won't even try to submit a patch for this because I will screw this up. So I politely ask someone with more intricate knowledge of this library, it's history and use to add a totally optional flag that returns the single host on this very narrow network called /32. On Tue, Sep 26, 2017 at 10:33 PM Eric V. Smith wrote: > > Eric V. Smith added the comment: > > Yes, due to backward compatibility constraints, the behavior is immutable. > > You might be able to argue for another method, say all_hosts(), or > something. Or maybe even a optional parameter to hosts() that defaults to > the existing behavior, but if provided, lets you select a new behavior. > > What I would not support is a change to hosts() (or a new method) that > treats a /32 network specially. > > -- > nosy: +eric.smith > > ___ > Python tracker > <https://bugs.python.org/issue31597> > ___ > -- ___ Python tracker <https://bugs.python.org/issue31597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31597] ipaddress.hosts() doesn't return anything on a /32 "network"
Lord Anton Hvornum added the comment: Historically Windows have struggled with /32 assigned networks. Trying to push such a network address to a Windows machine has usually (not all cases) rendered it connection-less, where as switches, routers, *nix etc have never had any major issues with the logic of a /32 network host isolation. Anyway, it was a slight joke/peck on the history of networking. On Tue, Sep 26, 2017 at 10:53 PM Eric V. Smith wrote: > > Eric V. Smith added the comment: > > You lost me at "some Windows mentality". I come from a networking > background. > > Sorry, I don't care enough about this issue to pursue it. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue31597> > ___ > -- ___ Python tracker <https://bugs.python.org/issue31597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
