[issue46930] Iterating over cls.__dict__ in classmethod causes RuntimeError when printing __annotations__
New submission from Fabian Zills : When iterating over __dict__ inside a classmethod, accessing __annotations causses RuntimeError: dictionary changed size during iteration. This only seems to affect Python 3.10.x on a Ubuntu system. The following can be used to reproduce this issue: class ExampleCls: @classmethod def iter_cls(cls): for name, val in cls.__dict__.items(): print(cls.__annotations__) This can be fixed for this Example by calling _ = cls.__annotations__ before iterating over the __dict__ -- messages: 414582 nosy: PythonF priority: normal severity: normal status: open title: Iterating over cls.__dict__ in classmethod causes RuntimeError when printing __annotations__ type: crash versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46930> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46064] Permalinks to underscored documentation entries don't work.
New submission from Fabian Dill : As an example, go to https://docs.python.org/3/library/constants.html and request a permalink to __debug__. The link you get will not jump to it. The link I get is https://docs.python.org/3/library/constants.html#debug__ -- assignee: docs@python components: Documentation messages: 408451 nosy: Fabian Dill, docs@python priority: normal severity: normal status: open title: Permalinks to underscored documentation entries don't work. type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43320] test test_webbrowser "can't locate runnable browser" with enable-optimizations
New submission from Fabian Beitler :
I downloaded the sources for python 3.8.8 (not tested with Python3.9.2. so
far)and compiled it
with enabled-optimisations parameter on a fresh Ubuntu 20.04 machine.
Beside the test_ssl error (there is an existing workaround, but still not happy
with that one tbh) I could solve, the test "test_webbrowser" fails and I don't
know how to handle that one.
ERROR: test_synthesize(test_webbrowser.ImportTest)
Traceback (most recent call last):
File "Path/Python-3.8.8/Lib/test/test_webbrowser.py", line 299, in
test_synthesize
webbrowser.get(sys.executable)
File "Path/Python-3.8.8/Lib/webbrowser.py", line 65, in get
raise Error("could not locate runnable browser")
webbrowser.Error: could not locate runnable browser
--
components: Tests
messages: 387672
nosy: swamper123
priority: normal
severity: normal
status: open
title: test test_webbrowser "can't locate runnable browser" with
enable-optimizations
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue43320>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43280] additional argument for str.join()
Change by Fabian Brinkmann : -- title: addition argument for str.join() -> additional argument for str.join() ___ Python tracker <https://bugs.python.org/issue43280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43280] addition argument for str.join()
New submission from Fabian Brinkmann : It would be nice to have an additional argument for str.join() so this ", ".join(["a", "b", "c"], ", and ") would output "a, b, and, c" -- components: Library (Lib) messages: 387426 nosy: f-brinkmann priority: normal severity: normal status: open title: addition argument for str.join() type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43280> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37287] picke cannot dump Exception subclasses with different super() args
Fabian Raab added the comment: It seems to that this problem is affecting __new__ methods independent of exceptions: >>> class NewBreaker: ... def __new__(cls, arg): ... return super().__new__(cls) ... >>> nb = NewBreaker(42) >>> import pickle >>> dumped = pickle.dumps(nb) >>> pickle.loads(dumped) Traceback (most recent call last): File "", line 1, in TypeError: __new__() missing 1 required positional argument: 'arg' -- ___ Python tracker <https://bugs.python.org/issue37287> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37287] picke cannot dump Exception subclasses with different super() args
Change by Fabian Raab : -- nosy: +raabf ___ Python tracker <https://bugs.python.org/issue37287> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36133] ThreadPoolExecutor and ProcessPoolExecutor, dynamic worker count
New submission from Fabian Dill : The request is, that the _max_workers attribute of the pools are exposed as a proper interface, that would allow changing of the worker amount after initialisation. -- components: Library (Lib) messages: 336745 nosy: Fabian Dill priority: normal severity: normal status: open title: ThreadPoolExecutor and ProcessPoolExecutor, dynamic worker count versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27875] Syslogs /usr/sbin/foo as /foo instead of as foo
New submission from Fabian Pietsch: When calling syslog.syslog() without calling syslog.openlog() before, openlog() gets called with no arguments. Documentation says: "The optional ident keyword argument is a string which is prepended to every message, and defaults to sys.argv[0] with leading path components stripped." -- "35.13. syslog — Unix syslog library routines" It leaves the final slash in, though. This produces syslog output for /usr/sbin/foo with identifier "/foo" instead of "foo". When reading syslog unprepared, one can easily think that to be a bug in the specific python script at hand (which it's not), or a chroot to be involved (which it's not, usually). So I consider this a bug. On freenode/#python I was referred to https://github.com/python/cpython/blob/master/Modules/syslogmodule.c#L98 for the code that does this. This issue is forwarded from a minor bug report reported by me at Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835577 A test script is attached, which, when called with absolute path, produces this in syslog: Aug 27 08:53:27 blackbox /test-syslog.py: Test from python! The slash is misleading/wrong. -- files: test-syslog.py messages: 273770 nosy: canvon priority: normal severity: normal status: open title: Syslogs /usr/sbin/foo as /foo instead of as foo type: behavior Added file: https://bugs.python.org/file44240/test-syslog.py ___ Python tracker <https://bugs.python.org/issue27875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27356] csv
New submission from Fabian:
Hi,
I am running Canopy on Windows 7 64 bit.
When I run the attached file, I get the following error:
> 5 with open('C:\Users\Anwender\Desktop\Test\blub.txt') as csvfile:
6 dialekt = csv.Sniffer().sniff(csvfile.read(1024))
IOError: [Errno 22] invalid mode ('r') or filename:
'C:\\Users\\Anwender\\Desktop\\Test\x08lub.txt'
As you see, Python complains about the file name after it changes the file name
for no reason.
The thing is, when I use a capital letter after every back slash it is fine,
but I needed quite some time to figure that out. So it is very annoying for
everyone encountering the problem for the first time.
Also numbers at the beginning of a file name seem not to work either.
Thank you for developing Python!
--
components: Unicode
files: MesspunkteAusKurven.py
messages: 268904
nosy: bethard, ezio.melotti, fabian_b, haypo
priority: normal
severity: normal
status: open
title: csv
Added file: http://bugs.python.org/file43490/MesspunkteAusKurven.py
___
Python tracker
<http://bugs.python.org/issue27356>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24667] OrderedDict.popitem()/__str__() raises KeyError
Fabian added the comment: Okay I think I've run the test suite on 3.6 although it only works with https://gerrit.wikimedia.org/r/#/c/229683/ now as inspect.getargspec has been removed (when I initially posted this, it was just deprecated). Well writing this I just thought I could've tested that on 3.5… well anyway I don't get any KeyErrors. -- ___ Python tracker <http://bugs.python.org/issue24667> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24667] OrderedDict.popitem()/__str__() raises KeyError
Fabian added the comment: Thank you for figuring it out and providing a patch after I couldn't really give good information. I haven't been able to test it for myself but your explanation makes sense :) -- ___ Python tracker <http://bugs.python.org/issue24667> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24667] OrderedDict.popitem()/__str__() raises KeyError
Fabian added the comment: Ah okay. If you look at Eric's response you'll see that this is a different issue and tracked in issue24721. I mean it is possible that urllib3 does it too (it's devs would need to answer that) but in the end highly unlikely as it doesn't happen on versions before 3.5b2. -- ___ Python tracker <http://bugs.python.org/issue24667> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24667] OrderedDict.popitem()/__str__() raises KeyError
Fabian added the comment: Really this bug and not the one mentioned by Mark? I've been using 3.4(.3) since we use requests (and therefore urllib3) which happened a few months ago. I also can't remember any failure on a Python 3.4 Travis build. -- ___ Python tracker <http://bugs.python.org/issue24667> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24667] OrderedDict.popitem()/__str__() raises KeyError
Fabian added the comment: Just as a note to the tests: You may not get the issues with OrderedDict as a failure/error at the end of the test suite. And you may (depending on the version) get a few errors because NoUsername was raised. That is unrelated to this issue and can be fixed by using a version after 6255530f has been merged. -- ___ Python tracker <http://bugs.python.org/issue24667> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24667] OrderedDict.popitem()/__str__() raises KeyError
Fabian added the comment: Oh sorry, I basically never need to install pywikibot anew so it's easy to forget but there is a submodule in scripts/i18n which needs to be cloned as well. With the following commands I could reproduce the error (and you don't even need to install requests and six): $ git clone --recursive g...@github.com:wikimedia/pywikibot-core.git test $ cd test/ $ echo "mylang='en'" >> user-config.py $ echo "family='wikipedia'" >> user-config.py $ python setup.py test With that you only need a network connection (as this error is in urllib3 I doubt it works without network connection) but you don't need any wiki account. If you want to test it with an account, execute “generate_user_files.py” before. Just as a note I've activated write and write failure tests but without an account these tests should not be run anyway. -- ___ Python tracker <http://bugs.python.org/issue24667> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24667] OrderedDict.popitem()/__str__() raises KeyError
Fabian added the comment: Okay I did a test run on all three 3.5 betas available to me through pyenv. The beta 3 failed as Python 3.6 does that popitem() raises a KeyError. The beta 2 had the bug that popitem() does not support keyword arguments so I wasn't able to test it there. And the beta 1 works fine so it looks like the C implementation is the cause of this. -- versions: +Python 3.5 ___ Python tracker <http://bugs.python.org/issue24667> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24667] OrderedDict.popitem()/__str__() raises KeyError
Fabian added the comment: Yes see the tests/README.rst. And afaik do you only need to have requests and six installed. -- ___ Python tracker <http://bugs.python.org/issue24667> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24667] OrderedDict.popitem()/__str__() raises KeyError
Fabian added the comment: It is consistent as in it happens on every run of the test suite. But unfortunately I haven't checked if it's always happening at the same place. Luckily we have 4 builds on Travis with 3.6 and in all it happened from the beginning and got > 100 matches for “KeyError:”: * https://travis-ci.org/wikimedia/pywikibot-core/jobs/71537432#L274 * https://travis-ci.org/wikimedia/pywikibot-core/jobs/71626596#L274 * https://travis-ci.org/wikimedia/pywikibot-core/jobs/71636529#L274 * https://travis-ci.org/wikimedia/pywikibot-core/jobs/71637809#L274 * https://travis-ci.org/xZise/pywikibot-core/builds/71550286#L274 Maybe I can do additional analysis but I'm pretty sure for me locally I didn't get failures so soon. And no I wasn't aware about OrderedDict implemented in C. Now I haven't done tests in 3.5.0b3 (which seems to be the newest version of 3.5 available via pyenv at the moment) as it's relatively cumbersome and prevents me from doing any development on pywikibot at the same time. Anyway I still might do it and report whether I get the error too (unless OrderedDict is still implemented in Python in that version). -- ___ Python tracker <http://bugs.python.org/issue24667> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24667] OrderedDict.popitem()/__str__() raises KeyError
Fabian added the comment: Well as I described in the opening post: "I don't think versions before Python 3.6 are affected as we had tests running on Python 3.5 (before Travis switched to 3.6 recently) and these all worked." Now tbh I don't know if a version of 3.5 is affected but was never tested by Travis. And if then the 3.6 branch was branched of that version. If that how it works. As I'm using pyenv I could easily test this on Python 3.5b3. By the way the last official test run on Pyhton 3.5 using Travis was using 3.5a4+: https://travis-ci.org/wikimedia/pywikibot-core/jobs/71443578#L144 -- ___ Python tracker <http://bugs.python.org/issue24667> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24667] OrderedDict.popitem()/__str__() raises KeyError
Fabian added the comment:
Looking further into this issue, OrderedDict.pop() using the key returned from
the KeyError (using eval(str(error))) also yields a KeyError. And
OrderedDict.popitem() does not change the dictionary (so it's not like the
KeyError is raised even though it worked).
Also it appears to be empty actually. list(OrderedDict) returns an empty list
even though str(OrderedDict) does not. So maybe some operations do only remove
entries from one part of the data so that popitem() still thinks it's in the
cache. Now I'm not familiar with urllib3 so I'm not sure how that internal
OrderedDict is used to narrow down what might cause that issue.
And additionally I tried to output keys(), items() and values() separately and
suddenly I get a KeyError even when I just do str():
conn = self.poolmanager.connection_from_url(url)
File
"/home/xzise/.pyenv/versions/3.6-dev/lib/python3.6/site-packages/requests/packages/urllib3/poolmanager.py",
line 139, in connection_from_url
return self.connection_from_host(u.host, port=u.port, scheme=u.scheme)
File
"/home/xzise/.pyenv/versions/3.6-dev/lib/python3.6/site-packages/requests/packages/urllib3/poolmanager.py",
line 125, in connection_from_host
self.pools[pool_key] = pool
File
"/home/xzise/.pyenv/versions/3.6-dev/lib/python3.6/site-packages/requests/packages/urllib3/_collections.py",
line 66, in __setitem__
__before = str(self._container)
KeyError: ('https', 'ru.wikipedia.org', 443)
--
title: OrderedDict.popitem() raises KeyError -> OrderedDict.popitem()/__str__()
raises KeyError
___
Python tracker
<http://bugs.python.org/issue24667>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24667] OrderedDict.popitem() raises KeyError
New submission from Fabian:
While testing pywikibot using requests and urllib3 on Python 3.6 we got an
interesting error:
==
ERROR: testQueryApiGetter (tests.wikidataquery_tests.TestApiSlowFunctions)
Test that we can actually retreive data and that caching works.
--
Traceback (most recent call last):
File "/home/travis/build/xZise/pywikibot-core/tests/wikidataquery_tests.py",
line 252, in testQueryApiGetter
data = w.query(q)
File
"/home/travis/build/xZise/pywikibot-core/pywikibot/data/wikidataquery.py", line
601, in query
data = self.getDataFromHost(fullQueryString)
File
"/home/travis/build/xZise/pywikibot-core/pywikibot/data/wikidataquery.py", line
563, in getDataFromHost
resp = http.fetch(url)
File "/home/travis/build/xZise/pywikibot-core/pywikibot/comms/http.py", line
359, in fetch
error_handling_callback(request)
File "/home/travis/build/xZise/pywikibot-core/pywikibot/comms/http.py", line
276, in error_handling_callback
raise request.data
File "/home/travis/build/xZise/pywikibot-core/pywikibot/comms/http.py", line
255, in _http_process
auth=auth, timeout=timeout, verify=True)
File
"/home/travis/virtualenv/python3.6-dev/lib/python3.6/site-packages/requests/sessions.py",
line 465, in request
resp = self.send(prep, **send_kwargs)
File
"/home/travis/virtualenv/python3.6-dev/lib/python3.6/site-packages/requests/sessions.py",
line 573, in send
r = adapter.send(request, **kwargs)
File
"/home/travis/virtualenv/python3.6-dev/lib/python3.6/site-packages/requests/adapters.py",
line 337, in send
conn = self.get_connection(request.url, proxies)
File
"/home/travis/virtualenv/python3.6-dev/lib/python3.6/site-packages/requests/adapters.py",
line 251, in get_connection
conn = self.poolmanager.connection_from_url(url)
File
"/home/travis/virtualenv/python3.6-dev/lib/python3.6/site-packages/requests/packages/urllib3/poolmanager.py",
line 139, in connection_from_url
return self.connection_from_host(u.host, port=u.port, scheme=u.scheme)
File
"/home/travis/virtualenv/python3.6-dev/lib/python3.6/site-packages/requests/packages/urllib3/poolmanager.py",
line 125, in connection_from_host
self.pools[pool_key] = pool
File
"/home/travis/virtualenv/python3.6-dev/lib/python3.6/site-packages/requests/packages/urllib3/_collections.py",
line 66, in __setitem__
_key, evicted_value = self._container.popitem(last=False)
KeyError: ('https', 'eu.wiktionary.org', 443)
Now that doesn't make much sense, as OrderedDict.popitem() only returns a
KeyError if it's empty but then not with that error message. Unfortunately I
can't reproduce it without doing the complete pywikibot test suite. When I only
execute the tests where it occurred I don't get any failures. So I modified the
output in urllib3 and returned the key as well as the content before
popitem(last=False) is called (I shortened the values):
Key: ('https', 'bn.wikipedia.org', 443)
Content: OrderedDict([(('https', 'bn.wikipedia.org', 443),
), (('https', 'bs.wikipedia.org', 443), <…0x7fe483d99470>),
(('https', 'ca.wikipedia.org', 443), <…0x7fe483da0e10>), (('https',
'cs.wikipedia.org', 443), <…0x7fe483dfc908>), (('https', 'da.wikipedia.org',
443), <…0x7fe483d98c88>), (('https', 'de.wikipedia.org', 443),
<…0x7fe4911e06a0>), (('https', 'diq.wikipedia.org', 443), <…0x7fe483d6b400>),
(('https', 'dsb.wikipedia.org', 443), <…0x7fe483d6bcf8>), (('https',
'en.wikipedia.org', 443), <…0x7fe483dc1da0>), (('https', 'eo.wikipedia.org',
443), <…0x7fe483d6cf28>), (('https', 'es.wikipedia.org', 443),
<…0x7fe483d6b4a8>), (('https', 'fa.wikipedia.org', 443), <…0x7fe483d27278>),
(('https', 'fi.wikipedia.org', 443), <…0x7fe483d6ce10>), (('https',
'fr.wikipedia.org', 443), <…0x7fe483e24cf8>), (('https', 'frr.wikipedia.org',
443), <…0x7fe483d39390>), (('https', 'ga.wikipedia.org', 443),
<…0x7fe483c99668>), (('https', 'gl.wikipedia.org', 443), <…0x7fe483ca3f98>),
(('https', 'als.wikipedia.org', 443), <…0x7fe483c4fcf8>), (('https',
'hu.wikipedia.org', 443), <…0x7fe483cd09e8>)])
As you can see it is not empty and the key in the KeyError is the first key in
the OrderedDict. Also
[issue24404] Python 2.7.0's BZ2File does not support with-statements
New submission from Fabian:
I had a weird bug recently where someone tried to use the with-statement on a
BZ2File. According to the documentation it was added in 2.7 and looking at
https://hg.python.org/cpython/rev/5d5d9074f4ca it looks like it was added
together with the support in gzip.
But after I've installed 2.7.0 I could use the with-statement on gzip but not
in BZ2File:
Python 2.7 (r27:82500, Jun 7 2015, 19:01:29)
[GCC 4.8.3 20140911 (Red Hat 4.8.3-7)] on linux3
Type "help", "copyright", "credits" or "license" for more information.
>>> import bz2
>>> with bz2.BZ2File('tests/data/xml/article-pyrus.xml.bz2') as f:
... c = f.read()
...
Traceback (most recent call last):
File "", line 1, in
AttributeError: __exit__
So I've installed 2.7.1 and sure enough it works there:
Python 2.7.1 (r271:86832, Jun 7 2015, 19:21:02)
[GCC 4.8.3 20140911 (Red Hat 4.8.3-7)] on linux3
Type "help", "copyright", "credits" or "license" for more information.
>>> import bz2
>>> with bz2.BZ2File('tests/data/xml/article-pyrus.xml.bz2') as f:
... c = f.read()
...
>>>
I guess the documentation needs be updated that since Python 2.7.1 BZ2File
supports the with-statement.
See also: https://phabricator.wikimedia.org/T101649
--
assignee: docs@python
components: Documentation
messages: 244962
nosy: docs@python, xZise
priority: normal
severity: normal
status: open
title: Python 2.7.0's BZ2File does not support with-statements
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue24404>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19003] email.generator.BytesGenerator corrupts data by changing line endings
Fabian added the comment: I can confirm this on 3.4.1 and is really annoying. But the patch should set '_is_raw_payload' to False if the payload is set via 'set_payload' (the operations in 'set_raw_payload' need to be switched). -- nosy: +xZise ___ Python tracker <http://bugs.python.org/issue19003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22282] ipaddress module accepts octal formatted IPv4 addresses in IPv6 addresses
Fabian added the comment: The patch adds an optional keyword which only accepts decimal numbers. -- keywords: +patch Added file: http://bugs.python.org/file36489/ipaddr.patch ___ Python tracker <http://bugs.python.org/issue22282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22282] ipaddress module accepts octal formatted IPv4 addresses in IPv6 addresses
New submission from Fabian:
The ipaddress module accepts IPv6 addresses if the IPv4 address is formatted as
an octal number, but http://tools.ietf.org/html/rfc3986#section-3.2.2 doesn't
allow leading zeroes in the IPv4 address.
This is the current behaviour (in 3.4.1):
>>> ipaddress.ip_address("::1.0.0.00")
IPv6Address('::100:0')
Expected:
>>> ipaddress.ip_address("::1.0.0.00")
Traceback (most recent call last):
File "", line 1, in
File "3.4.1/lib/python3.4/ipaddress.py", line 54, in ip_address
address)
ValueError: '::1.0.0.00' does not appear to be an IPv4 or IPv6 address
Because I didn't know it better, I first tried to patch the backport but this
might be still applicable the official code:
https://github.com/phihag/ipaddress/pull/12
--
messages: 225950
nosy: xZise
priority: normal
severity: normal
status: open
title: ipaddress module accepts octal formatted IPv4 addresses in IPv6 addresses
type: behavior
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue22282>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1398781] Example in section 5.3 "Pure Embedding" doesn't work.
Fabian Kochem added the comment: I just fell over the PYTHONPATH='' bit aswell. So yes, this is still valid. -- nosy: +Fabian.Kochem ___ Python tracker <http://bugs.python.org/issue1398781> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8876] distutils should not assume that hardlinks will work
Fabian Kochem added the comment: A dirty hack is to include this line at the top of your setup.py: del os.link -- ___ Python tracker <http://bugs.python.org/issue8876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8876] distutils should not assume that hardlinks will work
Fabian Kochem added the comment: Éric said that he should be able to get to it soon.: https://twitter.com/merwok_/status/425596183176704002 -- ___ Python tracker <http://bugs.python.org/issue8876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8876] distutils should not assume that hardlinks will work
Changes by Fabian Kochem : -- nosy: +Fabian.Kochem ___ Python tracker <http://bugs.python.org/issue8876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5815] locale.getdefaultlocale() missing corner case
Mike FABIAN added the comment: Serhiy> While normalize can return sd...@devanagari.utf-8, _parse_localename() Serhiy> should be able correctly parse it. But if normalize returns sd...@devanagari.utf-8, isn’t that quite useless because it is a locale name which does not actually work in glibc? Serhiy> Removing sd...@devanagari.utf-8 from alias table is another issue. Yes. I think it should be fixed in the alias table as well. -- ___ Python tracker <http://bugs.python.org/issue5815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5815] locale.getdefaultlocale() missing corner case
Mike FABIAN added the comment: In glibc, sd...@devanagari.utf-8 is an invalid locale name, only sd_IN.UTF-8@devanagari is valid: mfabian@ari:~ $ LC_ALL=sd_IN.UTF-8@devanagari locale charmap UTF-8 mfabian@ari:~ $ LC_ALL=sd...@devanagari.utf-8 locale charmap locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968 mfabian@ari:~ $ So I think this should be fixed in X.org. -- ___ Python tracker <http://bugs.python.org/issue5815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5815] locale.getdefaultlocale() missing corner case
Mike FABIAN added the comment: Serhiy> The /usr/share/X11/locale/locale.alias file in Ubuntu 12.04 LTS Serhiy> contains ks...@devanagari.utf-8 and sd...@devanagari.utf-8 Serhiy> entities. Yes, I know, that’s why I wrote that the Python code inherited this mistake from X.org. Serhiy> While the encoding is expected to be before the modifier, if Serhiy> there are systems with ks...@devanagari.utf-8 or Serhiy> sd...@devanagari.utf-8 locales we should support these weird case. There are no such systems really, in X.org this is just a mistake. glibc doesn’t write it like this and it is agains the specification here: http://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.html#tag_002 [language[_territory][.codeset][@modifier]] -- ___ Python tracker <http://bugs.python.org/issue5815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5815] locale.getdefaultlocale() missing corner case
Mike FABIAN added the comment:
Serhiy, in your patch you seem to have special treatment for
the devanagari modifier:
+# Devanagari modifier placed before encoding.
+return code, modifier.split('.')[1]
Probably because of
'ks_in@devanagari': 'ks...@devanagari.utf-8',
'sd': 'sd...@devanagari.utf-8',
in the locale_alias dictionary.
But I think these two lines are just wrong, this mistake
is inherited from the locale.alias from X.org where the
python locale_alias comes from.
glibc:
mfabian@ari:~
$ locale -a | grep ^sd
sd_IN
sd_IN.utf8
sd_IN.utf8@devanagari
sd_IN@devanagari
mfabian@ari:~
$ locale -a | grep ^ks
ks_IN
ks_IN.utf8
ks_IN.utf8@devanagari
ks_IN@devanagari
mfabian@ari:~
$
The encoding should always be *before* the modifier.
--
nosy: +mfabian
___
Python tracker
<http://bugs.python.org/issue5815>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin
Mike FABIAN added the comment: The patch http://bugs.python.org/file32552/0001-Issue-19534-fix-normalize-in-locale.py-to-make-it-wo.patch is against the current HEAD of the 2.7 branch, but Python 3.3 has exactly the same problem, the same patch fixes it for python 3.3 as well. -- ___ Python tracker <http://bugs.python.org/issue19534> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin
Mike FABIAN added the comment: I think the patch I attach here is a better fix than the patch in http://bugs.python.org/msg202469 because it makes the normalize() function behave more logical overall, with this patch, my test program prints: mfabian@ari:/local/mfabian/src/cpython (2.7-mike %) $ ./python ~/tmp/mike-test.py ja_JP.UTF-8 -> ja_JP.UTF-8 de_DE.SJIS -> de_DE.SJIS de_DE.foobar -> de_DE.foobar sr_RS.UTF-8@latin -> sr_RS.UTF-8@latin sr_rs@latin -> sr_RS.UTF-8@latin sr@latin -> sr_RS.UTF-8@latin sr_yu -> sr_RS.UTF-8@latin sr_yu.SJIS@devanagari -> sr_RS.SJIS@devanagari sr@foobar -> sr_RS.UTF-8@foobar sR@foObar -> sr_RS.UTF-8@foobar sR -> sr_RS.UTF-8 [18995 refs] mfabian@ari:/local/mfabian/src/cpython (2.7-mike %) $ The patch also contains a small fix for the “ks” and “sd” locales in the locale_alias dictionary, they had the “.UTF-8” in the wrong place: -'ks_in@devanagari': 'ks...@devanagari.utf-8', +'ks_in@devanagari': 'ks_IN.UTF-8@devanagari', -'sd': 'sd...@devanagari.utf-8', +'sd': 'sd_IN.UTF-8@devanagari', (This error is inherited from the locale.alias file from X.org where the locale_alias dictionary is generated from) -- keywords: +patch Added file: http://bugs.python.org/file32552/0001-Issue-19534-fix-normalize-in-locale.py-to-make-it-wo.patch ___ Python tracker <http://bugs.python.org/issue19534> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin
Mike FABIAN added the comment:
in locale.py, the comment above “locale_alias = {” says:
# Note that the normalize() function which uses this tables
# removes '_' and '-' characters from the encoding part of the
# locale name before doing the lookup. This saves a lot of
# space in the table.
But in normalize(), this is actually not done:
# First lookup: fullname (possibly with encoding)
norm_encoding = encoding.replace('-', '')
norm_encoding = norm_encoding.replace('_', '')
lookup_name = langname + '.' + encoding
code = locale_alias.get(lookup_name, None)
“norm_encoding” holds the locale name with these replacements,
but then it is not used in the lookup.
The patch in http://bugs.python.org/msg202469
fixes that, using the norm_encoding together with adding the alias
+'sr_rs.utf8@latin': 'sr_RS.UTF-8@latin',
makes it work for sr_RS.UTF-8@latin, my test program then outputs:
mfabian@ari:~
$ python2 ~/tmp/mike-test.py
ja_JP.UTF-8 -> ja_JP.UTF-8
de_DE.SJIS -> de_DE.SJIS
de_DE.foobar -> de_DE.foobar
sr_RS.UTF-8@latin -> sr_RS.UTF-8@latin
sr_rs@latin -> sr_RS.UTF-8@latin
sr@latin -> sr_RS.UTF-8@latin
sr_yu -> sr_RS.UTF-8@latin
sr_yu.SJIS@devanagari -> sr_RS.sjis_devanagari
sr@foobar -> sr@foobar
sR@foObar -> sR@foObar
sR -> sr_RS.UTF-8
mfabian@ari:~
$
But note that the normalization of the “sr_yu.SJIS@devanagari”
locale is still weird (of course a “sr_yu.SJIS@devanagari”
is quite silly and does not exist anyway, but the code in normalize()
does not seem to work as intended.
--
___
Python tracker
<http://bugs.python.org/issue19534>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin
Mike FABIAN added the comment:
A simple fix for that problem could look like this:
mfabian@ari:~
$ diff -u /usr/lib64/python2.7/locale.py.orig /usr/lib64/python2.7/locale.py
--- /usr/lib64/python2.7/locale.py.orig 2013-11-09 09:08:24.807331535 +0100
+++ /usr/lib64/python2.7/locale.py 2013-11-09 09:08:34.526390646 +0100
@@ -377,7 +377,7 @@
# First lookup: fullname (possibly with encoding)
norm_encoding = encoding.replace('-', '')
norm_encoding = norm_encoding.replace('_', '')
-lookup_name = langname + '.' + encoding
+lookup_name = langname + '.' + norm_encoding
code = locale_alias.get(lookup_name, None)
if code is not None:
return code
@@ -1457,6 +1457,7 @@
'sr_cs@latn': 'sr_RS.UTF-8@latin',
'sr_me':'sr_ME.UTF-8',
'sr_rs':'sr_RS.UTF-8',
+'sr_rs.utf8@latin': 'sr_RS.UTF-8@latin',
'sr_rs.utf8@latn': 'sr_RS.UTF-8@latin',
'sr_rs@latin': 'sr_RS.UTF-8@latin',
'sr_rs@latn': 'sr_RS.UTF-8@latin',
mfabian@ari:~
$
--
___
Python tracker
<http://bugs.python.org/issue19534>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin
Mike FABIAN added the comment:
The problem turns out to be caused by a problem in normalizing
the locale name, see the output of this test program:
mfabian@ari:~
$ cat ~/tmp/mike-test.py
#!/usr/bin/python2
import sys
import os
import locale
import encodings
import encodings.aliases
test_locales = [
'ja_JP.UTF-8',
'de_DE.SJIS',
'de_DE.foobar',
'sr_RS.UTF-8@latin',
'sr_rs@latin',
'sr@latin',
'sr_yu',
'sr_yu.SJIS@devanagari',
'sr@foobar',
'sR@foObar',
'sR',
]
for test_locale in test_locales:
print("%(orig)s -> %(norm)s"
%{'orig': test_locale,
'norm': locale.normalize(test_locale)}
)
mfabian@ari:~
$ python2 ~/tmp/mike-test.py
ja_JP.UTF-8 -> ja_JP.UTF-8
de_DE.SJIS -> de_DE.SJIS
de_DE.foobar -> de_DE.foobar
sr_RS.UTF-8@latin -> sr_RS.utf_8_latin
sr_rs@latin -> sr_RS.UTF-8@latin
sr@latin -> sr_RS.UTF-8@latin
sr_yu -> sr_RS.UTF-8@latin
sr_yu.SJIS@devanagari -> sr_RS.sjis_devanagari
sr@foobar -> sr@foobar
sR@foObar -> sR@foObar
sR -> sr_RS.UTF-8
mfabian@ari:~
$
I.e. “sr_RS.UTF-8@latin” is normalized to “sr_RS.utf_8_latin” which
is clearly wrong and causes a fallback to sr_RS when using gettext
which gives the cyrillic translations.
--
Added file: http://bugs.python.org/file32551/mike-test.py
___
Python tracker
<http://bugs.python.org/issue19534>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin
New submission from Mike FABIAN:
Originally reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1024667
I found that Serbian translations in Latin do not work when the locale
name is written as sr_RS.UTF-8@latin (one gets the cyrillic
translations instead), but they *do* work when the locale name is
written as sr_RS@latin (i.e. omitting the '.UTF-8'):
$ LANG='sr_RS.UTF-8' python2 -c 'import gettext;
print(gettext.ldgettext("anaconda", "What language would you like to use during
the installation process?").decode("UTF-8"))'
Који језик бисте желели да користите током процеса инсталације?
mfabian@ari:~
$ LANG='sr_RS.UTF-8@latin' python2 -c 'import gettext;
print(gettext.ldgettext("anaconda", "What language would you like to use during
the installation process?").decode("UTF-8"))'
Који језик бисте желели да користите током процеса инсталације?
mfabian@ari:~
$ LANG='sr_RS@latin' python2 -c 'import gettext;
print(gettext.ldgettext("anaconda", "What language would you like to use during
the installation process?").decode("UTF-8"))'
Koji jezik biste želeli da koristite tokom procesa instalacije?
mfabian@ari:~
$
The “gettext” command line tool does not have this problem:
mfabian@ari:~
$ LANG='sr_RS@latin' gettext anaconda "What language would you like to use
during the installation process?"
Koji jezik biste želeli da koristite tokom procesa instalacije?mfabian@ari:~
$ LANG='sr_RS.UTF-8@latin' gettext anaconda "What language would you like to
use during the installation process?"
Koji jezik biste želeli da koristite tokom procesa instalacije?mfabian@ari:~
$ LANG='sr_RS.UTF-8' gettext anaconda "What language would you like to use
during the installation process?"
Који језик бисте желели да користите током процеса инсталације?mfabian@ari:~
$
--
components: Library (Lib)
messages: 202467
nosy: mfabian
priority: normal
severity: normal
status: open
title: normalize() in locale.py fails for sr_RS.UTF-8@latin
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue19534>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17749] root logging functions break logger configuration
New submission from Fabian:
If I get and configure a named logger in the main module and another module
that is imported uses the root logging functions (e.g., logging.info("Hello
World!")) somehow affects the configuration of the first (named) logger.
The file m1.py defines the logger "testlogger" and then imports the module
m2.py. In m2.py the root logger is used through logging.info(...). This message
apparantly doesn't appear anywhere.
After the import in m1.py the previously defined logger is used through
logger.info(...). This message appears (formatted) in the logfile:
2013-04-16 11:23:56,231 INFO Hello from __main__
and (unformatted) at stdout:
INFO:testlogger:Hello from __main__
I did not expect this behavior, therefore I reported this bug. In my
expectation the call to logging.info() should not affect the behavior of the
named and configured logger.
Main module (m1.py):
import logging
def setup_logging():
# made this a function to avoid cluttering the global namespace
logger = logging.getLogger("testlogger")
logger.setLevel(logging.DEBUG)
formatter = logging.Formatter('%(asctime)s %(levelname)s %(message)s')
handler = (logging.FileHandler("testlog.log"),
logging.StreamHandler())
handler = handler[0] # 0 : write to logfile, 1 : write to stdout
handler.setFormatter(formatter)
logger.addHandler(handler)
return logger
logger = setup_logging()
import m2
logger.info("Hello from %s", __name__)
Other module (m2.py)
import logging
logging.info("Hello from %s", __name__)
I observed this behavior with Python v2.7.3
--
components: IO
messages: 187061
nosy: fmueller
priority: normal
severity: normal
status: open
title: root logging functions break logger configuration
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue17749>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16591] RUNSHARED wrong for OSX no framework
Fabian Groffen added the comment: > Which shell doesn't have $(command) support? It is not a bash-ism, but > is part of the POSIX shell definition (but wasn't present in older sh > implementations). Solaris' /bin/sh. -- ___ Python tracker <http://bugs.python.org/issue16591> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16591] RUNSHARED wrong for OSX no framework
Fabian Groffen added the comment:
re: single quotes -> double quotes
I made RUNSHARED consistent (although, as you point out, less broken) with the
other RUNSHARED assignments right above. If suggest to tackle the issue of
whitespace support for all RUNSHARED assignments, not just Darwin case.
re: `pwd` vs. $(pwd)
$ /bin/sh
$ echo $(pwd)
syntax error: `(' unexpected
Here again, even though Darwin/OSX may be shipped with /bin/sh being bash
(hence above problem not existing), for consistency, using `pwd` in all
RUNSHARED assignments is nice, IMO.
--
___
Python tracker
<http://bugs.python.org/issue16591>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16591] RUNSHARED wrong for OSX no framework
New submission from Fabian Groffen: Python fails to run python.exe on OSX when a non-framework build is requested, due to wrong quoting in configure.ac. Like all other RUNSHARED, it shouldn't be quoted because then `pwd` won't be expanded, resulting in a wrong DYLD_LIBRARY_PATH when regen is ran (from a different directory than where libpython3.3.dylib resides). Attached patch solves the issue. The issue seems to be in current 3.3 and default heads. -- components: Build files: 11_all_darwin-dyld-library-path.patch hgrepos: 162 keywords: patch messages: 176754 nosy: grobian priority: normal severity: normal status: open title: RUNSHARED wrong for OSX no framework type: compile error versions: Python 3.3 Added file: http://bugs.python.org/file28180/11_all_darwin-dyld-library-path.patch ___ Python tracker <http://bugs.python.org/issue16591> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails)
Fabian Groffen added the comment: I don't want to go through the paperwork nonsense just for a trivial patch, hence I didn't supply one, but instead provided all the information for you guys to make the correct fix. -- ___ Python tracker <http://bugs.python.org/issue14662> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails)
Fabian Groffen added the comment:
it seems errnomodule.c has no idea of ENOTSUP, and that's not the only missing
one.
OSX 10.7:
$ grep "^#define\sE" /usr/include/sys/errno.h | awk '{print $2}' | while read
line ; do grep -q ${line} Modules/errnomodule.c || echo "missing: $line" ; done
missing: ENOTSUP
missing: EBADRPC
missing: ERPCMISMATCH
missing: EPROGUNAVAIL
missing: EPROGMISMATCH
missing: EPROCUNAVAIL
missing: EFTYPE
missing: EAUTH
missing: ENEEDAUTH
missing: EPWROFF
missing: EDEVERR
missing: EBADEXEC
missing: EBADARCH
missing: ESHLIBVERS
missing: EBADMACHO
missing: ECANCELED
missing: ENOATTR
missing: ENOPOLICY
missing: ENOTRECOVERABLE
missing: EOWNERDEAD
missing: ELAST
Solaris 10:
$ grep "^#define\sE" /usr/include/sys/errno.h | awk '{print $2}' | while read
line ; do grep -q ${line} Modules/errnomodule.c || echo "missing: $line" ; done
missing: ECANCELED
missing: ENOTSUP
missing: EOWNERDEAD
missing: ENOTRECOVERABLE
missing: ELOCKUNMAPPED
missing: ENOTACTIVE
--
___
Python tracker
<http://bugs.python.org/issue14662>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails)
Fabian Groffen added the comment:
% echo "test" > /var/tmp/testfile
% python
Python 2.7.3 (default, Apr 26 2012, 19:06:37)
[GCC 4.2.1 (Gentoo 4.2.1_p5666, Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.move("/var/tmp/testfile", "./testfile");
Traceback (most recent call last):
File "", line 1, in
File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 299, in move
copy2(src, real_dst)
File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 129, in copy2
copystat(src, dst)
File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 103, in copystat
os.chflags(dst, st.st_flags)
OSError: [Errno 45] Operation not supported: './testfile'
>>>
% vi /Library/Gentoo/usr/lib/python2.7/shutil.py
% python
Python 2.7.3 (default, Apr 26 2012, 19:06:37)
[GCC 4.2.1 (Gentoo 4.2.1_p5666, Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.move("/var/tmp/testfile", "./testfile");
45
Traceback (most recent call last):
File "", line 1, in
File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 300, in move
copy2(src, real_dst)
File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 130, in copy2
copystat(src, dst)
File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 103, in copystat
os.chflags(dst, st.st_flags)
OSError: [Errno 45] Operation not supported: './testfile'
>>>
% grep 45 /usr/include/sys/errno.h
#define ENOTSUP 45 /* Operation not supported */
I tried with a FAT16 formatted USB-disk, but there it doesn't fail, so I did
some further digging. MS-DOS FS (under OSX) just seems to support setting
flags (I tried with stat.UF_HIDDEN, Finder no longer displays the file).
NFS, however, does NOT support any chflags call.
% python
Python 2.7.3 (default, Apr 26 2012, 19:06:37)
[GCC 4.2.1 (Gentoo 4.2.1_p5666, Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import errno
>>> print hasattr(errno, 'EOPNOTSUPP')
True
>>> print errno.EOPNOTSUPP
102
>>>
102 obviously != 45
% grep 102 /usr/include/sys/errno.h
#define EOPNOTSUPP 102 /* Operation not supported on socket */
I believe Python got it mixed up here, we're looking for ENOTSUP, but that one
doesn't exist, at least not here.
>>> print hasattr(errno, 'ENOTSUP')
False
--
___
Python tracker
<http://bugs.python.org/issue14662>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails)
Fabian Groffen added the comment: > I presume Python 3.2+ have the same behavior? I cannot compile that or get it working normally, so I can't tell for sure. Judging from the code, I'd say yes. -- ___ Python tracker <http://bugs.python.org/issue14662> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14662] shutil.move broken in 2.7.3 on OSX (chflags fails)
New submission from Fabian Groffen :
With current working dir an NFS-mounted ZFS share, and /var/tmp (OSX default)
HFS+:
% echo "test" > /var/tmp/testfile
% python
Python 2.7.3 (default, Apr 24 2012, 19:33:45)
[GCC 4.2.1 (Gentoo 4.2.1_p5666, Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import shutil
>>> shutil.move("/var/tmp/testfile", "./testfile");
Traceback (most recent call last):
File "", line 1, in
File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 299, in move
copy2(src, real_dst)
File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 129, in copy2
copystat(src, dst)
File "/Library/Gentoo/usr/lib/python2.7/shutil.py", line 103, in copystat
os.chflags(dst, st.st_flags)
OSError: [Errno 45] Operation not supported: './testfile'
>>>
% ls /var/tmp/testfile ./testfile
./testfile /var/tmp/testfile
The problem likely is that the flags stored on the HFS+ volume cannot be
applied to the NFS-mounted ZFS volume. This likely also occurs when doing a
bit more regular things, like e.g. moving/copying to a mounted USB disk (with
FAT32 filesystem).
I believe this is a "regression" introduced by
http://bugs.python.org/issue8746. Python-2.7.2 works fine.
While preserving flags is nice, it is questionable whether failure to do so in
this case is worth dying for. In particular, leaving behind both the original
as well as the copy is a bit messy.
--
components: None
messages: 159178
nosy: grobian
priority: normal
severity: normal
status: open
title: shutil.move broken in 2.7.3 on OSX (chflags fails)
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue14662>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7305] urllib2.urlopen() segfault using SSL on Solaris
Fabian Groffen added the comment: I recompiled openssl with noasm flag now for sparcv9 (like I do on 32-bits compiles), and the example runs fine for me on the T1, proving Python is not to blame here. That said, if your problem only occurs with 0.9.8 isn't it then likely that that version has some bug which is fixed in 1.0.0 series? My gdb backtraces pointed at code inside libcrypto (one of the ASM accelerators). I am using GCC and a minimum of host-provided libs though. % python2.7 -V Python 2.7.1 (r271:86832, Feb 14 2011, 12:37:15) [GCC 4.3.2] on sunos5 % file `which python2.7` /scratch/tmp/gentoo/sparcv9/usr/bin/python2.7: ELF 64-bit MSB executable, SPARC V9, total store ordering, version 1 (SYSV), dynamically linked (uses shared libs), not stripped % uname -a SunOS build-t1000-sol10.cwi.nl 5.10 Generic_139555-08 sun4v sparc SUNW,SPARC-Enterprise-T1000 Solaris -- ___ Python tracker <http://bugs.python.org/issue7305> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7305] urllib2.urlopen() segfault using SSL on Solaris
Fabian Groffen added the comment: Sorry for the noise. My issue seems to be caused by a broken openssl. It is a specific problem with the code for sparcv9 and the T1 CPU. Python can't do much about this. -- versions: -Python 2.7 ___ Python tracker <http://bugs.python.org/issue7305> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7305] urllib2.urlopen() segfault using SSL on Solaris
Fabian Groffen added the comment: Perhaps I should have been a bit more clear. Python 2.6 works fine for me on Solaris 10/Sparc64 (64-bits). Python 2.7.1 also works on Solaris 10/Sparc (32-bits), but not on Sparc64 (64-bits). -- ___ Python tracker <http://bugs.python.org/issue7305> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7305] urllib2.urlopen() segfault using SSL on Solaris
Fabian Groffen added the comment: I can reproduce this on Solaris 10/Sparc64 only, using Python 2.7.1. My core files aren't really useful though, nothing it can point to, everything is corrupt. -- nosy: +grobian versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue7305> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7718] Build shared libpythonX.Y.so on IRIX
Fabian Groffen added the comment: Is it necessary to file a new bug for the same issue, or can we reopen from here? With Stuart in the loop it looks to me the raised issues are dealt with? -- ___ Python tracker <http://bugs.python.org/issue7718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7718] Build shared libpythonX.Y.so on IRIX
Fabian Groffen added the comment: I've asked Stuart to sign up and comment on this bug to get his opinion. Sorry. -- ___ Python tracker <http://bugs.python.org/issue7718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6308] termios fix for QNX breaks HP-UX
Fabian Groffen added the comment: still applies to 2.7 -- nosy: +grobian versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue6308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7718] Build shared libpythonX.Y.so on IRIX
Fabian Groffen added the comment: I think so. From my experience he's mainly not willing to sign up to each and every bugtracking system, which I fully understand. Do you guys need signed contracts for each and every (even single line) patch? Is it better to report the problem and how it can possibly be redone by one of the python devs? In this case that would be something like "take the linux case, and change LD_LIBRARY_PATH to LD_LIBRARYN32_PATH". I'm really in favour of getting rid of these 35 patches against Python :) -- ___ Python tracker <http://bugs.python.org/issue7718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1471934] Python libcrypt build problem on Solaris 8, 9, 10 and OpenSolaris
Changes by Fabian Groffen : Added file: http://bugs.python.org/file15920/python-2.6.2-solaris64-crypt.patch ___ Python tracker <http://bugs.python.org/issue1471934> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1471934] Python libcrypt build problem on Solaris 8, 9, 10 and OpenSolaris
Fabian Groffen added the comment: I use this patch, which just always uses crypt_i on Solaris to work around the problem. -- keywords: +patch nosy: +grobian title: Python libcrypt build problem on Solaris 8 -> Python libcrypt build problem on Solaris 8, 9, 10 and OpenSolaris versions: +Python 2.7 Added file: http://bugs.python.org/file15919/python-2.7-solaris64-crypt.patch ___ Python tracker <http://bugs.python.org/issue1471934> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7719] distutils: ignore .nfsXXXX files
New submission from Fabian Groffen : NFS on certain platforms (most notably AIX, Solaris) use .nfsX files that appear and disappear automagically. distutils can get confused by that once a .nfsX file was earlier seen with listdir and then removed by the OS before its copied. Simply ignore .nfsX files as workaround. -- assignee: tarek components: Distutils files: python-2.5.1-distutils-aixnfs.patch keywords: patch messages: 97898 nosy: grobian, tarek severity: normal status: open title: distutils: ignore .nfs files type: behavior versions: Python 2.5, Python 2.6, Python 2.7 Added file: http://bugs.python.org/file15918/python-2.5.1-distutils-aixnfs.patch ___ Python tracker <http://bugs.python.org/issue7719> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7718] Build shared libpythonX.Y.so on IRIX
New submission from Fabian Groffen : Create a libpythonX.Y.so library on IRIX. Patch on behalf of Stuart Shelton. -- components: Build files: python-2.6-irix-libpython2.6.patch keywords: patch messages: 97897 nosy: grobian severity: normal status: open title: Build shared libpythonX.Y.so on IRIX versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file15917/python-2.6-irix-libpython2.6.patch ___ Python tracker <http://bugs.python.org/issue7718> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7717] Compilation fixes for IRIX
Changes by Fabian Groffen : Added file: http://bugs.python.org/file15916/python-2.6.4-irix.patch ___ Python tracker <http://bugs.python.org/issue7717> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7717] Compilation fixes for IRIX
New submission from Fabian Groffen : Patches to fix compilation issues on IRIX, on behalf of Frank Everdij and Stuart Shelton. -- components: Build files: python-2.7-irix.patch keywords: patch messages: 97896 nosy: grobian severity: normal status: open title: Compilation fixes for IRIX versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file15915/python-2.7-irix.patch ___ Python tracker <http://bugs.python.org/issue7717> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7716] IPv6 detection, don't assume existence of /usr/xpg4/bin/grep
New submission from Fabian Groffen : The solaris case implementation of the ipv6 check assumes /usr/xpg4/bin/grep is available. This gives error messages on e.g. IRIX where /etc/netconfig is available, but no /usr/xpg4/bin/grep. This is simply fixed by using $GREP which is set by configure, and will be set to /usr/xpkg4/bin/grep if no suitable grep was found in the path. Attached patch incorporates this change. -- files: python-2.5.1-no-hardcoded-grep.patch keywords: patch messages: 97892 nosy: grobian severity: normal status: open title: IPv6 detection, don't assume existence of /usr/xpg4/bin/grep versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file15913/python-2.5.1-no-hardcoded-grep.patch ___ Python tracker <http://bugs.python.org/issue7716> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7715] Allow use of GNU arch on Darwin
New submission from Fabian Groffen : Configure will die on Darwin with the message Unexpected output of 'arch' on OSX when GNU arch is in use. The following patch simply adds the output as given by GNU arch to allow a successful configure run. -- components: Build files: python-2.6.4-gnu-arch-darwin.patch keywords: patch messages: 97884 nosy: grobian severity: normal status: open title: Allow use of GNU arch on Darwin type: behavior versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file15912/python-2.6.4-gnu-arch-darwin.patch ___ Python tracker <http://bugs.python.org/issue7715> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7714] configure GCC version detection fix for Darwin
New submission from Fabian Groffen : configure.in contains a check for the compiler in use for Darwin like this: gcc_version=`gcc -v 2>&1 | grep version | cut -d\ -f3` This yields in a wrong answer if the output of gcc -v has "version" in another place as well, such as when --enable-version-specific-runtime-libs is enabled. A better way to retrieve the compiler version is to use GCC's -dumpversion argument, which works with Apple's GCC 3.3, 4.0.1 and 4.2.1 and doesn't need additional grepping/cutting, etc. The attached patch uses -dumpversion to retrieve the GCC version, which allows a successful configure run. -- components: Build files: python-2.5.1-darwin-gcc-version.patch keywords: patch messages: 97883 nosy: grobian severity: normal status: open title: configure GCC version detection fix for Darwin type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file15911/python-2.5.1-darwin-gcc-version.patch ___ Python tracker <http://bugs.python.org/issue7714> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7713] implement ability to disable automatic search path additions
New submission from Fabian Groffen : setup.py adds in various places hardcoded paths to locations in the filesystem that may contain libraries/includes to compile a given module or feature. While this behaviour is probably interesting for some users, it is undesirable for distributions that use a package manager to track and install dependencies in a given offset on top of a host system such as Mac OS X, Solaris, AIX, HPUX, etc. Examples are: http://trac.macports.org/browser/trunk/dports/lang/python26/files/patch-setup.py.diff http://www.mail-archive.com/openpkg-...@openpkg.org/msg09547.html http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/dev-lang/python/files/python-2.5.1-no-usrlocal.patch It would be great if there was a way to disable setup.py from looking for hardcoded paths, and instead completely rely on the behaviour of compiler and linker (or e.g. CFLAGS as given) -- components: Build messages: 97880 nosy: grobian severity: normal status: open title: implement ability to disable automatic search path additions type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue7713> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
