On Tue, May 29, 2018 at 06:29:50PM +1200, Greg Ewing wrote:
> Steven D'Aprano wrote:
> >But it doesn't matter: regular users can call chown -R:
>
> Only if you're not actually telling it to change anything.
That's not correct. Look closely at my example: the file ownership
recursively changed fr
Hello,
I've been working on a patch which speeds up shutil.copy* operations for
all 3 major platforms (Linux, Windows, OSX):
https://bugs.python.org/issue33671
Since the speedup is quite consistent I'd love to see this merged in, but
considering shutil.copy* is quite crucial I wanted to hear other
Whops, I hit "send" too soon. Sorry about the messed up message.
On Tue, May 29, 2018 at 10:56 AM, Giampaolo Rodola'
wrote:
> Hello,
> I've been working on a patch which speeds up shutil.copy* operations for
> all 3 major platforms (Linux, Windows, OSX):
> https://bugs.python.org/issue33671
> Si
Hello,
Python 3.7 removes the undocumented internal import `os.errno`.
We consider that a an implementation detail, which can be changed
*without notice* even in a bugfix release. Projects that depend on it
are incorrect and should be fixed.
On bpo-33666, there's a debate on whether the remova
> I don't think we can reasonably expect people who used built-in help as
> above to go back and check that Python's official docs *do not* contain
> `os.errno`.
Agree, but...
> Effectively, while `os.errno` is not very *discoverable*
> using official docs alone, I don't think calling it *undoc
On Tue, May 29, 2018 at 8:06 PM, Petr Viktorin wrote:
> I don't think we can reasonably expect people who used built-in help as
> above to go back and check that Python's official docs *do not* contain
> `os.errno`. Effectively, while `os.errno` is not very *discoverable* using
> official docs alo
On Tue, May 29, 2018 at 12:06:42PM +0200, Petr Viktorin wrote:
> Hello,
> Python 3.7 removes the undocumented internal import `os.errno`.
> We consider that a an implementation detail, which can be changed
> *without notice* even in a bugfix release. Projects that depend on it
> are incorrect and
On 05/29/18 13:57, Steven D'Aprano wrote:
On Tue, May 29, 2018 at 12:06:42PM +0200, Petr Viktorin wrote:
Hello,
Python 3.7 removes the undocumented internal import `os.errno`.
We consider that a an implementation detail, which can be changed
*without notice* even in a bugfix release. Projects th
(Apologies if you received an empty/unfinished e-mail here earlier; I
hit Send by mistake.)
On 05/29/18 13:57, Steven D'Aprano wrote:
On Tue, May 29, 2018 at 12:06:42PM +0200, Petr Viktorin wrote:
Hello,
Python 3.7 removes the undocumented internal import `os.errno`.
We consider that a an impl
> I agree that it's technically well within our rights to remove it
> without notice.
> But ... PEP8? A style guide defines what is a CPython implementation
> detail? That's not a place to point to while saying "told you so!" --
> perhaps "sorry for the inconvenience" would be more appropriate :)
On 29 May 2018 at 06:23, Giampaolo Rodola' wrote:
> ...as in (not tested):
>
> def _rchown(dir, user, group):
> for root, dirs, files in os.walk(dir, topdown=False):
> for name in files:
> chown(os.path.join(root, name), user, group)
>
> def chown(path,
On 29 May 2018 at 20:06, Petr Viktorin wrote:
> Is that reasoning sound?
> Should our policy on removing internal imports take that into account?
>
As Steven noted, the normative answer to this is in PEP 8:
https://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces
Since `os.errno
29.05.18 13:06, Petr Viktorin пише:
As you can see, the built-in documentation does not contain *any*
warnings against using `os.errno`.
You might think the fact that it's called "errno" and not "os.errno" is
a red flag, but it's not, really -- "os.path" is (on my system) named
"posixpath", yet
On Tue, May 29, 2018 at 05:37:06PM +0300, Serhiy Storchaka wrote:
> We have removed over 100 module attributes in 3.6 [2] and over 200
> module attributes in 3.7 [3].
>
> Some of these removals broke third-part projects [4], even removals of
> underscored names.
Yes, people will rely on undocu
I have been doing speed testing on our network frequently enough over the
last five year that I have a good feel for these changes. I have been
benchmarking various means for copying files of 1.0-500 MB between
workstations on our 1 Gbps LAN to local servers, and on our WAN which was
just upgraded
Yes. What Steve says at the end. Let's be kind and mention this one on the
release notes. But not all the others.
On Tue, May 29, 2018, 07:57 Steven D'Aprano wrote:
> On Tue, May 29, 2018 at 05:37:06PM +0300, Serhiy Storchaka wrote:
>
> > We have removed over 100 module attributes in 3.6 [2] and
Honestly, despite the occasional use case(1), I'm not sure that this is a
battery we need in the stdlib. Nobody seems too excited about writing the
code, and when the operation is needed, shelling out to the system chown is
not too onerous. (Ditto for chmod.)
(1) Not even sure that a use case was
On Tuesday, 29 May 2018 16:42:13 BST Eric Fahlgren wrote:
snip...
> On our WAN, which has a VPN endpoint 3000 miles from our office, routing
> back to a test server another 2000 miles inside the network (tracert shows
> 12-15 hops, 200 ms latency, arrrg), copying is slow no matter what: we are
>
Nah??
-- Carl Smith
[email protected]
On 24 May 2018 at 19:24, Carl Smith wrote:
> This is another suggestion for new syntax for assigning a name to the value
> of the predicate in an if, elif or while statement. It still uses `as` for
> its keyword, but with (more flexible) params instead
On Wed, May 30, 2018 at 4:48 AM, Carl Smith wrote:
> Nah??
Nah. It's already been discussed at interminable length as part of PEP
572. Feel free to browse that document.
ChrisA
___
Python-ideas mailing list
[email protected]
https://mail.python.o
On Tue, May 29, 2018 at 10:17 AM Barry Scott wrote:
> On Tuesday, 29 May 2018 16:42:13 BST Eric Fahlgren wrote:
>
> Maybe you are suffering from TCP windows scaling not work well enough?
>
Thanks for the tip, I'll have to mention that to our IT infrastructure guys
and see if they can check it ou
Ah. Nice one. I'll look through that.
-- Carl Smith
[email protected]
On 29 May 2018 at 19:52, Chris Angelico wrote:
> On Wed, May 30, 2018 at 4:48 AM, Carl Smith wrote:
> > Nah??
>
> Nah. It's already been discussed at interminable length as part of PEP
> 572. Feel free to browse that docu
On 5/29/2018 12:09 PM, Guido van Rossum wrote:
Yes. What Steve says at the end. Let's be kind and mention this one on
the release notes. But not all the others.
How about adding a general reminder. In Porting to 3.7:
"Imports into a module are a private implementation detail unless
otherwise
Have we received complaints about other cases? Whenever this breaks code
for which I am responsible I just blush and fix it, I don't complain.
Repeating the same warning typically just causes warning fatigue rather
than helping anyone.
On Tue, May 29, 2018 at 3:53 PM, Terry Reedy wrote:
> On 5/
Steven D'Aprano wrote:
Look closely at my example: the file ownership
recursively changed from steve.steve to steve.users.
You're quite right. I hadn't realised that chown can be
used to change the group as well as the user. It's permitted
to change the group to one that the user is a member of
BTW, I wouldn't argue that Python shouldn't provide things
that are only useful to root. While writing setuid utilities
in Python is a bad idea for lots of reasons, I don't think
there's anything wrong with becoming root by another means
and then running a Python program that you know well enough
On 5/29/2018 6:06 AM, Petr Viktorin wrote:
Python 3.7 removes the undocumented internal import `os.errno`.
Among a couple of hundred others, including some from idlelib.
We consider that a an implementation detail, which can be changed
*without notice* even in a bugfix release.
We core dev
On Wed, May 30, 2018 at 9:11 AM, Greg Ewing wrote:
> BTW, I wouldn't argue that Python shouldn't provide things
> that are only useful to root. While writing setuid utilities
> in Python is a bad idea for lots of reasons, I don't think
> there's anything wrong with becoming root by another means
>
On 29/05/2018 23:58, Guido van Rossum wrote:
> Have we received complaints about other cases? Whenever this breaks
> code for which I am responsible I just blush and fix it, I don't
> complain. Repeating the same warning typically just causes warning
> fatigue rather than helping anyone.
>
Configuration management tools with far more code than this are regularly
run with root privileges.
OTOH, Salt and Ansible, for example, both support recursive chown and
chmod; and report what actually changed. Yum/dnf probably do, too.
Supporting recursive chmod/chown OOB may be useful. That it
30 matches
Mail list logo
