[issue39142] logging.config.dictConfig will convert namedtuple to ConvertingTuple
New submission from Henrique :
While passing
{
"version": 1,
"disable_existing_loggers": False,
"formatters": {
"verbose": {"format": "%(levelname)s %(asctime)s %(module)s
%(message)s"}
},
"handlers": {
"stackdriver": {
"class": "google.cloud.logging.handlers.CloudLoggingHandler",
"client": client,
"resource": resource,
},
},
"root": {"level": "INFO", "handlers": ["stackdriver"]},
}
to logging.config.dictConfig it will convert resource, which is a namedtuple to
ConvertingTuple, this will make
google.cloud.logging.handlers.CloudLoggingHandler break down the line.
I am having to create a wrapper class like
class Bla:
resource = logging.resource.Resource(
type="cloud_run_revision",
labels={},
)
def _to_dict(self):
return self.resource._to_dict()
to go around this
--
messages: 358914
nosy: hcoura
priority: normal
severity: normal
status: open
title: logging.config.dictConfig will convert namedtuple to ConvertingTuple
type: crash
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue39142>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39142] logging.config.dictConfig will convert namedtuple to ConvertingTuple
Henrique added the comment:
Sorry for not sending a proper reproducible script when submitting the issue.
End of the day and quite frustrated with the bug, anyway, I attached a full
script that will show the error.
This is the custom handler I used:
class MyHandler(logging.StreamHandler):
def __init__(self, resource, *args, **kwargs):
super().__init__(*args, **kwargs)
self.resource: namedtuple = resource
def emit(self, record):
record.msg += f" {self.resource.type}"
return super().emit(record)
self.resource.type will throw and AttributeError when logging, because resource
gets converted from a namedtuple to a ConvertingTuple.
--
Added file: https://bugs.python.org/file48806/bug.py
___
Python tracker
<https://bugs.python.org/issue39142>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9305] Don't use east/west of UTC in date/time documentation
Henrique Bastos added the comment: Here goes a patch to replace east/west references on datetime documentation. As spoken with fdrake we think the datetime documentation could be improved extracting the timezone subclassing details to specific section. We'll be filling a new issue for that patch. -- nosy: +Rodolpho.Eckhardt, henriquebastos ___ Python tracker <http://bugs.python.org/issue9305> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9305] Don't use east/west of UTC in date/time documentation
Henrique Bastos added the comment: Here goes a patch to replace east/west references on datetime documentation. As spoken with fdrake we think the datetime documentation could be improved extracting the timezone subclassing details to specific section. We'll be filling a new issue for that patch. -- keywords: +patch Added file: http://bugs.python.org/file19694/datetime_doc_remove_east_west.diff ___ Python tracker <http://bugs.python.org/issue9305> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9305] Don't use east/west of UTC in date/time documentation
Henrique Bastos added the comment: To clarify: 1) "we" means henriquebastos, rbp, Rodolpho.Eckhardt. 2) Mentioning fdrake I was trying to say that we followed his suggestion to only submit the specific changes on this patch, leaving further documentation changes to another issue. Sorry about any inconvenience. -- ___ Python tracker <http://bugs.python.org/issue9305> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1745035] DoS smtpd vulnerability
Changes by Henrique Bastos : -- nosy: +henriquebastos ___ Python tracker <http://bugs.python.org/issue1745035> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2236] Distutils' mkpath implementation ignoring the "mode" parameter
New submission from Henrique Romano: The default value for mkpath's mode parameter is 0777 but it isn't used at any place; attached is a patch that just pass the parameter to os.mkdir call, this seems to fix the problem. -- components: Library (Lib) files: python2.5-distutils_mkpath_filemode.v1.diff keywords: patch messages: 63259 nosy: henrique severity: normal status: open title: Distutils' mkpath implementation ignoring the "mode" parameter type: resource usage versions: Python 2.5 Added file: http://bugs.python.org/file9605/python2.5-distutils_mkpath_filemode.v1.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2236> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32732] LoggingAdapter ignores extra kwargs of Logger#log()
Samuel Henrique added the comment:
Hello Vinay Sajip,
I would like to kindly ask you to please reconsider and give your thoughts on
my description of the issue here.
Let me try to work based on your last reply:
> ...has been around since Jan 2008, and it seems that no one in that time has
> raised this as a must-have
This is a fair statement and it certainly shows that this is not a big enough
issue for enough people to complain about. I believe it falls into the
"papercut" category of issues and people just override the "process" method
when they hit it.
> 1. If you want to pass different kwargs in every time, use a logger.
> 2. If you want to pass particular contextual information in which fits the
> "extra" parameter approach, use a LoggerAdapter.
> 3. If that doesn't do it for you, subclass LoggerAdapter and implement what
> you need.
We could improve the logging library by removing the limitation #1 with no
apparent downsides, so please bear with me for my example below.
> You haven't really explained why you need this to work in this particular
> way, so I suspect it could be an XY problem.
So Steffen Schuldenzucker already provided an use case, I have one which is
very similar and hopefully easily recognizable as a common (or at least not
rare) usage pattern of logging:
As a logging user, I would like to have a set of extra keys in the formatter,
some required and some optional, such that I can make use of LoggerAdapter to
set the constant extra values only once, and still pass the dynamic extra
values on each "log" method.
Pseudo code:
# assume logger is a logger object with a formatter that allows for dynamic
extra keys (dynamic = optional extra keys)
adapted_logger = logging.LoggerAdapter(logger, extra={"invocation_id":
"invocation_id_value"})
adapted_logger.info("test", extra={"resource_owner": "resource_owner_value"})
In this example I expect the log entry to contain both extra keys:
"invocation_id" and "resource_owner". invocation_id is reused in every log
entry but resource_owner changes based on what's being processed.
For reference, this is an example of a Formatter which allows for dynamic extra
keys and formats log entries to json serialized strings:
class ExtraFormatter(logging.Formatter):
"""
Dynamically adds any extra key to a json-like output.
"""
def format(self, record: logging.LogRecord) -> str:
default_attrs = vars(
logging.LogRecord(None, None, None, None, None, None, None)
).keys()
extras = set(record.__dict__.keys()) - set(default_attrs)
log_items = {"message": "%(message)s"}
for attr in extras:
log_items[attr] = f"%({attr})s"
format_str = json.dumps(log_items)
self._style._fmt = format_str
return super().format(record)
The reason I believe this is a papercut type of issue is that I would expect
the Formatter to control whether or not to show the extra key, not the
LoggerAdapter. It is counter intuitive to me that the LoggerAdapter would
silently drop any extra keys provided to the log methods, and I would expect
that LoggerAdapter would at least not allow for the parameter to be passed then
(I don't like this alternative either, but it removes the feeling of being
tricked).
Again, this is a problem that can easily be workaround-ed by overriding the
"process" method. But there seems to be a very good opportunity to improve the
Adapter instead and avoid letting other people hit this issue. I'm curious
about your opinion on any downsides to this change as I couldn't come up with
anything.
There is also a problem with the current documentation, in which the
LoggerAdapter doc led me (and other people, when we had to debug this issue) to
believe the Adapter would not silently drop the extra parameters. The only
place where this behavior is mentioned is in the logging-cookbook, in the
following part:
"Of course, if you had passed an ‘extra’ keyword argument in the call to the
adapter, it will be silently overwritten."
The "Of course" part is a little bit weird cause it implies it's an obvious
behavior, whereas the sentence just before this one says: "The default
implementation of this method leaves the message alone, but inserts an ‘extra’
key in the keyword argument whose value is the dict-like object passed to the
constructor.". Note how it uses the word "inserts" instead of "overrides".
So the documentation has to be updated, either to mention this behavior in the
LoggerAdapter documentation or to remove the part about extra being silently
overwritten in the cookbook, the only place this is mentioned (if this gets
changed).
[issue41546] pprint() gives exception when ran from pythonw
Henrique Gj added the comment: > Debug prints should not crash a program. > 'Not a bug' wait -- nosy: +henriquesdj0 ___ Python tracker <https://bugs.python.org/issue41546> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33081] multiprocessing Queue leaks a file descriptor associated with the pipe writer
New submission from Henrique Andrade : A simple example like such demonstrates that one of the file descriptors associated with the underlying pipe will be leaked: >>> from multiprocessing.queues import Queue >>> x = Queue() >>> x.close() Right after the queue is created we get (assuming the Python interpreter is associated with pid 8096 below): > ll /proc/8096/fd total 0 dr-x-- 2 hcma hcma 0 2018-03-15 14:03:23.210089578 -0400 . dr-xr-xr-x 9 hcma hcma 0 2018-03-15 14:03:23.190089760 -0400 .. lrwx-- 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 0 -> /dev/pts/25 lrwx-- 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 1 -> /dev/pts/25 lrwx-- 1 hcma hcma 64 2018-03-15 14:03:23.210089578 -0400 2 -> /dev/pts/25 lr-x-- 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 3 -> pipe:[44076946] l-wx-- 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 4 -> pipe:[44076946] lr-x-- 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 5 -> /dev/urandom After close(): > ll /proc/8096/fd total 0 dr-x-- 2 hcma hcma 0 2018-03-15 14:03:23.210089578 -0400 . dr-xr-xr-x 9 hcma hcma 0 2018-03-15 14:03:23.190089760 -0400 .. lrwx-- 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 0 -> /dev/pts/25 lrwx-- 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 1 -> /dev/pts/25 lrwx-- 1 hcma hcma 64 2018-03-15 14:03:23.210089578 -0400 2 -> /dev/pts/25 lr-x-- 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 3 -> pipe:[44076946] l-wx-- 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 4 -> pipe:[44076946] lr-x-- 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 5 -> /dev/urandom -- components: Library (Lib) messages: 313899 nosy: Henrique Andrade priority: normal severity: normal status: open title: multiprocessing Queue leaks a file descriptor associated with the pipe writer versions: Python 2.7 ___ Python tracker <https://bugs.python.org/issue33081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33081] multiprocessing Queue leaks a file descriptor associated with the pipe writer
Henrique Andrade added the comment: Correcting my original - after close(): > ll /proc/8096/fd total 0 dr-x-- 2 hcma hcma 0 2018-03-15 14:03:23.210089578 -0400 . dr-xr-xr-x 9 hcma hcma 0 2018-03-15 14:03:23.190089760 -0400 .. lrwx-- 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 0 -> /dev/pts/25 lrwx-- 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 1 -> /dev/pts/25 lrwx-- 1 hcma hcma 64 2018-03-15 14:03:23.210089578 -0400 2 -> /dev/pts/25 l-wx-- 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 4 -> pipe:[44076946] lr-x-- 1 hcma hcma 64 2018-03-15 14:03:33.145998954 -0400 5 -> /dev/urandom -- ___ Python tracker <https://bugs.python.org/issue33081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33081] multiprocessing Queue leaks a file descriptor associated with the pipe writer
Henrique Andrade added the comment: Pablo, but there is no way to close the other side. Indeed, if you look in the implementation, you will see that the writer file descriptor can't be closed. -- ___ Python tracker <https://bugs.python.org/issue33081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33081] multiprocessing Queue leaks a file descriptor associated with the pipe writer
Henrique Andrade added the comment: Unfortunately this is not the case. I will shrink my repro down to a more manageable size and post it here. -- ___ Python tracker <https://bugs.python.org/issue33081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33081] multiprocessing Queue leaks a file descriptor associated with the pipe writer
Henrique Andrade added the comment: Here is the repro (I am running this on Ubuntu 16 with the stock Python version 2.7.12): #!/usr/bin/env python import os import subprocess import sys from multiprocessing import Process, Queue from multiprocessing.queues import _sentinel def run_external_application(application_name, queue): """Runs an Oxygen application""" exit_status = 10 queue.put(exit_status) # none of the following help as far as making the pipe go away queue.put(_sentinel) queue.close() def run(application_name="external_application"): print "Starting '%s'" % application_name queue = Queue() application_process = Process(target=run_external_application, args=(application_name, queue)) application_process.start() try: application_process.join() except KeyboardInterrupt: application_process.terminate() exit_status = queue.get() print "exit status", exit_status queue.close() # the deletion below has no effect del queue # the only thing that will make the pipe go away is to uncomment the below statement # queue._writer.close() print "\nthe '%s' application finished with exit status '%s'...\n" % (application_name, exit_status) print "Note the file descriptor #4 below" subprocess.call(["ls", "-la", "/proc/%d/fd" % os.getpid()]) return exit_status if __name__ == "__main__": print "starting ", os.getpid() exit_status = run() sys.exit(exit_status) -- ___ Python tracker <https://bugs.python.org/issue33081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33081] multiprocessing Queue leaks a file descriptor associated with the pipe writer
Henrique Andrade added the comment: @pablo: I am using Python 2.7.12 (distributed with Ubuntu 16), what are you using? This might explain the difference between what we see. Yet, irrespective of this difference, imho, it would be a better design to have "close" actually closing the underlying resources. In general, if one has to delete and/or invoke the garbage collector on an object, it's an indication that the design needs a bit of polish. Just picture the small scenario I described amplified to a situation where a large number of queues is used, which is perhaps an artificial scenario, but one would end up with a bunch of file descriptors hanging around for no reason. This is what files and sockets, for example, would do. -- ___ Python tracker <https://bugs.python.org/issue33081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33081] multiprocessing Queue leaks a file descriptor associated with the pipe writer
Henrique Andrade added the comment: I don't want to "close the pipes but maintain the queue alive" - I want to terminate the queue and make sure that no resources are leaked. It's that simple. When one closes a file or a socket, there is no underlying OS resource being held. That's what I would like to have here too. Apparently the design does not support that and, if that's the case, it's fine, it's just that it goes against most of the norm afaict. On Sun, Mar 18, 2018 at 12:46 PM, Pablo Galindo Salgado < rep...@bugs.python.org> wrote: > > Pablo Galindo Salgado added the comment: > > Notice that the documentation for close says: > > > Indicate that no more data will be put on this queue by the current > process. The background thread will quit once it has flushed all buffered > data to the pipe. This is called automatically when the queue is garbage > collected. > > The method does not promise to close any pipe, just "Indicate that no more > data will be put on this queue by the current process". Closing prematurely > the writer side could lead to issues. I still do not understand why you > would want to close the pipes but maintain the queue alive. > > I could be missing something, so let's see if other people think > differently about this. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue33081> > ___ > -- Henrique Andrade | +1-530-426-2123 | h...@unscrambl.com | https://unscrambl.com -- ___ Python tracker <https://bugs.python.org/issue33081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33081] multiprocessing Queue leaks a file descriptor associated with the pipe writer
Henrique Andrade added the comment: Your comparison is not correct. RAII in C++ ensures that, on object destruction, resources that have been acquired will be closed and deallocated. The closest analogy in Python is the use of a context manager, which, btw, a Queue does not provide. Indeed, such a design (with a context manager) would have been cleaner because, on exit, both pipes would have been closed and file descriptors would not hang around. And, yes, that is what I'd prefer too - but one can't have everything. :) With the current design, which is more akin to Java, one is exposed to the vagaries of the garbage collector. Note that, even in Java, try-with-resources and the auto-closeable interface would also take care of this. In fact, most the Java classes that require external resources have migrated to this model. For these reasons, I think the design could be substantially improved (i.e., with a context manager or with the provision of a method that really terminates the queue, so resources are properly closed immediately). On Sun, Mar 18, 2018 at 1:12 PM, Pablo Galindo Salgado < rep...@bugs.python.org> wrote: > > Pablo Galindo Salgado added the comment: > > >"I want to terminate the queue and make sure that no resources are leaked. > > Then you don't need to do anything special, those will be cleared on > object destruction. This is not an unusual pattern even in other languages. > For example, RAII in C++ is one of the most used patterns for acquiring > resources and that works cleaning those resources on object destruction. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue33081> > ___ > -- Henrique Andrade | +1-530-426-2123 | h...@unscrambl.com | https://unscrambl.com -- ___ Python tracker <https://bugs.python.org/issue33081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33081] multiprocessing Queue leaks a file descriptor associated with the pipe writer
Henrique Andrade added the comment: You're a missing the fact that in C++, there is no garbage collector. The destructor both releases resources and deallocates memory. There is no window between releasing resources and object destruction. Python, while not exactly like Java, is similar to Java in the sense that there is a window of time between an object no longer having a reference and its being reaped by the garbage collector. During that window, resources can be held even if no longer in use. In extreme cases, a lot of these resources can be held (think hundreds of Queues being created and closed in succession without an intervening GC run), even if not used. Sure, at some point, they will be reaped, but it might be a while. And that's one of the reasons Python and Java have mechanisms to acquire/release resources in a more timely fashion. Context managers in the former and try-with-resources in the latter. The mere presence of a proper close/shutdown method can make this work in an improved way in the case of a Queue, allowing OS resources (pipes) to be released in a more timely fashion. But, sure, let's hear what the community thinks. On Sun, Mar 18, 2018, 14:01 Pablo Galindo Salgado wrote: > > Pablo Galindo Salgado added the comment: > > > RAII in C++ ensures that, on object destruction, resources that have > been acquired will be closed and deallocated. > > Which is exactly what is happening here. When the queue gets destroyed > (because the reference count reaches 0 or because of the garbage collector) > resources that have been acquired by the queue will be closed an > deallocated. > > Sadly, I don't think I have anything different to apport to this > discussion, so let's see what other people opinions are on this. > > Of course, feel free to start a thread on python-dev or python-ideas on > how to improve the design. :) > > -- > > ___ > Python tracker > <https://bugs.python.org/issue33081> > ___ > -- ___ Python tracker <https://bugs.python.org/issue33081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33117] asyncio example uses non-existing/documented method
New submission from Henrique Fingler : In the documentation of asyncio.run_coroutine_threadsafe(coro, loop), in Section 19.5.3.6 (https://docs.python.org/3/library/asyncio-task.html#asyncio.run_coroutine_threadsafe), the example code does the following: future = asyncio.run_coroutine_threadsafe(coro, loop) # Wait for the result with an optional timeout argument assert future.result(timeout) == 3 The problem is that the result method of a future, according to the documentation doesn't take parameters. It's in Section 19.5.3.4 (https://docs.python.org/3.8/library/asyncio-task.html#asyncio.Future.done) result() Return the result this future represents. The same function is used in Section 18.5.9.3 (https://docs.python.org/3/library/asyncio-dev.html#concurrency-and-multithreading) This error is present in all Python 3.* docs. From the asyncio source code (https://github.com/python/cpython/blob/master/Lib/asyncio/futures.py), we have this in the Future class definition: class Future: """This class is *almost* compatible with concurrent.futures.Future. Differences: - This class is not thread-safe. - result() and exception() do not take a timeout argument and raise an exception when the future isn't done yet. So this example needs to be reworked, I'd do it if I knew more about asyncio. My ideas involve either using a add_done_callback with a flag or just busy waiting until future.done(). -- assignee: docs@python components: Documentation messages: 314223 nosy: Henrique Fingler, docs@python priority: normal severity: normal status: open title: asyncio example uses non-existing/documented method versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33117> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1128] msilib.Directory.make_short only handles file names with a single dot in them
Henrique Baggio added the comment:
Sorry, I don't know how create a patch, but just change the line with
parts = file.split(".") to parts = os.path.splitext(file)
and the problem is fixed.
--
nosy: +hnrqbaggio
___
Python tracker
<http://bugs.python.org/issue1128>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1128] msilib.Directory.make_short only handles file names with a single dot in them
Henrique Baggio added the comment: I create a patch using the os.path.splitext function. -- Added file: http://bugs.python.org/file13846/msilib.__init__.patch ___ Python tracker <http://bugs.python.org/issue1128> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1128] msilib.Directory.make_short only handles file names with a single dot in them
Henrique Baggio added the comment: @Amaury, Sorry my mistake. I forgot splitext returns a tuple. =/ About your question, if the file name has less then 8 characters, then the function don't change it. Else, it return tha name with 8 chars. e.g., make_short(foo.2.txt) returns FOO.2.TXT and make_short(foo.longer_name.txt) returns FOO.LO~1.TXT -- ___ Python tracker <http://bugs.python.org/issue1128> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25459] EAGAIN errors in Python logging module
New submission from Henrique Andrade: There is a particular bug we hit when using the Python logging module very consistently under the particular settings in which we run one of our applications. We are using Python 2.7.10 on RHEL7/RHEL6/Ubuntu14.04. Anyways, here is the symptom: Traceback (most recent call last): File "/opt/continuum/anaconda/lib/python2.7/logging/__init__.py", line 880, in emit stream.write(fs % msg) IOError: [Errno 11] Resource temporarily unavailable Here is the suggested fix: 26c26 < import sys, os, time, cStringIO, traceback, warnings, weakref, collections, errno --- > import sys, os, time, cStringIO, traceback, warnings, weakref, collections 880,886c880 < while True: < try: < stream.write(fs % msg) < break < except IOError as e: < if e.errno != errno.EAGAIN: < raise --- > stream.write(fs % msg) -- components: Extension Modules messages: 253329 nosy: henrique_andrade priority: normal severity: normal status: open title: EAGAIN errors in Python logging module versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue25459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25459] EAGAIN errors in Python logging module
Henrique Andrade added the comment:
The stream in this case (where I hit the bug) is just the console, but I
suspect the same issue will affect other streams too.
A key piece of information is that this is probably triggered by having a
custom SIGPIPE handler, which my particular application has.
When a SIGPIPE handler is in place, errors such as EAGAIN and EWOULDBLOCK
might be generated and the logging module wasn't resilient to it.
Here is the unified patch output:
11:00:38|sequoia|/opt/continuum/anaconda> diff -u
/opt/continuum/anaconda/pkgs/python-2.7.8-0/lib/python2.7/logging/__init__.py
/opt/continuum/anaconda/pkgs/python-2.7.8-1/lib/python2.7/logging/__init__.py
---
/opt/continuum/anaconda/pkgs/python-2.7.8-0/lib/python2.7/logging/__init__.py
2014-07-02
19:08:57.0 -0400
+++
/opt/continuum/anaconda/pkgs/python-2.7.8-1/lib/python2.7/logging/__init__.py
2015-09-22
13:57:39.196032267 -0400
@@ -23,7 +23,7 @@
To use, simply 'import logging' and log away!
"""
-import sys, os, time, cStringIO, traceback, warnings, weakref, collections
+import sys, os, time, cStringIO, traceback, warnings, weakref,
collections, errno
__all__ = ['BASIC_FORMAT', 'BufferingFormatter', 'CRITICAL', 'DEBUG',
'ERROR',
'FATAL', 'FileHandler', 'Filter', 'Formatter', 'Handler',
'INFO',
@@ -877,7 +877,13 @@
#An extra encoding step seems to be needed.
stream.write((ufs %
msg).encode(stream.encoding))
else:
-stream.write(fs % msg)
+while True:
+try:
+stream.write(fs % msg)
+break
+except IOError as e:
+if e.errno != errno.EAGAIN:
+raise
except UnicodeError:
stream.write(fs % msg.encode("UTF-8"))
self.flush()
On Thu, Oct 22, 2015 at 10:01 AM, STINNER Victor
wrote:
>
> STINNER Victor added the comment:
>
> What is the type of the stream? Is is a pipe or a regular file? Or a
> socket?
>
> Can you please format the patch as an unified patch please?
>
> --
> nosy: +haypo
>
> ___
> Python tracker
> <http://bugs.python.org/issue25459>
> ___
>
--
___
Python tracker
<http://bugs.python.org/issue25459>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25459] EAGAIN errors in Python logging module
Henrique Andrade added the comment: Vinay, apologies for the long time you took me to respond (the notification was stuck in my Spam folder, thanks Gmail!). Indeed, both of your comments are spot on. In my particular case, I ended up implementing what your first suggestion alludes to (a retry capped by a maximum). The reason for my reporting this is because the existing (mainlined) implementation has shortcomings, which might be affecting others out there. I contacted the module developer, but no response. So assuming we have a consensus from whomever "owns" the module, I can volunteer to do a proper patch. On the issue of maximum retries, I would go with a reasonable (configurable) max as well as a (configurable) back-off sleep. On Sun, Feb 7, 2016 at 1:57 PM, Vinay Sajip wrote: > > Vinay Sajip added the comment: > > The problem with your suggested fix is that if you keep getting EAGAIN, > the handler will appear to hang. If you want to suggest that maybe we limit > the number of tries, then what number of retries would you pick, and why? > Also, a caller might want to know about EAGAIN, so I'm not sure you'd want > to (effectively) swallow it in the handler. > > Perhaps a different strategy (than just trying for ever) would be better. > If you know the application is unusual in having a SIGPIPE handler and you > think this is a contributory factor, why not just subclass the handler, add > a more resilient emit() and use that in your application? > > -- > status: open -> pending > > ___ > Python tracker > <http://bugs.python.org/issue25459> > ___ > -- Henrique Andrade | +1-530-426-2123 | h...@unscrambl.com | http://unscrambl.com -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue25459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46417] Clear static types in Py_Finalize() for embedded Python
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue46417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2236] Distutils' mkpath implementation ignoring the "mode" parameter
Carlos Henrique Romano added the comment: Patch updated, now it includes test. -- nosy: +chromano Added file: http://bugs.python.org/file18885/python-distutils_mkpath_filemode-v1.diff ___ Python tracker <http://bugs.python.org/issue2236> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2236] Distutils' mkpath implementation ignoring the "mode" parameter
Changes by Carlos Henrique Romano : Removed file: http://bugs.python.org/file18885/python-distutils_mkpath_filemode-v1.diff ___ Python tracker <http://bugs.python.org/issue2236> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2236] Distutils' mkpath implementation ignoring the "mode" parameter
Carlos Henrique Romano added the comment: Improving tests -- Added file: http://bugs.python.org/file18887/python-distutils_mkpath_filemode-v2.diff ___ Python tracker <http://bugs.python.org/issue2236> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2236] Distutils' mkpath implementation ignoring the "mode" parameter
Carlos Henrique Romano added the comment: Updating test in order to consider umask, this is supposed to fix buildbot issues. -- Added file: http://bugs.python.org/file18927/python-distutils_mkpath_filemode-test-update.diff ___ Python tracker <http://bugs.python.org/issue2236> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup loops with better bytecode
Changes by P. Henrique Silva <[EMAIL PROTECTED]>: -- nosy: +phsilva __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2459> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36876] Global C variables are a problem.
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue36876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36854] GC operates out of global runtime state.
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue36854> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24554] GC should happen when a subinterpreter is destroyed
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue24554> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36877] [meta] Move fields from _PyRuntimeState to PyInterpreterState.
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue36877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36710] Pass _PyRuntimeState as an argument rather than using the _PyRuntime global variable
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue36710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34690] Store startup modules as C structures for 20%+ startup speed improvement
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue34690> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37955] mock.patch incorrect reference to Mock
New submission from Paulo Henrique Silva : When explaining the usage of keyword arguments on mock.patch: ``` patch() takes arbitrary keyword arguments. These will be passed to the Mock (or new_callable) on construction. ``` default new_callable is MagicMock and it should be mentioned here instead of Mock (even tough MagickMock inherits from it). -- assignee: docs@python components: Documentation messages: 350537 nosy: docs@python, phsilva priority: normal severity: normal status: open title: mock.patch incorrect reference to Mock versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37955] mock.patch incorrect reference to Mock
Change by Paulo Henrique Silva : -- keywords: +patch pull_requests: +15204 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15521 ___ Python tracker <https://bugs.python.org/issue37955> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38116] Make select module PEP-384 compatible
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue38116> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44135] issubclass documentation doesn't explain tuple semantic
New submission from João Henrique Pimentel : The second parameter (classinfo) of the issubclass built-in function can be a Tuple and, starting from 3.10, it can be a Union Type as well. The documentation states that in these cases "every entry in classinfo will be checked", but it doesn't explain if the check is AND (all) or OR (any). In contrast, the documentation of isinstance is clear: "return True if object is an instance of *any* of the types". Here's a possible rewriting that reduces the odds of incorrect interpretations, based on the text of isinstance: ORIGINAL: "in which case every entry in classinfo will be checked" PROPOSAL: "in which case return True if class is a subclass of any entry in classinfo" -- assignee: docs@python components: Documentation messages: 393684 nosy: docs@python, joaozinho priority: normal severity: normal status: open title: issubclass documentation doesn't explain tuple semantic type: enhancement versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45544] Close 2to3 issues and list them here
Change by Paulo Henrique Silva : -- nosy: +phsilva nosy_count: 5.0 -> 6.0 pull_requests: +27387 pull_request: https://github.com/python/cpython/pull/18654 ___ Python tracker <https://bugs.python.org/issue45544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38500] Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue38500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue10915> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15751] Support subinterpreters in the GIL state API
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue15751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue39511> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39683] 2to3 fix_exitfunc suggests duplicated import of atexit module
Change by Paulo Henrique Silva : -- keywords: +patch nosy: +phsilva nosy_count: 1.0 -> 2.0 pull_requests: +18015 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18654 ___ Python tracker <https://bugs.python.org/issue39683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue1635741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39984] Move some ceval fields from _PyRuntime.ceval to PyInterpreterState.ceval
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue39984> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Change by Paulo Henrique Silva : -- pull_requests: +18468 pull_request: https://github.com/python/cpython/pull/19107 ___ Python tracker <https://bugs.python.org/issue1635741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37207] Use PEP 590 vectorcall to speed up calls to range(), list() and dict()
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue37207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Paulo Henrique Silva added the comment: About half of the remaining refs are related to encodings. I noticed that caches on Lib/encodings/__init__.py and codec_search_cach of PyInterpreterState are the places holding the refs. I removed those caches and number went do to: Before: 4382 refs left After : 2344 refs left (-46%) The way to destroy codec_search_cache was recently changed on #36854 and $38962. (Not proposing to merge this, but my changes are at https://github.com/python/cpython/compare/master...phsilva:remove-codec-caches). -- ___ Python tracker <https://bugs.python.org/issue1635741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Change by Paulo Henrique Silva : -- pull_requests: +18483 pull_request: https://github.com/python/cpython/pull/19122 ___ Python tracker <https://bugs.python.org/issue1635741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Change by Paulo Henrique Silva : -- pull_requests: +18511 pull_request: https://github.com/python/cpython/pull/19150 ___ Python tracker <https://bugs.python.org/issue1635741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Change by Paulo Henrique Silva : -- pull_requests: +18512 pull_request: https://github.com/python/cpython/pull/19151 ___ Python tracker <https://bugs.python.org/issue1635741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Paulo Henrique Silva added the comment: Updating on my findings on msg364833. It looks like encodings module is not being destoyed at all and keeping all the encoding refs alive. Looks like some cycle but I am not sure yet how to solve it. To validate this, I: - removed codec_search_cach of PyInterpreterState. - Py_DECREFd(encodings) after loading it on codecs.c. Before: 4376 refs left (37fcbb65d4) After : 352 refs left (-92%) I've updated the changes at https://github.com/python/cpython/compare/master...phsilva:remove-codec-caches (not a proposed patch, just to validate the idea) -- ___ Python tracker <https://bugs.python.org/issue1635741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Paulo Henrique Silva added the comment: Thanks for the clarifications. I will keep looking for simple modules, no state and easy to migrate but also dedicate more time to work on the more complex like datetime. I'm working on PR19122 corrections. -- ___ Python tracker <https://bugs.python.org/issue1635741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40071] test__xxsubinterpreters leaked [1, 1, 1] references: test_ids_global()
Change by Paulo Henrique Silva : -- keywords: +patch nosy: +phsilva nosy_count: 1.0 -> 2.0 pull_requests: +18529 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19151 ___ Python tracker <https://bugs.python.org/issue40071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40071] test__xxsubinterpreters leaked [1, 1, 1] references: test_ids_global()
Paulo Henrique Silva added the comment: I've got it, will investigate asap. -- ___ Python tracker <https://bugs.python.org/issue40071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40071] test__xxsubinterpreters leaked [1, 1, 1] references: test_ids_global()
Change by Paulo Henrique Silva : -- pull_requests: +18532 pull_request: https://github.com/python/cpython/pull/19172 ___ Python tracker <https://bugs.python.org/issue40071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40071] test__xxsubinterpreters leaked [1, 1, 1] references: test_ids_global()
Paulo Henrique Silva added the comment: The module still uses static state. Fixed the leak and will convert it to use per-module state in a separate issue. -- ___ Python tracker <https://bugs.python.org/issue40071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue33608> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40077] Convert static types to PyType_FromSpec()
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue40077> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40071] test__xxsubinterpreters leaked [1, 1, 1] references: test_ids_global()
Change by Paulo Henrique Silva : -- pull_requests: +18628 pull_request: https://github.com/python/cpython/pull/19273 ___ Python tracker <https://bugs.python.org/issue40071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40071] test__xxsubinterpreters leaked [1, 1, 1] references: test_ids_global()
Paulo Henrique Silva added the comment: As discussed on PR19172, this module uses a global state in functions that do not receive a PyModule* and right now converting such cases to per-module state is not trivial. I will wait for PEP-573 implementation that will hopefully make this easier. Pushed PR19273 to avoid the potential crash induced by the original change. -- ___ Python tracker <https://bugs.python.org/issue40071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40137] TODO list when PEP 573 "Module State Access from C Extension Methods" will be implemented
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue40137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Paulo Henrique Silva added the comment:
Repeated msg355187 testing on master[056c08211b].
---
#include
void func()
{
Py_Initialize(); Py_Finalize();
Py_ssize_t cnt = _Py_GetRefTotal();
printf("sys.gettotalrefcount(): %zd\n", cnt);
}
int main(int argc, char *argv[])
{
Py_SetProgramName(L"./_testembed");
for (int i=0; i < 10; i++) {
func();
}
}
---
No refs leaking anymore!?
---
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241
---
--
___
Python tracker
<https://bugs.python.org/issue1635741>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10399] AST Optimization: inlining of function calls
Change by Paulo Henrique Silva : -- nosy: +phsilva ___ Python tracker <https://bugs.python.org/issue10399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7946] Convoy effect with I/O bound threads and New GIL
Changes by P. Henrique Silva : -- nosy: +phsilva ___ Python tracker <http://bugs.python.org/issue7946> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40731] CWI url's protocol on LICENSE file from http to https
New submission from Vinicius Henrique Silva Bastos : CWI url's protocol on LICENSE file from http to https from: http://www.cwi.nl to: https://www.cwi.nl Obs.: Learning about pull requests and how it works. -- assignee: docs@python components: Documentation files: LICENSE hgrepos: 388 messages: 369610 nosy: bastosvinicius, docs@python priority: normal severity: normal status: open title: CWI url's protocol on LICENSE file from http to https type: enhancement versions: Python 3.10 Added file: https://bugs.python.org/file49181/LICENSE ___ Python tracker <https://bugs.python.org/issue40731> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40731] CWI url's protocol on LICENSE file from http to https
Change by Vinicius Henrique Silva Bastos : -- keywords: +patch pull_requests: +19586 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20317 ___ Python tracker <https://bugs.python.org/issue40731> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
