[issue44996] tarfile missing TarInfo.offset_data member in documentation
New submission from Nils : The title says it all: `TarInfo` objects are missing their `offset_data` member in all documentation versions. -- assignee: docs@python components: Documentation messages: 400248 nosy: docs@python, nilsnolde priority: normal severity: normal status: open title: tarfile missing TarInfo.offset_data member in documentation 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/issue44996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22240] argparse support for "python -m module" in help
Nils Kattenbeck added the comment: I implemented the logic and adjusted the existing tests to have a fixed program name. I also fixed the build error by changing how zip files are detected. Based on you comment Nick you however even had a different idea. Currently I check if __spec__.__loader__ is a zip loader but if I understood correct you suggest the check if __spec__.__location__ is a proper subdir of sys.argv[0]? https://github.com/septatrix/cpython/compare/main...septatrix:enhance/argparse-prog-name. When I have some more time I will check whether mocking works and otherwise checkout test.support.script_helper or making the function accept spec/argv0 -- ___ Python tracker <https://bugs.python.org/issue22240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13824] argparse.FileType opens a file and never closes it
Nils Kattenbeck added the comment: A good alternative would be to use pathlib.Path. The only downside would be that one has to manually handle `-` but besides that it solves most problems. Still the fact that file descriptors are kept open should be added as a warning to the docs -- nosy: +Nils Kattenbeck ___ Python tracker <https://bugs.python.org/issue13824> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22240] argparse support for "python -m module" in help
Nils Kattenbeck added the comment: I expanded the patch from tebeka to also work with invocations like `python3 -m serial.tools.miniterm` where `miniterm.py` is a file and not a directory with a `__main__.py`. This was able to handle everything I threw at it. However due to the import of zipfile which itself imports binascii the build of CPython itself fails at the `sharedmods` stage... ```text CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -fwrapv -O3 -Wall' _TCLTK_INCLUDES='' _TCLTK_LIBS='' ./python -E ./setup.py build Traceback (most recent call last): File "/home/septatrix/Documents/programming/cpython/./setup.py", line 3, in import argparse ^^^ File "/home/septatrix/Documents/programming/cpython/Lib/argparse.py", line 93, in from zipfile import is_zipfile as _is_zipfile ^ File "/home/septatrix/Documents/programming/cpython/Lib/zipfile.py", line 6, in import binascii ^^^ ModuleNotFoundError: No module named 'binascii' make: *** [Makefile:639: sharedmods] Error 1 ``` I guess this is because binascii is a c module and not yet build at that point in time. Does anyone who knows more about the build system have an idea how to resolve this? --- Resolving this bug would also allow the removal of several workarounds for this in the stdlib: * https://github.com/python/cpython/blob/83d1430ee5b8008631e7f2a75447e740eed065c1/Lib/unittest/__main__.py#L4 * https://github.com/python/cpython/blob/83d1430ee5b8008631e7f2a75447e740eed065c1/Lib/json/tool.py#L19 * https://github.com/python/cpython/blob/83d1430ee5b8008631e7f2a75447e740eed065c1/Lib/venv/__init__.py#L426 -- Added file: https://bugs.python.org/file50174/patch.diff ___ Python tracker <https://bugs.python.org/issue22240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22240] argparse support for "python -m module" in help
Nils Kattenbeck added the comment: I am not sure if the patch correctly handles calling a nested module (e.g. `python3 -m serial.tools.miniterm`). Would it also be possible to detect if python or python3 was used for the invocation? -- nosy: +Nils Kattenbeck ___ Python tracker <https://bugs.python.org/issue22240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41249] TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules
Nils Kattenbeck added the comment: > The way I fixed this is I added `__forward_module__` to `typing.ForwardRef`, > so that it can resolve the forward reference with the same globals as the > ones specified by the module in `__forward_module__`. `TypedDict`'s metaclass > should then pass the dictionary’s module name to the annotations’ forward > references via the added `module`’s keyword argument in > `typing._type_check()`. I can work in a pull request with this solution and > discuss any potential problems. While this seems like a good solution I would still like to figure out why TypedDict do not preserve MRO. Because for now I have not found a reason nor did someone on the typing-sig mailinglist have a clue. Should there (no longer) be a reason for this then this problem has a trivial solution (just re-add the MRO and use that). -- ___ Python tracker <https://bugs.python.org/issue41249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41249] TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules
Nils Kattenbeck added the comment: > I believe it had something to do with TypedDict instances being instances of > dict at runtime, but I can't actually reconstruct the reason. Hm that may be true. My limited low-level Python knowledge leads me to believe that this could also be done using __new__ but I also read that most magic methods get called as type(Foo).__magic__(bar, ...) so that might not be possible. (However also no methods can be declared on a TypedDict class so that might not be a problem?) > Maybe it's written up in PEP 589, but I suspect not (I skimmed and couldn't > find it). I read it completely and could not find anything > If you ask on typing-sig maybe David Foster (who contributed the initial idea > and implementation) remembers. I asked [here on typing-sig](https://mail.python.org/archives/list/typing-...@python.org/thread/RNFWPRLHTUTZES2FDSSMY472JFGMD4EW/) but did not yet get any responses. -- ___ Python tracker <https://bugs.python.org/issue41249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41249] TypedDict inheritance doesn't work with get_type_hints and postponed evaluation of annotations across modules
Nils Kattenbeck added the comment: What is/was the initial reason to not preserve the MRO for a TypedDict? The only thing which came to my mind would be instantiation performance but as annotations are not evaluated by default and on the right-hide side of assignment most people will use dict literals I am not sure if this is still relevant. Otherwise it might even be simpler to just preserve the original bases in TypedDict but please correct me if I overlooked something -- nosy: +Nils Kattenbeck ___ Python tracker <https://bugs.python.org/issue41249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25024] Allow passing "delete=False" to TemporaryDirectory
Nils Kattenbeck added the comment: While the proposal linked by C.A.M. solves one of the use cases but it does not address the others. One use cases which is rather common for me it is e.g. to have scripts/programs which allow configuring whether temporary directories should get deleted or stay persistent after program exit. Currently this always requires hand rolled wrappers like the following: def mkdtemp_persistent(*args, persistent=True, **kwargs): if persistent: @contextmanager def normal_mkdtemp(): yield tempfile.mkdtemp() return normal_mkdtemp(*args, **kwargs) else: return tempfile.TemporaryDirectory(*args, **kwargs) with mkdtemp_persistent(persistent=False) as dir: ... Which gets the job done but is not as user friendly as other parts of the stdlib. -- nosy: +Nils Kattenbeck ___ Python tracker <https://bugs.python.org/issue25024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1717] Get rid of more references to __cmp__
Nils Kattenbeck added the comment: Has there been any resolution regarding `sortTestMethodsUsing`? See https://bugs.python.org/msg77261 I spend a decent time and read the documentation thrice before realizing it received an old-style compare function. Brett's proposal for a new attribute seems like a sane way to do this without breaking backwards compatibility. Or will this continue using an old-style compare function for the foreseeable future? -- nosy: +Nils Kattenbeck ___ Python tracker <https://bugs.python.org/issue1717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44137] importlib.resources.path raises RuntimeError when FileNotFoundError is raise in context manager
Nils Kattenbeck added the comment: Thanks for looking into it. Yes I can confirm that `importlib_resources` has the expected behaviour - I did not download Python 3.10 as the code seems to be the same. -- ___ Python tracker <https://bugs.python.org/issue44137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44137] importlib.resources.path raises RuntimeError when FileNotFoundError is raise in context manager
Nils Kattenbeck added the comment: Yes I understand that the function handles this specially to not raise an exception if the file is not found in the package (even though the intention behind this is not clear to me). However if a user causes a FileNotFoundException itself inside of the context manager everything breaks (e.g. does something erroneous with the path, calls subprocess.run with a non existing binary etc). -- ___ Python tracker <https://bugs.python.org/issue44137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44137] importlib.resources.path raises RuntimeError when FileNotFoundError is raise in context manager
Change by Nils Kattenbeck : -- title: importlib.resources.path raises RuntimeError import FileNotFoundError is raise in context manager -> importlib.resources.path raises RuntimeError when FileNotFoundError is raise in context manager ___ Python tracker <https://bugs.python.org/issue44137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44137] importlib.resources.path raises RuntimeError import FileNotFoundError is raise in context manager
New submission from Nils Kattenbeck :
When a FileNotFoundError is raised inside while the importlib.resources.path
context manager is active a RuntimeError is raised.
Looking at the (3.8) code it seems that FileNotFound exceptions are handled
specially from all other exceptions which may lead to this behaviour. While the
code in 3.9 changed significantly the same behaviour can be observed.
Files:
.
└── my_package
├── data.txt (empty)
├── __init__.py (empty)
└── test.py
Content of test.py:
import importlib.resources
def main():
with importlib.resources.path('my_package', 'data.txt') as p:
raise FileNotFoundError()
if __name__ == '__main__':
main()
Exact error message:
RuntimeError: generator didn't stop after throw()
--
components: Library (Lib)
messages: 393686
nosy: Nils Kattenbeck, brett.cannon, jaraco
priority: normal
severity: normal
status: open
title: importlib.resources.path raises RuntimeError import FileNotFoundError is
raise in context manager
type: behavior
versions: Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue44137>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34137] Add Path.lexist() to pathlib
Nils Philippsen added the comment: I've come across this issue lately and proposed a PR which implements this and, analogous to os.stat(), adds a follow_symlinks parameter to Path.exists(). -- ___ Python tracker <https://bugs.python.org/issue34137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34137] Add Path.lexist() to pathlib
Change by Nils Philippsen : -- keywords: +patch pull_requests: +20316 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21157 ___ Python tracker <https://bugs.python.org/issue34137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34137] Add Path.lexist() to pathlib
Change by Nils Philippsen : -- nosy: +nils ___ Python tracker <https://bugs.python.org/issue34137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38756] Add generic versions of weakref types to typing module
Nils Kattenbeck added the comment: Okay, if I want to start a discussion about adding weakref types to PEP 585 where should do it? The mailing list or as an issue in the PEP repo? -- ___ Python tracker <https://bugs.python.org/issue38756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38761] weakref.WeakSet not instanceof collections.abc.Set
New submission from Nils Kattenbeck : Instances of weakref.WeakSet are not instances of Set and therefore not of MutableSet but they are instances of Collection. They however implement all required methods for a MutableSet and Weak(Key|Value)Dictionary are correctly identified. Is this just an oversight or am I missing something? from weakref import WeakKeyDictionary, WeakValueDictionary, WeakSet from collections.abc import MutableMapping, Collection, Set, MutableSet wkdict = WeakKeyDictionary() wvdict = WeakValueDictionary() ws = WeakSet() assert isinstance(wkdict, MutableMapping) assert isinstance(wvdict, MutableMapping) assert isinstance(ws, Collection) assert not isinstance(ws, Set) assert not isinstance(ws, MutableSet) -- components: Library (Lib) messages: 356326 nosy: Nils Kattenbeck priority: normal severity: normal status: open title: weakref.WeakSet not instanceof collections.abc.Set versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue38761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38756] Add generic versions of weakref types to typing module
Nils Kattenbeck added the comment: Okay nevermind, after looking in the PEP again and inspecting the __annotations__ property I learned that annotations are never evaluated and just saved as a string when using said future statement. However this may still be relevant as typing.get_type_hints will still fail. For my use case however this is sufficient. -- ___ Python tracker <https://bugs.python.org/issue38756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38756] Add generic versions of weakref types to typing module
Nils Kattenbeck added the comment: Yes thank you, using 'from __future__ import annotations' works fantastic. I did not knew about this functionality of the annotations future import statement, I thought it was only for postponed evaluation but I probably missed something in the PEP... -- ___ Python tracker <https://bugs.python.org/issue38756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38756] Add generic versions of weakref types to typing module
Nils Kattenbeck added the comment: A possible use case would be having multiple users and some groups said users can belong to. When using a WeakSet a user won't be part of a groups after he deleted his account without having to iterate over all groups. class User: pass class Group: users: WeakSet[User] def __init__(self, users: Iterable[User]): self.users = WeakSet(users) # somewhere else a collection of all active users Types I would like to see added as a generic would be primarily: - WeakKeyDictionary - WeakValueDictionary - WeakSet Additionally it would be nice to have generic versions of: - ref (would probably return Optional[T] on call?) - WeakMethod - ProxyType - CallableProxyType Although the last two could probably be just annotated using T because they mostly should behave the same... -- ___ Python tracker <https://bugs.python.org/issue38756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38756] Add generic versions of weakref types to typing module
New submission from Nils Kattenbeck : I would like to request the addition of generic variants of some of the types in weakref to the typing module. This would for example include weakref.WeakKeyDictionary among others. Doing so would allow one to add type annotations to code using such data structures. -- components: Library (Lib) messages: 356304 nosy: Nils Kattenbeck priority: normal severity: normal status: open title: Add generic versions of weakref types to typing module type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31652] make install fails: no module _ctypes
Nils Goroll added the comment: In case this helps: I noticed this during the build: *** WARNING: renaming "_ssl" since importing it failed: ld.so.1: python: fatal: libssl.so.1.1: open failed: No such file or directory *** WARNING: renaming "_hashlib" since importing it failed: ld.so.1: python: fatal: libssl.so.1.1: open failed: No such file or directory *** WARNING: renaming "_ctypes" since importing it failed: ld.so.1: python: fatal: libffi.so.6: open failed: No such file or directory ... Following modules built successfully but were removed because they could not be imported: _ctypes _hashlib _ssl In my case the reason was that libffi was installed under /opt/local, so the fix was: ./configure LDFLAGS='-L/opt/local/lib -R/opt/local/lib' and rebuild For other users I would recommend to inspect the build output for _ctypes related errors, I am not saying that the cause is the same -- nosy: +slink ___ Python tracker <https://bugs.python.org/issue31652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35558] venv: running activate.bat gives ' parameter format not correct - 65001'
Change by Nils Lindemann : -- resolution: -> duplicate stage: -> resolved status: -> closed ___ Python tracker <https://bugs.python.org/issue35558> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35558] venv: running activate.bat gives ' parameter format not correct - 65001'
New submission from Nils Lindemann :
Windows 7, Python 3.7.1:260ec2c36a
after doing
C:\python\python -m venv C:\myvenv
and then
C:\>myvenv\Scripts\activate.bat
it prints
parameter format not correct - 65001
However, it activates the venv - the prompt shows
(myvenv) C:\>
and
C:\myvenv\Scripts;
gets prepended to PATH.
When i outcomment
for /f "tokens=2 delims=:" %%a in ('"%SystemRoot%\System32\chcp.com"') do (
set "_OLD_CODEPAGE=%%a"
)
in the activate.bat then the message wont show up.
related:
https://stackoverflow.com/questions/51358202/python-3-7-activate-venv-error-parameter-format-not-correct-65001-windows
--
messages: 332320
nosy: Nils-Hero
priority: normal
severity: normal
status: open
title: venv: running activate.bat gives ' parameter format not correct - 65001'
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue35558>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31816] Unexpected behaviour of `dir()` after implementation of __dir__
Nils Diefenbach <23okrs20+pyt...@mykolab.com> added the comment: Alright. Are there any other magic methods that do some post-processing on a custom implementation of them ? I couldn't think of one, which is why this behaviour appeared odd to me. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue31816> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31816] Unexpected behaviour of `dir()` after implementation of __dir__
New submission from Nils Diefenbach <23okrs20+pyt...@mykolab.com>: When defining a custom __dir__ method in a class, calling dir() on said class still sorts the output. This is, imo, unexpected behaviour, especially if the order of output was specified in __dir__ and is somehow relevant. Example and more detail here https://stackoverflow.com/questions/46824459/custom-dir-returns-list-of-attributes-sorted-alphabetically -- messages: 304606 nosy: nlsdfnbch priority: normal severity: normal status: open title: Unexpected behaviour of `dir()` after implementation of __dir__ type: behavior versions: Python 3.5 ___ Python tracker <https://bugs.python.org/issue31816> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30580] WSGI examples raise AttributeError: __exit__
Nils Lindemann added the comment: ok -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue30580> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30580] WSGI examples raise AttributeError: __exit__
Nils Lindemann added the comment: I am not sure if the py package i found on PyPi is what you meant, but if you mean the py launcher (the py.exe in the windows dir), yes, i have that. My system was indeed misconfigured as you correctly guessed, i had the .py filetype pointing to a Python version 3.5. I have now uninstalled everything, manually cleaned up the registry, reinstalled Python 3.6 and now everything works. Sorry, my mistake. -- resolution: not a bug -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue30580> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30580] WSGI examples raise AttributeError: __exit__
Nils Lindemann added the comment: What would that be? If i google 'py helper command' i get no good results. -- resolution: not a bug -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue30580> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30580] WSGI examples raise AttributeError: __exit__
Nils Lindemann added the comment: I just found out that the example works in idle and if i do in a console: python server.py but not if i do just: server.py What is the secret behind this? -- ___ Python tracker <http://bugs.python.org/issue30580> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30580] WSGI examples raise AttributeError: __exit__
Nils Lindemann added the comment:
I tried a few online python 3 interpreters.
These give the same exception:
http://www.learnpython.org/en/Hello%2C_World%21
http://rextester.com/l/python3_online_compiler
http://ideone.com/pIMilt
http://www.tutorialspoint.com/execute_python3_online.php
And this one worked:
https://repl.it/languages/python3
the example i tried was:
from wsgiref.simple_server import make_server, demo_app
with make_server('', 8000, demo_app) as httpd:
print("Serving HTTP on port 8000...")
httpd.serve_forever()
My Python installation is a default x64 installation. No changes were made
during installation, except installation path, which has no spaces in it. I
have no third part modules installed which could interfer. I have also a Python
2.7 installed but it is not on my path.
--
___
Python tracker
<http://bugs.python.org/issue30580>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30580] WSGI examples raise AttributeError: __exit__
New submission from Nils Lindemann:
All examples on
https://docs.python.org/3/library/wsgiref.html
raise this exception:
Traceback (most recent call last):
File "C:\Code\test\server.py", line 110, in
with make_server('', 8000, simple_app) as httpd:
AttributeError: __exit__
Tested with
Python 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 18:41:36) [MSC v.1900 64 bit
(AMD64)] on win32
--
messages: 295253
nosy: Nils-Hero
priority: normal
severity: normal
status: open
title: WSGI examples raise AttributeError: __exit__
versions: Python 3.6
___
Python tracker
<http://bugs.python.org/issue30580>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25444] Py Launch Icon
Nils Lindemann added the comment: Two years later: To the dude who removed the rocket from the icons in 3.6: I LOVE YOU! -- ___ Python tracker <http://bugs.python.org/issue25444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25444] Py Launch Icon
Nils Lindemann added the comment: i see now what you mean. I have this icon too (py 3.5.0 idle icon.png). Something is misconfigured with the icons in the python 3.5.0 windows installer, also python files in explorer have no icons. Thanks for your hint with the python ideas list, i will post a message there. -- Added file: http://bugs.python.org/file40894/py 3.5.0 idle icon.png ___ Python tracker <http://bugs.python.org/issue25444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25444] Py Launch Icon
Nils Lindemann added the comment: it seems i have still not explained my issue in an understandable way: the three first icons in the file list in the screenshot, aka the icons which are used in eg py 3.2, these icons are cool. the icon i do not like, is the launcher icon which is used in eg py 3.5 and which shows up in the windows task bar when i run python scripts which open a commandline. This is the last icon in the file list in the screenshot. Im fine with everything else, i always liked the original icons, just the new launcher icon is terrible in my opinion :-( -- ___ Python tracker <http://bugs.python.org/issue25444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25444] Py Launch Icon
Nils Lindemann added the comment: let me reformulate it: my main intention is to get rid of the launcher symbol, or at least have a nicer looking symbol, i dont care for the idle symbol. -- ___ Python tracker <http://bugs.python.org/issue25444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25444] Py Launch Icon
Nils Lindemann added the comment: The icons are not intended to be used instead of the three default icons, please dont, these are just great. I am just targeting the current launcher symbol: * It contains a symbol of an instrument which can be used to kill people. * in the 16x16 icon it is not clear at all what this is. it just looks like a smudge on the icon. When i first saw it i touched it to see if the smudge is on my screen. * the symbol indicates that one is running the launcher. But thats not true, he is running the process that was launched by the launcher. So if this symbol is used for the exe which is the launcher, ok, but using it for all processes started with it is wrong in my opinion. The icons for idle are just suggestions, using an alternative icon for idele, as i said, may be helpful to separate idle from command lines. The alternative icons for the launcher are just thought as source of inspiration. Actually i think launched processes (except maybe idle) should use the standard py exe icon! -- ___ Python tracker <http://bugs.python.org/issue25444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25444] Py Launch Icon
Nils Lindemann added the comment: Here is also a zip containing the icons. -- Added file: http://bugs.python.org/file40818/icons.zip ___ Python tracker <http://bugs.python.org/issue25444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25444] Py Launch Icon
Nils Lindemann added the comment: Hm actually an alternative icon for idle can be useful to separate it from command lines in the task bar. But a special launcher symbol is not necessary in my opinion. -- ___ Python tracker <http://bugs.python.org/issue25444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25444] Py Launch Icon
New submission from Nils Lindemann: Hi, See attached screen for a list of alternative 16x16 icon suggestions to the current launcher symbol, which i dont like (Dudes, rockets are used in wars!). I copied them a few times to show how they look in groups. (while i was at it i also created an icon for idle, see the idle window in the Screenshot). Actually i wonder why it is necessary at all to use more than the three default icons, but if, then my icons are better. Hopefully i can inspire the designer to do a redesign of the luncher icon :-) Nils -- components: IDLE, Installation, Windows files: (py icons, idle) screenshot.png messages: 253203 nosy: Nils-Hero, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Py Launch Icon type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40815/(py icons, idle) screenshot.png ___ Python tracker <http://bugs.python.org/issue25444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py
nils added the comment:
The workaround indeed works. At least I can work now until this gets officialy
fixed. Thanks!
export CFLAGS=$(python3.4 -c 'import sysconfig;
print(sysconfig.get_config_var("CFLAGS").replace("-Werror=declaration-after-statement",""))')
--
___
Python tracker
<http://bugs.python.org/issue21121>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21121] -Werror=declaration-after-statement is added even for extension modules through setup.py
New submission from nils: I got an error while rebuilding a module for 3.4. This was a ISO C90 error but setup.py explicitely adds "-std=c99" to the gcc parameters, and indeed it is used. fifo.h:114:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] uint32_t ofs = fifo->write_count - fifo->write_offset; However, Py 3.4 seems to add -Werror=declaration-after-statement also for extension modules. This should not happe (said also Yhg1s in #python). Attached is a file that shows the setup.py and also the error log. -- components: Build, Distutils, Extension Modules files: pybug.txt messages: 215305 nosy: dstufft, eric.araujo, nilsge priority: normal severity: normal status: open title: -Werror=declaration-after-statement is added even for extension modules through setup.py versions: Python 3.4 Added file: http://bugs.python.org/file34692/pybug.txt ___ Python tracker <http://bugs.python.org/issue21121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17816] Weak*Dictionary KeyErrors during callbacks
Nils Bruin added the comment: One solution is to patch both WeakValueDictionary and WeakKeyDictionary with their own clear methods where we first store the strong links (to keys, resp. values) in a list, then clear the underlying dictionaries (this will now trigger the deletion of the weakrefs, so all callbacks are neutralized), and then delete the list. It does use more storage that way, but it gets rid of the ignored key errors. This is a different problem from issue7105, which deals with the (much more complicated) scenario of avoiding dictionary reshaping due to GC when iterators are still (potentially) active. -- keywords: +patch Added file: http://bugs.python.org/file30101/17816_custom_clear.patch ___ Python tracker <http://bugs.python.org/issue17816> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17816] Weak*Dictionary KeyErrors during callbacks
Nils Bruin added the comment: I think the difference in behaviour between Py3 and Py2 is coming from: http://hg.python.org/cpython/file/a26df2d03989/Objects/dictobject.c#l1275 which first clears all values before removing any keys. For a WeakValueDictionary that means all the weakrefs are neutralized before the can be activated. I don't quite understand how Py3 manages to avoid problems for a WeakKeyDictionary, but apparently it does. -- ___ Python tracker <http://bugs.python.org/issue17816> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17816] Weak*Dictionary KeyErrors during callbacks
Nils Bruin added the comment: Have you tried if the fix at issue7105 solves the problem? I don't see the patch there introduce a `clear` method override for WeakValueDictionary or WeakKeyDictionary. The one for WeakSet still calls self.data.clear(), which for dictionaries would still result in the problem in this ticket (but not for WeakSet, because clearing a WeakSet shouldn't decref anything other than the weak references stored in the underlying set). -- ___ Python tracker <http://bugs.python.org/issue17816> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17816] Weak*Dictionary KeyErrors during callbacks
New submission from Nils Bruin: The following program is a little dependent on memory layout but will usually generate lots of Exception KeyError: (A(9996),) in ignored messages in Python 2.7. import weakref class A(object): def __init__(self,n): self.n=n def __repr__(self): return "A(%d)"%self.n def mess(n): D=weakref.WeakValueDictionary() L=[A(i) for i in range(n)] for i in range(n-1): j=(i+10)%n D[L[i]]=L[j] return D D=mess(1) D.clear() The reason is that on D.clear() all entries are removed from D before actually deleting those entries. Once the entries are deleted one-by-one, sometimes the removal of a key will result in deallocation of that key, which may be a not-yet-deleted ex-value of the dictionary as well. The callback triggers on the weakref, but the dict itself was already emptied, so nothing is found. I've checked and on Python 3.2.3 this problem does not seem to occur. I haven't checked the Python source to see how Python 3 behaves differently and whether that behaviour would be easy to backport to fix this bug in 2.7. -- components: Library (Lib) messages: 187570 nosy: Nils.Bruin priority: normal severity: normal status: open title: Weak*Dictionary KeyErrors during callbacks versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue17816> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17526] inspect.findsource raises undocumented error for code objects with empty filename
Nils Bruin added the comment: The most straightforward change I can think of is to change the line if not sourcefile and file[0] + file[-1] != '<>': to if not sourcefile and (not file or file[0] + file[-1] != '<>'): That solves the problem in the cases I have observed. -- ___ Python tracker <http://bugs.python.org/issue17526> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17526] inspect.findsource raises undocumented error for code objects with empty filename
New submission from Nils Bruin:
It would seem reasonable that an empty filename would be a legitimate way of
indicating that a code object does not have a corresponding source file.
However, if one does that then inspect.findsource raises an unexpected
IndexError rather than the documented IOError.
This seems due to the fix introduced on issue9284
Python 3.2.3 (default, Jun 8 2012, 05:40:07)
[GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import inspect
>>> C=compile("print(1)","","single")
>>> D=compile("print(1)","","single")
>>> inspect.findsource(C)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib64/python3.2/inspect.py", line 547, in findsource
raise IOError('could not get source code')
IOError: could not get source code
>>> inspect.findsource(D)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib64/python3.2/inspect.py", line 537, in findsource
if not sourcefile and file[0] + file[-1] != '<>':
IndexError: string index out of range
--
components: Library (Lib)
messages: 185025
nosy: Nils.Bruin
priority: normal
severity: normal
status: open
title: inspect.findsource raises undocumented error for code objects with empty
filename
type: behavior
versions: Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue17526>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11912] Python shouldn't use the mprotect() system call
Nils Breunese added the comment: I contacted the author of iotop and he told me iotop does not use mprotect (but it does use dlopen). Guess I'll have to do some more digging to find what is exactly doing the call to mprotect. -- ___ Python tracker <http://bugs.python.org/issue11912> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11912] Python shouldn't use the mprotect() system call
Nils Breunese added the comment: I haven't had any problems with other Python applications like this, Python seems fine otherwise. I just noticed that iotop has a dependency on python-ctypes, which sounds like it could be iotop doing the mprotect() calls via ctypes. Does that make sense? -- ___ Python tracker <http://bugs.python.org/issue11912> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11912] Python shouldn't use the mprotect() system call
Nils Breunese added the comment: I got this error message in /var/log/messages when trying to start iotop: Apr 13 08:49:37 hostname kernel: grsec: From xxx.xxx.xxx.xxx: denied RWX mprotect of /lib64/ld-2.5.so by /usr/bin/iotop[iotop:9836] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:9351] uid/euid:0/0 gid/egid:0/0 Apr 13 08:49:37 hostname kernel: iotop[9836]: segfault at 6248c405dda0 ip 6248c3e489ec sp 7fffa52e8410 error 7 in ld-2.5.so[6248c3e42000+1c000] /usr/bin/iotop is a Python script and according to that log message grsecurity detected a call to mprotect(). -- ___ Python tracker <http://bugs.python.org/issue11912> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11912] Python shouldn't use the mprotect() system call
New submission from Nils Breunese : When I try to run iotop [0] on CentOS 5.6 on a kernel with grsecurity [1] then iotop won't start because grsecurity is blocking Python because of its use of the mprotect() system call. Please see http://www.atomicorp.com/wiki/index.php/ASL_FAQ#grsec:_denied_RWX_mprotect for more information. The authors of this hardened Linux kernel suggested to file a bug with Python because using mprotect() is apparently a very bad thing to do. [0] http://guichaz.free.fr/iotop/ [1] http://grsecurity.net/ -- messages: 134314 nosy: breun priority: normal severity: normal status: open title: Python shouldn't use the mprotect() system call type: security versions: 3rd party ___ Python tracker <http://bugs.python.org/issue11912> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6011] python doesn't build if prefix contains non-ascii characters
Nils Philippsen added the comment: NB: it's not the shell, but the kernel which interprets the shebang line (and subsequently calls the shell /bin/sh with it if it's missing, causing funny effects when it encounters the first import line and you happen to have ImageMagick installed). -- ___ Python tracker <http://bugs.python.org/issue6011> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6011] python doesn't build if prefix contains non-ascii characters
Changes by Nils Philippsen : -- nosy: +nils ___ Python tracker <http://bugs.python.org/issue6011> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1675951] [gzip] Performance for small reads and fix seek problem
Changes by Nils Philippsen : -- nosy: +nils ___ Python tracker <http://bugs.python.org/issue1675951> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2504] Add gettext.pgettext() and variants support
Changes by Nils Philippsen : -- nosy: +nils ___ Python tracker <http://bugs.python.org/issue2504> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
