[issue46091] IndendationError from multi-line indented statements
New submission from Jeremy : At some point in 3.9 Python appears to have stopped accepting source that starts with an indent, then a '\', then the indented statement. From the lexical analysis [1] "Indentation cannot be split over multiple physical lines using backslashes; the whitespace up to the first backslash determines the indentation." Running the attached program under 3.8.12 I get: ``` 0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 ``` But running under 3.10.0 I get: ``` File "/Users/jeremyp/tmp/nodent.py", line 3 """Print a Fibonacci series up to n.""" ^ IndentationError: expected an indented block after function definition on line 1 ``` Running under 3.9.9 also gives an IndentationError, both with and without -X oldparser. So this doesn't seem directly related to the new parser, but seems likely it is fall out from the general grammar restructuring. IMHO it isn't a particularly nice feature for the language to have. Especially since not all lines like '\' behave the same. But it was there and documented for many years, so should probably be put back. Does a core developer agree? That the implementation is not following the spec? [1]: https://docs.python.org/3/reference/lexical_analysis.html#indentation -- components: Parser files: nodent.py messages: 408651 nosy: lys.nikolaou, pablogsal, ucodery priority: normal severity: normal status: open title: IndendationError from multi-line indented statements versions: Python 3.10, Python 3.11, Python 3.9 Added file: https://bugs.python.org/file50496/nodent.py ___ Python tracker <https://bugs.python.org/issue46091> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46091] IndendationError from multi-line indented statements
Jeremy added the comment: Wow, this was a fast turnaround! I was going to spin some cycles on this, but would have not seen the solution in 50m. -- ___ Python tracker <https://bugs.python.org/issue46091> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46274] backslash creating statement out of nothing
New submission from Jeremy : A source of one or more backslash-escaped newlines, and one final newline, is not tokenized the same as a source where those lines are "manually joined". The source ``` \ \ \ ``` produces the tokens NEWLINE, ENDMARKER when piped to the tokenize module. Whereas the source ``` ``` produces the tokens NL, ENDMARKER. What I expect is to receive only one NL token from both sources. As per the documentation "Two or more physical lines may be joined into logical lines using backslash characters" ... "A logical line that contains only spaces, tabs, formfeeds and possibly a comment, is ignored (i.e., no NEWLINE token is generated)" And, because these logical lines are not being ignored, if there are spaces/tabs, INDENT and DEDENT tokens are also being unexpectedly produced. The source ``` \ ``` produces the tokens INDENT, NEWLINE, DEDENT, ENDMARKER. Whereas the source (with spaces) ``` ``` produces the tokens NL, ENDMARKER. -- components: Parser messages: 409811 nosy: lys.nikolaou, pablogsal, ucodery priority: normal severity: normal status: open title: backslash creating statement out of nothing versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46274> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38044] unittest causing segfaults with string malloc in c++ module
New submission from Jeremy :
If a unittest is written which accesses a module written in C++ (I used
Pybind11 to allow Python access) which uses malloc for a string, a segmentation
fault is caused. This is not replicated when malloc is used for some other data
types such as int, char or char*
C++ code:
#include
#include
#include
using namespace std;
void t(){
string * data = (string*)malloc(100*sizeof(string));
data[0] = "this is a test";
cout<
<https://bugs.python.org/issue38044>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44675] Cross-platform issues with private methods and multiprocessing
New submission from Jeremy :
While writing a program using the multiprocessing library I stumbled upon what
appears to be a bug with how different platforms deal with private methods.
When a class has a private method which is the target for a multiprocessing
process, this name is correctly resolved on Linux (20.04.1-Ubuntu running
Python 3.8.10) but fails to be resolved correctly on MacOS (Python 3.8.2 and
3.8.8) or Windows 10 (Python 3.9.6).
import multiprocessing
class Test(object):
def __init__(self):
self.a = 1
self._b = 2
self.__c = 3
self.run1()
self.run2()
def _test1(self, conn):
conn.send(self._b)
def __test2(self, conn):
conn.send(self.__c)
def run1(self):
print("Running self._test1()")
parent, child = multiprocessing.Pipe()
process = multiprocessing.Process(target=self._test1, args=(child, ))
process.start()
print(parent.recv())
process.join()
def run2(self):
print("Running self.__test2()")
parent, child = multiprocessing.Pipe()
process = multiprocessing.Process(target=self.__test2, args=(child, ))
process.start()
print(parent.recv())
process.join()
if __name__ == "__main__":
t = Test()
On Linux, this has the intended behavior of printing:
Running self._test1()
2
Running self.__test2()
3
However, on Windows 10, this results in an Exception being raised:
Running self._test1()
2
Running self.__test2()
Traceback (most recent call last):
File "", line 1, in
File
"C:\Users\\AppData\Local\Programs\Python\Python39\lib\multiprocessing\spawn.py",
line 116, in spawn_main
exitcode = _main(fd, parent_sentinel)
File
"C:\Users\\AppData\Local\Programs\Python\Python39\lib\multiprocessing\spawn.py",
line 126, in _main
self = reduction.pickle.load(from_parent)
AttributeError: 'Test' object has no attribute '__test2'
A similar exception is also raised on MacOS for this code.
It would therefore appear that there is different behavior for resolving class
attributes starting with `__` on different platforms (at least within
multiprocessing). It is my understanding that because multiprocessing.Process
is called within the class, the private method should be within scope and so
should resolve correctly.
I'm aware that Python doesn't have strict private methods, and instead renames
them (Test.__test2 becomes Test._Test__test2) - explaining why on Windows it
cannot find the attribute with that name.
My question really is, which platform is correct here, and is the inconsistency
intentional? I'd suggest Linux is most correct here as the process is spawned
from within the object so the method should be in scope, but either way, the
inconsistency between platforms may cause some unintended issues.
--
components: Library (Lib), Windows, macOS
messages: 397810
nosy: ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, ymerej,
zach.ware
priority: normal
severity: normal
status: open
title: Cross-platform issues with private methods and multiprocessing
type: behavior
versions: Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue44675>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45545] chdir __exit__ is not safe
New submission from Jeremy :
The way that contextlib.chdir currently restores the old working directory, an
exception is raised if the program was already close to or beyond a system's
PATH_MAX. The context manager has no issue crafting the path in __enter__
because os.getcwd() can return a path that is longer than PATH_MAX, but when
used in __exit__ os.chdir() cannot use a path that long.
I think an __exit__ should be as cautious as possible to not raise as the
exception can occur far away from where the context manager was created. Its
also doesn't reflect the programmer actually using the context manager
incorrectly as they might not have any control or care where the process was
started, yet if it happened to already be at a deep path when launched, any use
of chdir anywhere would cause exceptions.
I have tested this on macOS 11.13 using APFS but I am sure it would also fail
on other macs and Linuxes. I don't know about Windows. Note I originally
created this test as a patch to Lib/tests/test_contextlib.py but libregrtest
uses os.getcwd() in its runner and that disrupts the traceback and
misidentifies the cause of failure. Test file:
```python
import os
import shutil
from contextlib import chdir
def test_long_path():
# NAME_MAX of 255
long_filename = "_".join(["testdir"]*32)
long_path_end = startingwd = os.getcwd()
try:
# I thought this would have to be 16, i.e. a path length over 4096,
PATH_MAX
# but seemingly just crossing 1050 is enough to fail
for _ in range(4):
os.mkdir(long_filename)
os.chdir(long_filename)
long_path_end = os.path.join(long_path_end, long_filename)
os.mkdir(long_filename)
long_path_end = os.path.join(long_path_end, long_filename)
with chdir(long_filename):
#self.assertEqual(os.getcwd(), long_path_end)
assert os.getcwd() == long_path_end
print("passed")
finally:
shutil.rmtree(os.path.join(startingwd, long_filename),
ignore_errors=True)
test_long_path()
```
And output:
```
$ ./python.exe ./test_chdir.py
passed
Traceback (most recent call last):
File "/Users/ucodery/git/cpython/./test_chdir.py", line 27, in
test_long_path()
File "/Users/ucodery/git/cpython/./test_chdir.py", line 19, in test_long_path
with chdir(long_filename):
^^
File "/Users/ucodery/git/cpython/Lib/contextlib.py", line 781, in __exit__
os.chdir(self._old_cwd.pop())
^
OSError: [Errno 63] File name too long:
'/Users/ucodery/git/cpython/testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir/testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir/testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir/testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_te
stdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir_testdir'
```
--
files: test_chdir.py
messages: 404534
nosy: ucodery
priority: normal
severity: normal
status: open
title: chdir __exit__ is not safe
type: behavior
versions: Python 3.11
Added file: https://bugs.python.org/file50377/test_chdir.py
___
Python tracker
<https://bugs.python.org/issue45545>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45545] chdir __exit__ is not safe
Jeremy added the comment: Yes, precisely. Besides being an unreachable long abs path, it might have been deleted since last visited. I’m working on a few more odd test cases. -- ___ Python tracker <https://bugs.python.org/issue45545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45545] chdir __exit__ is not safe
Jeremy added the comment: >If os.chdir is in os.supports_fd, the context manager can use dirfd = >os.open(os.getcwd(), os.O_RDONLY). Using an fd should also work around the >deleted directory case, though POSIX doesn't specify whether fchdir() succeeds >in this case. It does in Linux, and the resulting state is the same as >deleting the current working directory. Yes, I was considering an open fd to guarantee to return to the old pwd as long as it existed. I said as much on the mailing list, but was uncertain if it was possible do deadlock holding on to arbitrary directory handles. If it's possible at all to deadlock, and I think it is, I don't think we can use this; not in a stdlib implementation. The reason for the deadlock is too hidden from the user and debugging it would be difficult. It would be fine for a user implementation where they understood the implications and made other guarantees about their traversals, but we can't be sure everyone using this implementation would read an understand this limitation. I hadn't considered systems that don't support fd vops. I also hadn't considered crossing mount points and if that could cause any additional error cases. I don't think it can, not that we could correct in user-space and with just using os.chdir(). >In Windows, SetCurrentDirectoryW() resolves the full path. So the result from >os.getcwd() should always work with os.chdir(). The context manager could >prevent the original directory from getting deleted by opening it without >delete sharing (e.g. via _winapi.CreateFile). Though it may be more reasonable >to just let it fail to restore the original working directory. Thanks, I am much less familiar with these APIs. So I believe you are saying the implementation as is will work in all reasonable cases for Windows. I think attempting to move back to a directory that has been removed should be an error. Especially if we give the same behavior on Linux. Producing a FileNotFoundError gives the user the power to decide if they do in fact want to handle that differently. -- ___ Python tracker <https://bugs.python.org/issue45545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45545] chdir __exit__ is not safe
Change by Jeremy : -- keywords: +patch pull_requests: +27481 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29218 ___ Python tracker <https://bugs.python.org/issue45545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45545] chdir __exit__ is not safe
Jeremy added the comment: A LBYL won't always raise errors early as you point out. It will give earlier warnings for a lot of cases, but makes contextlib.chdir usable in less places than os.chdir. Some return paths will always be errors, and some will be technically recoverable but too difficult to detect and or fragile. That's why I think any solution should incorporate the `ignore_errors` flag. Its pretty ugly to wrap a context manager in a try: except: just because you were trying to clean up after whatever you were doing but the cwd changed in unexpected ways, maybe out of your control. -- ___ Python tracker <https://bugs.python.org/issue45545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45545] chdir __exit__ is not safe
Jeremy added the comment: > How common do you expect such errors to be though? Do you expect them to be > more or less common than with os.chdir()? Do you expect the mitigations to > be any different than with a failing os.chdir()? It has come up for me with some frequency. But I'm sure my use case is an outlier, stress testing filesystems and working on backup/restore. The thing about needing to access long paths is that you have to do it with these leaps of <= PATH_MAX until you get close enough to the end. Whether you use relative paths or open fds, you have to get there slowly and then walk back along the same path. This would be greatly simplified by contextlib.chdir if it isn't restricted to absolute paths; otherwise it will remain as much a manual effort as ever. It also has to do with the scope of any try block. If we leave any exceptions to bubble up to the caller, then any code in the with block is also being guarded. Presumably the caller used chdir because they want to do more os operations in the with block, but they won't be able to sort out if the ENOENT or similar error was from the context manager or their own, perhaps more critical, os operations. > If the context manager isn't going to address the long-path case reliably > using either a file-descriptor approach or repeated relative chdir() calls, > then I think failing early like this is the next best choice. I thought about going down the fd road but as not every platform can chdir to a fd, the relative way back would have to be implemented anyways. It didn't seem worth it to have different platforms behave differently on exiting the context manager. -- ___ Python tracker <https://bugs.python.org/issue45545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [ python-Bugs-1569998 ] 2.5 incorrectly permits break inside try statement
I'm working on this bug now, but can't get an SF login to update the bug report. Jeremy On 10/3/06, SourceForge.net <[EMAIL PROTECTED]> wrote: > Bugs item #1569998, was opened at 2006-10-03 14:04 > Message generated for change (Settings changed) made by gbrandl > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470 > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: Parser/Compiler > Group: Python 2.5 > Status: Open > Resolution: None > >Priority: 8 > Submitted By: Nick Coghlan (ncoghlan) > Assigned to: Nobody/Anonymous (nobody) > Summary: 2.5 incorrectly permits break inside try statement > > Initial Comment: > The new AST compiler permits the break statement inside > *any* frame block, rather than requiring that there be > a loop somewhere on the block stack. > > Will add examples in a comment where SF shouldn't > destroy the formatting. > > -- > > Comment By: Nick Coghlan (ncoghlan) > Date: 2006-10-03 14:05 > > Message: > Logged In: YES > user_id=1038590 > > Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit > (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more > information. > >>> try: > ... print 1 > ... break > ... print 2 > ... finally: > ... print 3 > ... > SyntaxError: 'break' outside loop > > Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 > bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more > information.>>> try: > ... print 1 > ... break > ... print 2 > ... finally: > ... print 3 > ... > 1 > 3 > > ------ > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569998&group_id=5470 > ___ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu > > ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x
Jeremy Kloth added the comment: The test only completed once I purposefully terminated the offending Python process. The only identifying information I noticed was the command-line of `-c "while True: pass"`, indicating it was stuck in either test_call_timeout() or test_timeout() in test_subprocess.py. Something to note is that Windows does not, by default, have a concept of process trees whereas terminating a parent automatically kills the children. Eryk Sun may have additional ideas on how this desired behavior could be accomplished. -- nosy: +eryksun, jkloth ___ Python tracker <https://bugs.python.org/issue46716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x
Jeremy Kloth added the comment: I've been able locally to reproduce the test_subprocess hang. The responsible function is subprocess.run(). The test case, test_timeout(), uses a small timeout value (0.0001), which, when given enough load, can cause the run() call to hang. A judicious use of prints in subprocess.py, reveals that the timeout passed to wait() ends up being negative. That value, once cast to a DWORD, ultimately causes a very long wait (0xfff2, in my testing). It does seem that only the Windows Popen._wait() cannot handle negative timeout values, so the fix should be as simple as coercing the timeout values to >= 0. -- Added file: https://bugs.python.org/file50623/process.py ___ Python tracker <https://bugs.python.org/issue46716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x
Jeremy Kloth added the comment: > > the fix should be as simple as coercing the timeout values to >= 0. > > Popen._remaining_time() should return max(endtime - _time(), 0). That was my first initial instinct as well, however, that change would also affect more of the Popen behavior and need a much more thorough investigation of the POSIX side of Popen. > Popen._wait() should raise OverflowError if the timeout is too large for the > implementation. In Windows, the upper limit in milliseconds is > `_winapi.INFINITE - 1` (about 49.7 days). It's important to only allow the > timeout in milliseconds to be _winapi.INFINITE when `timeout is None`. I agree. > The DWORD converter in _winapi needs to subclass unsigned_long_converter. The > current implementation based on the legacy format unit "k" is too lenient. > Negative values and values that are too large should fail. Whilst I agree this is a correct solution, I fear the potential 3rd-party breakage alone should bump this to its own issue. I believe that this then leads to the following action items for this issue: 1) modify Windows Popen._wait() to raise on out of bounds values [< 0 or >= INFINITE] 2) cap Popen._remaining_time() return value to >= 0 3) change _winapi DWORD converter be unsigned long 4) use Job objects to group Windows processes for termination Have I missed anything? I should be able to knock out PRs for these today. -- Jeremy Kloth -- nosy: +jeremy.kloth ___ Python tracker <https://bugs.python.org/issue46716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46778] Enable parallel compilation on Windows builds
New submission from Jeremy Kloth : While the current build does enable building of projects in parallel (msbuild -m), the compilation of each project's source files is done sequentially. For large projects like pythoncore or _freeze_module this can take quite some time. This simple PR speeds things up significantly, ~2x on machines that I have access. -- components: Build, Windows messages: 413412 nosy: jkloth, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Enable parallel compilation on Windows builds versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46778> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46778] Enable parallel compilation on Windows builds
Change by Jeremy Kloth : -- keywords: +patch pull_requests: +29535 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31390 ___ Python tracker <https://bugs.python.org/issue46778> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46788] regrtest fails to start on missing performance counter names
New submission from Jeremy Kloth : When attempting to run the test harness, I receive the following: Traceback (most recent call last): File "", line 198, in _run_module_as_main File "", line 88, in _run_code File "C:\Public\Devel\cpython\main\Lib\test\__main__.py", line 2, in main() ^^ File "C:\Public\Devel\cpython\main\Lib\test\libregrtest\main.py", line 736, in main Regrtest().main(tests=tests, **kwargs) ^^ File "C:\Public\Devel\cpython\main\Lib\contextlib.py", line 155, in __exit__ self.gen.throw(typ, value, traceback) ^ File "C:\Public\Devel\cpython\main\Lib\contextlib.py", line 155, in __exit__ self.gen.throw(typ, value, traceback) ^ File "C:\Public\Devel\cpython\main\Lib\test\support\os_helper.py", line 396, in temp_dir yield path ^^ File "C:\Public\Devel\cpython\main\Lib\contextlib.py", line 155, in __exit__ self.gen.throw(typ, value, traceback) ^ File "C:\Public\Devel\cpython\main\Lib\test\support\os_helper.py", line 427, in change_cwd yield os.getcwd() ^ File "C:\Public\Devel\cpython\main\Lib\test\support\os_helper.py", line 449, in temp_cwd yield cwd_dir ^ File "C:\Public\Devel\cpython\main\Lib\test\libregrtest\main.py", line 658, in main self._main(tests, kwargs) ^ File "C:\Public\Devel\cpython\main\Lib\test\libregrtest\main.py", line 704, in _main self.win_load_tracker = WindowsLoadTracker() File "C:\Public\Devel\cpython\main\Lib\test\libregrtest\win_utils.py", line 41, in __init__ self.start() File "C:\Public\Devel\cpython\main\Lib\test\libregrtest\win_utils.py", line 70, in start counter_name = self._get_counter_name() File "C:\Public\Devel\cpython\main\Lib\test\libregrtest\win_utils.py", line 90, in _get_counter_name system = counters_dict['2'] ~^ KeyError: '2' This is due to my machine missing the localized names for the performance counters. Other performance monitoring tools operate just fine. While I have been working around this issue for some time, it has become difficult to seperate the workarounds from actually changes in the test harness. The PR (https://github.com/python/cpython/pull/26578) from https://bugs.python.org/issue44336 also solves this issue by accessing the counters directly instead of relying on their localized names. -- components: Tests, Windows messages: 413493 nosy: jkloth, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: regrtest fails to start on missing performance counter names versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46788] regrtest fails to start on missing performance counter names
Change by Jeremy Kloth : -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issue46788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46789] Restore caching of externals on Windows buildbots
New submission from Jeremy Kloth : A recent change to the buildmaster config effectively disabled the caching of the externals for Windows buildbots: https://github.com/python/buildmaster-config/pull/255 If the caching is desired, a simple change to the buildmaster config is needed (define EXTERNALS_DIR in the build environment). Or, to continue with fetching them each run, the buildbot scripts in Tools\buildbot can be simplified. Once a course of action is determined I can develop the requisite PR(s) in the appropriate tracker. -- components: Build, Tests, Windows messages: 413494 nosy: jkloth, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Restore caching of externals on Windows buildbots ___ Python tracker <https://bugs.python.org/issue46789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46789] Restore caching of externals on Windows buildbots
Change by Jeremy Kloth : -- nosy: +pablogsal, vstinner ___ Python tracker <https://bugs.python.org/issue46789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46790] Normalize handling of negative timeouts in subprocess.py
New submission from Jeremy Kloth : As a follow on to bpo-46716, the various timeout parameters currently deal with negative values differently in POSIX and Windows. On POSIX, a negative value is treated the same as 0; check completion and raise TimeoutExpired is still running. On Windows, the negative value is treated as unsigned and ultimately waits for ~49 days. While the Windows behavior is obviously wrong and will be fixed internally as part of bpo-46716, that still leaves what to do with timeouts coming from user-space. The current documentation just states that after `timeout` seconds TimeoutExpired is raised. A liberal reading of the documentation could lead one to believe any value <=0 would suffice for an "active" check (the POSIX behavior). OR, the documentation could be amended and negative values are now invalid and apply range checking in the user-facing functions. -- components: Library (Lib) messages: 413496 nosy: jkloth priority: normal severity: normal status: open title: Normalize handling of negative timeouts in subprocess.py versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46790] Normalize handling of negative timeouts in subprocess.py
Change by Jeremy Kloth : -- nosy: +eryksun, vstinner ___ Python tracker <https://bugs.python.org/issue46790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46790] Normalize handling of negative timeouts in subprocess.py
Jeremy Kloth added the comment: Oh, I forgot to add that I'm in favor of following the threading.py behavior of allowing <=0 to mean "non-blocking" (i.e., just check). This would probably also benefit from a documentation update to clarify. -- ___ Python tracker <https://bugs.python.org/issue46790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46789] Restore caching of externals on Windows buildbots
Jeremy Kloth added the comment: I personally would like to see caching restored so as to keep the duration of buildbot runs as low as possible. The repeated fetching effectively doubles compilation time for my Win11 builder. -- ___ Python tracker <https://bugs.python.org/issue46789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46789] Restore caching of externals on Windows buildbots
Jeremy Kloth added the comment: > Would it be possible to create a download cache somewhere outside the Python > source tree, so "git clean -fdx" would not remove this cache? I was thinking of locating it next to the checkout directory. The current structure is: [worker root] -- [builder root] [checkout] I propose to add the externals directory within the builder root, so each branch would still have a unique copy. -- nosy: +jeremy.kloth ___ Python tracker <https://bugs.python.org/issue46789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46857] Python leaks one reference at exit on Windows
Jeremy Kloth added the comment:
Good news, the difference on Windows was easy enough to find, bad news total
refs are now negative!
--- a/Objects/exceptions.c
+++ b/Objects/exceptions.c
@@ -3647,8 +3647,7 @@ _PyBuiltins_AddExceptions(PyObject *bltinmod)
#define INIT_ALIAS(NAME, TYPE) \
do { \
-Py_INCREF(PyExc_ ## TYPE); \
-Py_XDECREF(PyExc_ ## NAME); \
+Py_XSETREF(PyExc_ ## NAME, PyExc_ ## TYPE); \
PyExc_ ## NAME = PyExc_ ## TYPE; \
if (PyDict_SetItemString(mod_dict, # NAME, PyExc_ ## NAME)) { \
return -1; \
As the PyExc_* aliases just deprecated names for PyExc_OSError, there is no
need to increment their refcounts. Or they could be decremented in Fini(). Or
they could finally be removed entirely.
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue46857>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46857] Python leaks one reference at exit on Windows
Jeremy Kloth added the comment: Note that an allocated block is still leaking. Strange as well, when using dump_refs, the total refs are much more negative (-12 linux, -13 Windows) -- ___ Python tracker <https://bugs.python.org/issue46857> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46857] Python leaks one reference at exit on Windows
Jeremy Kloth added the comment: > Oh wow. How did you find this leak? Did you read all C files and check for > code specific to Windows? How did you proceed? Well spotted! Initially, I modified Py_INCREF to dump the object (addr & tp_name) on initial inc (ob_refcnt == 1) and Py_DECREF to dump on final dec (ob_refcnt == 0). Then filter that list (~65K) to find objects not dealloc'ed. Given those names (~200), cross-check with source files containing 'ifdef MS_WINDOWS' (and related spellings). > Which command do you type? Do you pass -I option to Python? For both as -I disables environment lookup: --- a/Python/initconfig.c +++ b/Python/initconfig.c @@ -757,6 +757,7 @@ config_init_defaults(PyConfig *config) config->user_site_directory = 1; config->buffered_stdio = 1; config->pathconfig_warnings = 1; + config->dump_refs = 1; #ifdef MS_WINDOWS config->legacy_windows_stdio = 0; #endif For linux: ./configure --enabled-shared --with-py-debug --with-trace-refs make build_all LD_LIBRARY_PATH=$PWD ./python -X showrefcount -I -c pass For Windows: Add "#define Py_TRACE_REFS 1" to PC\pyconfig.h build.bat -d -e amd64\python_d.exe -X showrefcount -I -c pass > I proposed GH-31594 to fix this macro. Even using that change, I still have negative refs (but I still have Py_TRACE_REFS defined) -- nosy: +jeremy.kloth ___ Python tracker <https://bugs.python.org/issue46857> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46857] Python leaks one reference at exit on Windows
Jeremy Kloth added the comment: > ./configure --enabled-shared --with-py-debug --with-trace-refs (that's what I get for typing from memory): ./configure --enable-shared --with-pydebug --with-trace-refs > > I proposed GH-31594 to fix this macro. > > Even using that change, I still have negative refs (but I still have > Py_TRACE_REFS defined) I initially missed the _PySet_Dummy change, with that total refs (w/o dump_refs) is now 0. -- ___ Python tracker <https://bugs.python.org/issue46857> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46857] Python leaks one reference at exit on Windows
Jeremy Kloth added the comment: Did you also modify initconfig.c? That part is required as the usual processing of the environment variable PYTHONDUMPREFS needed to enable tracing output is ignored with -I -- ___ Python tracker <https://bugs.python.org/issue46857> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: sys.settrace closure interaction bug
Can you file a bug report for this? I'm guessing that the trace code
has some bad interaction with LOAD_LOCALS, such that a free variable
passed through the class gets treated as local instead. I can
reproduce this problem in Python 2.4, so it's a long-standing bug.
Also, as a matter of terminology, there is no currying going on. It's
just a problem with closures.
Jeremy
On 10/1/06, Scott Marks <[EMAIL PROTECTED]> wrote:
> The code below exhibits different behavior depending on whether it invokes
> sys.settrace ('-t' option) or not. This means that (in a more complicated
> case) debugging the code (which uses sys.settrace) makes it fail. Any
> ideas?
>
> """ Demonstrace that tracing messes up curried class definitions """
>
> # Some simple command line parsing: -t or --trace means trace, nothing
> means don't trace
> import sys
>
> def usage( ):
> print 'Usage:', sys.argv[ 0 ], '[-t | --trace]'
> sys.exit( 1 )
>
> if 1 == len( sys.argv ):
> pass
> elif 2 == len( sys.argv ):
> if sys.argv[ 1 ]=='-t' or sys.argv[ 1 ]=='--trace':
> def trace ( frame, event, arg ):
> # print frame, event, arg
> return trace
> sys.settrace( trace )
> else:
> usage( )
> else:
> usage( )
>
>
>
> # The test: define a class factory with a curried member function
>
> def the_factory( parm1 ):
> class the_class( object ):
> def curried( self ): return parm1
> return the_class
>
> x = the_factory( 42 )
>
> y = x( )
>
> try:
> x.parm1
> print "Failure: x (the manufactured class) has attribute parm1?!"
> except AttributeError:
> print "Success with the manufactured class!"
>
> try:
> y.parm1
> print "Failure: y (the instance) has attribute parm1?!"
> except AttributeError:
> print "Success with the instance!"
>
> assert y.curried( ) == 42, "Currying didn't work?!"
>
>
> ___
> Python-bugs-list mailing list
> Unsubscribe:
> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>
>
>
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12785] list_distinfo_file is wrong
Jeremy Kloth added the comment: The attached patch seems to work as-is. That is, just testing for `self.path` as the prefix. On Windows, at least, the paths in RECORD are always absolute. Further changes will be necessary, of course, once changes for alternative paths (--prefix, --home, and so on) are incorporated. -- nosy: +jkloth ___ Python tracker <http://bugs.python.org/issue12785> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13102] xml.dom.minidom does not support default namespaces
Jeremy Kloth added the comment: Please read the link which you posted. Quoting the second paragraph, second sentence: "Default namespace declarations do not apply directly to attribute names;" and from the third paragraph, third sentence: "The namespace name for an unprefixed attribute name always has no value." Therefore minidom *is* conformant by having None as the namespace-uri for unprefixed attribute names. -- nosy: +jkloth ___ Python tracker <http://bugs.python.org/issue13102> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12569] sqlite3 segfaults and bus errors when given certain unicode strings as queries
New submission from Jeremy Banks :
I was experimenting with the sqlite3 library and noticed that using certain
strings as identifiers cause bus errors or segfaults. I'm not very familiar
with unicode, but after some Googling I'm pretty sure this happens when I use
non-characters or surrogate characters incorrectly.
This causes a bus error:
import sqlite3
c = sqlite3.connect(":memory:")
table_name = '"' + chr(0xD800) + '"'
c.execute("create table " + table_name + " (bar)")
The equivalent Python 2 (replacing chr with unichr) works properly.
--
components: Library (Lib)
messages: 140381
nosy: jeremybanks
priority: normal
severity: normal
status: open
title: sqlite3 segfaults and bus errors when given certain unicode strings as
queries
type: crash
versions: Python 3.1
___
Python tracker
<http://bugs.python.org/issue12569>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12569] sqlite3 segfaults and bus errors when given certain unicode strings as queries
Jeremy Banks added the comment: I'm using OS X 10.6.7. The bus error is occurring with my Python 3.1 installation: path: /Library/Frameworks/Python.framework/Versions/3.1/bin/python3 sqlite3.version == 2.4.1 sqlite3.sqlite_version = 3.6.11. But now that you mention it, my MacPorts installations of Python 3.0 and 3.1 just get an exception like you do: paths: /opt/local/bin/python3.0 / python3.1 sqlite3.version == 2.4.1 sqlite3.sqlite_version == 3.7.7.1 A Python 2.7 installation where it works without any error: path: /Library/Frameworks/Python.framework/Versions/2.7/bin/python sqlite3.version == 2.6.0 sqlite3.sqlite_version == 3.6.12 A MacPorts Python 2.6 installation where it works without any error: path: /opt/local/bin/python2.6 sqlite3.version == 2.4.1 sqlite3.sqlite_version == 3.7.7.1 -- ___ Python tracker <http://bugs.python.org/issue12569> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12569] sqlite3 segfaults and bus errors when given certain unicode strings as queries
Jeremy Banks added the comment: I'll try that, thank you. If it works without exception in Python 2, isn't the behaviour in Python 3 a regression bug, even if it doesn't crash? If so, should I create a new/separate issue for the behaviour? -- ___ Python tracker <http://bugs.python.org/issue12569> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12627] Implement PEP 394: The "python" Command on Unix-Like Systems
Changes by Jeremy Bicha : -- nosy: +jbicha ___ Python tracker <http://bugs.python.org/issue12627> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug
Changes by Jeremy Kloth : -- nosy: +jkloth ___ Python tracker <http://bugs.python.org/issue12729> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12678] test_packaging and test_distutils failures under Windows
Jeremy Kloth added the comment: The failure was due to the sdist command having different default formats for each platform (i.e., POSIX: gztar, Win32: zip). Patch attached. -- keywords: +patch nosy: +jkloth Added file: http://bugs.python.org/file22952/test_sdist.diff ___ Python tracker <http://bugs.python.org/issue12678> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12895] In MSI/EXE installer, allow installing Python modules in free path
Changes by Jeremy Kloth : -- nosy: +jkloth ___ Python tracker <http://bugs.python.org/issue12895> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11805] package_data only allows one glob per-package
Changes by Jeremy Kloth : -- nosy: +jkloth ___ Python tracker <http://bugs.python.org/issue11805> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9217] 2to3 crashes with some doctests
Jeremy Thurgood added the comment: This seems to be fixed in 3.2 and the 2.7 maintenance branch, but here's a (one-liner) patch for people who want to fix their local installations. -- keywords: +patch nosy: +jerith Added file: http://bugs.python.org/file18750/2to3_log_fix.patch ___ Python tracker <http://bugs.python.org/issue9217> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9997] function named 'top' gets unexpected namespace/scope behaviour
Jeremy Hylton added the comment: Let me fix that. -- nosy: +Jeremy.Hylton ___ Python tracker <http://bugs.python.org/issue9997> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9997] function named 'top' gets unexpected namespace/scope behaviour
Changes by Jeremy Thurgood : -- nosy: +jerith ___ Python tracker <http://bugs.python.org/issue9997> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6792] Distutils-based installer does not detect 64bit versions of Python
Changes by Jeremy Kloth : -- nosy: +jkloth ___ Python tracker <http://bugs.python.org/issue6792> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10175] vs version for win32 compilation of extension modules is undocumented.
Changes by Jeremy Kloth : -- nosy: +jkloth ___ Python tracker <http://bugs.python.org/issue10175> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10175] vs version for win32 compilation of extension modules is undocumented.
Jeremy Kloth added the comment: A quick look with Dependency Walker gives me the following: Python 2.4,2.5 -- MSVC .NET 2003 (7.1) Python 2.6,2.7,3.0,3.1 -- MSVC 2008 (9.0) Note these are only for the official python.org builds. Each version can also be built using other MSVC versions. To the best of my knowledge Python 3.2 will also be built using MSVC 2008 as 2010 support hasn't been discussed yet. -- ___ Python tracker <http://bugs.python.org/issue10175> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10217] python-2.7.amd64.msi install fails
Changes by Jeremy Kloth : -- nosy: +jkloth ___ Python tracker <http://bugs.python.org/issue10217> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11921] distutils2 should be able to compile an Extension based on the Python implementation version
Changes by Jeremy Kloth : -- nosy: +jkloth ___ Python tracker <http://bugs.python.org/issue11921> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10231] SimpleHTTPRequestHandler directory bugs
Jeremy Thurgood added the comment: Attached a patch to test for and fix the first two issues described in this ticket. Basically, it modifies SimpleHTTPRequestHandler.send_head() to operate on a path already stripped of the query string and fragment rather than the completely unparsed URL. -- keywords: +patch nosy: +jerith Added file: http://bugs.python.org/file19654/issue10231.diff ___ Python tracker <http://bugs.python.org/issue10231> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1859] textwrap doesn't linebreak on "\n"
Jeremy Thurgood added the comment: The weird behaviour is caused by newlines being treated as normal whitespace characters and not actually causing _wrap_chunks() to break the line. This means that it builds "lines" of up to 'width' characters which may contain newlines: >>> text = '''\ ... aaa aaa aaa ... bbb bbb bbb ... ccc ccc ccc ... ddd ddd ddd''' >>> T = TextWrapper(replace_whitespace=False, width=17) >>> T.wrap(text) ['aaa aaa aaa\nbbb', 'bbb bbb\nccc ccc', 'ccc\nddd ddd ddd'] >>> for line in T.wrap(text): print(line) ... aaa aaa aaa bbb bbb bbb ccc ccc ccc ddd ddd ddd There's no clean way to deal with this inside _wrap_chunks() (as Greg implied), so I think we should just document the existing behaviour and recommend the splitlines() workaround. It might be useful to add a wrap_paragraphs() convenience function that does the split/wrap/join, but I don't think that would add enough value to be worth the change. -- nosy: +jerith ___ Python tracker <http://bugs.python.org/issue1859> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1859] textwrap doesn't linebreak on "\n"
Jeremy Thurgood added the comment: Here's a doc patch for py3k. A similar patch for 2.7 (and other versions?) might be a good idea. -- keywords: +patch Added file: http://bugs.python.org/file19676/issue1859_docs.diff ___ Python tracker <http://bugs.python.org/issue1859> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10231] SimpleHTTPRequestHandler directory bugs
Jeremy Thurgood added the comment:
Thanks for the comments.
There are two separate things here: the URL and the filesystem path. The only
part of the URL we care about is the path section, but the fragment ("#anchor")
and query parameters ("?foo") are valid -- SimpleHTTPRequestHandler just
ignores them. translate_path() turns the URL into the filesystem path, which
may be a file or a directory, by extracting the URL path and mapping it onto
the filesystem.
The bug is that the fragment and query parameters are stripped in
translate_path(), but are *not* stripped when manipulating the URL for the
redirect.
This means that when the URL is "/something?foo" and the cwd is "/tmp", the
filesystem path is "/tmp/something" (which is a directory) and therefore the
response needs to be a redirect. The redirect needs to modify the path section
of the URL (which is "/something") to add a slash. This means the redirect
needs to be to "/something/" (or "/something/?foo" if you want to preserve the
query parameters) rather than "/something?foo/" which is what the current
implementation does.
translate_path() unescapes the URL path before mapping it to the filesystem,
which means that "/something%3Ffoo" (and even "/something%3Ffoo?bar") will be
turned into the filesystem path "/tmp/something?foo".
I'll add some tests for the "/something%3Ffoo" case and possibly update
send_head() to preserve the fragment and query parameters on redirect.
--
status: pending -> open
___
Python tracker
<http://bugs.python.org/issue10231>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10231] SimpleHTTPRequestHandler directory bugs
Jeremy Thurgood added the comment: Updated patch as per previous comment. -- Added file: http://bugs.python.org/file19701/issue10231_v2.diff ___ Python tracker <http://bugs.python.org/issue10231> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10231] SimpleHTTPRequestHandler directory bugs
Jeremy Thurgood added the comment: On Sun, Nov 21, 2010 at 10:37, Senthil Kumaran wrote: > Now, what happens when you type "http://bugs.python.org?10231"; [1] in > your browser? According to this bug report, the server should 301 > redirect it to "http://bugs.python.org/?10231";. If you try this, this > does not happen. The browser (client) is in fact, changing it to the > corrected URL (because the original is invalid) and the server is just > ignoring the so called query portion). I see your point now, but I don't agree with it completely. It seems reasonable to allow query parameters to specify things like sort order for a directory listing or have a fragment to focus the browser on a particular entry. On the other hand, if we don't want to support the redirect with a fragment or query parameters, we should instead return a 400 response. I can't see any situation in which redirecting "/something?foo" to "/something?foo/" is the correct behaviour. > If you use, urllib2 to request the above [1], you will find that it > will fail with 401 error. A 401 is "Unauthorized", which means the server is asking for authentication -- I don't think that's relevant here. -- ___ Python tracker <http://bugs.python.org/issue10231> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10231] SimpleHTTPRequestHandler directory bugs
Jeremy Thurgood added the comment: On Sun, Nov 21, 2010 at 17:11, Senthil Kumaran wrote: >>I can't see any situation in which redirecting >> "/something?foo" to "/something?foo/" is the correct behaviour. > As I explained, in the previous post, this would *not happen* in > practical scenarios, because code won't reach that point for valid > URLs. It reaches that point in the tests I added, and the results confirm the first two points in the original bug report. Am I mistaken? "/something?foo" is a valid URL. If "/something" is translated to a file on the filesystem, the content of that file is returned. If it is translated to a directory on the filesystem, a 301 to "/something?foo/" is returned. -- ___ Python tracker <http://bugs.python.org/issue10231> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10937] WinPE 64 bit execution results with errors
New submission from Jeremy Langley : old versions of python worked on old versions of winpe by copying the c:\python25\ directory over to the mounted (iso,usb) filesystem, then rebooting with the media and running the python.exe from the ramdrive. This formula no longer works with 64 bit versions of winpe (which is one way to push win7-64bit. When it's tried one gets platform based errors. -- components: Build messages: 126479 nosy: gettingback2basics priority: normal severity: normal status: open title: WinPE 64 bit execution results with errors type: feature request ___ Python tracker <http://bugs.python.org/issue10937> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2885] Create the urllib package
Jeremy Hylton <[EMAIL PROTECTED]> added the comment: Oops. Let me look at this tomorrow. It was down to one failing test that last time I checked. Jeremy On Wed, Jun 11, 2008 at 10:10 PM, Barry A. Warsaw <[EMAIL PROTECTED]> wrote: > > Barry A. Warsaw <[EMAIL PROTECTED]> added the comment: > > This didn't get done for the first beta. Please try to do it asap after > the beta releases. > > -- > nosy: +barry > priority: release blocker -> critical > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue2885> > ___ > ___ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu > > ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2885> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3377] Invalid child node access in ast.c
Changes by Jeremy Hylton <[EMAIL PROTECTED]>: -- assignee: -> jhylton nosy: +jhylton ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3377> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3377] Invalid child node access in ast.c
Jeremy Hylton <[EMAIL PROTECTED]> added the comment: Committed revision 65064. -- status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3377> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3347] urllib.robotparser doesn't work in Py3k
Jeremy Hylton <[EMAIL PROTECTED]> added the comment: Committed revision 65118. I applied a simple version of this patch and added a unittest. -- assignee: -> jhylton nosy: +jhylton status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3347> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1540] Refleak tests: test_doctest and test_gc are failing
Jeremy Hylton added the comment: I'm trying to figure out the attached script. If I run Python 3.0, the script doesn't run because of the undefined gc.DEBUG_OBJECTS. If I just remove that, the script runs without error. Does that mean the problem is fixed? Or is running without an error an example of the problem? If I add gc.DEBUG_SAVEALL, it fails--but that seems obvious because DEBUG_SAVEALL adds all objects with finalizers to gc.garbage. -- nosy: +Jeremy.Hylton ___ Python tracker <http://bugs.python.org/issue1540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1540] Refleak tests: test_doctest and test_gc are failing
Jeremy Hylton added the comment: I spent some time to understand the example script today. The specific issue is that a set of objects get put into the list of unreachable objects with finalizers (both Immutable and Finalizer instances). When Cycle's __dict__ is cleared, it also decrefs Immutable which resurrects it and Finalizer. The garbage collector is not prepared for an unreachable finalizer object to become reachable again. More generally, it's hard to assume anything about the state of the finalizers after unreachable trash is collected. I'll think more about what to do, but I don't see any easy solutions. -- ___ Python tracker <http://bugs.python.org/issue1540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1540] Refleak tests: test_doctest and test_gc are failing
Jeremy Hylton added the comment: One last thought on this bug. The problem is that after we try to delete garbage, we really can't know much about the state of the objects in the finalizers list. If any of the objects that are cleared end up causing a finalizer to run, then any of the objects in the finalizers list may be reachable again. One possibility is to do nothing with the objects in the finalizers list if there was any garbage to delete. That means objects with finalizers would be harder to get to gc.collect()--for example, you'd need to call gc.collect() twice in a row. The first time to clear garbage, the second time to handle unreachable objects with finalizers. Or the GC could run a second time if garbage was cleared and finalizers was non-empty. A more complicated possibility would be to track some object state about when a finalizer was run. If any of the objects in finalizers had a finalizer that ran while garbage was cleared, we could skip the finalizers list. I don't know how to implement this, since an arbitrary C type could run Python code in tp_dealloc without notifying GC. -- ___ Python tracker <http://bugs.python.org/issue1540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1540] Refleak tests: test_doctest and test_gc are failing
Jeremy Hylton added the comment: Amaury-- I think that will work. I put together a small patch that seems to pass all the tests, but it too messy. We need some care to make sure we don't spin forever if there's some degenerate case where we never escape GC. -- ___ Python tracker <http://bugs.python.org/issue1540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [issue7806] httplib.HTTPConnection.getresponse closes socket which destroys the response
I don't think the HTTPConnection class was designed to work with sockets that don't follow the Python socket API. If you want to use a different socket, you should create some wrapper that emulates the Python socket ref count behavior. Jeremy On Mon, Feb 1, 2010 at 5:23 PM, Robert Buchholz wrote: > > Robert Buchholz added the comment: > > An example cannot be constructed using the standard python socket class. As > you point out, the response.will_close attribute is set correctly: The client > is supposed to close to connect after completion of the request (as does the > server). However, when the HTTPConnection object calls close() on the socket, > reading the request is not completed -- the request object merely created a > file-like object representing the socket. > > The reason why this is not an issue is that the Python socket library does > reference counting to determine when to close a socket object. When the > HTTPConnection calls close(), its own socket object is destroyed and > unreferenced. However, the file-like object in the HTTPResponse still has a > copy of the socket. > > In alternative socket implementations (like Paramiko SOCKS-proxied sockets), > this poses a problem: When the socket user calls close(), they actually close > the socket -- as the original socket API documentation describes: > > close() > Close the socket. It cannot be used after this call. > > makefile([mode[, bufsize]]) -> file object > Return a regular file object corresponding to the socket. The mode > and bufsize arguments are as for the built-in open() function. > > Consequently, I do not consider this to be a bug in Paramiko and reported it > for the httplib. I can present example code using a paramiko tunneled socket > (client and server) if you like. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue7806> > ___ > ___ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu > > ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7806] httplib.HTTPConnection.getresponse closes socket which destroys the response
Jeremy Hylton added the comment: On Fri, Feb 19, 2010 at 6:22 PM, R. David Murray wrote: > > R. David Murray added the comment: > > But a goal is for the standard library to work with Python implementations > other than CPython, and the reference counting behavior described won't > happen in non-reference counting implementations. So I don't think that > requiring emulation of ref-counting behavior is valid. I don't think an implementation of Python sockets would be considered correct unless it supported this behavior. CPython goes to elaborate lengths to make it work across platforms. Jeremy > -- > nosy: +r.david.murray > > ___ > Python tracker > <http://bugs.python.org/issue7806> > ___ > -- ___ Python tracker <http://bugs.python.org/issue7806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7806] httplib.HTTPConnection.getresponse closes socket which destroys the response
Jeremy Hylton added the comment: On Sat, Feb 20, 2010 at 12:06 AM, R. David Murray wrote: > > R. David Murray added the comment: > > But the docs (which presumably describe the API) say that the socket is > unusable after the call to close, which argues that the paramiko sockets are > following the documented API. Do the docs need to be corrected? I mean the documented socket API. Jeremy > -- > > ___ > Python tracker > <http://bugs.python.org/issue7806> > ___ > -- ___ Python tracker <http://bugs.python.org/issue7806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7806] httplib.HTTPConnection.getresponse closes socket which destroys the response
Jeremy Hylton added the comment: In particular, I mean this part of the socket API: socket.makefile([mode[, bufsize]]) Return a file object associated with the socket. (File objects are described in File Objects.) The file object references a dup()ped version of the socket file descriptor, so the file object and socket object may be closed or garbage-collected independently. The socket must be in blocking mode (it can not have a timeout). The optional mode and bufsize arguments are interpreted the same way as by the built-in file() function. The language may be a little vague, but it means that closing the file generated by makefile() should not close the underlying socket. Jeremy On Sun, Feb 21, 2010 at 3:23 PM, Jeremy Hylton wrote: > > Jeremy Hylton added the comment: > > On Sat, Feb 20, 2010 at 12:06 AM, R. David Murray > wrote: >> >> R. David Murray added the comment: >> >> But the docs (which presumably describe the API) say that the socket is >> unusable after the call to close, which argues that the paramiko sockets are >> following the documented API. Do the docs need to be corrected? > > I mean the documented socket API. > > Jeremy > >> -- >> >> ___ >> Python tracker >> <http://bugs.python.org/issue7806> >> ___ >> > > -- > > ___ > Python tracker > <http://bugs.python.org/issue7806> > ___ > _______ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu > > -- ___ Python tracker <http://bugs.python.org/issue7806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7806] httplib.HTTPConnection.getresponse closes socket which destroys the response
Jeremy Hylton added the comment: On Sun, Feb 21, 2010 at 5:38 PM, Robert Buchholz wrote: > > Robert Buchholz added the comment: > > almost... HTTPConnection is calling close() on the socket object, but > HTTPResponse still has an open file-like object from a previous makefile() > call. That object still has an internal reference to the socket. That's right. The makefile() method on sockets works that way, and the HTTP library depends on that behavior (and pretty much always has). Jeremy > > -- > > ___ > Python tracker > <http://bugs.python.org/issue7806> > ___ > -- ___ Python tracker <http://bugs.python.org/issue7806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [issue4617] SyntaxError when free variable name is also an exception target
It's an interesting bug. Maybe the compiler shouldn't allow you to use such a variable as a free variable in a nested function? On Thu, Feb 11, 2010 at 9:09 PM, Craig McQueen wrote: > > Craig McQueen added the comment: > > There's also this one which caught me out: > > def outer(): > x = 0 > y = (x for i in range(10)) > del x # SyntaxError > > -- > nosy: +cmcqueen1975 > > ___ > Python tracker > <http://bugs.python.org/issue4617> > ___ > ___ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu > > ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4617] SyntaxError when free variable name is also an exception target
Jeremy Hylton added the comment: On Mon, Feb 22, 2010 at 6:10 PM, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > All examples so far (*) have to do with our inability to have properly nested > blocks. If we did, I'd make the except clause a block, and I'd issue a syntax > warning or error if a nested block shadowed a variable referenced outside it. > Ditto for generator expressions and comprehensions. There's no reason we couldn't revise the language spec to explain that except clauses and comprehensions are block statements, i.e. statements that introduce a new block. For the except case, there would be some weird effects. y = 10 try: ... except SomeError as err: y = 12 print y # prints 10 In the example above, y would be a local variable in the scope of the except handler that shadows the local variable in the block that contains the try/except. It might be confusing that you couldn't assign to a local variable in the except handler without using a nonlocal statement. > As long as we don't have nested blocks, I think it's okay to see the > limitation on (implicit or explicit) "del" of a cell variable as a compiler > deficiency and fix that deficiency. The general request here is to remove all the SyntaxErrors about deleting cell variables, right? Instead, you'd get a NameError at runtime saying that the variable is currently undefined. You'd want that change regardless of whether we change the language as described above. hoping-for-some-bdfl-pronouncements-ly y'rs, Jeremy > __ > (*) However there's also this example: > >>>> def f(): > ... try: 1/0 > ... except Exception as a: > ... def g(): return a > ... return g > ... > SyntaxError: can not delete variable 'a' referenced in nested scope >>>> > > -- > > ___ > Python tracker > <http://bugs.python.org/issue4617> > ___ > -- ___ Python tracker <http://bugs.python.org/issue4617> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4617] SyntaxError when free variable name is also an exception target
Jeremy Hylton added the comment: The patch looks pretty good. I'd factor out the common error-checking code (common between LOAD_DEREF and DELETE_DEREF) into a helper function. It would also be good to add some test cases. Jeremy On Tue, Feb 23, 2010 at 9:38 AM, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > I don't think so. It's very marginal. > > --Guido (on Android) > > On Feb 23, 2010 8:52 AM, "Amaury Forgeot d'Arc" > wrote: > > Amaury Forgeot d'Arc added the comment: > > The above patch adds a new opcode (DELETE_DEREF), does the Moratorium apply > here? > > -- > > ___ > Python tracker > <http://bugs.python... > > -- > Added file: http://bugs.python.org/file16341/unnamed > > ___ > Python tracker > <http://bugs.python.org/issue4617> > ___ -- ___ Python tracker <http://bugs.python.org/issue4617> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4199] add shorthand global and nonlocal statements
Jeremy Hylton added the comment: Is deferred blocker a higher priority? Jeremy On Tue, Feb 23, 2010 at 4:37 PM, Georg Brandl wrote: > > Georg Brandl added the comment: > > "High" is not high enough :) > > -- > priority: high -> deferred blocker > > ___ > Python tracker > <http://bugs.python.org/issue4199> > ___ > -- ___ Python tracker <http://bugs.python.org/issue4199> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4199] add shorthand global and nonlocal statements
Jeremy Hylton added the comment: On Sat, Dec 6, 2008 at 1:28 PM, Benjamin Peterson wrote: > > Benjamin Peterson added the comment: > > I think I may have been merging add_ast_fields when I wrote the patch. > > Here's a new patch that handles "global x, = (5,)". To do it, I added a > new flag* to the Global and Nonlocal AST objects that indicates whether > the value needs to be unpacked or not. You shouldn't need to do this. The unpack is implied if the number of identifiers is greater than 1. Jeremy > * The flag is an int. The bool AST type was removed in py3k. > > Added file: http://bugs.python.org/file12254/global_nonlocal_shorthand2.patch > > ___ > Python tracker > <http://bugs.python.org/issue4199> > ___ > ___ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu > > -- ___ Python tracker <http://bugs.python.org/issue4199> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [issue4199] add shorthand global and nonlocal statements
I also notice that the Grammar in the PEP is more complicated:
nonlocal_stmt ::=
"nonlocal" identifier ("," identifier)*
["=" (target_list "=")+ expression_list]
| "nonlocal" identifier augop expression_list
The Grammar in the patch is:
+global_stmt: 'global' NAME (',' NAME)* [','] ['=' testlist]
+nonlocal_stmt: 'nonlocal' NAME (',' NAME)* [','] ['=' testlist]
It appears that the PEP is trying to support:
nonlocal x = y = z = 1
nonlocal a, b = c, d = 1
If we're going to support the PEP as written, I think we need to
modify Global() and Nonlocal() to look exactly like Assign(), but add
an extra check to verify that all of the expressions in the targets
are Name, List, or Tuple. You'd probably want to check this at the
time you are generating the AST, so that you're not stuck with some
extra state in the compiler traversal about whether you are generating
code for a Global() or an Assign().
This approach makes the compiler code very simple. We use exactly the
same code for Global(), Nonlocal(), and Assign(). It does have the
downside that you need to enforce this unwritten constraint of the AST
in ast.c and in the ast module.
It also means that the AST will change in a non-backwards compatible
way. I don't see how to do that given that we're also changing the
language spec. (Do you want to include the spec change in your
patch?)
Jeremy
On Tue, Feb 23, 2010 at 6:41 PM, Jeremy Hylton wrote:
> On Sat, Dec 6, 2008 at 1:28 PM, Benjamin Peterson
> wrote:
>>
>> Benjamin Peterson added the comment:
>>
>> I think I may have been merging add_ast_fields when I wrote the patch.
>>
>> Here's a new patch that handles "global x, = (5,)". To do it, I added a
>> new flag* to the Global and Nonlocal AST objects that indicates whether
>> the value needs to be unpacked or not.
>
> You shouldn't need to do this. The unpack is implied if the number of
> identifiers is greater than 1.
>
> Jeremy
>
>
>
>> * The flag is an int. The bool AST type was removed in py3k.
>>
>> Added file: http://bugs.python.org/file12254/global_nonlocal_shorthand2.patch
>>
>> ___
>> Python tracker
>> <http://bugs.python.org/issue4199>
>> ___
>> ___
>> Python-bugs-list mailing list
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>>
>>
>
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4199] add shorthand global and nonlocal statements
Jeremy Hylton added the comment:
I guess there's some question about whether the syntax in the PEP was
considered carefully when it was approved. If so, I'm not sure that
we want to re-open the discussion. On the other hand, it's been a
long time since the PEP was approved and we do have a moratorium on
language changes, so it doesn't hurt to slow things down.
I'd argue that the intent of the PEP is pretty clear. You can take
any assignment statement where the LHS doesn't have subscripts, put a
nonlocal or global in front of it, and it means that all those
assignments are to global/nonlocal variables.
Jeremy
On Wed, Feb 24, 2010 at 4:20 AM, Georg Brandl wrote:
>
> Georg Brandl added the comment:
>
>> I also notice that the Grammar in the PEP is more complicated:
>> nonlocal_stmt ::=
>> "nonlocal" identifier ("," identifier)*
>> ["=" (target_list "=")+ expression_list]
>> | "nonlocal" identifier augop expression_list
>>
>> The Grammar in the patch is:
>> +global_stmt: 'global' NAME (',' NAME)* [','] ['=' testlist]
>> +nonlocal_stmt: 'nonlocal' NAME (',' NAME)* [','] ['=' testlist]
>>
>> It appears that the PEP is trying to support:
>>
>> nonlocal x = y = z = 1
>> nonlocal a, b = c, d = 1
>
> It also tries to support augmented assignment; however I'm not sure what the
> semantics of that should be.
>
> Further, there is an ambiguity if too much freedom is allowed: what about
>
> global x = 1, y
>
> Is it declaring a global "x" and assigning a tuple, or declaring a global "x"
> and a global "y"?
>
>> If we're going to support the PEP as written, I think we need to
>> modify Global() and Nonlocal() to look exactly like Assign(), but add
>> an extra check to verify that all of the expressions in the targets
>> are Name, List, or Tuple. You'd probably want to check this at the
>> time you are generating the AST, so that you're not stuck with some
>> extra state in the compiler traversal about whether you are generating
>> code for a Global() or an Assign().
>
> I would not support List or Tuple as targets. Same basic problem as
> above, and I don't see a use case.
>
> I see two possibilities for the actual syntax:
>
> 1) global *either* supports multiple identifiers, *or* one identifier
> and an assignment.
>
> 2) global always supports multiple identifiers, each with an optional
> assignment; tuples need parentheses.
>
> In both cases, I would keep it simple and not allow multiple targets or
> augmented assignment.
>
> --
>
> ___
> Python tracker
> <http://bugs.python.org/issue4199>
> ___
>
--
___
Python tracker
<http://bugs.python.org/issue4199>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6500] urllib2 maximum recursion depth exceeded
Jeremy Hylton added the comment: Ok. I'll take a look, too. Jeremy On Sat, Feb 27, 2010 at 4:30 AM, Ezio Melotti wrote: > > Changes by Ezio Melotti : > > > -- > nosy: +orsenthil > status: pending -> open > > ___ > Python tracker > <http://bugs.python.org/issue6500> > ___ > -- ___ Python tracker <http://bugs.python.org/issue6500> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8069] struct documentation problem and suggestion to add fixed size formats
New submission from Jeremy Sanders :
The struct documentation at http://docs.python.org/library/struct.html says:
Standard size and alignment are as follows: no alignment is required for any
type (so you have to use pad bytes); short is 2 bytes; int and long are 4
bytes; long long (__int64 on Windows) is 8 bytes; float and double are 32-bit
and 64-bit IEEE floating point numbers, respectively. _Bool is 1 byte.
long on linux x86-64 is not 4 bytes. It is 8 bytes long:
xpc1:~:$ python
Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> struct.calcsize('L')
8
>>> struct.calcsize('l')
8
It is 4 bytes on i386, however. The documentation should say that long is 8
bytes on linux x86-64.
Also, would it not be a good idea to add struct sizes with specific data sizes,
e.g. 1 byte, 2 bytes, 4 bytes, 8 bytes, so that it is easier to write
cross-platform code?
--
components: Library (Lib)
messages: 100470
nosy: jeremysanders
severity: normal
status: open
title: struct documentation problem and suggestion to add fixed size formats
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue8069>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8069] struct documentation problem and suggestion to add fixed size formats
Jeremy Sanders added the comment: Sorry - I didn't read the docs clearly enough. This probably isn't a bug then. Can you mark it invalid? -- ___ Python tracker <http://bugs.python.org/issue8069> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2531] float compared to decimal is silently incorrect.
New submission from Jeremy Dunck <[EMAIL PROTECTED]>:
Within python 2.5.2:
>>> from decimal import Decimal
>>> x = 3.0
>>> y = Decimal('0.25')
>>> x > y
False (expected error, as in 2.4, or True)
--
components: Library (Lib)
messages: 64827
nosy: jdunck
severity: normal
status: open
title: float compared to decimal is silently incorrect.
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2531>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2531] float compared to decimal is silently incorrect.
Changes by Jeremy Dunck <[EMAIL PROTECTED]>: -- type: -> behavior __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2531> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2775] Implement PEP 3108
Jeremy Hylton <[EMAIL PROTECTED]> added the comment: I'm working on the new urllib package. -- nosy: +jhylton __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2775> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1346238] A constant folding optimization pass for the AST
Changes by Jeremy Hylton <[EMAIL PROTECTED]>: -- nosy: +jhylton _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1346238> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1524825] ConfigParser: accept leading whitespace on options+comments
Jeremy Thurgood <[EMAIL PROTECTED]> added the comment: This looks very much like a duplicate of issue 1714. Perhaps the two should be merged? -- nosy: +jerith _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1524825> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2775] Implement PEP 3108
Jeremy Hylton <[EMAIL PROTECTED]> added the comment: I think we should move robotparser into the urllib package. Anyone disagree? Jeremy __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2775> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1491] BaseHTTPServer incorrectly implements response code 100
Jeremy Thurgood <[EMAIL PROTECTED]> added the comment: Added handling for "Expect: 100-continue" header to BaseHTTPRequestHandler. By default, any request that has this header gets a 100 Continue response (with no other headers) before do_WHATEVER() is called. By overriding handle_expect_100(), you can reject incoming requests instead of sending a 100 Continue if you so desire. Refactoring as per comments above was also performed. Note: This patch changes the default behaviour in the case where both the client and the server claim to support HTTP/1.1 from doing nothing in the case of an "Expect: 100-continue" header on the request to sending a 100 Continue response and then completing the request as normal. -- keywords: +patch nosy: +jerith Added file: http://bugs.python.org/file10269/BaseHTTPServer_continue.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1491> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1491] BaseHTTPServer incorrectly implements response code 100
Jeremy Thurgood <[EMAIL PROTECTED]> added the comment: The above patch adds a set of tests for BaseHTTPServer, although the only tests actually written were those around the areas touched by the work done for this issue. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1491> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1348] httplib closes socket, then tries to read from it
Changes by Jeremy Hylton <[EMAIL PROTECTED]>: -- nosy: +jhylton __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1348> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4291] Allow Division of datetime.timedelta Objects
Jeremy Banks <[EMAIL PROTECTED]> added the comment: Sorry, allowing for conversion to int/float is probably a more sensible solution. This idea was brought to my mind when I was making a very very simple script for a friend to display how far through a time range we currently are. For example: elapsed = datetime.timedelta(hours=4, days=3) duration = datetime.timedelta(days=30) percentage = (100 * elapsed / duration) In my case, precision wasn't important so I just divided elapsed.days by duration.days, but it would be continent to have an accurate result by just writing what I did above. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4291> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4291] Allow Division of datetime.timedelta Objects
New submission from Jeremy Banks <[EMAIL PROTECTED]>: It would be convenient if it were possible to divide one datetime.timedelta object by another to determine their relative durations. Were the datetime module pure Python a crude solution would just be to add two methods like this: def toMicroseconds(self): return ((self.days * 24 * 60) + self.seconds * 100) + self.microseconds def __truediv__(self, other): return self.toMicroseconds() / other.toMicroseconds() However, I don't understand know the Python C API well enough to know how to patch the C module. -- components: Library (Lib) messages: 75670 nosy: Jeremy Banks severity: normal status: open title: Allow Division of datetime.timedelta Objects type: feature request ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4291> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4291] Allow Division of datetime.timedelta Objects
Jeremy Banks <[EMAIL PROTECTED]> added the comment: Thanks, I should have paid more attention to the results when I searched for duplicates. I think that Christian's suggestion of enabling float() and int() for timedeltas is worth having here, though. -- nosy: -christian.heimes ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4291> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4327] Patch: simplify complex constant assignment statements
Jeremy Hylton <[EMAIL PROTECTED]> added the comment: It seems generally useful to have a helper function to replace a range of nodes in a sequence of statements with another sequence of nodes. A general API like that would allow you to insert or delete nodes as well as replacing one node with a set of nodes. It seems like that could be implemented pretty independently of this patch, and would then simplify it. I don't think it's a good idea to add the Seq type just to simplify the implementation. -- nosy: +jhylton ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4327> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [issue4327] Patch: simplify complex constant assignment statements
On Mon, Nov 24, 2008 at 12:14 PM, David Turner <[EMAIL PROTECTED]> wrote: > > David Turner <[EMAIL PROTECTED]> added the comment: > > jhylton, keep in mind that this would require an additional "parent" > argument to each function which takes a stmt. Do you think this added > complexity is worth it? Or we could add parent pointers in the tree, right? Jeremy > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue4327> > ___ > ___ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu > > ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4336] Fix performance issues in xmlrpclib
Jeremy Hylton <[EMAIL PROTECTED]> added the comment: This patch makes sense in principle, but some of the details need to change. The _send_output() method is used by some clients, merely because it can be used :-(. It's fairly easy to preserve this API for backwards compatibility. I am also worried about this new api call getheaderdata(). It complicates the API. Even if it were necessary, it needs a better name, because getheaderdata() doesn't sound like a method that changes the connection state or consumes buffered header data. I think it would be better to have the new behavior exposed only through HTTPConnection and not HTTP, since that's a Python 1.5.2 compatibility API(!). We can make some small changes to xmlrpclib to use the newer API. It would probably be a good change merely because py3k now uses the newer API. I've got a working local change, but it's still a little ugly. -- assignee: -> jhylton nosy: +jhylton status: open -> pending ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4336> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4336] Fix performance issues in xmlrpclib
Jeremy Hylton <[EMAIL PROTECTED]> added the comment: Just wanted to mention that the best solution is to update as much code as possible to use HTTPConnection instead of HTTP. I'm not sure how easy it is to do for xmlrpclib, since it exposes methods like send_content(). I guess we can preserve those APIs somehow, but it won't be pretty. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4336> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4327] Patch: simplify complex constant assignment statements
Jeremy Hylton <[EMAIL PROTECTED]> added the comment: I haven't thought about the code in a while, but what code that modifies the AST are we worried about? There are lots of modifications in ast.c, since it is being created there. The case we really care about is sequences, where we want to modify the sequence. The creation goes through macros like asdl_seq_SET(), so we could just change the macro. What are other cases we need to worry about? Jeremy On Mon, Nov 24, 2008 at 12:50 PM, David Turner <[EMAIL PROTECTED]> wrote: > > David Turner <[EMAIL PROTECTED]> added the comment: > > Sure, but that's an even bigger change. Every piece of code which > modifies the AST would now also have to modify parent pointers. Having > the pointers would make many things easier, but I didn't want to make a > very invasive change like that without thinking it through thoroughly. > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue4327> > ___ > ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4327> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [issue4336] Fix performance issues in xmlrpclib
Actually, the patch doesn't work :-). The httplib API allows you to pass a file or a string for the body of the request. The getheaderdata() + body case only works for the string. Easy to fix, but I worry that he still run into Nagle problems with the file case, which was presumably added for efficiency. Jeremy On Mon, Nov 24, 2008 at 12:32 PM, Jeremy Hylton <[EMAIL PROTECTED]> wrote: > > Jeremy Hylton <[EMAIL PROTECTED]> added the comment: > > This patch makes sense in principle, but some of the details need to > change. The _send_output() method is used by some clients, merely > because it can be used :-(. It's fairly easy to preserve this API for > backwards compatibility. > > I am also worried about this new api call getheaderdata(). It > complicates the API. Even if it were necessary, it needs a better name, > because getheaderdata() doesn't sound like a method that changes the > connection state or consumes buffered header data. > > I think it would be better to have the new behavior exposed only through > HTTPConnection and not HTTP, since that's a Python 1.5.2 compatibility > API(!). We can make some small changes to xmlrpclib to use the newer > API. It would probably be a good change merely because py3k now uses > the newer API. > > I've got a working local change, but it's still a little ugly. > > -- > assignee: -> jhylton > nosy: +jhylton > status: open -> pending > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue4336> > ___ > ___ > Python-bugs-list mailing list > Unsubscribe: > http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu > > ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1208304] urllib2's urlopen() method causes a memory leak
Jeremy Hylton <[EMAIL PROTECTED]> added the comment: Python 2.4 is now in security-fix-only mode. No new features are being added, and bugs are not fixed anymore unless they affect the stability and security of the interpreter, or of Python applications. http://www.python.org/download/releases/2.4.5/ This bug doesn't rise to the level of making into a 2.4.6. -- nosy: +jhylton resolution: -> wont fix status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1208304> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
