[issue47121] math.isfinite() can raise exception when called on a number
Change by Nathaniel Manista : -- nosy: +Nathaniel Manista ___ Python tracker <https://bugs.python.org/issue47121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43255] Ceil division with /// operator
Change by Nathaniel Manista : -- nosy: +Nathaniel Manista ___ Python tracker <https://bugs.python.org/issue43255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46639] Ceil division with math.ceildiv
Change by Nathaniel Manista : -- nosy: +Nathaniel Manista ___ Python tracker <https://bugs.python.org/issue46639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17519] unittest should not try to run abstract classes
Nathaniel Manista added the comment: michael.foord: I am now persuaded that the feature requested here ought be reconsidered (since my last comment there's been a lot of chatter about it behind closed doors at work, but I can at least cite https://github.com/abseil/abseil-py/issues/166 as a public example of the question coming up). Would it be appropriate to file a new issue? My issue tracker training brought me up to believe that it's better to reopen an existing closed issue in a circumstance like this, but I respect that that may not be the custom in this issue tracker, and besides I lack the permission in this issue tracker to reopen this issue. -- ___ Python tracker <https://bugs.python.org/issue17519> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43596] change assertRaises message when wrong exception is raised
Change by Nathaniel Manista : -- nosy: +Nathaniel Manista ___ Python tracker <https://bugs.python.org/issue43596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17519] unittest should not try to run abstract classes
Nathaniel Manista added the comment: In the years since this was considered and declined, I wonder if the facts have changed sufficiently to make it now worth doing? I often find myself writing TestCases for interfaces, and those define test_* methods that call the interface under test, but of course my TestCase needs to be abstract because I'm only testing an interface and not a concrete implementation of that interface. It's also the case when I'm writing this kind of test that I wish to use a type-checker, and if I can have my abstract TestCase inherit from unittest.TestCase, that will satisfy my type-checker's questions about why I believe my TestCase has all kinds of assert* methods defined that it doesn't otherwise see. I currently have the impression that if this is cheap enough to do, it may be worth doing just for the ergonomics alone? It mightn't make anything impossible become possible to do, but I forecast that it would make something difficult to do much more straightforward to do. (I remain a fan of the all-powerful load_tests protocol, but... often it's nice to escape all the responsibility that comes with use of it.) -- ___ Python tracker <https://bugs.python.org/issue17519> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43015] Add str.replaceall?
New submission from Nathaniel Manista : Chained str.replace calls can sometimes be pretty unattractive; what are the chances that we could have an str.replaceall method? Of type Callable[[Mapping[str, str]], str]? Check out absl::StrReplaceAll (https://github.com/abseil/abseil-cpp/blob/22771d471930ce88e1e75d0ca9dd8c65a7b0f895/absl/strings/str_replace.h#L73-L98) for a similarly useful function in C++. -- components: Unicode messages: 385581 nosy: Nathaniel Manista, ezio.melotti, vstinner priority: normal severity: normal status: open title: Add str.replaceall? type: enhancement versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41292] Dead link in Windows FAQ
Change by Nathaniel Manista : -- nosy: +Nathaniel Manista ___ Python tracker <https://bugs.python.org/issue41292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30757] pyinstaller can be added to docs, py2exe ref can be updated
Change by Nathaniel Manista : -- nosy: +Nathaniel Manista ___ Python tracker <https://bugs.python.org/issue30757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27721] distutils strtobool returns 0 and 1 rather than False and True
Change by Nathaniel Manista : -- nosy: +Nathaniel Manista ___ Python tracker <https://bugs.python.org/issue27721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34858] MappingProxy objects should JSON serialize just like a dictionary
Nathaniel Manista added the comment: Err, "... it's something that complicates writing code according to...", sorry. -- ___ Python tracker <https://bugs.python.org/issue34858> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34858] MappingProxy objects should JSON serialize just like a dictionary
Nathaniel Manista added the comment:
There's a great deal more additional discussion about this over at
https://discuss.python.org/t/json-does-not-support-mapping-and-mutablemapping/2829,
but I would like to heartily "hear hear" this issue for the way it is weird
that
json.dumps(frozendict.frozendict({'3':5}))
does not evaluate to the string "{'3': 5}" and it's something that makes
writing according to and teaching others to code according to the
make-your-code-safer-by-using-immutability-in-all-possible-things principle.
------
nosy: +Nathaniel Manista
___
Python tracker
<https://bugs.python.org/issue34858>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17519] unittest should not try to run abstract classes
Change by Nathaniel Manista : -- nosy: +Nathaniel Manista ___ Python tracker <https://bugs.python.org/issue17519> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34648] Confirm the types of parameters of traceback.format_list and traceback.StackSummary.from_list post-3.5
Nathaniel Manista added the comment: > The question that needs to be answered here is "why we should support > Iterable[FrameSummary]?" and you're one the one who needs to answer > it Okay, here are a few reasons: 1) A function that requires that an input be a List invites the question “why is an Iterable, or a Collection, or a Sequence, not sufficient?”. Of course the best way to handle that question is to widen the API to accept at least a Sequence so that the question isn’t even asked, but the next-best way to handle the question is with an answer like “because the function mutates the given List”. But that’s not the answer to the question here (which is a big part of why I opened the bug, asking the question more directly). So far the answer seems to be “because we wanted to be conservative in our API design” and “because we didn’t want to support what we weren’t testing”. Those are good answers, but I’d like to persuade you that they are no longer good enough. 2) Because List is invariant in element type whereas Sequence, Collection, and Iterable are covariant (I'm nearly certain) in element type, format_list is hard to use with type-checked code (see the discussion in https://github.com/python/typeshed/pull/2436 if you’re not following it already). Should the typeshed-canonicalized type of format_list’s “extracted_list” parameter be “List[FrameSummary]”? If so, then given a subclass MyFrameSummarySubclass of FrameSummary, List[MyFrameSummarySubclass] would *not* be valid to pass to format_list. That seems like a poor developer experience, right? If the type of “extracted_list” were widened to Sequence[FrameSummary], Collection[FrameSummary], or (ideally) Iterable[FrameSummary], then an expression of type Iterable[MyFrameSummarySubclass] would be perfectly fine to pass for “extracted_list”. 3) I tried to pass an Iterable[FrameSummary] to traceback.format_list in my own code. My situation is not itself open source but is a bit like this: def _FormatFrames(frame) -> str: """Generate a traceback of the current position of the thread in the code.""" frame_tuples = [] while frame: filename = lineno = frame.f_lineno line = frame_tuples.append((filename, lineno, frame.f_code.co_name, line,)) frame = frame.f_back formatted_frame_strings = traceback.format_list( traceback.FrameSummary(file_name, line_number, frame_name, line=line) for file_name, line_number, frame_name, line in frame_tuples) return ''.join(formatted_frame_strings) . > instead of saying our design decisions were "absurd" and "not wise", > without giving any concrete use cases for your "wider" design choice. According to what we’ve learned over the course of the life and use of Python, and according to what we understand as best practices in the year 2018: I believe it is absolutely unwise to have offer an API that requires that a given parameter be a List without documenting the reasons sustaining that extremely limited design. Why won’t a Sequence suffice? Heck, why won’t some other implementation of MutableSequence suffice? Notice that I opened this bug with the question “wait, really?” rather than the statement “this is wrong and must be changed” - it might be the case that List is the best choice for the type of the parameter (though I now doubt it even more) but certainly it’s clear that *the documentation does not establish or communicate why a List is required*. > Initial docstring for format_list() were added in 2000: > https://github.com/python/cpython/commit/e7b146fb3bdc#diff-e57ff53a569d0ebbe201ad0c102ee27e > > Given a list of tuples as returned by extract_tb() or > extract_stack(), return a list of strings ready for printing. I have no doubt that that’s what was written in 2000, when we didn’t know nearly as much as we do today and when what were considered best practices were radically different. Now we know more - particularly for this case “never ask for a List where asking for a MutableSequence will do, and never ask for a MutableSequence where asking for a Sequence will do, and never ask for a Sequence where asking for a Collection will do, and never ask for a Collection where asking for an Iterable will do”. The big question for format_list is “will an Iterable do?”. If not, that’s strange and unique by today’s standards and practices and the function’s documentation should at least give some enlightenment as to why it is the case. > There are no tests for iterables other than list at > https://github.com/python/cpython/blob/master/Lib/test/test_traceback.py I’d be happy to add some… except test_traceback.py doesn’t appear to contain any direct testing of format_list, and I can’t find “the format_list tests” to which
[issue34648] Confirm the types of parameters of traceback.format_list and traceback.StackSummary.from_list post-3.5
Nathaniel Manista added the comment: > In 3.4, format_list() was documented to accept return values of extract_tb() > > and extract_stack() functions and they both were returned lists: > > def extract_tb(tb, limit=None): > return list(_extract_tb_iter(tb, limit=limit)) > > def extract_stack(f=None, limit=None): > stack = list(_extract_stack_iter(_get_stack(f), limit=limit)) > stack.reverse() > return stack I think that’s an unnecessarily and extraordinarily narrow reading - you could use the same reading to make a judgement of “format_list may only be passed values returned by extract_tb and extract_stack rather than other values of the same type”, and that would be absurd. I don’t think it’s a wise choice to say “because the motivation for offering the format_list function was to work with values returned by extract_tb and extract_stack, the allowed inputs to format_list should be restricted to just those types”. Why not support Iterable[FrameSummary]? A choice to support Iterable[FrameSummary] *is also a choice to support List[FrameSummary]*. It's just a "wider" choice; it’s not a breaking choice to drop support for List[FrameSummary]. > I don't think we support the "pass manually created iterables" case here. What’s a “manually created iterable”? What kinds of iterables aren’t “manually created iterables”? Can their differences be captured in the type system? > Yes, the old API is still supported for backwards compatibility reasons. This is a very flat statement that invites questions by what it doesn’t say and by the way it describes something that is true today without saying for how long into the future that thing will remain true. For how long will the old API be supported for backwards compatibility reasons? Is new code encouraged to use the new API? If the new API is better, shouldn’t new code use it? If the new API isn’t better, why was it introduced? -- ___ Python tracker <https://bugs.python.org/issue34648> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34648] Confirm the types of parameters of traceback.format_list and traceback.StackSummary.from_list post-3.5
Nathaniel Manista added the comment: ... and while we're here, how about StackSummary.from_list's "a_list" parameter as well: 3) Can it be Iterable? It looks like it can be Iterable? Is it fine for it to be Iterable? 4) Should the component type of "a_list" be FrameSummary? Is the support for Tuple[str, int, str, Optional[str]] merely backward-looking, or is new code encouraged to pass Tuple[str, int, str, Optional[str]] objects? -- title: Confirm the type of traceback.format_list post-3.5 -> Confirm the types of parameters of traceback.format_list and traceback.StackSummary.from_list post-3.5 ___ Python tracker <https://bugs.python.org/issue34648> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34648] Confirm the type of traceback.format_list post-3.5
New submission from Nathaniel Manista : So I'm fixing a bug in typeshed's accounting of the traceback module (https://github.com/python/typeshed/pull/2436) and the documented semantics of traceback.format_list don't quite smell to me what I think they might be intended to be: 1) I know it has the name "format_list", but is it really intended to require a list? Why not a sequence, or a collection, or an iterable? I would think it would be fine to pass an iterable to traceback.format_list. Is it fine? 2) What is the desired component type for the aggregate passed to format_list? In 3.4-and-earlier it was Tuple[str, int, str, Optional[str]], and that still works in 3.5-through-3.8, but is that just backwards compatibility or is that something that users of traceback.format_list should feel encouraged to continue passing into the future? Sorry for filing a bug just to ask "huh; really?" but... please confirm? -- assignee: docs@python components: Documentation messages: 325175 nosy: Nathaniel Manista, docs@python priority: normal severity: normal status: open title: Confirm the type of traceback.format_list post-3.5 type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34648> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34538] Remove encouragement to author a base class for all Exception subclasses in a module
Nathaniel Manista added the comment: I’d like to try to steer this conversation back toward what I think is the actionable question: “does the exemplification of this practice in the Errors and Exceptions portion of The Python Tutorial bring about a net benefit or a net cost to its intended audience?”. What is the benefit? It is that when an author happens to be authoring a module *all user-defined Exception subclasses of which satisfy some more-specific-than-Exception type* the author is led to define an intermediate class between Exception and the directly-used user-defined Exception subclasses capturing that type in a usable code element. What readers of the tutorial enjoy this benefit? Pretty much only those authors (who happen to be authoring a module *all user-defined Exception subclasses of which satisfy some more-specific-than-Exception type*) who are still learning about classes and inheritance. That’s a doubly slim population, isn’t it? Maybe also those who kind of know, but aren’t so sure and could use some reinforcement from seeing in the tutorial something that they independently did on their own in their own code. I wouldn’t think that authors who already know with confidence and from experience about classes and inheritance would benefit from the example in the tutorial, so “In my experience as a teacher, the possibility doesn't usually occur to people without it having been suggested” comes as a surprise to me. But… okay, them too - but again, only when they happen to be authoring a module *all user-defined Exception subclasses of which satisfy some more-specific-than-Exception type*. What is the cost? It is that when an author happens to be authoring a module that does *not* have the property that all user-defined Exception subclasses satisfy some more-specific-than-Exception type, the common intermediate class is just bloat. It’s noise disrupting the signal. It undermines the API design advice “when in doubt, leave it out”. It unnecessarily widens the module’s API. It undermines the API design advice “classes are the most complex kind of code element in common use so they have the highest value proposition to satisfy to justify their existence”. It violates the Liskov Substitution Principle. Maybe most importantly, it obscures other relationships among the user-defined Exception subclasses in the module such as a superclass shared by some-but-not-all of the module’s user-defined Exception subclasses, if such other relationships exist. What readers of the tutorial pay this cost? Those who are still learning the language. And those who are following pattern and convention - note that the tutorial contains only one example of user-defined Exception subclasses, and… an unfortunate fact of life of tutorials is that readers are invited to generalize from single examples. And, as I think we’ve seen in this conversation, those who just picked up the practice at one point and have kept it going. The Exception subclass hierarchy of sqlite3 that was mentioned earlier in this conversation demonstrates exactly this bloat and misapplication - there’s Warning, which is a direct subclass of Exception, and there’s Error, which is also a direct subclass of Exception and has the erroneous specification “The base class of the other exceptions in this module”, and there’s DatabaseError, which is a subclass of Error, and then there are IntegrityError, ProgrammingError, OperationalError, and NotSupportedError, which inherit from DatabaseError. What’s the use of Error? There are no code elements in the module specified as raising Error. There’s example code in the module showing “except sqlite3.Error”, but why shouldn’t that be “except sqlite3.DatabaseError”? It’s a red herring is that the practice appears widely applied in existing Python code - well of course; it’s been exemplified in the tutorial for seventeen years! :-P One last thing to consider: look at the example specifically - InputError and TransitionError. There’s no elsewhere-in-the-module example code showing a function that has “Error” in its “Raises:” specification and could raise either an InputError or a TransitionError, and there’s no outside-of-the-module example code showing a user of the module calling a module function and saving duplicated lines of code because they want to respond to InputErrors and TransitionErrors in exactly the same way. We should remove the “Base class for exceptions in this module” Error class from the tutorial’s example because it just isn’t beneficial enough, in enough applicable modules, to enough authors, and it’s more than costly enough, in enough modules to which it doesn’t apply, and to enough authors, even just as noise and API bloat. I don’t know that this could have been calculated from first principles seventeen years ago; I think perhaps it took the experience of having the guidance out there, so rarely merited and so widely
[issue34590] "Logging HOWTO" should share an example of best practices for using logging in a library
Nathaniel Manista added the comment: Something... related, that may perhaps belong in a separate issue, but that I want to at least mention here because it would be solved if logging-in-libraries best practices were authoritatively documented and exemplified: it's just too consarn easy to "hold [the logging module] wrong" and wind up with "No handlers could be found for logger" log spam: https://www.google.ca/search?q=site:stackoverflow.com+"No+handlers+could+be+found+for+logger;. Why should a Logger object need to have .basicConfig() called on it after retrieval (where "retrieval" means "getLogger call") and before use anyway? Why can't it just be ready for use (at least as ready for use as .basicConfig makes it) when passed from the logging module to the logging-using module like nearly any other object passed from the standard library to standard-library-using code? (The documentation says "No handlers could be found for logger" spam only happens pre-3.2, but some of my users at least think they see it in later Pythons.) -- ___ Python tracker <https://bugs.python.org/issue34590> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34590] "Logging HOWTO" should share an example of best practices for using logging in a library
New submission from Nathaniel Manista : https://docs.python.org/3.8/howto/logging.html#configuring-logging-for-a-library is a bit too short and doesn't answer some questions that I have as a library author about the best ways to use logging in a library. Should I make use of a single logger object in my library, multiple loggers in a tree, or multiple unrelated loggers? Since I have just one public module, I'm tempted to say that I should just use one logger object. Should I present as part of my public API the name of the logger object(s) used? Probably - the documentation starts with "When developing a library which uses logging, you should take care to document how the library uses logging - for example, the names of loggers used.". But should I also include the logger objects in my API? If an application wants to reach my logger, why should they use "logging.getLogger()" rather than "my_library.LOGGER"? Should I use my library's fully-qualified name as the name of its logger? This seems like a great idea because it's unlikely to bring up any new conflicts. Is it a best practice? Is there any better practice? The "Configuring Logging for a Library" text could answer these questions, and maybe it should, but... I really think a toy library example that library authors could follow would also help a great deal. -- assignee: docs@python components: Documentation messages: 324652 nosy: Nathaniel Manista, docs@python priority: normal severity: normal status: open title: "Logging HOWTO" should share an example of best practices for using logging in a library type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34590> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34538] Remove encouragement to author a base class for all Exception subclasses in a module
New submission from Nathaniel Manista : https://docs.python.org/3.8/tutorial/errors.html (and all other versions of that page back at least as far as 2.7) currently contain the guidance "When creating a module that can raise several distinct errors, a common practice is to create a base class for exceptions defined by that module, and subclass that to create specific exception classes for different error conditions: ". It may have seemed like a good idea at the time, but we now know from years of experience that this is an experiment that didn't pan out and we can consider this guidance a Now-Contraindicated Best Practice Of Yesteryear™. Modules define subclasses of Exception for lots of reasons. Some of those subclasses have no relation to one another except that they are subclasses of Exception. Some of those subclasses define Exception instances that are never raised by code in the module, but that are expected to be raised by code passed to and called by the module. Yes, there are times when a common base class may be appropriate - such as when an inheritance hierarchy and polymorphism that satisfy the Liskov Substitution Principle make sense for the Exception subclasses, and when the base class itself is used (such as when the base class is an item in the Raises: section of a function's doc string). But these cases aren't so common as to justify the advice being offered generally about all Exception subclass definitions. Exception subclasses are just classes. Advising that authors may wish to define a common base class for all Exception subclasses in a module is like advising authors that they may wish to define a common base class for all object subclasses in a module - it's very, very, very occasionally a good idea in the particular circumstances of a particular module's implementation, but very generally not. -- assignee: docs@python components: Documentation messages: 324286 nosy: Nathaniel Manista, docs@python priority: normal severity: normal status: open title: Remove encouragement to author a base class for all Exception subclasses in a module type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34538> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34133] ValueError documented as being restricted to only "a built-in operation or function"
Nathaniel Manista added the comment: Thank you both! -- ___ Python tracker <https://bugs.python.org/issue34133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34133] ValueError should not be documented as being restricted to only "a built-in operation or function"
New submission from Nathaniel Manista : The documentation for ValueError currently describes it as being "Raised when a built-in operation or function receives an argument that has the right type but an inappropriate value, and the situation is not described by a more precise exception such as IndexError.", but the Python community has (quite rightly!) adopted it as the exception to raise in any system when that system is passed a value for a parameter that is type-correct but of an invalid value. (Because what, is every library going to present a "my_library.ValueError" exception instead? That would be ridiculous.) ValueError's documentation should drop the "a built-in operation or function" wording. Perhaps go with something like "When raised indicates that a function or method was passed a value of the correct type but an invalid value"? -- assignee: docs@python components: Documentation messages: 321784 nosy: Nathaniel Manista, docs@python priority: normal severity: normal status: open title: ValueError should not be documented as being restricted to only "a built-in operation or function" type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23495] The writer.writerows method should be documented as accepting any iterable (not only a list)
Change by Nathaniel Manista <nathan...@google.com>: -- nosy: +Nathaniel Manista ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue23495> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31739] socket.close recommended but not demonstrated in same-page example code
Nathaniel Manista <nathan...@google.com> added the comment: As I am learning from the examples, I don't have the confidence to propose a fix to them. :-P For the IPv4-and-IPv6 "Echo server program": should s be closed at some point after "conn, addr = s.accept()"? Should s be closed on the line immediately after "conn, addr = s.accept()", should it be closed on the last line (after the "with conn:" context is exited), or is either acceptable? Should the "very simple network sniffer with raw sockets on Windows" have a with statement or "s.close()"? Should the "communicate to a CAN network using the raw socket protocol" example have a with statement or "s.close()"? Of course it's possible that I'm misunderstanding one or more things. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31739> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31739] socket.close recommended but not demonstrated in same-page example code
New submission from Nathaniel Manista <nathan...@google.com>: https://docs.python.org/3.7/library/socket.html#socket.socket.close says "it is recommended to close() [sockets] explicitly, or to use a with statement around them", but in the example code on the same page at https://docs.python.org/3.7/library/socket.html#example correct use of the .close() method seems to be missing. -- assignee: docs@python components: Documentation messages: 303993 nosy: Nathaniel Manista, docs@python priority: normal severity: normal status: open title: socket.close recommended but not demonstrated in same-page example code type: enhancement versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31739> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22729] `wait` and `as_completed` depend on private api
Nathaniel Manista added the comment: gRPC Python is strongly affected by this as well. We use grpc.Future objects (https://github.com/grpc/grpc/blob/e5f99b587338164230b0b2121d242fb015c2ae5a/src/python/grpcio/grpc/__init__.py#L50) to represent RPCs taking place asynchronously. Despite our grpc.Futures being interface-compatible with concurrent.futures.Future objects, we (in our tests) and our users (in their applications) cannot make use of the concurrent.futures.as_completed function (https://github.com/grpc/grpc/blob/e5f99b587338164230b0b2121d242fb015c2ae5a/src/python/grpcio_tests/tests/unit/_rpc_test.py#L388 shows the "wrapping" that has to be done to work around the problem). It's not at all clear why as_completed shouldn't work with any future objects that are public-interface-compatible with concurrent.futures.Future objects. I would be happy to reimplement the function if my change would be accepted. I part ways with this issue's original reporter in that I don't see the need to widen the public API any further with a "remove_done_callback" method... but maybe I'm missing some small detail? ------ nosy: +Nathaniel Manista ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22729> ___ ___ 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
Nathaniel Manista added the comment: Wait, really? My report came out of a real bug that I had in my system and shipped to my users; it wasn't academic or contrived at all. -- ___ 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
[issue28537] abc module fails to reject instantiation of some multiply-inheriting classes that fail to implement abstract methods
New submission from Nathaniel Manista: The attached file when executed should fail (raise an exception) one line above where it actually does. Right? I discovered this in 2.7 but have confirmed that it's still a problem in 3.6.0b2. -- components: Library (Lib) files: abc_what.py messages: 279465 nosy: Nathaniel Manista, aleax priority: normal severity: normal status: open title: abc module fails to reject instantiation of some multiply-inheriting classes that fail to implement abstract methods type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45226/abc_what.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
