Change by Nathaniel Manista :
--
nosy: +Nathaniel Manista
___
Python tracker
<https://bugs.python.org/issue47121>
___
___
Python-bugs-list mailing list
Unsub
Change by Nathaniel Manista :
--
nosy: +Nathaniel Manista
___
Python tracker
<https://bugs.python.org/issue43255>
___
___
Python-bugs-list mailing list
Unsub
Change by Nathaniel Manista :
--
nosy: +Nathaniel Manista
___
Python tracker
<https://bugs.python.org/issue46639>
___
___
Python-bugs-list mailing list
Unsub
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
Change by Nathaniel Manista :
--
nosy: +Nathaniel Manista
___
Python tracker
<https://bugs.python.org/issue43596>
___
___
Python-bugs-list mailing list
Unsub
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
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
Change by Nathaniel Manista :
--
nosy: +Nathaniel Manista
___
Python tracker
<https://bugs.python.org/issue41292>
___
___
Python-bugs-list mailing list
Unsub
Change by Nathaniel Manista :
--
nosy: +Nathaniel Manista
___
Python tracker
<https://bugs.python.org/issue30757>
___
___
Python-bugs-list mailing list
Unsub
Change by Nathaniel Manista :
--
nosy: +Nathaniel Manista
___
Python tracker
<https://bugs.python.org/issue27721>
___
___
Python-bugs-list mailing list
Unsub
Nathaniel Manista added the comment:
Err, "... it's something that complicates writing code according to...", sorry.
--
___
Python tracker
<https://bugs.python.o
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
Change by Nathaniel Manista :
--
nosy: +Nathaniel Manista
___
Python tracker
<https://bugs.python.org/issue17519>
___
___
Python-bugs-list mailing list
Unsub
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 invite
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_it
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 FrameSum
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
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
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
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
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
Nathaniel Manista added the comment:
Thank you both!
--
___
Python tracker
<https://bugs.python.org/issue34133>
___
___
Python-bugs-list mailing list
Unsub
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
exce
Change by Nathaniel Manista <nathan...@google.com>:
--
nosy: +Nathaniel Manista
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
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()
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 sam
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
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.p
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
29 matches
Mail list logo
