Re: [Python-Dev] What's required to keep OS/2 support in Python 3.3
On 07/01/12 08:22, Paul Smedley wrote: For the purpose of debugging you could *not* ignore the error and instead print it out or bail out. Thanks - commenting out the ImportErrors block, I get: ImportError: No module named encodings OK got through this - PYTHONPATH in makefile was borked for OS/2 (: separators vs ; which don't work so well with drive letters) Now having trouble importing the _io module even though it's builtin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's required to keep OS/2 support in Python 3.3
On 08/01/12 19:07, Paul Smedley wrote: On 07/01/12 08:22, Paul Smedley wrote: For the purpose of debugging you could *not* ignore the error and instead print it out or bail out. Thanks - commenting out the ImportErrors block, I get: ImportError: No module named encodings OK got through this - PYTHONPATH in makefile was borked for OS/2 (: separators vs ; which don't work so well with drive letters) Now having trouble importing the _io module even though it's builtin to be clear, the error is: Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "U:/DEV/python-3.2.2/Lib/io.py", line 60, in Killed by SIGABRT ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's required to keep OS/2 support in Python 3.3
On 08/01/12 19:12, Paul Smedley wrote:
On 08/01/12 19:07, Paul Smedley wrote:
On 07/01/12 08:22, Paul Smedley wrote:
For the purpose of debugging you could *not* ignore the error and
instead print it out or bail out.
Thanks - commenting out the ImportErrors block, I get:
ImportError: No module named encodings
OK got through this - PYTHONPATH in makefile was borked for OS/2 (:
separators vs ; which don't work so well with drive letters)
Now having trouble importing the _io module even though it's builtin
to be clear, the error is:
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
File "U:/DEV/python-3.2.2/Lib/io.py", line 60, in
Killed by SIGABRT
and it's dying in _iomodule.c at:
/* put os in the module state */
state->os_module = PyImport_ImportModule("os");
if (state->os_module == NULL){
fprintf(stderr,"_iomodule fail\n");
goto fail;}
for some reason.. at least I'm slowly making progress :P (I think)
Cheers,
Paul
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] usefulness of Python version of threading.RLock
> The yes/no answer is "No, we can't drop it". Thanks, that's a clear answer :-) > I'm not convinced of the benefits of removing the pure Python RLock > implementation Indeed. As noted, this issue with signal handlers is more general, so this wouldn't solve the problem at hand. I just wanted to know whether we could remove this "duplicate" code, but since it might be used by some implementations, it's best to keep it. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A question about the subprocess implementation
Phil Vandry TZoNE.ORG> writes: > proc.stdin, proc.stdout, and proc.stderr aren't meant to be a reference > to the file that got connected to the subprocess' stdin/stdout/stderr. > They are meant to be a reference to the OTHER END of the pipe that got > connected. Of course, and I've been using them like that, in general. But reading those two sentences above made the light bulb come on :-) Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Hash collision security issue (now public)
In http://mail.python.org/pipermail/python-dev/2012-January/115368.html Stefan Behnel wrote: > Admittedly, this may require some adaptation for the PEP393 unicode memory > layout in order to produce identical hashes for all three representations > if they represent the same content. They SHOULD NOT represent the same content; comparing two strings currently requires converting them to canonical form, which means the smallest format (of those three) that works. If it can be represented in PyUnicode_1BYTE_KIND, then representations using PyUnicode_2BYTE_KIND or PyUnicode_4BYTE_KIND don't count as canonical, won't be created by Python itself, and already compare unequal according to both PyUnicode_RichCompare and stringlib/eq.h (a shortcut used by dicts). That said, I don't think smallest-format is actually enforced with anything stronger than comments (such as in unicodeobject.h struct PyASCIIObject) and asserts (mostly calling _PyUnicode_CheckConsistency). I don't have any insight on how prevalent non-conforming strings will be in practice, or whether supporting their equality will be required as a bugfix. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
On Sun, Jan 8, 2012 at 16:33, Jim Jewett wrote: > In http://mail.python.org/pipermail/python-dev/2012-January/115368.html > Stefan Behnel wrote: Can you please configure your mail client to not create new threads like this? As if this topic wasn't already hard enough to follow, it now exists across handfuls of threads with the same title. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Backed out changeset 36f2e236c601: For some reason, rewinddir() doesn't work as
On Mon, Jan 9, 2012 at 5:31 AM, charles-francois.natali wrote: > Backed out changeset 36f2e236c601: For some reason, rewinddir() doesn't work > as > it should on OpenIndiana. Can rewinddir() end up touching the filesystem to retrieve data? I noticed that your previous change (the one this checkin reverted) moved it outside the GIL release macros. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Backed out changeset 36f2e236c601: For some reason, rewinddir() doesn't work as
2012/1/8 Nick Coghlan : > On Mon, Jan 9, 2012 at 5:31 AM, charles-francois.natali > wrote: >> Backed out changeset 36f2e236c601: For some reason, rewinddir() doesn't >> work as >> it should on OpenIndiana. > > Can rewinddir() end up touching the filesystem to retrieve data? I > noticed that your previous change (the one this checkin reverted) > moved it outside the GIL release macros. It just resets a position count. (in glibc). -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] py3benchmark not working
Hello,
I tried to compare the py3k baseline with my randomhash branch but the
benchmark suite is failing.
I've follewed the instruction
# hg clone http://hg.python.org/benchmarks/ py2benchmarks
# mkdir py3benchmarks;
# cd py3benchmarks
# ../py2benchmarks/make_perf3.sh ../py2benchmarks
# python3.1 perf.py -b py3k old_py3k new_py3k
but the suite immediately bails out:
$ ../3.1/python perf.py -r -b default ../py3k/python ../randomhash/python
Running 2to3...
INFO:root:Running ../py3k/python lib/2to3/2to3 -f all lib/2to3_data
Traceback (most recent call last):
File "perf.py", line 2236, in
main(sys.argv[1:])
File "perf.py", line 2192, in main
options)))
File "perf.py", line 1279, in BM_2to3
return SimpleBenchmark(Measure2to3, *args, **kwargs)
File "perf.py", line 706, in SimpleBenchmark
*args, **kwargs)
File "perf.py", line 1275, in Measure2to3
return MeasureCommand(command, trials, env, options.track_memory)
File "perf.py", line 1223, in MeasureCommand
CallAndCaptureOutput(command, env=env)
File "perf.py", line 1053, in CallAndCaptureOutput
raise RuntimeError("Benchmark died: " + str(stderr, 'ascii'))
RuntimeError: Benchmark died: RefactoringTool: Skipping implicit fixer:
buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
Traceback (most recent call last):
File "lib/2to3/2to3", line 5, in
sys.exit(main("lib2to3.fixes"))
File
"/media/ssd/heimes/python/py3benchmarks/lib/2to3/lib2to3/main.py", line
173, in main
options.processes)
File
"/media/ssd/heimes/python/py3benchmarks/lib/2to3/lib2to3/refactor.py",
line 700, in refactor
items, write, doctests_only)
File
"/media/ssd/heimes/python/py3benchmarks/lib/2to3/lib2to3/refactor.py",
line 294, in refactor
self.refactor_dir(dir_or_file, write, doctests_only)
File
"/media/ssd/heimes/python/py3benchmarks/lib/2to3/lib2to3/refactor.py",
line 314, in refactor_dir
self.refactor_file(fullname, write, doctests_only)
File
"/media/ssd/heimes/python/py3benchmarks/lib/2to3/lib2to3/refactor.py",
line 741, in refactor_file
*args, **kwargs)
File
"/media/ssd/heimes/python/py3benchmarks/lib/2to3/lib2to3/refactor.py",
line 349, in refactor_file
tree = self.refactor_string(input, filename)
File
"/media/ssd/heimes/python/py3benchmarks/lib/2to3/lib2to3/refactor.py",
line 381, in refactor_string
self.refactor_tree(tree, name)
File
"/media/ssd/heimes/python/py3benchmarks/lib/2to3/lib2to3/refactor.py",
line 455, in refactor_tree
new = fixer.transform(node, results)
File
"/media/ssd/heimes/python/py3benchmarks/lib/2to3/lib2to3/fixes/fix_operator.py",
line 43, in transform
method = self._check_method(node, results)
File
"/media/ssd/heimes/python/py3benchmarks/lib/2to3/lib2to3/fixes/fix_operator.py",
line 89, in _check_method
method = getattr(self, "_" + results["method"][0].value.encode("ascii"))
TypeError: Can't convert 'bytes' object to str implicitly
Christian
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py3benchmark not working
On Mon, 09 Jan 2012 02:01:46 +0100 Christian Heimes wrote: > > I tried to compare the py3k baseline with my randomhash branch but the > benchmark suite is failing. > > I've follewed the instruction For the record, you don't really need this. Just run the "2n3" benchmark set (it works under both 2.x and 3.x). The "py3k" set will include a couple more/other benchmarks though. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python as a Metro-style App
On Sat, Jan 7, 2012 at 2:57 PM, Antoine Pitrou wrote: > Depending on the extent of removed/disabled functionality, it might not > be very interesting to have a Metro port at all. Win 8 is practically a new OS target - the nt module may need to be replaced with a metro module to handle it well. Accessing the WinRT APIs directly from Python will also require a set of Python projections for the API, which should be straightforward to generate from the WinRT metadata files. I know Dino Viehland did some work on that; not sure if he can elaborate or not though. Otherwise, IronPython would be the only option for writing Metro apps in Python - not that I'd be *horribly* upset at that :). IronPython is slowly growing Metro support, and it seems like most things will work, but the .NET framework shields it from a lot of the WinRT guts. - Jeff ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
