[issue31264] Import Package/Module through HTTP/S repository
R. David Murray added the comment: Indeed, I personally can't imagine a circumstance in which I'd want to use this feature. Even inside an org. It also has security implications, which would also make it a harder sell. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31264> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31263] Assigning to subscript/slice of literal is permitted
R. David Murray added the comment: Sometimes it does, sometimes we make the change in a feature release, often after a deprecation period. But in this case there is doubt that the behavior is incorrect in the first place. This discussion should move to the python-ideas mailing list. I'm going to close the issue, at least for now. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31263] Assigning to subscript/slice of literal is permitted
R. David Murray added the comment: If you would disallow "a = [0]; [5, a][1][:] = [3]", then your proposal will not be accepted, for backward compatibility reasons if nothing else. -- versions: +Python 3.7 -Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31264] Import Package/Module through HTTP/S repository
R. David Murray added the comment: This kind of proposal should start with a discussion on the python-ideas mailing list. You can reopen the issue if there is a consensus for moving forward...but I wouldn't be surprised if this was considered to be a PEP level proposal. -- nosy: +brett.cannon, eric.snow, ncoghlan, r.david.murray resolution: -> later stage: -> resolved status: open -> closed versions: +Python 3.7 -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31264> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31263] Assigning to subscript/slice of literal is permitted
R. David Murray added the comment: I'm don't have a lot of experience with parsers, but I suspect that we consider the cost of making the grammar more complex to be more significant than the benefit we'd get from catching these at compile time. And as Vedran says, defining what can be caught without breaking legitimate things is distinctly non-trivial. I vote to just close this issue. If you come up with a proposal we can reopen. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31263> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31262] Documentation Error
R. David Murray added the comment: No, that sentence is telling you what the *Python*'s behavior is, using C++ terminology. Unlike C++, where class members are private by default, the Python equivalent of class members are public by default. If you can figure out a clearer way to phrase that you may reopen the issue with your suggestion. -- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31262> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31261] unittest fails to properly destruct objects created during setUp if a test fails
R. David Murray added the comment: GC cleanup is not guaranteed to be synchronous. You are observing normal Python behavior here. Cleanup does not happen until the TestCase instance is finalized (thus eliminating the self.dummy reference to your DummyClass). In the case of passing tests, that is after the '.' is printed. In the case of failing tests, that is after the failure is printed, which isn't until the failure summary is printed at after running all tests. If it is important to you that DummyClass be finalized, you need to add an addCleanup call to your setUp method that will do whatever finalization you need done. Including doing 'del self.dummy' (or self.dummy = None) if you need the reference to it gone...but depending on garbage collection is a bad idea, so if you are doing that there is probably something sub-optimal about your design. -- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31253] Python fails to parse triple quoted (commented out) code
R. David Murray added the comment: And being "accepted" does not change the fact that one needs to be aware of the fact that syntactically they are string literals and not syntactic comments. Which was your point. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31253] Python fails to parse triple quoted (commented out) code
R. David Murray added the comment: Just FYI, Vedran, almost everyone gets this one wrong :) I too once thought that triple quoted text used as comments was bad style, but in fact I learned they are an accepted way in Python to do multiline comments. Accepted by Guido, at least: https://sgillies.net/2017/05/30/python-multi-line-comments-and-triple-quoted-strings.html :) It is not a common practice, though, in my observation, since most code editors support automatically prefixing and unprefixing a block with '#' characters, and highlight such blocks as comments while they do not highlight strings used as comments as comments. It is an interesting observation that to use it to comment out a block of code one should use the raw string version. Hopefully the existence of this issue will make that slightly more discoverable. -- nosy: +r.david.murray title: Python fails to parse commented out code -> Python fails to parse triple quoted (commented out) code ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31251] Diameter protocol in Python
R. David Murray added the comment: This isn't a help forum, it is a place for reporting bugs in Python. The kind of question you are asking is best asked on the python-list mailing list (see mail.python.org). -- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed type: resource usage -> ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31239] namedtuple comparison ignores types
R. David Murray added the comment: This is by design: namedtuples are tuples in which you can access the elements by name. If you have a tuple with the same elements, but no name access, they should compare equal, because they are fundamentally tuples. The names are just a convenience. Even if this were not so, it is not something that could be changed, for backward compatibility reasons. If you want a different data types, make them :) -- nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31239> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31231] Travis CI mac test broken: ./python: is a directory
R. David Murray added the comment: Ah, this is probably the issue: https://github.com/python/cpython/pull/3134 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31231] Travis CI mac test broken: ./python: is a directory
R. David Murray added the comment: Heh. I saw the PR but didn't realize it was attached to this issue :) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31231] Travis CI mac test broken: ./python: is a directory
R. David Murray added the comment: The docs you point to are correct (they mention python.exe). The Travis log also shows it using python.exe. So the error message about the directory must be about some other operation than just running the python command. -- components: +macOS nosy: +ned.deily, r.david.murray, ronaldoussoren ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31222] datetime.py implementation of .replace inconsistent with C implementation
R. David Murray added the comment: See also issue 20371. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31210] Can not import modules if sys.prefix contains DELIM
Changes by R. David Murray <rdmur...@bitdance.com>: -- title: Can not import site from sys.prefix containing DELIM -> Can not import modules if sys.prefix contains DELIM ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31210] Can not import site from sys.prefix containing DELIM
R. David Murray added the comment: All right. So the challenge here for windows is: if python is installed on a path that has a semicolon in one of the directory names, is it even possible to populate sys.path such that modules can be imported from the lib directory that is under that path? (IMO we shouldn't jump through big hoops to support this, but if it can be done and the refactoring Nick is contemplating makes it *relatively* easily, it would probably be good to do, to be consistent). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31210] Can not import site from sys.prefix containing DELIM
R. David Murray added the comment:
Is this post wrong then?:
https://superuser.com/questions/584870/how-can-i-add-a-folder-containing-a-semicolon-to-the-windows-path
("I noticed that the semicolon ; is a valid character for Windows (NTFS) file
and directory names.")
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31210>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31218] del expects __delitem__ if __setitem__ is defined
R. David Murray added the comment: I'm not sure we would consider this a bug (the message is accurate), but I wouldn't object to fixing it, since that would indeed seem more consistent with how __delitem__ and del are defined in the language reference. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31218> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27413] Add an option to json.tool to bypass non-ASCII characters.
Changes by R. David Murray <rdmur...@bitdance.com>: -- versions: +Python 3.7 -Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27413] Add an option to json.tool to bypass non-ASCII characters.
Changes by R. David Murray <rdmur...@bitdance.com>: -- nosy: +qingyunha ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31216] Add ensure_ascii argument to json.tool
R. David Murray added the comment: This is a duplicate of issue 27413. -- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Add an option to json.tool to bypass non-ASCII characters. ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31216> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31214] os.walk has a bug on Windows
Changes by R. David Murray <rdmur...@bitdance.com>: -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31214> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31210] Can not import site from sys.prefix containing DELIM
Changes by R. David Murray <rdmur...@bitdance.com>: -- nosy: +brett.cannon, eric.snow, ncoghlan ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31210] Can not import site from sys.prefix containing DELIM
R. David Murray added the comment: OK, that seems reasonable to me. I'll reopen the issue. Assuming other developers agree that this should be changed, I'm not sure if it will qualify as a bug or an enhancement, so I'm leaving versions unselected for now :) -- resolution: not a bug -> stage: resolved -> status: closed -> open ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31210] Can not import site from sys.prefix containing DELIM
R. David Murray added the comment: You mean to create the entries on sys.path that do not come from the PYTHONPATH? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31194] Inconsistent __repr__s for _collections objects
R. David Murray added the comment: This is a duplicate of issue 27541. -- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Repr of collection's subclasses ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31194> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31210] Can not import site from sys.prefix containing DELIM
R. David Murray added the comment: I'm not sure there is anything we should do here, then, because we are conforming to the posix parsing for PATH in our PYTHONPATH implementation. I think if you want to pursue this further you should take it to the python-ideas mailing list. I'm going to close the issue, but you can reopen it if python-ideas thinks it is worth doing something (and there is something we can reasonably do :) -- resolution: -> not a bug stage: -> resolved status: open -> closed type: crash -> behavior ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31210] Can not import site from sys.prefix containing DELIM
R. David Murray added the comment: By DELIM, you mean the shell ':'? As far as I've been able to determine there is no way defined in posix to escape that character. If you can find one, please let us know. (I think the same is true for the Windows semicolon but I'm not sure.) -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31210> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30824] Add mimetype for extension .json
Changes by R. David Murray <rdmur...@bitdance.com>: -- stage: needs patch -> backport needed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30824> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30824] Add mimetype for extension .json
R. David Murray added the comment: New changeset 8204b903683f9e0f037ccfaa87622716019914d7 by R. David Murray (Nate Tangsurat) in branch 'master': bpo-30824: Add mimetype for .json (#3048) https://github.com/python/cpython/commit/8204b903683f9e0f037ccfaa87622716019914d7 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30824> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31193] re.IGNORECASE strips combining character from lower case of LATIN CAPITAL LETTER I WITH DOT ABOVE
David MacIver added the comment: Sure, but 'i' is a single code point. The bug is that the regex matches 'i', not that it doesn't match the actual two codepoint lower case of the string. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31193> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31201] module test that failed doesn't exist
R. David Murray added the comment: Yep, I figured that. That's why I suggested the clarification to the README, if someone wants to generate a PR for it. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31201> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31199] configure checks fail confusingly under --with-address-sanitizer if libasan is missing
Changes by R. David Murray <rdmur...@bitdance.com>: -- title: !HAVE_CLOCK_GETTIME causes problems with _PyTime_FromTimespec -> configure checks fail confusingly under --with-address-sanitizer if libasan is missing ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31199> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31201] module test that failed doesn't exist
R. David Murray added the comment: Replace "test_that_failed" with the name of the test that failed. The README could be improved by saying: If any tests fail, you can re-run the failing test(s) in verbose mode. For example if, 'test_os' and 'test_gdb' failed, you can run:: make test TESTOPTS="-v test_os test_gdb" -- assignee: -> docs@python components: +Documentation -Tests nosy: +docs@python, r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31201> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31193] re.IGNORECASE strips combining character from lower case of LATIN CAPITAL LETTER I WITH DOT ABOVE
New submission from David MacIver:
chr(304).lower() is a two character string - a lower case i followed by a
combining chr(775) ('COMBINING DOT ABOVE').
The re module seems not to understand the combining character and a regex
compiled with IGNORECASE will erroneously match a single lower case i without
the required combining character. The attached file demonstrates this. I've
tested this on Python 3.6.1 with my locale as ('en_GB', 'UTF-8') (I don't know
whether that matters for reproducing this, but I know it can affect how
lower/upper work so am including it for the sake of completeness).
The problem does not reproduce on Python 2.7.13 because on that case
chr(304).lower() is 'i' without the combining character, so it fails earlier.
This is presumably related to #12728, but as that is closed as fixed while this
still reproduces I don't believe it's a duplicate.
--
components: Library (Lib)
files: casing.py
messages: 300219
nosy: David MacIver
priority: normal
severity: normal
status: open
title: re.IGNORECASE strips combining character from lower case of LATIN
CAPITAL LETTER I WITH DOT ABOVE
versions: Python 3.6
Added file: http://bugs.python.org/file47080/casing.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31193>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31184] Fix data descriptor detection in inspect.getattr_static
New submission from David Halter: inspect.getattr_static is currently not identifying data descriptors the right way. Data descriptors are defined by having a __get__ attribute and at least one of the __set__ and __delete__ attributes. Implementation detail: Both __delete__ and __get__ set the same slot called tp_descr_set in CPython. I have attached a patch that fixes the issue IMO. -- files: 0001-Fix-data-descriptor-detection-in-inspect.getattr_sta.patch keywords: patch messages: 300170 nosy: davidhalter priority: normal severity: normal status: open title: Fix data descriptor detection in inspect.getattr_static versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file47078/0001-Fix-data-descriptor-detection-in-inspect.getattr_sta.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31148] Can we get an MSI installer for something past 3.4.4?
R. David Murray added the comment: Steve, when we changed installers was that when we also fixed the security/permissions problems with the install dir? If permissions are the issue the OP's problem may have nothing to do with it not being msi. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4963] mimetypes.guess_extension result changes after mimetypes.init()
David K. Hess added the comment: FYI, PR opened: https://github.com/python/cpython/pull/3062 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4963] mimetypes.guess_extension result changes after mimetypes.init()
Changes by David K. Hess <david_k_h...@mac.com>: -- pull_requests: +3096 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4963> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31167] timedelta produced by datetime.__sub__ does not take Daylight Savings Time into account
R. David Murray added the comment:
It is by design. Read the footnote associated with the subtraction opertion on
datetimes: after subtraction date2 + timedelta = date1, which implies that the
subtraction ignores daylight savings transitions, since the addition does
("Note that no time zone adjustments are done even if the input is an aware
object").
Perhaps the reason why it is designed this way is menioned in the PEP; I
haven't looked.
--
nosy: +r.david.murray
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31167>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31163] Return destination path in Path.rename and Path.replace
R. David Murray added the comment: I agree. The normal python convention is that an immutable object returns the new value when an operation "changes" it, while a mutable object returns None. It seems like replace and rename should follow this convention (and that it would also be convenient). -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31163> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31162] urllib.request.urlopen error
R. David Murray added the comment: What makes you think this is a python bug rather than exactly what it says: a cert verification error? -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31156] Stopiteration terminates while-loop
R. David Murray added the comment: >>> while True: ... raise StopIteration ... Traceback (most recent call last): File "", line 2, in StopIteration -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31156> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31154] Path.replace and Path.rename naming, behavior and documentation
R. David Murray added the comment: Both the replace and rename functions will remain in the API, as they mirror the os module, not the os itself. I agree that the naming is unfortunate, but it has the weight of history behind it, so we are stuck with it. Issue 24229 rejected adding a copy method. Having replace and rename return a value strikes me as a good idea. Please open a separate issue with that enhancement proposal, and nosy 'pitrou', who is the author of the pathlib module. -- nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31154> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31148] Can we get an MSI installer for something past 3.4.4?
R. David Murray added the comment: The short answer is no. We no longer use the MSI installer. Perhaps the windows experts will be interested in exploring why you can't use the current installers, since they work for most people. -- components: +Windows nosy: +paul.moore, r.david.murray, steve.dower, tim.golden, zach.ware ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31143] lib2to3 requires source files for fixes
R. David Murray added the comment: Ah, I see. We don't really support .pyc-only distribution, though we try not to break it. Do you want to propose a fix? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31143> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31143] lib2to3 requires source files for fixes
R. David Murray added the comment: What are you reporting as the bug here? 2to3 obviously can't work without the source, so based just on what you have written here this sounds like an Azure bug. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31143> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31136] raw strings cannot end with a backslash character r'\'
R. David Murray added the comment: In fact, this ia a FAQ: https://docs.python.org/3/faq/design.html#why-can-t-raw-strings-r-strings-end-with-a-backslash -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31123] fnmatch does not follow Unix fnmatch functionality
R. David Murray added the comment: That seems like a reasonable use case, but is fnmatch what git is using for this? If so, what is the feature set required? In any case, the existing functionality must remain as is for backward compatibility reasons, so this would either be a new function or keyword controlled optional behavior. (You will note that our fnmatch documentation specifically mentions treating / as a normal character.) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31123> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31129] RawConfigParser.items() is unusual in taking arguments
Changes by R. David Murray <rdmur...@bitdance.com>: -- type: -> enhancement ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31129] RawConfigParser.items() is unusual in taking arguments
R. David Murray added the comment: For backward compatibility reasons this will not be changed. I don't know if the idea of adding a method and doing a documentation deprecation is worth it or not. -- nosy: +lukasz.langa, r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5996] abstract class instantiable when subclassing dict
R. David Murray added the comment: Closed issue 31127 as a duplicate of this one. -- nosy: +Kevin Shweh ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31127] Abstract classes derived from built-in classes don't block instance creation
R. David Murray added the comment: This is a duplidate of issue 5996. It is not clear if we are going to treat it as a bug or a doc bug. -- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> abstract class instantiable when subclassing dict ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31126] dict comprehension shouldn't raise UnboundLocalError
R. David Murray added the comment: I wonder if that explanation should be added to the doc section to which I pointed. I thought I'd remembered something like that being in there, but it isn't. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29427] Option to skip padding for base64 urlsafe encoding/decoding
Changes by R. David Murray <rdmur...@bitdance.com>: -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29427> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31126] dict comprehension shouldn't raise UnboundLocalError
R. David Murray added the comment:
The behavior is consistent:
>>> a = [1, 2]
>>> b = [3, 4]
>>> [(a, b) for a in a for b in b]
Traceback (most recent call last):
File "", line 1, in
File "", line 1, in
UnboundLocalError: local variable 'b' referenced before assignment
I'm not sure why it is only the nested loop that raises the error
(https://docs.python.org/3/reference/expressions.html#displays-for-lists-sets-and-dictionaries
seems to imply it should raise for both)
By the way, the actual result of your comprehesion would be {"a": 2, "b" 2}.
--
nosy: +r.david.murray
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31126>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31125] shelve.open of temporary file fails with error "anydbm.error: db type could not be determined"
R. David Murray added the comment: By the way, if you want to open a doc issue with a suggestion of how to clarify this in the docs, that would be welcome. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31125] shelve.open of temporary file fails with error "anydbm.error: db type could not be determined"
R. David Murray added the comment: No, it should not. A DBM is not necessarily a single file. What you should be doing is creating a temporary *directory*, and opening your DB inside that. -- components: +Library (Lib) -IO nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31123] fnmatch does not follow Unix fnmatch functionality
R. David Murray added the comment: Looking at the fnmatch man page, it looks like there are option flags that some shells use that our fnmatch doesn't support. I'm not sure if supporting them is a good idea for us or not, but it is probably worth discussing. I suspect our fnmatch was implemented before gnu added those extensions. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31123> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31123] fnmatch does not follow Unix fnmatch functionality
Changes by R. David Murray <rdmur...@bitdance.com>: -- type: behavior -> enhancement versions: -Python 2.7, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31123> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31123] fnmatch does not follow Unix fnmatch functionality
R. David Murray added the comment: I don't believe there is an equivalent unix command. Are you referring to the fnmatch glibc function? Can you demonstrate the differences? I doubt we will change the functionality, but that would be the minimum starting point for a discussion. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31123> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31117] Intersphinx file objects.inv missing 'list' from py:class
Changes by R. David Murray <rdmur...@bitdance.com>: -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Built-in list disappeared from Python 2.7 intersphinx inventory ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31085] Add option for namedtuple to name its result type automatically
R. David Murray added the comment:
Yeah, different developers have different opinions. We discuss (I'd say argue,
which is accurate, but has acquired negative connotations) until we reach a
consensus. And if we don't reach a consensus we leave it alone ("status quo
wins a stalemate").
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31085>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31111] Python 3.6 has an inaccessible attribute on FileNotFoundError
R. David Murray added the comment: It is intended. See issue 30554. -- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Inaccessible attribute characters_written on OSError instances ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue3> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31099] Timer error pop from empty deque/list
R. David Murray added the comment: Perhaps I'm missing something, but isn't this to be expected? Timer will run d.popleft() repeatedly until you get the error you see because the list is empty. Are you thinking that setup is run each time? That would defeat its purpose. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31085] Add option for namedtuple to name its result type automatically
R. David Murray added the comment: The specialized use case is wanting to autogenerate a name with no other information provided. You suggested csv as one example where this would be used, but even in that case I'd rather see something based on the filename than a mashup of field names. I would also personally rather see '_' than a long string of field names (it would make the debug output prettier because the lines would be shorter). In contrast, being able to specify a name satisfies a wide variety of use cases, including that of autogenerating names with no other information provided. Which is why that is included in the API. I hear you about the rename logic. But for myself, since I don't like the idea of the name being a mashup of the field names, it isn't convincing :) I wrote a "parameterized tests" extension for unittest, and it has the option of autogenerating the test name from the parameter names and values. I've never used that feature, and I am considering ripping it out before I release the package, to simplify the code. If I do I might replace it with a hook for generating the test name so that the user can choose their own auto-naming scheme. Perhaps that would be an option here: a hook for generating the name, that would be called where you want your None processing to be? That would not be simpler than your proposal, but it would be more general (satisfy more use cases) and might be worth the cost. On the other hand, other developers might not like the API bloat ;) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31089] email.utils.parseaddr fails on odd double quotes in multiline header
R. David Murray added the comment: Yes, that is mostly likely why parseaddr operates the way it does. The old email package does not do very much hand-holding, it expects you to understand the RFCs, which as you note is a rather daunting task. The new email package (the new policies) in python3 aim to incorporate as much understanding of the RFCs into the library as possible and "do the right thing" automatically so you don't have to worry about it (it can't hide 100%, though...). As for universal new line mode, you are correct that technically \n by itself is data per the RFC (and illegal in the middle of a quoted string like that), but the way Python handles "text" is to convert \r\n into \n internally. So while parseaddr is doing the "right thing" per the RFC, the input parsing parts of the email package in fact accept \n or even mixed line endings to accommodate the difference between unix/python line endings and RFC line endings. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31089> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31085] Add option for namedtuple to name its result type automatically
R. David Murray added the comment: I think the "vaguely" pretty much says it, and you are the at least the first person who has *requested* it :) This is one of those cost-versus-benefit calculations. It is a specialized use case, and in other specialized use cases the "automatically generated" name that makes the most sense is likely to be something different than an amalgamation of the field names. So I vote -0.5. I don't think even the small complication of the existing code is worth it, but I'm not strongly opposed. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31089] email.utils.parseaddr fails on odd double quotes in multiline header
R. David Murray added the comment:
Ah, I take it back. With \n it retains the \n in the decoded name field.
There is a bug of some sort here (\r\n should be treated the same as \n, I
think, whatever way it is treated). I don't think this is worth addressing,
given that the new policies provide a much better API for interacting with
Messages, and you can in fact easily unfold the line before parsing it if you
need to do it in 2.7:
>>> parseaddr(''.join(m['from'].splitlines()))
('=?UTF-8?Q?Anita_=W4=86ieckli=C5=84ska_|_PATO_Nieruch?=
=?UTF-8?Q?omo=C5=9Bci?=', 'anita.wiecklin...@pato.com.pl')
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31089>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31089] email.utils.parseaddr fails on odd double quotes in multiline header
R. David Murray added the comment:
parseaddr does what you expect if the message has been read using universal
newline mode (ie: the linesep is \n):
>>> parseaddr('"=?UTF-8?Q?Anita_=W4=86ieckli=C5=84ska_|_PATO_Nieruch?=\n
>>> =?UTF-8?Q?omo=C5=9Bci?=" <anita.wiecklin...@pato.com.pl>"')
('=?UTF-8?Q?Anita_=W4=86ieckli=C5=84ska_|_PATO_Nieruch?=\n
=?UTF-8?Q?omo=C5=9Bci?=', 'anita.wiecklin...@pato.com.pl')
I suppose this wouldn't be *that* hard to fix. If it isn't too complex and you
want to propose a patch I'll take a look.
In any case it works fine in python3 using the new policies:
>>> from email import message_from_string as mfs
>>> from email.policy import default
>>> m = mfs('From: "=?UTF-8?Q?Anita_=W4=86ieckli=C5=84ska_|_PATO_Nieruch?=\r\n
>>> =?UTF-8?Q?omo=C5=9Bci?=" <anita.wiecklin...@pato.com.pl>"\r\n\r\ntest',
>>> policy=default)
>>> m['from'].addresses
(Address(display_name='Anita =W4\udc86iecklińska | PATO Nieruch omości',
username='anita.wiecklinska', domain='pato.com.pl'),)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31089>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31071] *args unpacking can mask TypeErrors
R. David Murray added the comment:
Thanks for the report. Retitling because this has nothing to do with map:
>>> def foo(*args):
... raise TypeError('fake')
... yield 1
...
>>> foo(1, *foo())
Traceback (most recent call last):
File "", line 1, in
TypeError: foo() argument after * must be an iterable, not generator
>>> foo(*foo())
Traceback (most recent call last):
File "", line 1, in
File "", line 2, in foo
TypeError: fake
--
nosy: +r.david.murray
stage: -> needs patch
title: Bad error message about maps not iterable -> *args unpacking can mask
TypeErrors
versions: +Python 3.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31071>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31065] Documentation for Popen.poll is unclear
R. David Murray added the comment: Agreed. Explicit is good. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31065] Documentation for Popen.poll is unclear
R. David Murray added the comment: Yes we can add "otherwise return None". However it is pretty clear as is, since "poll" implies an immediate return, and if there's no return code to return, the logical value in Python to get back is None :) -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31065> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31057] pydoc for tempfile.TemporaryDirectory should say it returns the name
R. David Murray added the comment: Boy, I wasn't thinking very clearly when I wrote that. As pointed out on the PR, tempfile.TemporaryDirectory of course returns a TemporaryDirectory object. That's in the nature of Python. I was reading so poorly that I didn't even notice it was the docstring you were modifying :( The main docs phrase this more clearly, especially the sentence that says the name can be retrieved from the name property (and I see I was wrong, it does use 'name', not 'path'). We don't want to copy all of the text from there, but it could be used as a model to improve the phrasing. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31042] Inconsistency in documentation of operator.index
R. David Murray added the comment: I agree with Raymond. I'm not sure that adding roughly is going to decrease the possibility of confusion, but I won't object to it. In a way, it's too bad we didn't make the attribute lookup machinery look up all dunder methods on the class, so that a.__index__ would call the class method. I think backward compatibility prevented that. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31055] All Sphinx generated pages could have a new "Edit This Page" link adjacent to the existing "Show Source"
R. David Murray added the comment: No, we understand the process, the problem is that except for the 'dev' docs, the link would be to a branch other than master. That's the problem that we're discussing. Maybe instead of an edit link on non-dev docs we could have a message saying that if you want to propose a change you can use the edit link on the 'dev' version of the docs? Maybe with a link or button that would take them to the dev version of the page? -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31057] pydoc for tempfile.TemporaryDirectory should say it returns the name
R. David Murray added the comment: It actually returns the path, since "name" often means the last component of the path. Just saying "path" might be confused with pathlib, though. So I guess we'd have to say "returning its path as a string", which sounds awkward. The original wording is in fact accurate, since most people will understand "the directory" as the directory path as a string. I'm not sure this change would be an improvement. I'm not saying no, though. I guess you'd say I'm -0 on changing it. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31057> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27715] call-matcher breaks if a method is mocked with spec=True
David Hoyes added the comment: I came across a different failing test case, which looks a lot like the same issue: ``` from unittest import mock class Foo(object): def __call__(self, x): return x m = mock.create_autospec(Foo, instance=True) m(7) m.assert_called_once_with(7) ``` In mock 1.0.1 this passes, but in Python 3.5 we get this error: ``` TypeError: missing a required argument: 'x' The above exception was the direct cause of the following exception: Traceback (most recent call last): File "euhpc/tmp/mockbug.py", line 12, in m.assert_called_once_with(7) File "/usr/lib/python3.5/unittest/mock.py", line 803, in assert_called_once_with return self.assert_called_with(*args, **kwargs) File "/usr/lib/python3.5/unittest/mock.py", line 792, in assert_called_with raise AssertionError(_error_message()) from cause AssertionError: Expected call: mock(7) Actual call: mock(7) ``` -- nosy: +David Hoyes ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27715> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31052] smtplib not honoring bcc header
R. David Murray added the comment: smtplib in 2.7 doesn't know anything about RFC822 or any of the replacement RFCs. sendmail accepts a *string*, and doesn't understand or modify anything about that string except the newlines. It is your responsibility not to *add* the BCC header. What you want to do is put the BCC (and CC!) recipients in your toaddr list passed to sendmail, and *not* add a BCC header. In Python3 smtplib has a send_message method that accepts a Message object, and that method uses the BCC to inform where to send the message and strips the header before sending. That is, smtplib's send_message method *does* implement RFC5322 behaviors. -- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31052> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31025] io.BytesIO: no way to get the length of the underlying buffer without copying data
R. David Murray added the comment: So you are saying that BytesIO has code that checks that its argument only has a single reference and modifies the string in place when it can if so? You can't depend on that in any other implementation of Python, and shouldn't depend on it in CPython either. Even in CPython you can't guarantee that case 1 is case 1, since the argument could conceivably be an interned string. So the seek approach is the only one that makes semantic sense, I think. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31025> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31021] Clarify programming faq.
R. David Murray added the comment: I think Terry and his OP are reacting to the fact that "-190 % 12 == -10" looks like it is saying that that expression is True in Python, which it is not (and that's the point). IMO, another issue is that "and then compilers that truncate i // j need to make i % j have the same sign as i." doesn't have enough connection in the naive reader's mind with "-190 % 12 == -10 is a bug waiting to bite" for easy comprehension. A potential fix to both these issues would be to say "if -190 % 12 were equal to -10 in Python (the way it is in most C programs), that would quite often be a bug waiting to happen in code using the % operator." -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31025] io.BytesIO: no way to get the length of the underlying buffer without copying data
R. David Murray added the comment: I'm confused, I don't see how there can be any difference between (1) and (2). -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31025> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30714] test_ssl fails with openssl 1.1.0f: test_alpn_protocols()
R. David Murray added the comment: Well, the reason one *might* consider a test failure as a release blocker (and I'm not saying you should, I'm just explaining the possible logic) is that distros would understandably like the test suite to pass before they include a release in their distribution. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30714> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30974] Update os.samefile docstring to match documentation
R. David Murray added the comment: I would take "actual file" as meaning the file the symlink points to, so I'd say the documentation matches the implementation according to your description of the two. The current docs actually say "refer to the same file or directory", and mention os.stat explicitly, so again I'd say the docs and implementation match. It sounds like what you want is to open a feature request for a samefile equivalent that does not follow symlinks. lsamefile? We could use this issue for making the docstring match the docs, though. I think the sentence in the docs is short enough to just get copied into the docstring. -- assignee: -> docs@python components: +Documentation nosy: +docs@python, r.david.murray title: os.samefile / shutil._samefile: following symlinks -> Update os.samefile docstring to match documentation versions: +Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30973] Regular expression "hangs" interpreter
R. David Murray added the comment: Right. We don't try to fix handling these kinds of exponential expressions. This is a case of "don't do that" :) (I don't know if the regex module is better at "handling" this kind of regex bug.) -- nosy: +r.david.murray resolution: -> wont fix stage: -> resolved status: open -> closed type: crash -> behavior ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30973> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30971] Improve code readability of json.tool
R. David Murray added the comment: However, our general policy is that we don't make such changes unless we are also touching the code for other reasons. So I think using this PR as a base for your feature PRs, and then committing everything together if they are accepted, would be the way to go. I don't know if it would work to actually use it as a base for the other PRs in github, or if it would work better to just make it the initial commit in a commit series. The github workflow is too new for us to have definite answers to such questions :) -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30970] return-value of filecmp.dircmp.report_*
R. David Murray added the comment: Thanks for wanting to improve Python. However, the purpose of those function is to *print* the result. They intentionally do not have return values. All of the values that you would have these functions return are accessible via attributes already. -- nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30969] Docs should say that `x is z or x == z` is used for `x in y` in containers that do not implement `__contains__`
R. David Murray added the comment: I think you change is appropriate given that the "equivalent to" for the built in iterators contains the 'is' expression. However, I also think we should drop that second whole paragraph, and in the previous paragraph say "...but are :term:`iterable`...". Because conceptually what we do is iterate whatever we're given if iter doesn't return a TypeError, and it is iter that handles the fallback to the older __getitem__ protocol. I don't see why we should re-explain the iteration protocol in the docs for 'in'. (I haven't looked at how this is actually implemented, but the implementation ought to be equivalent to that or we will eventually run into bugs.) I don't think this would result in any loss of precision or understandability, and in fact I think it would make it easier to understand. See also issue 27605, which also wants to edit this section slightly. -- nosy: +r.david.murray, rhettinger ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30969> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30576] http.server should support HTTP compression (gzip)
R. David Murray added the comment: Getting input from python ideas is a great idea :) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30956] ftplib behaves oddly if socket timeout is greater than the default
Changes by R. David Murray <rdmur...@bitdance.com>: -- type: crash -> behavior versions: +Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30956] ftplib behaves oddly if socket timeout is greater than the default
R. David Murray added the comment: I changed the title to reflect the problem, but note that I'm *assuming* it is "greater than the default" that is the issue, I haven't actually tested that theory. -- title: ftplib socket timeout can't be handled -> ftplib behaves oddly if socket timeout is greater than the default ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30956] ftplib socket timeout can't be handled
R. David Murray added the comment: I would like to leave this issue open. It is clear that the behavior for long timeouts does not match the docs, and that should be investigated if someone has the motivation :) -- resolution: works for me -> stage: resolved -> status: closed -> open ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30960] Python script is failing to run
R. David Murray added the comment: This is a bug tracker for Python. 3.2 is out of maintenance, so such a question is not appropriate for this forum. In any case it is an issue with your install, not with Python itself, so again not appropriate for this forum. You should ask for help on the python-list mailing list, or the #python irc channel on freenode. I wish we could help you here, but we need to keep this forum focused on bugs in Python itself. Please do not reopen the issue. louielu, if you want to continue to help Megha, which would be great, please take it to private email. -- nosy: +r.david.murray status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30940] Documentation for round() is incorrect.
R. David Murray added the comment: We don't need to burden Mark with doing a PR for this (unless he wants to). This is a good new contributer practice issue :) -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30956] ftplib socket timeout can't be handled
R. David Murray added the comment:
Given:
import socket
from ftplib import FTP
try:
ftp = FTP('host.i.know.will.hang.com', timeout=4)
except socket.timeout:
print('caught')
I see 'caught' printed on the console. However, if I increase the timeout to
400, then on both 3.5 tip and 3.6 tip I get a TimeoutError, not a
socket.timeout. If I increase the timeout to 4000, I get the TimeoutError in a
much shorter time than 4000 seconds.
So, *something* is wrong here. Looking at the code it isn't obvious what.
Here is the traceback:
Traceback (most recent call last):
File "../p36/temp.py", line 4, in
ftp = FTP('', timeout=4)
File "/home/rdmurray/python/p35/Lib/ftplib.py", line 118, in __init__
self.connect(host)
File "/home/rdmurray/python/p35/Lib/ftplib.py", line 153, in connect
source_address=self.source_address)
File "/home/rdmurray/python/p35/Lib/socket.py", line 712, in create_connection
raise err
File "/home/rdmurray/python/p35/Lib/socket.py", line 703, in create_connection
sock.connect(sa)
TimeoutError: [Errno 110] Connection timed out
Your traceback is different because your timeout is occurring after the initial
connection. Are you sure your socket.timeout is the correct one? You might
try printing socket.__file__ to check.
--
nosy: +r.david.murray
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30956>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30954] backport unittest.TestCase.assertLogs to 2.7?
R. David Murray added the comment: There is, however, unittest2 on pypi that has most of the python3 features backported. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30954> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30954] backport unittest.TestCase.assertLogs to 2.7?
R. David Murray added the comment: No. 2.7 is in maintenance mode and gets no new features. -- nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30954> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30952] include Math extension in SQlite
Changes by R. David Murray <rdmur...@bitdance.com>: -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30952> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30576] http.server should support HTTP compression (gzip)
R. David Murray added the comment: I do not have a strong opinion on this issue, but I share Martin's doubts that it should be added. It certainly should not be on by default if it is added. We should get input from other core devs. -- nosy: +r.david.murray ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
