[issue4476] compileall fails if current dir has a "types" package
Change by Felipe Rodrigues : -- pull_requests: -26023 ___ Python tracker <https://bugs.python.org/issue4476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4476] compileall fails if current dir has a "types" package
Felipe Rodrigues added the comment: sorry about the noise, everyone. Missed an '6' in the end of the issue name -- ___ Python tracker <https://bugs.python.org/issue4476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44766] [easy doc] Remove redundant info in README.valgrind
Change by Felipe Rodrigues : -- keywords: +patch nosy: +fbidu nosy_count: 2.0 -> 3.0 pull_requests: +26026 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27509 ___ Python tracker <https://bugs.python.org/issue44766> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4476] compileall fails if current dir has a "types" package
Change by Felipe Rodrigues : -- nosy: +fbidu nosy_count: 5.0 -> 6.0 pull_requests: +26023 pull_request: https://github.com/python/cpython/pull/27509 ___ Python tracker <https://bugs.python.org/issue4476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44539] Imghdr JPG Quantized
Change by Felipe Rodrigues : -- nosy: +fbidu ___ Python tracker <https://bugs.python.org/issue44539> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37195] test_utime fails on MacOS Mojave (Kernel Version 18.6.0:)
Felipe Rodrigues added the comment: Hi all! I'm seeing the same error that @pablogsal saw here, but I'm on Linux Mint 20.1 x86_64 (Kernel 5.4.0-77): ./python -m test test_os -R : -v == CPython 3.11.0a0 (heads/pr_26964:d375c08c75, Jul 3 2021, 07:47:01) [GCC 9.3.0] == Linux-5.4.0-77-generic-x86_64-with-glibc2.31 little-endian == cwd: /home/fbidu/collab/cpython/build/test_python_276759æ == CPU count: 8 == encodings: locale=UTF-8, FS=utf-8 0:00:00 load avg: 0.71 Run tests sequentially 0:00:00 load avg: 0.71 [1/1] test_os (...) == FAIL: test_utime (test.test_os.UtimeTests) -- Traceback (most recent call last): File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 797, in test_utime self._test_utime(set_time) File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 785, in _test_utime self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6) AssertionError: 1.0 != 1.002003 within 1e-06 delta (0.0020029977 difference) == FAIL: test_utime_by_indexed (test.test_os.UtimeTests) -- Traceback (most recent call last): File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 815, in test_utime_by_indexed self._test_utime(set_time) File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 785, in _test_utime self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6) AssertionError: 1.0 != 1.002003 within 1e-06 delta (0.0020029977 difference) == FAIL: test_utime_by_times (test.test_os.UtimeTests) -- Traceback (most recent call last): File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 824, in test_utime_by_times self._test_utime(set_time) File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 785, in _test_utime self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6) AssertionError: 1.0 != 1.002003 within 1e-06 delta (0.0020029977 difference) == FAIL: test_utime_dir_fd (test.test_os.UtimeTests) -- Traceback (most recent call last): File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 857, in test_utime_dir_fd self._test_utime(set_time) File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 785, in _test_utime self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6) AssertionError: 1.0 != 1.002003 within 1e-06 delta (0.0020029977 difference) == FAIL: test_utime_directory (test.test_os.UtimeTests) -- Traceback (most recent call last): File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 863, in test_utime_directory self._test_utime(set_time, filename=self.dirname) File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 785, in _test_utime self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6) AssertionError: 1.0 != 1.002003 within 1e-06 delta (0.0020029977 difference) == FAIL: test_utime_fd (test.test_os.UtimeTests) -- Traceback (most recent call last): File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 844, in test_utime_fd self._test_utime(set_time) File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 785, in _test_utime self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6) AssertionError: 1.0 != 1.002003 within 1e-06 delta (0.0020029977 difference) == FAIL: test_utime_nofollow_symlinks (test.test_os.UtimeTests) -- Traceback (most recent call last): File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 834, in test_utime_nofollow_symlinks self._test_utime(set_time) File "/home/fbidu/collab/cpython/Lib/test/test_os.py", line 785, in _test_utime self.assertAlmostEqual(st.st_atime, atime_ns * 1e-9, delta=1e-6) AssertionError: 1.0 != 1.002003 within 1e-06 delta (0.0020029977 difference) -- Ran 314 tests in 1.172s FAILED (failures=7, skipped=46) Additional info based on what a
[issue42914] pprint numbers with underscore
Felipe added the comment: All yours! I'm tied up so won't be able to submit the PR On Thu, 25 Feb 2021 at 10:12, Stéphane Blondon wrote: > > Stéphane Blondon added the comment: > > I add the same idea but later than you, so I'm interested by such feature. > > Felipe: do you want to add a pull request to this issue (with Serhiy > Storchaka implementation because it's the simplest one)? > > If not, I plan to write it. > I will write it too if there is no reply in one month. > > -- > nosy: +sblondon > > ___ > Python tracker > <https://bugs.python.org/issue42914> > ___ > -- ___ Python tracker <https://bugs.python.org/issue42914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43019] wait_for(to_thread)) does not work as expected. Extra documentation or fix needed.
New submission from Felipe Faria :
Consider the following:
```
import asyncio
import time
async def async_test():
while True:
await asyncio.sleep(1)
print("in here - async")
def sync_test():
while True:
time.sleep(1)
print("in here - sync")
async def main():
async def tryexcept(func):
try:
await func
except asyncio.exceptions.TimeoutError:
print("error thrown")
await tryexcept(asyncio.wait_for(async_test(), timeout=5))
await tryexcept(asyncio.wait_for(asyncio.to_thread(sync_test), timeout=5))
print("back in the main thread")
asyncio.run(main())
```
The above will lead to:
```
in here - async
error thrown
in here - sync
error thrown
back in the main thread
in here - sync
in here - sync
in here - sync
[... continues on forever ...]
```
It seems that the new thread created by `to_thread` is never cancelled and
continues running forever despite the timeout error thrown. This might lead to
some unwarranted (and hidden) behavior depending on the application.
Frankly, I'm unsure if a possible bug fix is even viable as from my knowledge
cancelling threads in Python is not recommended. However, if not, I think a
documentation update would be helpful.
On my end messing with an existing sync library + `to_thread` + `wait_for` led
me to believe that the execution had been cancelled, when instead it kept on
shooting unexpected web requests.
Thank you.
--
components: asyncio
messages: 385602
nosy: asvetlov, felipefaria, yselivanov
priority: normal
severity: normal
status: open
title: wait_for(to_thread)) does not work as expected. Extra documentation or
fix needed.
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue43019>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42914] pprint numbers with underscore
Felipe added the comment:
Here is an implementation of the safe repr for numbers if helpful:
```
def safe_repr_int(object):
sign = ''
if object < 0:
sign = '-'
object = -object
r = repr(object)
if len(r) <= 4:
return sign + r
parts = [sign]
left = len(r) % 3
if left:
parts.append(r[0:left])
parts.append('_')
r = r[left:]
parts.append(r[0:3])
for i in range(3, len(r), 3):
parts.append('_')
parts.append(r[i:i + 3])
return ''.join(parts)
```
--
___
Python tracker
<https://bugs.python.org/issue42914>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42914] pprint numbers with underscore
New submission from Felipe : It would be nice if pprint learned to insert underscores in long numbers Current behavior: >>> pprint.pprint(int(1e9)) 10 Desired behavior >>> pprint.pprint(int(1e9)) 1_000_000_000 Wikipedia tells me that "groups of 3" is the international standard to be followed here [1][2] [1] https://en.wikipedia.org/wiki/ISO_31-0#Numbers [2] https://en.wikipedia.org/wiki/Decimal_separator#Digit_grouping -- components: Library (Lib) messages: 384982 nosy: fov priority: normal severity: normal status: open title: pprint numbers with underscore type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21032] Socket leak if HTTPConnection.getresponse() fails
Change by Felipe Rodrigues : -- nosy: +fbidu nosy_count: 3.0 -> 4.0 pull_requests: +21848 pull_request: https://github.com/python/cpython/pull/22737 ___ Python tracker <https://bugs.python.org/issue21032> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13464] HTTPResponse is missing an implementation of readinto
Change by Felipe Rodrigues : -- nosy: +fbidu nosy_count: 5.0 -> 6.0 pull_requests: +21847 pull_request: https://github.com/python/cpython/pull/22737 ___ Python tracker <https://bugs.python.org/issue13464> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42062] Usage of HTTPResponse.url
Change by Felipe Rodrigues : -- keywords: +patch pull_requests: +21701 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22738 ___ Python tracker <https://bugs.python.org/issue42062> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42062] Usage of HTTPResponse.url
New submission from Felipe Rodrigues :
Hello all,
While testing some static analysis tools on HTTP/client.py, Pylint pointed
me to HTTPResponse.geturl() method with a "no-member" error for the `url`
attribute. I tried invoking the `geturl` method and reading the
`HTTPResponse.url` attribute using a sample code from the official docs:
```
import http.client
conn = http.client.HTTPSConnection("www.python.org")
conn.request("GET", "/")
r1 = conn.getresponse()
print(r1.status, r1.reason)
r1.geturl()
r1.url
```
```
import http.client
conn = http.client.HTTPSConnection("www.python.org")
conn.request("GET", "/")
r1 = conn.getresponse()
data1 = r1.read()
conn.request("GET", "/")
r1 = conn.getresponse()
while chunk := r1.read(200):
print(repr(chunk))
r1.geturl()
r1.url
```
Both of those examples will raise an `AttributeError: 'HTTPResponse' object has
no attribute 'url'`.
I tried searching through this module's history from when this line originally
appeared,
https://github.com/python/cpython/commit/6c5e28c383bf587f80d01e52f887801be200200d
but
I wasn't able to find this attribute being set internally by the class, even
though there is an `url` attribute at __init__.
So, I wonder if this attribute was intended to be set externally as in `r1.url
= 'something'`
or if it is just a bug
--
components: Library (Lib)
messages: 378814
nosy: fbidu
priority: normal
severity: normal
status: open
title: Usage of HTTPResponse.url
___
Python tracker
<https://bugs.python.org/issue42062>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42060] Usage of assert in http/client.py
Change by Felipe Rodrigues : -- keywords: +patch pull_requests: +21700 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22737 ___ Python tracker <https://bugs.python.org/issue42060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42060] Usage of assert in http/client.py
New submission from Felipe Rodrigues : Hi all! I was testing some static analysis tool and decided to use the HTTP module as testing ground. While running `bandit` at the client module, it detected 3 instances of using `assert` inside the code. Twice in the HTTPResponse class and once in the HTTPConnection class. Now, I know that this will only cause any trouble when running python with the optimize settings turned on and if someone is that concerned about optimization, they probably won't be using the stdlib's HTTP implementation, but I think it would be fitting to fix this corner case. I've written a PR that fixes this but I'm not sure if the raised exceptions and messages are ok -- components: Library (Lib) messages: 378810 nosy: fbidu priority: normal severity: normal status: open title: Usage of assert in http/client.py versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37943] mimetypes.guess_extension() doesn’t get JPG right
Felipe Rodrigues added the comment:
@_savage, on the commit @xtreak referred, there's a note that "image/jpg" and
some other non-standard mimetypes are only supported if `strict=False`[1]
So, this:
>>> mimetypes.guess_extension("image/jpg")
Gives no return. But this works:
>>> mimetypes.guess_extension("image/jpg", strict=False)
'.jpg'
-
I guess we could improve the current documentation [2]. It currently specifies
correctly the `strict` behavior:
> The optional strict argument is a flag specifying whether the list of known
> MIME types is limited to
> only the official types registered with IANA. When strict is True (the
> default), only the IANA types
> are supported; when strict is False, some additional non-standard but
> commonly used MIME types are
> also recognized.
But I think it would be nice to have a table specifying what are those
"non-standard but commonly used MIME types". Personally, I'd have a hard time
guessing on a regular day of my life which of 'image/jpeg' and 'image/jpg' is
standard or not. We could even add a nice note pointing out that the
`common_types` property [3] is a list of those supported non-standard type .
Given the fact that the `strict` flag is used by different methods with the
same behavior, maybe we could add a note on the top of the doc explaining the
general meaning of that flag.
[1]:
https://github.com/python/cpython/commit/2a99fd911ebeecedbb250a05667cd46eca4735b9#diff-fc65388a9cdf41980b2c31de5de67758R547
[2]: https://docs.python.org/3.10/library/mimetypes.html#mimetypes.guess_type
[3]: https://docs.python.org/3.10/library/mimetypes.html#mimetypes.common_types
--
nosy: +fbidu
___
Python tracker
<https://bugs.python.org/issue37943>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41220] add optional make_key argument to lru_cache
Felipe Rodrigues added the comment: Correction: (...) on the _caller_ to solve the hashing* issue (...) -- ___ Python tracker <https://bugs.python.org/issue41220> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41220] add optional make_key argument to lru_cache
Felipe Rodrigues added the comment: Hello all, I love discussions about caching! While I do see the point of Itayazolay's proposal, I think that it should be on the _caller_ to solve the caching issue, and not on the _callee_ to provide a way to make it happen. That is, I think that if one wants to use a cache, they should make sure their arguments are hashable and not that we should modify called functions to provide workarounds for those. -- nosy: +fbidu ___ Python tracker <https://bugs.python.org/issue41220> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35919] multiprocessing: shared manager Pool fails with AttributeError
Change by Felipe A. Hernandez : -- components: +Library (Lib) type: -> behavior versions: +Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue35919> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35919] multiprocessing: shared manager Pool fails with AttributeError
Felipe A. Hernandez added the comment:
import traceback
import multiprocessing.managers
class MyManager(multiprocessing.managers.SyncManager):
pass
class DictList(multiprocessing.managers.BaseProxy):
_method_to_typeid_ = {'__getitem__': 'dict'}
def __getitem__(self, key):
return self._callmethod('__getitem__', (key,))
MyManager.register('DictList', None, DictList)
with MyManager() as manager:
nested = manager.DictList([{'hello': 'world'}])
print(nested[0]['hello']) # world
proxy = manager.list([nested])
try:
print(proxy[0][0]['hello'])
except AttributeError:
traceback.print_exc()
print("""
Bug: AttributeError: ProxyBase._callmethod is None
--
This error is raised because proxies returned as #RETURN messages
have no manager reference, which is required to resolve typeids
(using BaseManager._registry).
Only proxies returned as #PROXY messages will be fully functional.
This is an undocumented current implementation limitation.
Fix (proposal)
--
Include the manager class (not the instance) as part of the proxy
serialization in BaseProxy.__reduce__, as BaseManager._registry is
a class variable.
Note: #PROXY message protocol can be also replaced by regular proxy
serialization after this fix, resulting on simpler codebase.
""")
--
nosy: +Felipe A. Hernandez
___
Python tracker
<https://bugs.python.org/issue35919>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40042] Enum Flag: psuedo-members have None for name attribute
New submission from Felipe Rodrigues : Hi, Can you elaborate on this? Thanks! -- nosy: +fbidu ___ Python tracker <https://bugs.python.org/issue40042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39246] shutil.rmtree is inefficient because of using os.scandir instead of os.walk
Felipe A. Hernandez added the comment: After some tests, due the accumulating nature of fwalk, I've just realised it's not very safe for big directories, so I'll be closing this issue. Alternatively, using py37+ fd based scandir, and dir_fd unlink and rmdir calls would reduce complexity while improving safety. Sorry for the noise. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39246] shutil.rmtree is inefficient because of using os.scandir instead of os.walk
New submission from Felipe A. Hernandez : os.rmtree has fd-based symlink replacement protection when iterating with scandir (after bpo-28564). This logic could be greatly simplified simply by os.fwalk in supported platforms, which already implements a similar (maybe safer) protection. -- components: Library (Lib) messages: 359512 nosy: Felipe A. Hernandez priority: normal severity: normal status: open title: shutil.rmtree is inefficient because of using os.scandir instead of os.walk versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38619] [Doc] UUID.hex is lowercase
New submission from Felipe : The hex property of `UUID` is implemented as `'%032x' % self.int` Is it specified that this will always be lowercase? If so, can we add a note to the documentation indicating so? -- assignee: docs@python components: Documentation, Library (Lib) messages: 33 nosy: docs@python, fov priority: normal severity: normal status: open title: [Doc] UUID.hex is lowercase type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38619> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19953] __iadd__() doc not strictly correct
Change by Felipe Manzano : -- pull_requests: +11750, 11751 ___ Python tracker <https://bugs.python.org/issue19953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19953] __iadd__() doc not strictly correct
Change by Felipe Manzano : -- pull_requests: +11750 ___ Python tracker <https://bugs.python.org/issue19953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19953] __iadd__() doc not strictly correct
Change by Felipe Manzano : -- pull_requests: +11750, 11751, 11752 ___ Python tracker <https://bugs.python.org/issue19953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23078] unittest.mock patch autospec doesn't work on staticmethods
Felipe added the comment: Please go ahead with the PR. I can't push this one through, but would be great to have this finally land! On Thu, 17 Jan 2019 at 03:42, Karthikeyan Singaravelan < rep...@bugs.python.org> wrote: > > Karthikeyan Singaravelan added the comment: > > @berker.peksag I have converted the patch at > https://bugs.python.org/file40470/issue23078.patch and pushed it to a > GitHub branch > https://github.com/python/cpython/compare/master...tirkarthi:bpo23078 . I > am willing to open a PR attributing to @fov in case you haven't had the > time to look into this. > > I am removing 3.6 since it's security fixes only mode. > > Thanks > > -- > nosy: +cjw296, mariocj89, xtreak > versions: -Python 3.6 > > ___ > Python tracker > <https://bugs.python.org/issue23078> > ___ > -- ___ Python tracker <https://bugs.python.org/issue23078> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25416] Add encoding aliases from the (HTML5) Encoding Standard
Felipe Rodrigues added the comment: Ezio, I have issued a simple PR that adds just the two aliases cited in the issue's initial message. I would like to implement tests but as I wrote in the PR's message, I'm not really sure how to proceed with that. bpo-18624 is really related to this issue and in there is a reference to a test_codecs.py file that I did not find. If you could give me a few pointer on how to proceed, I'll be glad to improve my PR, add tests and even add all the other aliases that are missing. -- ___ Python tracker <https://bugs.python.org/issue25416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19376] document that strptime() does not support the Feb 29 if the format does not contain the year
Felipe Rodrigues added the comment: What about adding some more information in the exception message in addition to the docs? I mean, if we're raising an issue because someone inserted Feb 29, we add a note about leap year in the exception message -- nosy: +fbidu ___ Python tracker <https://bugs.python.org/issue19376> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18624] Add alias for iso-8859-8-i which is the same as iso-8859-8
Change by Felipe Rodrigues : -- pull_requests: +9550 ___ Python tracker <https://bugs.python.org/issue18624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25416] Add encoding aliases from the (HTML5) Encoding Standard
Change by Felipe Rodrigues : -- keywords: +patch pull_requests: +9549 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue25416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26005] Denial of Service in SimpleHTTPServer and BaseHTTPServer
Change by Felipe Rodrigues : -- pull_requests: +9104 ___ Python tracker <https://bugs.python.org/issue26005> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34576] [EASY doc] http.server, SimpleHTTPServer: warn users on security
Change by Felipe Rodrigues : -- keywords: +patch pull_requests: +9103 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34832] "Short circuiting" in base64's b64decode, decode, decodebytes
Felipe Rodrigues added the comment:
For reference in future discussions, Python's base64 module implements RFC 3548
(https://tools.ietf.org/html/rfc3548) whose section 2.3
(https://tools.ietf.org/html/rfc3548#section-2.3) discusses about
"Interpretation of non-alphabet characters in encoded data".
The section's content is:
Base encodings use a specific, reduced, alphabet to encode binary
data. Non alphabet characters could exist within base encoded data,
caused by data corruption or by design. Non alphabet characters may
be exploited as a "covert channel", where non-protocol data can be
sent for nefarious purposes. Non alphabet characters might also be
sent in order to exploit implementation errors leading to, e.g.,
buffer overflow attacks.
Implementations MUST reject the encoding if it contains characters
outside the base alphabet when interpreting base encoded data, unless
the specification referring to this document explicitly states
otherwise. Such specifications may, as MIME does, instead state that
characters outside the base encoding alphabet should simply be
ignored when interpreting data ("be liberal in what you accept").
Note that this means that any CRLF constitute "non alphabet
characters" and are ignored. Furthermore, such specifications may
consider the pad character, "=", as not part of the base alphabet
until the end of the string. If more than the allowed number of pad
characters are found at the end of the string, e.g., a base 64 string
terminated with "===", the excess pad characters could be ignored.
In my opinion, the RFC is rather permissive about strange characters in the
encoded data. The RFC refers to the MIME specification that ignores the data
and hints the possibility of rejecting the pad symbol '=' unless it is found in
the end of the string.
I think that our best option if we would like to address this issue is to add
an 'errors' argument whose default value will keep the current behavior for
backwards compatibility but will accept more options in order to both ignore
the strange characters and carry on with the processing - like bytes.decode's
errors=ignore flag - and to raise an error in such situations, like
bytes.decode's errors=strict.
--
___
Python tracker
<https://bugs.python.org/issue34832>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34832] "Short circuiting" in base64's b64decode, decode, decodebytes
Felipe Rodrigues added the comment: Actually, I'm not even sure if it makes sense to decode the 'first valid substring'... IMHO, we should warn the user -- ___ Python tracker <https://bugs.python.org/issue34832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34832] "Short circuiting" in base64's b64decode, decode, decodebytes
Felipe Rodrigues added the comment: I am not sure if simply ignoring the non-valid character is the best way to go. Feels like silencing errors. b64decode does accept the 'validate' flag - defaulted to False - that will halt the execution and throw an error. What might be a good idea is to implement an 'errors' argument that accepts 'ignore' as a value, like we do for bytes.decode (https://docs.python.org/3/library/stdtypes.html#bytes.decode) -- nosy: +fbidu ___ Python tracker <https://bugs.python.org/issue34832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34576] [EASY doc] http.server, SimpleHTTPServer: warn users on security
Felipe Rodrigues added the comment: Well, even if we do fix some security issues in SimpleHTTPServer, it doesn't change the fact that it shouldn't really be used for sensitive applications. I like how Django docs handles a similar issue regarding their development server (https://docs.djangoproject.com/en/2.1/ref/django-admin/#runserver) > DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through > security audits or performance tests. (And that’s how it’s gonna stay. We’re > in the business of making Web frameworks, not Web servers, so improving this > server to be able to handle a production environment is outside the scope of > Django.) I think that the same philosophy applies to SimpleHTTPServer. If the warning should be add to the docs, I'll be glad to issue an PR fixing it! -- nosy: +fbidu ___ Python tracker <https://bugs.python.org/issue34576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34728] deprecate *loop* argument for asyncio.sleep
Change by Felipe Rodrigues : -- nosy: +fbidu ___ Python tracker <https://bugs.python.org/issue34728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32432] [BUG] Python vs Macbook High Sierra 10.13.2
Felipe Filgueira Barral added the comment: Tks Ronald, solve the problem! =) -- ___ Python tracker <https://bugs.python.org/issue32432> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32432] [BUG] Python vs Macbook High Sierra 10.13.2
Change by Felipe Filgueira Barral : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue32432> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32432] [BUG] Python vs Macbook High Sierra 10.13.2
New submission from Felipe Filgueira Barral : When i open the IDLE and try include ' or " in any script, the python closes alone! Does anyone know what might be happening? I use mac, version high sierra... Process: Python [1048] Path: /Applications/Python 3.6/IDLE.app/Contents/MacOS/Python Identifier: org.python.IDLE Version: 3.6.4 (3.6.4) Code Type: X86 (Native) Parent Process: ??? [1] Responsible: Python [1048] User ID: 501 Date/Time: 2017-12-27 14:12:58.552 -0200 OS Version: Mac OS X 10.13.2 (17C88) Report Version: 12 Anonymous UUID: 0681CD4F-4E3E-670B-B04B-6F062C271803 Time Awake Since Boot: 3800 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0001, 0x Exception Note: EXC_CORPSE_NOTIFY Termination Signal: Illegal instruction: 4 Termination Reason: Namespace SIGNAL, Code 0x4 Terminating Process: exc handler [0] Application Specific Information: *** Terminating app due to uncaught exception 'NSRangeException', reason: '-[__NSCFConstantString characterAtIndex:]: Range or index out of bounds' Application Specific Backtrace 1: 0 CoreFoundation 0x93a5f0e2 __raiseError + 178 1 libobjc.A.dylib 0xa6aaa346 objc_exception_throw + 273 2 CoreFoundation 0x93a5f005 +[NSException raise:format:] + 101 3 CoreFoundation 0x9394de6d -[__NSCFString characterAtIndex:] + 93 4 Tk 0x9d5c486a TkpInitKeymapInfo + 609 5 Tk 0x9d5c0cb7 TkpRedirectKeyEvent + 1098 6 Tk 0x9d5ca1f6 Tk_MacOSXSetupTkNotifier + 744 7 Tcl 0x9d4ca37e Tcl_DoOneEvent + 269 8 _tkinter.cpython-36m-darwin.so 0x003ee679 _tkinter_tkapp_mainloop + 233 9 Python 0x0006c566 _PyCFunction_FastCallDict + 582 10 Python 0x000f5e75 call_function + 629 11 Python 0x000fbd89 _PyEval_EvalFrameDefault + 23241 12 Python 0x000f51bf _PyEval_EvalCodeWithName + 2367 13 Python 0x000f59f9 fast_function + 249 14 Python 0x000f5e50 call_function + 592 15 Python 0x000fbd89 _PyEval_EvalFrameDefault + 23241 16 Python 0x000f51bf _PyEval_EvalCodeWithName + 2367 17 Python 0x000f59f9 fast_function + 249 18 Python 0x000f5e50 call_function + 592 19 Python 0x000fbd89 _PyEval_EvalFrameDefault + 23241 20 Python 0x000f51bf _PyEval_EvalCodeWithName + 2367 21 Python 0x000f5383 PyEval_EvalCode + 115 22 Python 0x0013090e PyRun_FileExFlags + 206 23 Python 0x00130c39 PyRun_SimpleFileExFlags + 505 24 Python 0x0014b3fb Py_Main + 4139 25 Python 0x1e62 main + 498 26 Python 0x1c65 start + 53 27 ??? 0x0002 0x0 + 2 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.CoreFoundation 0x93a5f3e3 TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION + 3 1 com.apple.CoreFoundation 0x93a5f381 __raiseError + 849 2 libobjc.A.dylib 0xa6aaa346 objc_exception_throw + 273 3 com.apple.CoreFoundation 0x93a5f005 +[NSException raise:format:] + 101 4 com.apple.CoreFoundation 0x9394de6d -[__NSCFString characterAtIndex:] + 93 5 Tk 0x9d5c486a 0x9d518000 + 70 6 Tk 0x9d5c0cb7 0x9d518000 + 691383 7 Tk 0x9d5ca1f6 0x9d518000 + 729590 8 Tcl 0x9d4ca37e Tcl_DoOneEvent + 269 9 _tkinter.cpython-36m-darwin.so0x003ee679 _tkinter_tkapp_mainloop + 233 10 org.python.python 0x0006c566 _PyCFunction_FastCallDict + 582 11 org.python.python 0x000f5e75 call_function + 629 12 org.python.python 0x000fbd89 _PyEval_EvalFrameDefault + 23241 13 org.python.python 0x000f51bf _PyEval_EvalCodeWithName + 2367 14 org.python.python 0x000f59f9 fast_function + 249 15 org.python.python 0x000f5e50 call_function + 592 16 org.python.python 0x000fbd89 _PyEval_EvalFrameDefault + 23241 17 org.python.python 0x000f51bf _PyEval_EvalCodeWithName + 2367 18 org.python.python 0x000f59f9 fast_function + 249 19 org.python.python 0x000f5e50 call_function + 592 20 org.python.python 0x000fbd89 _PyEval_EvalFrameDefault + 23241 21 org.python.python 0x000f51bf _PyEval_EvalCodeWithName + 2367 22 org.python.python 0x000f5383 PyEval_EvalCode + 115 23 org.python.python 0x0013090e PyRun_FileExFlags + 206 24 org.python.python 0x00130c39 PyRun_SimpleFileExFlags + 505 25 org.python.python 0x0014b3fb Py_Main + 4139 26 Python 0x1e62 main + 498 27 Python 0x1c65 start + 53 Thread 1: 0 libsystem_kernel.dylib 0xa76ad6ee __workq_kernreturn + 10 1 libsystem_pthread.dylib 0xa77dae70 _pthread_wqthread + 992 2 libsystem_pthread.dylib 0xa77daa6a start_wqthread + 34 Thread 2: 0 libsystem_kernel.dylib 0xa76ad6ee __workq_kernreturn + 10 1 libsystem_pthread.dylib 0xa77db090 _pthread_wqthread + 1536 2 libsystem_pthread.dylib 0xa77daa6a start_wqthread + 34 Thread 3: 0 libsystem_kernel.dylib 0xa76ad07e __select + 10 1 Tcl 0x9d4fa09e 0x9d454000 + 680094 2 libsystem_pthread.dylib 0xa77db50d _pthread_body + 347 3 libsystem_pthread.dylib 0xa77db3b2 _pthread_start + 357 4 libsystem_pthread.dylib 0xa77daa8e thread_start + 34 Thread 4:: com.apple.NSEventThread 0 libsystem_kernel.dylib 0xa76a3742 mach_msg_trap + 10 1 libsystem_kernel.dylib 0xa76a2d7f mach_msg + 47 2 com.apple.CoreFoundation 0x9394d
[issue25144] 3.5 Win install fails with "TARGETDIR"
Change by Felipe : -- nosy: -fov ___ Python tracker <https://bugs.python.org/issue25144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31533] Dead link in SSLContext.set_ciphers documentation
Felipe added the comment: Sure, will do! -- ___ Python tracker <https://bugs.python.org/issue31533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31533] Dead link in SSLContext.set_ciphers documentation
Felipe added the comment: Woops. Apologies -- I somehow deleted that part from the report. Thanks Antoine for jumping in. If you are using the wiki url, make sure not to include the question mark at the end :-) -- ___ Python tracker <https://bugs.python.org/issue31533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31533] Dead link in SSLContext.set_ciphers documentation
New submission from Felipe: The link to the `OpenSSL cipher list format` 404s. I don't know if it's where the original meant to point, but the same information is available at https://wiki.openssl.org/index.php/Manual:Ciphers(1)#CIPHER_LIST_FORMAT -- assignee: docs@python components: Documentation messages: 302629 nosy: docs@python, fov priority: normal severity: normal status: open title: Dead link in SSLContext.set_ciphers documentation versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue31533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25785] TimedRotatingFileHandler missing rotations
New submission from Felipe Cruz: I'm using TimedRotatingFileHandler to rotate a log file *every* minute. If I stop my program, in the middle of a minute, and start again, the next rotation will happen at (currentTime + 60). The result of this behavior is that I'll end up with files "log_01" and "log_03", instead of "log_01", "log_02" and "log_03". I'm using this class with a little modification which sets the next rollover time to (currentTime + (self.interval - currentSecond)). In this case, even If I stop and start my program in the middle a minute, the next rollover time will be the end of the current minute, not 60 seconds later and the result will be one file for each minute. To sum up, what happen is that the same program with the very same configuration, produces a different result if stopped for even just one second. If the interval was "rotate every 60 seconds" I would be ok, but If I'm configuring to rotate every minute I expect one file for each minute if the program was running the time the minutes changed. -- messages: 255757 nosy: felipecruz priority: normal severity: normal status: open title: TimedRotatingFileHandler missing rotations type: behavior versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue25785> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25432] isinstance documentation: explain behavior when type is a tuple
Felipe Volpone added the comment: r.david.murray: I liked your way. -- ___ Python tracker <http://bugs.python.org/issue25432> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25144] 3.5 Win install fails with "TARGETDIR"
Changes by Felipe : Added file: http://bugs.python.org/file40492/Python 3.5.0 (32-bit)_20150916132422.log ___ Python tracker <http://bugs.python.org/issue25144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25144] 3.5 Win install fails with "TARGETDIR"
New submission from Felipe: The 3.5 Windows installer fails with "The TARGETDIR variable must be provided when invoking this installer" Here are the steps I followed: 1. Initial screen: - uncheck the add path and all users options - select "Customize installation" 2. Optional features: - Check all boxes except "all users" 3. Advanced options - Uncheck all - Pick a different path to install to (clean folder) 4. A message box pops up saying "The TARGETDIR variable must be provided when invoking this installer" -- I hit OK. 5. Final screen showing 0x8007063 - Fatal error during installation I've saved the log file and can upload if helpful, but will have to remove personal info first -- components: Installation messages: 250857 nosy: fov priority: normal severity: normal status: open title: 3.5 Win install fails with "TARGETDIR" type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue25144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23078] unittest.mock patch autospec doesn't work on staticmethods
Felipe added the comment: The attached patch implements these changes through _callable instead. This patch also ensures that the underlying object that staticmethod and classmethod wrap is a callable object as well. -- Added file: http://bugs.python.org/file40470/issue23078.patch ___ Python tracker <http://bugs.python.org/issue23078> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24651] Mock.assert* API is in user namespace
Felipe added the comment: Not sure it's my place to comment here, but here are my 2 cents: I think Robert's proposal to have module functions is the only way to have a user-friendly and robust API, and it solves more than just the assert typo problem. (And yes, it would require moving the mock public API entirely to functions/classmethods). To me, there's an underlying fragility in mock since the current API for `Mock` is not cleanly separated from the mocked API. This issue creates the problem of the assert typos, and also creates problems with name conflicts (I've always thought the `.call_count` attribute was particularly likely to be clobbered). The only bullet-proof way I can think of to ensure such a conflict does not take place is to separate the namespaces altogether, by moving the data out of the Mock object and into a global structure. E.g., `mock.Mock` could have a class attribute (say `mock.Mock.call_log`) tracking all of the calls to all mocks, and there could be a series of classmethods to query this store. Unfortunately, this design goes seriously against the grain of OOP, but we're essentially back to Robert's proposal. A more OOP-friendly approach sacrifices the '100% clash-proof guarantee' and only provides a 'highly unlikely to clash' guarantee instead: Mangle the mock API namespace. Mock currently does this for its internal attributes (e.g., `._mock_parent`) but not for its public API (e.g., `.assert_called_once_with`). To remain user-friendly, of course we wouldn't require users to mangle names by hand, but would provide convenience functions to access these mangled attributes/methods, which puts us right back at Robert's proposal. -- nosy: +fov ___ Python tracker <http://bugs.python.org/issue24651> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23078] unittest.mock patch autospec doesn't work on staticmethods
Felipe added the comment: Regarding Claudiu's comment about `staticmethod(x)` or `classmethod(x)` not being callable, would it suffice to add a specific check of the form `(isinstance(x, (classmethod, staticmethod)) and _callable(x.__func__))`? Separately, would it be better to include the check for `staticmethod` and `classmethod` objects (with an underlying callable) inside the `_callable` function? Not sure if this would break anything, but it seems like conceptually the issue is with the definition of a callable object, not the selection of mock type to use. -- nosy: +fov ___ Python tracker <http://bugs.python.org/issue23078> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22988] No error when yielding from `finally`
Felipe added the comment: Thanks for the clarification; sorry I misread issue #14718. I agree with Ethan's point. Though I would say "Yield expressions are allowed anywhere in try ... except ... finally constructs." I'd also like to explicitly add a point about the exception-handling machinery getting frozen, but I'm not sure how to phrase it clearly and accurately. Here's an attempt (my adds in square brackets): "By suspended, we mean that all local state is retained, including the current bindings of local variables, the instruction pointer, the internal evaluation stack, [active exception handlers, and paused exceptions in finally blocks]." Another approach would be: "By suspended, we mean that all local state is retained, including the current bindings of local variables, the instruction pointer, and the internal evaluation stack. [The state of any exception-handling code is also retained when yielding from a try ... except ... finally statement.]" -- ___ Python tracker <http://bugs.python.org/issue22988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22988] No error when yielding from `finally`
New submission from Felipe: This bug report is the opposite of issue #14718. The interpreter did not raise an error when it encountered a `yield` expression inside the `finally` part of a `try/finally` statement. My system's info: Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:15:05) [MSC v.1600 32 bit (Intel)] on win32 More detail === My interpreter does not raise any errors when yielding from a `finally` block. The documentation states, "Yield expressions are allowed in the try clause of a try ... finally construct."[1] Though not explicitly stated, the suggestion is that `yield` is not allowed in the `finally` clause. Issue #14718 suggests that this interpretation is correct. Not raising an exception for `yield` inside of `finally` can cause incorrect behavior when the generator raises its own unhandled exception in the `try` block. PEP 342 says, "If the generator raises an uncaught exception, it is propagated to send()'s caller." In this case, however, the exception gets paused at the `yield` expression, instead of propagating to the caller. Here's an example that can clarify the issue: >>> def f(): # I expected this function not to compile ... try: ... raise ValueError ... finally: ... yield 1 # Execution freezes here instead of propagating the ValueError ... yield "done" ... >>> g = f() >>> g.send(None) # PEP 342 would require ValueError to be raised here 1 >>> g.send(1) Traceback (most recent call last): File "", line 1, in File "", line 3, in f2 ValueError I may be arguing over the meaning of "uncaught exception," but I expected (given that the function compiles and doesn't raise a `RuntimeError`) the `ValueError` to propagate rather than get frozen. Example 2 --- The second example is adapted from http://bugs.python.org/issue14718, where the submitter received a `RuntimeError`, but I did not: >>> def f2(): # I also expected this function not to compile ... try: ... yield 1 ... finally: ... yield 4 ... >>> g = f() # issue 14718 suggests this should raise RuntimeError >>> next(g) 1 >>> next(g) 4 >>> next(g) Traceback (most recent call last): File "", line 1, in StopIteration Possible resolution: = 1. Enforce the ban on `yield` inside a finally `clause`. It seems like this should already be happening, so I'm not sure why my version isn't performing the check. This could be a run-time check (which seems like it may already be implemented), but I think this could even be a compile-time check (by looking at the AST). 2. Clarify the documentation to make explicit the ban on the use of `yield` inside the `finally` clause, and specify what type of error it will raise (i.e., `SyntaxError` or `RuntimeError`? or something else?). I'll submit a patch for 2 if there's support for this change, and I will work on 1 if someone can point me in the right direction. I've engaged with the C source relating to the different protocols, but have never looked through the compiler/VM. Notes [1] https://docs.python.org/3.4/reference/expressions.html#yield-expressions -- components: Interpreter Core messages: 232081 nosy: fov priority: normal severity: normal status: open title: No error when yielding from `finally` type: behavior versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue22988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20768] pyconfig.h #defines macros in global namespace
Felipe Sateler added the comment: I'm sorry but I definitely don't have time or knowledge about python to propose a patch (simply removing pyconfig.h clearly doesn't work). As to the question, please clarify. I have a python module, which includes Python.h, which includes pyconfig.h. I don't include Python.h everywhere. My build system does use several HAVE_* macros. It seems as if no breakage has occurred, but this is not guaranteed. And I shouldn't need to tiptoe around other libraries feature test macros, especially when they infringe on the global namespace. -- Saludos, Felipe Sateler -- ___ Python tracker <http://bugs.python.org/issue20768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20768] pyconfig.h #defines macros in global namespace
New submission from Felipe Sateler: I reported the following in the debian bug tracker[1], and it was requested that I report it here. pyconfig.h has definitions like the following: #define HAVE_DIRENT_H 1 #define HAVE_DLFCN_H 1 These are the general form feature test macros take in practically any software project. This means that when building a python module these feature macros conflict. In the best scenario, you get a redefinition warning. In the worst scenario, the build breaks because of inconsistent #defines between the module and pyconfig.h. Please either don't include pycongfig.h from Python.h, or appropiately namespace the test macros (PYTHON_HAVE_* or something like that). [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738726 -- components: Installation messages: 212178 nosy: fsateler priority: normal severity: normal status: open title: pyconfig.h #defines macros in global namespace versions: Python 2.7, Python 3.4 ___ Python tracker <http://bugs.python.org/issue20768> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16105] Pass read only FD to signal.set_wakeup_fd
Felipe Cruz added the comment: Looks good. -- ___ Python tracker <http://bugs.python.org/issue16105> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16105] Pass read only FD to signal.set_wakeup_fd
Felipe Cruz added the comment: Looks like PyErr_WriteUnraisable can be a better choice. Exceptions at random execution points looks a little bit dirty at least for this case. -- ___ Python tracker <http://bugs.python.org/issue16105> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16853] add a Selector to the select module
Felipe Cruz added the comment:
Hi.. 2 comments related to Kqueue/OSX(16.8)
1 - In tulip/selectors.py L311 and L314 - is key.fd not fd
2 - In EventLoopTestsMixin::test_writer_callback if the writer socket isn't
non-blocking, the test hangs forever..
3 - Errors:
ERROR: testCreateSslTransport (tulip.events_test.PollEventLoopTests)
File "/Users/felipecruz/Projects/tulip3/tulip/selectors.py", line 180, in
_key_from_fd
raise RuntimeError("No key found for fd {}".format(fd))
RuntimeError: No key found for fd -2
ERROR: test_sock_client_ops (tulip.events_test.KqueueEventLoopTests)
File "/Users/felipecruz/Projects/tulip3/tulip/selectors.py", line 180, in
_key_from_fd
raise RuntimeError("No key found for fd {}".format(fd))
RuntimeError: No key found for fd 77
--
___
Python tracker
<http://bugs.python.org/issue16853>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16853] add a Selector to the select module
Felipe Cruz added the comment: Hi Antonie, What you said also makes sense to me. There is one problem(?) that _map_events() is called for every event(for Poll and EPoll) and this can make things slower (I didn't tested it). Also, does it needs to be thread-safe? -- ___ Python tracker <http://bugs.python.org/issue16853> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16853] add a Selector to the select module
Felipe Cruz added the comment: I think you have a point. Did you know about the tulip project? http://code.google.com/p/tulip/source/browse/tulip/unix_events.py#76 It has a PollsterBase class and a SelectPollster(PollsterBase) so the idea is to have a Poller(and you call poll()) but select can be used underneath. Since tulip will be merged to stdlib, maybe you can work on tulip itself. Current tulip Pollers don't return (fd, event) but I have a fork that does for Poll, EPoll, KQueue and WindowsPollster: https://bitbucket.org/felipecruz/tulip/ The selector class doesn't have this change (return fd, mask tuple) right now. -- nosy: +felipecruz ___ Python tracker <http://bugs.python.org/issue16853> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16565] Increase Py_AddPendingCall array size
Felipe Cruz added the comment: Without debug backtrace #0 sem_post () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_post.S:34 #1 0x004d456e in PyGILState_Release () #2 0x759b9cdc in notify_func_wrapper (arg=0x78c0) at ../sysdeps/pthread/aio_notify.c:45 #3 0x77bc4e9a in start_thread (arg=0x759b5700) at pthread_create.c:308 #4 0x769b64bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #5 0x in ?? () -- ___ Python tracker <http://bugs.python.org/issue16565> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16565] Increase Py_AddPendingCall array size
Felipe Cruz added the comment: Yes! 2.7.3 build with pydebug. -- ___ Python tracker <http://bugs.python.org/issue16565> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16565] Increase Py_AddPendingCall array size
Felipe Cruz added the comment: Running test_aio_read [New Thread 0x77ff7700 (LWP 20681)] [New Thread 0x761ff700 (LWP 20682)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x761ff700 (LWP 20682)] sem_post () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_post.S:34 34 ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_post.S: No such file or directory. (gdb) backtrace #0 sem_post () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_post.S:34 #1 0x0051b053 in PyThread_release_lock (lock=0x0) at Python/thread_pthread.h:346 #2 0x004c868f in PyEval_ReleaseLock () at Python/ceval.c:265 #3 0x00501974 in PyThreadState_DeleteCurrent () at Python/pystate.c:321 #4 0x00502116 in PyGILState_Release (oldstate=PyGILState_UNLOCKED) at Python/pystate.c:652 #5 0x7660ed44 in aio_completion_handler (sigval=...) at pyaio/core.c:26 #6 0x76409cdc in notify_func_wrapper (arg=0x78c0) at ../sysdeps/pthread/aio_notify.c:45 #7 0x77bc4e9a in start_thread (arg=0x761ff700) at pthread_create.c:308 #8 0x771f14bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #9 0x in ?? () -- ___ Python tracker <http://bugs.python.org/issue16565> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16565] Increase Py_AddPendingCall array size
Felipe Cruz added the comment: Just confirmed that signals is not a viable option. Is too slow, as Antonie already pointed. It's almost 5 times slower than with SIGEV_THREAD. The problem now is: If I use Py_AddPendingCall, the tests can hang sometimes. I can still follow Amaury suggestion tough. If I try to acquire the GIL PyGILState_Ensure() call PyObject_CallObject and release the GIL in the aio_completion_handler function a SEGFAULT occurs in 2.7.3 but not in 3.3 and newer.. This branch works only on 3.3 and newer: https://github.com/felipecruz/pyaio/tree/feature/check_no_pending_call This other branch will segfault 2.7.3 with just acquire and release GIL on the completion handler: https://github.com/felipecruz/pyaio/tree/feature/py27_gil_error Since this looks very strange, can someone confirm this behavior? Tested on a Ubuntu12 64. -- ___ Python tracker <http://bugs.python.org/issue16565> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16565] Increase Py_AddPendingCall array size
New submission from Felipe Cruz: Current pending calls limit is too small and it can be easily reached in very intensive async file io applications. There is a little hack in pyaio[1] which sleeps if Py_AddPendingCall returns < 0 but It's not totally clear to me why the size of pendind calls array is only 32. [1] https://github.com/felipecruz/pyaio -- components: IO messages: 176491 nosy: felipecruz priority: normal severity: normal status: open title: Increase Py_AddPendingCall array size versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue16565> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16105] Pass read only FD to signal.set_wakeup_fd
Felipe Cruz added the comment: I've followed latest suggestions. Test and code updated. -- Added file: http://bugs.python.org/file27598/issue16105_v4.patch ___ Python tracker <http://bugs.python.org/issue16105> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16105] Pass read only FD to signal.set_wakeup_fd
Felipe Cruz added the comment: This patch retries write() until success if errno == EINTR. There is also a test. -- Added file: http://bugs.python.org/file27428/issue16105_v3.patch ___ Python tracker <http://bugs.python.org/issue16105> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16105] Pass read only FD to signal.set_wakeup_fd
Felipe Cruz added the comment: > Raising an error in case the signal can't be written to the FD > (because the other end didn't drain the pipe/socket) seems reasonable. > You should just retry on EINTR (although any sane implementation > shouldn't return EINTR on non-blocking write, I don't think it's > strictly prohibited by POSIX). You mean retry one time or until success? -- Added file: http://bugs.python.org/file27406/issue16105_v2.patch ___ Python tracker <http://bugs.python.org/issue16105> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16105] Pass read only FD to signal.set_wakeup_fd
Felipe Cruz added the comment: > Why limit to EBADF? You could also have EPIPE, EINVAL and many other errors. > The only error you may not want to report is EAGAIN. Charles, You're right! If all errno cases get covered in the patch, will It looks reasonable? -- ___ Python tracker <http://bugs.python.org/issue16105> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16105] Pass read only FD to signal.set_wakeup_fd
Felipe Cruz added the comment: Hello, since Antonie mentioned Py_AddPendingCall I came up with a patch describing what he proposed. Let me know if this patch can be improved or discarded(if the problem requires a more sophisticated solution). In case of improvement I can also submit another patch with a test case. -- keywords: +patch Added file: http://bugs.python.org/file27394/issue16105_v1.patch ___ Python tracker <http://bugs.python.org/issue16105> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15897] zipimport.c doesn't check return value of fseek()
Felipe Cruz added the comment: Should I send patches for 3.2 and 2.7? -- ___ Python tracker <http://bugs.python.org/issue15897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16105] Pass read only FD to signal.set_wakeup_fd
Felipe Cruz added the comment: I would not say that is a bug, but there is a write(wakeup_fd) call with ignored return code and maybe this can be improved to an output to stderr, or maybe a better solution. -- ___ Python tracker <http://bugs.python.org/issue16105> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16105] Pass read only FD to signal.set_wakeup_fd
New submission from Felipe Cruz: It's possible to set a read only FD to signal.set_wakeup_fd(fd) Since write call[1] inside 'trip_signal' return code is ignored, no error will be raised. An untested solution is to call fcntl in this FD to check presence of write flags. 1 - http://hg.python.org/cpython/file/fb90e2ff95b7/Modules/signalmodule.c#l187 -- components: Library (Lib) messages: 171745 nosy: felipecruz priority: normal severity: normal status: open title: Pass read only FD to signal.set_wakeup_fd type: behavior versions: Python 2.6, Python 2.7, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue16105> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15897] zipimport.c doesn't check return value of fseek()
Felipe Cruz added the comment: Hello! Just sent the Contributor Agreement Form. -- ___ Python tracker <http://bugs.python.org/issue15897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15744] missing tests for {RawIO,BufferedIO,TextIO}.writelines
Felipe Cruz added the comment: Updated based on Pitrou comments -- Added file: http://bugs.python.org/file27220/issue15744_v2.patch ___ Python tracker <http://bugs.python.org/issue15744> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15744] missing tests for {RawIO,BufferedIO,TextIO}.writelines
Felipe Cruz added the comment:
Add tests for {RawIO,BufferedIO,TextIO}.writelines()
--
keywords: +patch
nosy: +felipecruz
Added file: http://bugs.python.org/file27200/issue15744_v1.patch
___
Python tracker
<http://bugs.python.org/issue15744>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15948] Unchecked return value of I/O functions
Felipe Cruz added the comment: I can submit patches.. Is there any problem to send 1 patch per module? -- nosy: +felipecruz ___ Python tracker <http://bugs.python.org/issue15948> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15897] zipimport.c doesn't check return value of fseek()
Felipe Cruz added the comment: v4 - inline fseek return code check - as Christian suggested -- Added file: http://bugs.python.org/file27195/issue15897_v4.patch ___ Python tracker <http://bugs.python.org/issue15897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15897] zipimport.c doesn't check return value of fseek()
Felipe Cruz added the comment: I've updated the patch changing fseek_error goto block error return from PyErr_SetFromErrno to PyErr_Format(ZipImportError, "can't read Zip file: %R", archive); (returning NULL after). -- Added file: http://bugs.python.org/file27194/issue15897_v1.patch ___ Python tracker <http://bugs.python.org/issue15897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15897] zipimport.c doesn't check return value of fseek()
Felipe Cruz added the comment: Patch updated - fseek errors messges will be "can't read Zip file' and not "can't Open Zip file" -- Added file: http://bugs.python.org/file27192/issue15897_v1.patch ___ Python tracker <http://bugs.python.org/issue15897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15897] zipimport.c doesn't check return value of fseek()
Felipe Cruz added the comment: Hello! This is one of my first patches. Tests still OK! Let me know what you think! Thanks! -- keywords: +patch nosy: +felipecruz Added file: http://bugs.python.org/file27191/issue15897_v1.patch ___ Python tracker <http://bugs.python.org/issue15897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7484] smtplib: verify breaks with Postfix servers
Felipe Cruz added the comment: You're very kind David. Hope I can contribute with something more relevant next time :) best regards, Felipe 2011/7/18 R. David Murray > > R. David Murray added the comment: > > Thank you both for your work on this. The patch I committed is a > combination of my _addr_only, Filipe's tests, and Catalin's modifications to > those tests. quoteaddr, although in the __all__, is not documented and is > really an implementation detail, as is the new _addr_only. So I am only > testing them indirectly through the documented parts of the API (I added a > test for <> address, and one for an IDNA encoded address). > > Catalin, I think you are correct about the try/except/None stuff. As far > as I can tell it is left over from the old days before the email package and > its philosophy of never throwing parsing errors. Nowadays if parseaddr > throws an error, it is a bug. That's a refactoring not a bug fix, though, > so I didn't backport it. > > -- > resolution: -> fixed > stage: test needed -> committed/rejected > status: open -> closed > > ___ > Python tracker > <http://bugs.python.org/issue7484> > ___ > -- Added file: http://bugs.python.org/file22693/unnamed ___ Python tracker <http://bugs.python.org/issue7484> ___You're very kind David.Hope I can contribute with something more relevant next time :)best regards,Felipe2011/7/18 R. David Murray <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> R. David Murray <mailto:rdmur...@bitdance.com";>rdmur...@bitdance.com> added the comment: Thank you both for your work on this. Â The patch I committed is a combination of my _addr_only, Filipe's tests, and Catalin's modifications to those tests. Â quoteaddr, although in the __all__, is not documented and is really an implementation detail, as is the new _addr_only. Â So I am only testing them indirectly through the documented parts of the API (I added a test for <> address, and one for an IDNA encoded address). Catalin, I think you are correct about the try/except/None stuff. Â As far as I can tell it is left over from the old days before the email package and its philosophy of never throwing parsing errors. Â Nowadays if parseaddr throws an error, it is a bug. Â That's a refactoring not a bug fix, though, so I didn't backport it. -- resolution: Â -> fixed stage: test needed -> committed/rejected status: open -> closed ___ Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> <http://bugs.python.org/issue7484"; target="_blank">http://bugs.python.org/issue7484> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7484] smtplib: verify breaks with Postfix servers
Felipe Cruz added the comment: Can anyone take a loot at those patches? Do they need more tests? -- ___ Python tracker <http://bugs.python.org/issue7484> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7484] smtplib: verify breaks with Postfix servers
Changes by Felipe Cruz : Added file: http://bugs.python.org/file21652/issue7484-27_2.diff ___ Python tracker <http://bugs.python.org/issue7484> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7484] smtplib: verify breaks with Postfix servers
Felipe Cruz added the comment: David.. I extracted quoteaddr code to _addrformat and now quoteaddr and _addronly call _addrformat passing a format (<%s> or %s). I've also created quoteaddr and _addronly test functions as well modified VRFY and EXPN tests to make sure they call _addronly and pointed brackets aren't added. Let me know if those patches still need improvements. -- Added file: http://bugs.python.org/file21651/issue7484-py3k_2.diff ___ Python tracker <http://bugs.python.org/issue7484> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7484] smtplib: verify breaks with Postfix servers
Changes by Felipe Cruz : Added file: http://bugs.python.org/file21642/issue7484-27.diff ___ Python tracker <http://bugs.python.org/issue7484> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7484] smtplib: verify breaks with Postfix servers
Felipe Cruz added the comment: I've rewrote those patches to 'default' and 2.7 -- nosy: +felipecruz Added file: http://bugs.python.org/file21641/issue7484-py3k.diff ___ Python tracker <http://bugs.python.org/issue7484> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3410] platform.version() don't work as expected in Vista in portuguese
Felipe Portella added the comment: The same happens in Portuguese version ... the regex fails because ver returns "Versão" ... []'s On Mon, Jul 6, 2009 at 7:54 AM, Ezio Melotti wrote: > > Ezio Melotti added the comment: > > Won't that fail with Windows versions in Japanese, Chinese, Arab and > similar? > If 'Version' is translated in all the languages as a single word and > it's between whitespaces (or even between a [ and a space), \S+ should > be safe enough, otherwise \w+ with the re.U flag should work. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue3410> > ___ > -- title: platform.version() don't work as expected in Vista inportuguese -> platform.version() don't work as expected in Vista in portuguese Added file: http://bugs.python.org/file14457/unnamed ___ Python tracker <http://bugs.python.org/issue3410> ___The same happens in Portuguese version ... the regex fails because ver returns "Versão" ...[]'sOn Mon, Jul 6, 2009 at 7:54 AM, Ezio Melotti <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: Ezio Melotti <mailto:ezio.melo...@gmail.com";>ezio.melo...@gmail.com> added the comment: Won't that fail with Windows versions in Japanese, Chinese, Arab and similar? If 'Version' is translated in all the languages as a single word and it's between whitespaces (or even between a [ and a space), \S+ should be safe enough, otherwise \w+ with the re.U flag should work. -- ___ Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> <http://bugs.python.org/issue3410"; target="_blank">http://bugs.python.org/issue3410> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4164] String double quoted fatal problem
New submission from Felipe <[EMAIL PROTECTED]>: Hi I have a problem with python 2.6, when i try to process strings with triple-quoted string literal i get an error: a='a''a' #1 double quoted Ok a='a''''a' # 2 Ok a= 'a''''''a' # 3 doble quoted -- SyntaxError: EOF while scanning triple-quoted string literal a= 'a''''''''a' # 4 ok a='a''''''''''a' # 5 same error impair doble quoted a='a''''''''''''a' # 6 Ok... a... #7 error.. -- components: Library (Lib) messages: 75038 nosy: cliffdover88 severity: normal status: open title: String double quoted fatal problem type: compile error versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4164> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3410] platform.version() don't work as expected in Vista in portuguese
New submission from Felipe Portella <[EMAIL PROTECTED]>: Using Vista in Portuguese platform.version is returning "32bits" instead of "6.0.6001". This is because in file platform.py line 379 thee regular expression try to search for the word "Version" in english, while in Portuguese the command ver will return "Versão". To solve this issue simple change: 'Version ([\d.]+))') for '\S+ ([\d.]+))') -- components: Library (Lib) messages: 69987 nosy: portella severity: normal status: open title: platform.version() don't work as expected in Vista in portuguese type: behavior versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3410> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
