date:20190718

[issue37612] os.link(..., follow_symlinks=True) broken on Linux

2019-07-18 Thread Serhiy Storchaka



Serhiy Storchaka  added the comment:

Not always linkat() can be used instead of link(). But on Windows (where there 
is no linkat()) os.link() creates a new link to the symbolic link itself. This 
is yet one argument for making follow_symlinks=False by default and changing 
the default behavior of os.link() on NetBSD.

--
nosy: +eryksun, larry, serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37555] _CallList.contains doesn't always respect ANY.

2019-07-18 Thread Karthikeyan Singaravelan



Change by Karthikeyan Singaravelan :


--
nosy: +cjw296, mariocj89, michael.foord

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37618] Docs: Code example locations in stdtypes

2019-07-18 Thread Kyle Stanley



New submission from Kyle Stanley :

In the docs for the module stdtypes, the code example for several commonly used 
functions are in the bytearray section instead of the str section, where new 
users are far more likely to look. The new users are much more likely to 
benefit from seeing examples of these functions. A few examples of this 
include: islower(), isupper(), and istitle(). Since the functionality is very 
similar for functions such as str.islower() and bytearray.islower(), it doesn't 
seem necessary to include separate examples for each. With that in mind, here's 
a couple of potential solutions:

1) Move the location of the code examples to the str equivalent. This would 
require only removing the 'b' notation proceeding the strings. A link to the 
str equivalent could be potentially provided.

2) Provide a reference link to equivalent bytearray function in the str 
function's summary. This would be a bit easier since the code examples would 
not have to me modified or moved. However, for reasons stated above, it seems 
to make a bit more sense to have the examples be in the str functions rather 
than in the bytearray functions.

I can start working on a PR to address this, but I'll wait on some feedback 
first.

--
assignee: docs@python
components: Documentation
messages: 348104
nosy: aeros167, docs@python
priority: normal
severity: normal
status: open
title: Docs: Code example locations in stdtypes
versions: Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37555] _CallList.contains doesn't always respect ANY.

2019-07-18 Thread Elizabeth Uselton

Elizabeth Uselton added the comment:

Just added a fix for the tests I added in the last commit showing the order
sensitivity in assertEqual when dealing with ANY and _Call or _CallList
objects. _Call and _CallList currently depend on ordering to correctly process
that an object being compared to ANY with __eq__ should return True. I put more
notes in the commit message.

A note on the two newer tests: I want to be sensitive to the idea that I might
be pushing back against desired behavior here. I think there is a case to be
made that one should expect mock.assertEqual(a, b) to implement a == b, and not
care about b == a, in which case maybe order sensitivity in assertEqual makes
sense. That said, today I showed a few of my most Python experience heavy
colleagues the tests showing that assertEqual was order sensitive when passed
_Call or _CallList objects, and based on anecdotal evidence the existing
behavior definitely violates the principle of least astonishment. Additionally,
the test Karthikeyan kindly linked me
https://github.com/python/cpython/blob/master/Lib/unittest/test/testmock/testhelpers.py#L46
seems to imply that an order agnostic assertEqual is the desired behavior.

A note on the fix: This fix feels like it's not as small as it could be. I am
still musing over whether it'd be better if instead of the or statements and
swapping the comparison order in _CallList's __contains__ method, I made a
wrapper that would swap that comparison order in the case that one of the
arguments is a BoundArgument, since that was the original problem. That fix
would probably not affect the order sensitivity of assertEqual, so it's
partially about what we want there. I'll play around with it and see what I can
discover. I'll also see if I can do anything to more explicitly to check for
ANY, as Paul suggested.

I'm very curious what you all think about whether the assertEqual behavior is a
feature or a bug, and if the other fix idea seems better than this one. If
neither of these ideas seem like a good fix, I'd love some guidance on what
concerns are and what might be a good approach to try next.

73 matches

Mail list logo