Jason R. Coombs added the comment:
New changeset 136735c1a2efb320e4cbb64b40f1191228745b39 by Jason R. Coombs in
branch 'master':
bpo-39297: Update for importlib_metadata 1.4. (GH-17947)
https://github.com/python/cpython/commit/136735c1a2efb320e4cbb64b40f1191228745b39
Jason R. Coombs added the comment:
Given that this issue only affects those who upgraded from beta versions, I'm
inclined to say it shouldn't be part of the installer, and that the long tail
of users affected probably can track it down here.
I don't feel strongly about it though
Jason R. Coombs added the comment:
In issue39103, I filed a bug relating to this issue.
I'd like for Python to provide a portable implementation of strftime instead of
just documenting that the version isn't portable.
Given that this ticket assigned to 'docs' suggests that a portable
Jason R. Coombs added the comment:
In issue39211, I've done a good deal of investigation on this issue and
confirmed your findings - on Windows, the server fails to bind dual stack on
Windows, but instead binds IPV6ONLY. That needs to be fixed such that the
default is to bind dual-stack
Jason R. Coombs added the comment:
New changeset ee94bdb0598f9bc47d6a49e58fffc97aa617be96 by Jason R. Coombs in
branch 'master':
bpo-38907: In http.server script, restore binding to IPv4 on Windows. (GH-17851)
https://github.com/python/cpython/commit/ee94bdb0598f9bc47d6a49e58fffc97aa617be96
Change by Jason R. Coombs :
--
keywords: +patch
pull_requests: +17273
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17851
___
Python tracker
<https://bugs.python.org/issu
Change by Jason R. Coombs :
--
pull_requests: +17272
pull_request: https://github.com/python/cpython/pull/17851
___
Python tracker
<https://bugs.python.org/issue38
Change by Jason R. Coombs :
--
pull_requests: +17274
pull_request: https://github.com/python/cpython/pull/17851
___
Python tracker
<https://bugs.python.org/issue20
Jason R. Coombs added the comment:
Other than addressing issue38907, is there anything else to be done here? In
GH-17851, I've proposed a surgical fix to address the issue with IPv4 being
unbound on Windows.
--
___
Python tracker
<ht
Jason R. Coombs added the comment:
> It's the addition of flags=socket.AI_PASSIVE on Lib/http/server.py:1233
> that's causing this.
Can you elaborate? What is it causing?
I can see that flag was added in
https://github.com/python/cpython/pull/11767/c
Jason R. Coombs added the comment:
First, a quick primer in IP:
- Addresses are written as :::::::, but any
single span of zeros can be written as ::, so `::` is all zeros and `::1` is
the same as :::::::0001.
- ::1 is the local
Jason R. Coombs added the comment:
Indeed, if I apply this patch:
```
diff --git a/Lib/http/server.py b/Lib/http/server.py
index 47a4fcf9a6..de995ae4b9 100644
--- a/Lib/http/server.py
+++ b/Lib/http/server.py
@@ -1246,6 +1246,11 @@ def test(HandlerClass=BaseHTTPRequestHandler
Jason R. Coombs added the comment:
In PR 17378, we discussed and I believe the conclusion is that the fix in the
other PR(s) is sufficient to address the deficiency.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -&g
Jason R. Coombs added the comment:
New changeset 33cb4a62bf6848093b7a05c9794582d204798b1b by Jason R. Coombs (Miss
Islington (bot)) in branch '3.8':
bpo-38907: Suppress any exception when attempting to set V6ONLY. (GH-17864)
(GH-17865)
https://github.com/python/cpython/commit
Change by Jason R. Coombs :
--
pull_requests: +17281
pull_request: https://github.com/python/cpython/pull/17864
___
Python tracker
<https://bugs.python.org/issue38
Jason R. Coombs added the comment:
New changeset 5ed9d60bc53e2eb0a88f07d5afe5299acdc0b216 by Jason R. Coombs (Miss
Islington (bot)) in branch '3.8':
bpo-38907: In http.server script, restore binding to IPv4 on Windows.
(GH-17851) (#17854)
https://github.com/python/cpython/commit
Jason R. Coombs added the comment:
New changeset 7cdc31a14c824000cbe8b487900c9826a33f6940 by Jason R. Coombs in
branch 'master':
bpo-38907: Suppress any exception when attempting to set V6ONLY. (GH-17864)
https://github.com/python/cpython/commit/7cdc31a14c824000cbe8b487900c9826a33f6940
Jason R. Coombs added the comment:
The latest release, 1.3.0, includes extensibility support and has been merged
with the cpython branch of the importlib_resources project. I believe that code
is now synced with this project and ready to be applied here. I'm hoping
benthayer can apply
Change by Jason R. Coombs :
--
versions: +Python 3.9 -Python 3.8
___
Python tracker
<https://bugs.python.org/issue35967>
___
___
Python-bugs-list mailin
Jason R. Coombs added the comment:
New changeset 3e72de9e08b03a15875f5b226c5f096e567dab42 by Miss Islington (bot)
in branch '3.8':
[3.8] bpo-39667: Sync zipp 3.0 (GH-18540) (GH-18701)
https://github.com/python/cpython/commit/3e72de9e08b03a15875f5b226c5f096e567dab42
Jason R. Coombs added the comment:
In the 3.8 backport, I retained API compatibility and backported only the
performance improvement code.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracke
Jason R. Coombs added the comment:
The aformentioned test broke tests in buildbots:
https://buildbot.python.org/all/#builders/105/builds/779
--
___
Python tracker
<https://bugs.python.org/issue35
Jason R. Coombs added the comment:
I'm hoping that PR 19544 fixes the issue.
--
___
Python tracker
<https://bugs.python.org/issue35967>
___
___
Python-bug
Jason R. Coombs added the comment:
New changeset 4b4e90a51848578dc06341777a929a0be4f4757f by Jason R. Coombs in
branch 'master':
bpo-35967: Baseline values for uname -p (GH-12824)
https://github.com/python/cpython/commit/4b4e90a51848578dc06341777a929a0be4f4757f
Change by Jason R. Coombs :
--
pull_requests: +18891
pull_request: https://github.com/python/cpython/pull/19544
___
Python tracker
<https://bugs.python.org/issue35
Jason R. Coombs added the comment:
New changeset e72cbcb346cfcc1ed7741ed6baf1929764e1ee74 by Jason R. Coombs in
branch 'master':
bpo-35967: Make test_platform.test_uname_processor more lenient to satisfy
build bots. (GH-19544)
https://github.com/python/cpython/commit
Jason R. Coombs added the comment:
New changeset 518835f3354d6672e61c9f52348c1e4a2533ea00 by Jason R. Coombs in
branch 'master':
bpo-35967 resolve platform.processor late (GH-12239)
https://github.com/python/cpython/commit/518835f3354d6672e61c9f52348c1e4a2533ea00
Change by Jason R. Coombs :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Jason R. Coombs :
--
keywords: +patch
pull_requests: +19044
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19722
___
Python tracker
<https://bugs.python.org/issu
Jason R. Coombs added the comment:
> I thought it might be useful for testing purposes if os.path (i.e. ntpath and
> posixpath) had a way to set the home directory that it uses in way that
> wouldn't affect other libraries and child processes.
I was thinking about this, and
New submission from Jason R. Coombs :
In https://github.com/jaraco/path/issues/186, the Path project discovered a
regression with Python 3.8. It seems that if one creates a symlink with an
absolute path. I used `shutil.copytree('temp', 'temp2', True)` and it produced
this result
Jason R. Coombs added the comment:
I strongly suspect bpo-37834 and GH-15231 is where the difference was
introduced.
--
___
Python tracker
<https://bugs.python.org/issue40
Jason R. Coombs added the comment:
Thank you Eryk for the thorough and informative investigation. Seriously, wow.
> Do you want 3.8 to revert to using the print name, at least for symlinks?
> (ntpath._readlink_deep would need to be modified to support long target
> paths.) Or
New submission from Jason R. Coombs :
In issue40570, I learned that some users are still relying on legacy tuple-like
behaviors of `platform.uname()`, namely the access by item position and length:
```
platform.uname()[0]
len(platform.uname())
```
I propose to deprecate these behaviors
Jason R. Coombs added the comment:
Thanks Marc-Andre for the suggestion, but I don't think that approach is viable
here. The whole point of issue35967 was to defer the execution of the
`.processor` behavior until it was requested. The intention is not to extend
the tuple, but to shorten
Jason R. Coombs added the comment:
New changeset 2c3d508c5fabe40dac848fb9ae558069f0576879 by Jason R. Coombs in
branch 'master':
bpo-40570: Improve compatibility of uname_result with late-bound .platform
(#20015)
https://github.com/python/cpython/commit
Jason R. Coombs added the comment:
I've gone ahead and merged PR 20015 to fix the issue, but I'm happy to revisit
if a better approach is proposed.
--
keywords: +3.9regression -patch
resolution: -> fixed
stage: patch review -> resolved
status: open -&g
Jason R. Coombs added the comment:
In https://github.com/jaraco/cpython/tree/bc73729eb9, I started drafting a
proposed implementation to address this concern, but ran into a snag - the
tests immediately reveal that `tuple(platform.uname())` invokes `__len__`,
triggering the deprecation
Jason R. Coombs added the comment:
My bad. I probably could have been more proactive about providing a reproducer.
The problem, as described above (msg335220) and in the associated cmdix ticket,
is that invocation of `platform.(anything)` causes shelling out to execute
"uname"
Jason R. Coombs added the comment:
> Platform differences can be papered over with functions.
I’m not suggesting that from within Python there should be another way to
detect a home directory. The expanduser functionality as written is just fine
for that, though I agree with Steve that us
Jason R. Coombs added the comment:
> This is only an issue for broken symlinks, right? (More precisely, those that
> cannot be resolved, which may include very long paths on some machines.)
Unfortunately, no. In the original post above, you can see temp/bar points to
C:\Users\jarac
Jason R. Coombs added the comment:
Today I ran into an issue due to this change. I have a test that sets
`os.environ['HOME']` in order to ensure that `os.path.expanduser(~)` returns
that value
(https://github.com/pypa/setuptools/blob/f6f25adfc81df76e186bf6c3738a1baa0f92be05/setuptools/tests
Jason R. Coombs added the comment:
I should also point out that this was a documented feature of Python that was
removed without any deprecation period.
--
___
Python tracker
<https://bugs.python.org/issue36
Jason R. Coombs added the comment:
I addressed the [setuptools test suite
issue](https://github.com/pypa/setuptools/issues/2112) with [this
commit](https://github.com/pypa/setuptools/commit/f866311d60f54499c3637309e3429780d8c8f218).
What was a one-line elegant solution is now multiple lines
Jason R. Coombs added the comment:
> you added a late binding optimization for the whole uname return
tuple to save the effort of ... shell access.
It wasn't to save the effort and it wasn't an optimization. There was a
fundamental race condition where it became impossible to implem
Jason R. Coombs added the comment:
In issue40570, Marc-Andre writes:
> I don't think that deprecating standard tuple access is an option
for the uname() return value, since it's documented to be a tuple.
My thinking here is that as part of the deprecation, the documentation would be
upda
Jason R. Coombs added the comment:
How's that for service ;)
Glad to hear it worked. I'm going to close this as won't fix (as it was
reported against 3.7 and 3.8 and changing it for them would be
backward-incompatible, even if more correct). Please report back if that
outcome
Change by Jason R. Coombs :
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Jason R. Coombs added the comment:
I believe this issue was addressed in the latest importlib_resources. If so,
that behavior is being ported to Python 3.9 in issue39791. Would you test with
`importlib_resources` 1.1 or later and see if that suits your purposes? If so,
please use
Jason R. Coombs added the comment:
New changeset 044cf94f610e831464a69a8e713dad89878824ce by Ronald Oussoren in
branch 'master':
bpo-22490: Remove __PYVENV_LAUNCHER__ from environment during launch (GH-9516)
https://github.com/python/cpython/commit/044cf94f610e831464a69a8e713dad89878824ce
Change by Jason R. Coombs :
--
pull_requests: +18472
pull_request: https://github.com/python/cpython/pull/19111
___
Python tracker
<https://bugs.python.org/issue22
Jason R. Coombs added the comment:
New changeset c959fa9353b92ce95dd7fe3f25fe65bacbe22338 by Miss Islington (bot)
in branch '3.8':
bpo-22490: Remove __PYVENV_LAUNCHER__ from environment during launch (GH-9516)
(GH-19110)
https://github.com/python/cpython/commit
Jason R. Coombs added the comment:
New changeset 5765acaf64cc2c52ce8a35de9407faddf6885598 by Jason R. Coombs in
branch '3.7':
[3.7] bpo-22490: Remove __PYVENV_LAUNCHER__ from environment during launch
(GH-9516) (GH-19111)
https://github.com/python/cpython/commit
Change by Jason R. Coombs :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Jason R. Coombs :
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue22490>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jason R. Coombs added the comment:
I've filed [Homebrew/brew#7204](https://github.com/Homebrew/brew/issues/7204)
to track the testing/validation of this change against Homebrew.
--
___
Python tracker
<https://bugs.python.org/issue22
Jason R. Coombs added the comment:
New changeset 9a81ab107a54b8ca320fb703f7c68e14ccd9d016 by Zackery Spytz in
branch 'master':
bpo-39830: Add zipfile.Path to __all__ (GH-19115)
https://github.com/python/cpython/commit/9a81ab107a54b8ca320fb703f7c68e14ccd9d016
Jason R. Coombs added the comment:
Thanks for the report and the fix.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Jason R. Coombs added the comment:
New changeset 15e5024d04fc89d948ae761d88048bc58a56b650 by Roman Yurchak in
branch 'master':
bpo-40029 mark test_importlib.test_zip as requiring zlib (#19105)
https://github.com/python/cpython/commit/15e5024d04fc89d948ae761d88048bc58a56b650
--
nosy
Jason R. Coombs added the comment:
New changeset 7f7e706d78ab968a1221c6179dfdba714860bd12 by Jason R. Coombs in
branch 'master':
bpo-39791: Add files() to importlib.resources (GH-19722)
https://github.com/python/cpython/commit/7f7e706d78ab968a1221c6179dfdba714860bd12
Change by Jason R. Coombs :
--
pull_requests: +19326
pull_request: https://github.com/python/cpython/pull/20015
___
Python tracker
<https://bugs.python.org/issue40
Jason R. Coombs added the comment:
I've merged PR 19722. Some follow up actions I'd like to do:
- Add hooks for `.files()` on built-in loaders.
- Replace `loader.get_resource_reader()` with adapters around `.files()` for
built-in loaders
Jason R. Coombs added the comment:
Thanks David for the report and the draft PR (which helped me validate my
thinking on the matter). In PR 20015, I've included additional tests. I've also
re-written the compatibility functions to rely on the main `__iter__` override.
Another situation
Jason R. Coombs added the comment:
It was intentional to address issue35967, although it was meant to remain
compatible.
Is len(uname()) an important behavior to retain? It feels like an
implementation detail to me.
--
___
Python tracker
<ht
Jason R. Coombs added the comment:
If it is important to retain the `len`, it's probably also important to retain
the `[-N]` accesses and possibly other behaviors of a length 6 tuple.
--
___
Python tracker
<https://bugs.python.org/issue40
Jason R. Coombs added the comment:
> I haven't yet figured out whether there's a convenient way for the reader to
> not keep the ZIP open for as long as it exists, but I think that's going to
> be the safest fix.
You may be right here. I don't fully understand the repro, but it se
Jason R. Coombs added the comment:
In jaraco/zipp, I've implemented three of the options above:
- https://github.com/jaraco/zipp/tree/bugfix/bpo-40564-option-1
- https://github.com/jaraco/zipp/tree/bugfix/bpo-40564-option-2
- https://github.com/jaraco/zipp/tree/bugfix/bpo-40564-option-5
Change by Jason R. Coombs :
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Jason R. Coombs added the comment:
This issue was addressed incidentally in
[jaraco/zipp#56](https://github.com/jaraco/zipp/issues/56) released as zipp
3.2.0.
I'd like to incorporate the tests submitted in PR 22711 and then port those
changes to Python
Jason R. Coombs added the comment:
New changeset 967fddae2fe48f297563c358bdbdde1e2cfed4ee by Jason R. Coombs in
branch '3.8':
[3.8] bpo-41855: Fix duplicate results in FastPath.zip_children() (#22404)
https://github.com/python/cpython/commit/967fddae2fe48f297563c358bdbdde1e2cfed4ee
Change by Jason R. Coombs :
--
pull_requests: +21684
pull_request: https://github.com/python/cpython/pull/22716
___
Python tracker
<https://bugs.python.org/issue42
Jason R. Coombs added the comment:
Thanks Eryk for following up. Glad to hear the issue has been fixed upstream!
--
___
Python tracker
<https://bugs.python.org/issue21
Jason R. Coombs added the comment:
This sounds like a worthy improvement. Are you interested in preparing a patch?
Would you consider contributing it to https://github.com/jaraco/zipp first?
--
___
Python tracker
<https://bugs.python.
Change by Jason R. Coombs :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Jason R. Coombs :
As reported in https://gitlab.com/python-devs/importlib_metadata/-/issues/124,
it would be nice if the PackageNotFoundError gave some guidance to the user
about the context of the error and how to investigate.
--
assignee: jaraco
components
Jason R. Coombs added the comment:
Thanks Terry.
The correct URL is
[jaraco/keyring#445](https://github.com/jaraco/keyring/issues/445).
--
___
Python tracker
<https://bugs.python.org/issue41
New submission from Jason R. Coombs :
In [pypa/keyring#445](https://github.com/pypa/keyring/445) and issue839151, we
learned that there are Python interpreters in which `sys.argv` is an empty
list, is not a list, or is not initialized at all. Through use of
`sys.argv[0]`, the documentation
Jason R. Coombs added the comment:
Implementing that last option:
```
diff --git a/zipp.py b/zipp.py
index 697d4a9..f244cba 100644
--- a/zipp.py
+++ b/zipp.py
@@ -111,6 +111,7 @@ class CompleteDirs(zipfile.ZipFile):
res = cls.__new__(cls)
vars(res).update(vars(source
Jason R. Coombs added the comment:
I am able to replicate the failure using the ondisk fixture:
```diff
diff --git a/test_zipp.py b/test_zipp.py
index a6fbf39..539d0a9 100644
--- a/test_zipp.py
+++ b/test_zipp.py
@@ -259,3 +259,11 @@ class TestPath(unittest.TestCase):
def
Jason R. Coombs added the comment:
I suspect the issue lies in how the CompleteDirs.make [replaces one instance
with
another](https://github.com/jaraco/zipp/blob/8ad959e61cd4be40baab93528775c2bf03c8f4e1/zipp.py#L112-L114)
in order to provide a complete list of implied directories
Jason R. Coombs added the comment:
I've attempted to replicate the issue in the
[zipp](https://github.com/jaraco/zipp) test suite with this test:
```diff
diff --git a/test_zipp.py b/test_zipp.py
index a6fbf39..dc7c8aa 100644
--- a/test_zipp.py
+++ b/test_zipp.py
@@ -259,3 +259,10 @@ class
Jason R. Coombs added the comment:
I see a few options here:
- Implement CompleteDirs/FastLookup as adapters instead of subclasses, allowing
the original ZipFile object to represent the state in a single place. This
approach would likely be slower due to the indirection on all operations
Jason R. Coombs added the comment:
One possible option to guarantee initialization could be for PyInitialize to
always call PySys_SetArgvEx(1, [""], 0), providing a default value for embedded
interpreters that fail to call it.
--
Change by Jason R. Coombs :
--
keywords: +patch
pull_requests: +21443
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22403
___
Python tracker
<https://bugs.python.org/issu
Jason R. Coombs added the comment:
I've released zipp 3.2.0 that includes a fix for this issue (option 2). Please
test it out.
Because this change affects the user's expectation about the effect of what's
passed in, I'm hesitant to backport it to 3.8 and 3.9. It's too late to go into
3.9.0
Jason R. Coombs added the comment:
The relevant commit is already present in importlib_metadata as
[079ca1cb701a5f4aab0a9cb00b0782c7ea8fb70b](https://gitlab.com/python-devs/importlib_metadata/-/commit/079ca1cb701a5f4aab0a9cb00b0782c7ea8fb70b).
--
components: +Library (Lib
New submission from Jason R. Coombs :
Scott J. reports in an e-mail:
When upgrading to Python 3.8.2, we noticed two issues in
importlib.metadata which are not present in importlib_metadata.
1. FastPath.zip_children() is very slow for large zips. Python 3.8.3
> already has a
Change by Jason R. Coombs :
--
pull_requests: +21444
pull_request: https://github.com/python/cpython/pull/22404
___
Python tracker
<https://bugs.python.org/issue41
Jason R. Coombs added the comment:
I've also created this alternative to option 2:
- https://github.com/jaraco/zipp/tree/bugfix/bpo-40564-mixin
This alternative approach uses a mix-in rather than subclasses, creating a new
class on-demand. I was hoping this approach would enable just
Change by Jason R. Coombs :
--
keywords: +patch
pull_requests: +21408
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22371
___
Python tracker
<https://bugs.python.org/issu
Jason R. Coombs added the comment:
Fix merged into master. Please use zipp 3.2.0 on Python 3.9 and earlier for the
improved behavior or report back here if a backport is needed (and why).
--
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Pyth
Jason R. Coombs added the comment:
New changeset ebbe8033b1c61854c4b623aaf9c3e170d179f875 by Jason R. Coombs in
branch 'master':
bpo-40564: Avoid copying state from extant ZipFile. (GH-22371)
https://github.com/python/cpython/commit/ebbe8033b1c61854c4b623aaf9c3e170d179f875
Change by Jason R. Coombs :
--
resolution: -> fixed
___
Python tracker
<https://bugs.python.org/issue40564>
___
___
Python-bugs-list mailing list
Unsubscrib
Jason R. Coombs added the comment:
New changeset 5c1d745da5e1166a8724b619060165dcf3949e93 by Miss Islington (bot)
in branch '3.8':
bpo-39830: Add zipfile.Path to __all__ (GH-19115) (GH-19116)
https://github.com/python/cpython/commit/5c1d745da5e1166a8724b619060165dcf3949e93
Jason R. Coombs added the comment:
Thanks Steve. While I was able to avoid the original symptom by not using
readlink, I still think there's an issue here, both in the surprising behavior
observed by shutil.copyfile, but also by the essential behavior of readlink.
The more essential issue
Change by Jason R. Coombs :
--
pull_requests: +19816
pull_request: https://github.com/python/cpython/pull/20576
___
Python tracker
<https://bugs.python.org/issue39
Jason R. Coombs added the comment:
This issue doesn't happen on my mac that installs homebrew globally. Do the
build instructions assume Homebrew is installed system-wide?
--
___
Python tracker
<https://bugs.python.org/issue40
Jason R. Coombs added the comment:
In [this
commit](https://github.com/jaraco/jaraco.develop/commit/e3e5f66ca6693d8ec3abd31d99d491f6dfa1f67d),
I include "xz" in the routine. Should Python's developer docs include
something like that to ensure com
Change by Jason R. Coombs :
--
components: +macOS
nosy: +ned.deily, ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue40840>
___
___
Python-bug
New submission from Jason R. Coombs :
Attempting to build Python on macOS following [the
instructions](https://devguide.python.org/setup/#macos-and-os-x) (for Homebrew).
xz is installed:
```
$ brew --prefix xz
901 - 1000 of 1483 matches
Mail list logo
