Ronald Oussoren added the comment:
I intend to commit my latest version of the patch during the europython
sprints, with a minor change: don't include dump(s) and load(s), that change
(and the other items on "open issues" in my last post) can be
Ronald Oussoren added the comment:
Note that the OSX port already does this for framework builds. I don't know why
we don't use the same code for shared library builds.
Issue #15498 contains a patch that switches this code from a deprecated
nextstep-era API to dladdr.
Two comme
Ronald Oussoren added the comment:
Any review would be greatly appreciated. One thing I'm not too happy about is
the use of magic numbers in the binary plist support code, but I think that
using constants or a dispatch table would not make the code any cl
Ronald Oussoren added the comment:
I've attached a slightly updated version of the patch. The documentation now
lists dump and load as the primary API, with the old API as a deprecated
alternative.
The code hasn't been changed to relect this yet, but does contain a number of
Ronald Oussoren added the comment:
This version should be better:
* There should be no lines longer than 80 characters
* Changed coding style of the (private) XML plist writer classes
to PEP8
* Public API is now dump/dumps and load/loads, the old API is still
available and deprecated
Ronald Oussoren added the comment:
Issue #8828 adds a new API to the os module, as such it is inappropriate for a
back port (no new features in stable releases)
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue18
Ronald Oussoren added the comment:
Updated version of the patch, with some semantic changes and tests for the
Python level API.
Known issues:
* Patches uses tabs for indentation
* No tests for the C level API
* I don't like implementation of slot_tp_getattro_super
--
Added
Changes by Ronald Oussoren :
Removed file: http://bugs.python.org/file30546/issue-18181-poc.txt
___
Python tracker
<http://bugs.python.org/issue18181>
___
___
Python-bug
Changes by Ronald Oussoren :
Removed file: http://bugs.python.org/file30555/issue-18181-poc-v3.txt
___
Python tracker
<http://bugs.python.org/issue18181>
___
___
Pytho
Changes by Ronald Oussoren :
Removed file: http://bugs.python.org/file30528/supers.py
___
Python tracker
<http://bugs.python.org/issue18181>
___
___
Python-bugs-list m
Changes by Ronald Oussoren :
Removed file: http://bugs.python.org/file30556/super-hook-proposal.rst
___
Python tracker
<http://bugs.python.org/issue18181>
___
___
Pytho
Ronald Oussoren added the comment:
Also updated the draft PEP text
--
Added file: http://bugs.python.org/file30767/super-hook-proposal.rst
___
Python tracker
<http://bugs.python.org/issue18
Ronald Oussoren added the comment:
This is a duplicate of #18021
--
nosy: +ronaldoussoren
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
superseder: -> Update broken link to Apple Publication Style Guide
type:
Changes by Ronald Oussoren :
Removed file: http://bugs.python.org/file30526/plistlib_generate_testdata.py
___
Python tracker
<http://bugs.python.org/issue14455>
___
___
Ronald Oussoren added the comment:
Updated test-data generator: it now encodes the data using base64, to
make it easier to generate a file with limited line lengths.
--
Added file: http://bugs.python.org/file30790/plistlib_generate_testdata.py
Ronald Oussoren added the comment:
v8 of the patch contains 1 change from v7: the test data is encoded
in base64. This was primarily done to ensure that the file has
usable line lengths. A nice side effect is that it is now harder than
ever to manually change the test data, as the comment
Ronald Oussoren added the comment:
The documentation for 3.3 and default now explicitly mentions that the std*
streams are opened as binary streams when universal_newlines is false.
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -&g
Ronald Oussoren added the comment:
I intend to apply this patch to default (and only that branch) after running
the testsuite and with a small change: the stack size will be 0x100 (double
it current value) to sync it with the stack size for the main thread, which was
recently set to that
Ronald Oussoren added the comment:
Good question, the libffi copy included with cpython has recently changed.
There are HP-UX buildbots, but they have build problems. I'll try to test on an
HP-UX system I've access to.
--
___
Python trac
Changes by Ronald Oussoren :
--
nosy: +ned.deily
___
Python tracker
<http://bugs.python.org/issue5262>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ronald Oussoren :
--
assignee: ronaldoussoren ->
___
Python tracker
<http://bugs.python.org/issue8410>
___
___
Python-bugs-list mailing list
Un
Ronald Oussoren added the comment:
So much for testing, the machine I'm trying to test on is fairly old and
doesn't have an up to date compiler. That compiler crashes when trying to build
the 2.7.5 release :-(
--
___
Python trac
Ronald Oussoren added the comment:
Download link for the latest version:
http://opensource.apple.com/tarballs/libedit/libedit-31.tar.gz
The archive only includes an Xcode based build system, the makefile based
system was removed some time ago.
It might be better to use
<h
Ronald Oussoren added the comment:
I propose to close this issue because this is likely a bug in a beta version of
OSX and that's not something we'll try to work around in the python sources.
--
___
Python tracker
<http://bugs.python.o
Ronald Oussoren added the comment:
I'm not sure what's going on here, the build already seems to behave correctly.
What I've done:
* Create a python installation in /opt/python2.7
(configure --prefix=/opt/python2.7; make; make install)
* Now build and the tip of the
Ronald Oussoren added the comment:
Also the compiler invocations looks fine:
for the main build:
...
clang -c -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g
-fwrapv -O3 -Wall -Wstrict-prototypes -Wno-unused-value -Wno-empty-body
-Qunused-arguments-I. -IInclude -I
Ronald Oussoren added the comment:
Have you heard anything from Apple? If you have a radar number I could try to
ping someone at Apple.
I'd be in favor of working around this issue in posixmodule.c if they don't
respond or if they won't fix the issue in 10.8 (and I wouldn&#x
Ronald Oussoren added the comment:
This bug is ancient by now, but not fixed. I've reproduced the issue with a
recent release of Python and the problem is an encoding exception in
Objective-C:
2013-07-06 12:17:20.511 Python Launcher[43030:f0b] *** Terminating app due to
uncaught exce
Changes by Ronald Oussoren :
--
versions: +Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue12990>
___
___
Python-bugs-list mailin
Ronald Oussoren added the comment:
I've commit a fix for this problem in the branches for 2.7, 3.3 and the
upcoming 3.4 release. This means the problem will be fixed in the next releases
from those branches.
--
resolution: -> fixed
stage: test needed -> committed/reje
New submission from Ronald Oussoren:
While working on a Python Launcher issue (#12990) I noticed some compiler
warnings for Python Launcher.
The attached patch removes those warnings, and cleans up some indentation
issues.
Ned: do you have an opinion on applying this to the 3.3 and 2.7
Changes by Ronald Oussoren :
--
versions: +Python 3.3, Python 3.4 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue10735>
___
___
Python-bugs-list m
Ronald Oussoren added the comment:
The bytes_methods.h issue is not present in the default branch, but is still
present in the 2.7 branch. I'm not sure why those defines are there, I'm adding
Gregory P. Smith to the nosy list because he added the defines and might
remember why they
Ronald Oussoren added the comment:
The example uses unions, which libffi doesn't really support (see for example
<https://github.com/atgreen/libffi/issues/33>).
There is an issue in the python tracker about union support in ctypes: #16575.
FWIW. I can still reproduce the issue wit
Ronald Oussoren added the comment:
Strange, I have LANG=en_US.UTF-8 in my environment and no LC_CTYPE. A clean
test account does have the same behavior as you are seeing.
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.
Ronald Oussoren added the comment:
The UTF-8 value seems suspect to me, but is actually supported by the system,
changing it to a nonsense value results in failure in the C function setlocale.
As for the patch: I'd add this workaround only to the OSX platform (that is,
test for sys.pla
Ronald Oussoren added the comment:
Is this still an issue? I won't be able to look into this until I get home from
EP, I didn't bring my disk with virtual machines to the conference.
--
___
Python tracker
<http://bugs.python.o
Ronald Oussoren added the comment:
Sigh... The crash is a subprocess started with fork is not entirely unexpected,
although I had hoped that the current version of _scproxy would be safe enough.
A number of Apple frameworks detect that a process called fork after they
initialized and then
Ronald Oussoren added the comment:
The test for darwin is needed because other platforms don't support "UTF-8" as
a valid LC_CTYPE name, on a recent linux box:
>>> locale.setlocale(locale.LC_CTYPE, "UTF-8")
Traceback (most recent call last):
File "&q
Ronald Oussoren added the comment:
I've some more digging to do then, although I expect that nobody knows anymore
why the #define's are there. It should be safe to remove them by now, and they
are not present in the default branch.
--
Changes by Ronald Oussoren :
Removed file: http://bugs.python.org/file21243/issue-11445.txt
___
Python tracker
<http://bugs.python.org/issue11445>
___
___
Python-bug
Ronald Oussoren added the comment:
I've attached an updated patch (against the 2.7 branch, the same idea should
work for 3.3 and default).
This does two things:
1) Explicity add '-Wl,-search_paths_first' to LDFLAGS on Mac OS X.
This ensures that the linker behaves like
Ronald Oussoren added the comment:
Creating flat packages should be easy enough, I'm hoping to experiment with
them during the sprints at EP (but we're already at the end of the first day).
At first I feared that creating installers in the new format would require
using GUI to
Ronald Oussoren added the comment:
I just created a very crude package with the "new" tools.
$ pkgbuild --analyze --root /tmp/_py/_root pkgbuild.plist
...
$ pkgbuild --root /tmp/_py/_root --identifier org.python.python34
--component-plist pkgbuild.plist pythoninstall.pkg
pkgbuil
Ronald Oussoren added the comment:
Also worthwhile to look into:
http://s.sudre.free.fr/Software/Packages/about.html
This is a GUI tool for creating packages, with a command-line tool for
scripting. At the very least we could use this to check if it is possible to
build a flat installer that
Changes by Ronald Oussoren :
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ronald Oussoren added the comment:
Ned: is this still relevant? On first glance the patch has not been applied
yet, but the funtionality may have been added in another form.
Also, I don't agree with the removal of group write-permissions. The current
permissions allow users with
Ronald Oussoren added the comment:
I'm closing this issue because I haven't been able to reproduce and the issue
doesn't contain enough information to determine the cause of the crash (the
buildbot logs are gone by now, and probably wouldn't have contained the
require
Ronald Oussoren added the comment:
I'm revisiting some old issues, and while I don't mind adding workarounds to
the various scripts I do not consider this to be a bug. This is unexpected
behavior from the platform, and only affects running scripts from the
command-line (bundling the
Ronald Oussoren added the comment:
This is IMHO a release blocker: the the shell-script version of python-config
doesn't work on a major platform (OSX), and (older) commercial unix systems.
The easiest workaround is to remove the shell script and keep using the python
script.
--
New submission from Ronald Oussoren:
In OSX 10.8 the Gestalt() funtion in CoreServices is deprecated. This function
is used in the _gestalt extension and exported to Python code.
The only in-tree user of this (private) extension is the platform module, it
uses gestalt as one of the
Ronald Oussoren added the comment:
Interestingly enough it seems to hang while handling an import error, when I
break executation and look at the stack trace I see (amongst others):
#5 0x0001000b11f1 in import_all_from [inlined] () at
/Users/ronald/Projects/python/rw/default/Python
Ronald Oussoren added the comment:
Why use a shell script in the first place? The shell script doesn't do
everything the python script does (an example of this is that on OSX distutils
and sysconfig can tweak the CFLAGS and LDFLAGS as needed based on the curent
OSX version and the inst
Changes by Ronald Oussoren :
Removed file: http://bugs.python.org/file18266/smime.p7s
___
Python tracker
<http://bugs.python.org/issue5262>
___
___
Python-bugs-list mailin
Changes by Ronald Oussoren :
--
priority: normal -> low
versions: +Python 3.4 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue5262>
___
___
Python-
Ronald Oussoren added the comment:
This should do the trick, the shell script version is replaced by the python
version when building on OSX.
And yes, the use of readlink is guarded but that doesn't help because you then
use a command-line flag that isn't supported on OSX:
$ r
Ronald Oussoren added the comment:
Sorry about the confusion, "-f" isn't supported either that's why I noticed
there is a problem.
$ readlink -f .
readlink: illegal option -- f
usage: readlink [-n] [file ...]
Again, why is does does have to be a shell script anyway?
I r
Ronald Oussoren added the comment:
Matthias: sorry, I completely missed the message where you explained why the
script is now a shell script.
The customization is performed by _osx_xsupport.customize_config_vars.
What this is used for:
* We ship binaries build with a specific compiler
Ronald Oussoren added the comment:
I thinking about closing this issue, but need to do some more research before
doing so. In particular, I need to check the behavior of double clicking on
python files on Windows and the main Linux desktops. IIRC double clicking a .py
file on Windows will
Ronald Oussoren added the comment:
Right. And I'm even more sensitive as usual about that after reading webpage
that appearently popular with newbies and explains that you install Python by
first removing /System/Library/Frameworks/Python.framework. I still can't
understand that
Changes by Ronald Oussoren :
--
assignee: ronaldoussoren ->
components: -Macintosh
___
Python tracker
<http://bugs.python.org/issue18401>
___
___
Python-
Ronald Oussoren added the comment:
The file not even empty, it doesn't even exist in default installations.
As Ned mentioned the CA roots on OSX are stored in a system database (the
keychain). The situation is more or less the same as on Windows: their either
needs to be code that querie
Ronald Oussoren added the comment:
The attached patch removes the use of the Gestalt API.
The removed code is effectively dead, I yet have to find a machine were
platform._mac_ver_xml does not work and the gestalt based code only gets used
when the XML variant does not work
Ronald Oussoren added the comment:
Do we follow the deprecation procedure for private functions as well?
The patch removes a private and undocumented extension, and removes a private
function that uses that extension. There is no change in the public API.
Also, as I mentioned before the
Ronald Oussoren added the comment:
I had hoped to just drop it in 3.4.
To remove:
* extension _gestalt
* function platform._mac_ver_gestalt
* function platform._mac_ver_lookup (only used by ^^^)
* function platform._bcd2str (likewise)
To change:
* function platform.mac_ver: remove call to
Ronald Oussoren added the comment:
Actually attach the latest version of the patch.
--
Added file: http://bugs.python.org/file30874/issue-14455-v8.txt
___
Python tracker
<http://bugs.python.org/issue14
Ronald Oussoren added the comment:
Two small technical comments:
1) I'd add a configure or compile-time check to determine if the procfs
interface might be available. I don't like probing for features that
you know are not available.
2) MacOSX has simular functionality usi
Ronald Oussoren added the comment:
There's an annoyingly long discussion about sum() on python-ideas.
IMHO the documentation should mention, as it does now, that sum is intended to
be used with a sequence of numbers even it does work with most objects that
support the + operator (such
Ronald Oussoren added the comment:
Yes, the docstring isn't meant to be exhaustive documentation. The manual is
more exhaustive and, as you noted, already contains links to alternatives.
--
___
Python tracker
<http://bugs.python.org/is
Ronald Oussoren added the comment:
Isn't this because the first entry of sys.path is '' when python is started
without a script? All other paths on sys.path are already absolute paths
(tested with a relative path in $PYTHONPATH).
If that's correct, just adding os.getcwd()
Ronald Oussoren added the comment:
Appending a sequence of lists with sum is inefficient because it (currently)
does a lot of copying, and that gets noticable when you sum a larger number of
lists
Note how using sum for add 200 lists is more than twice as long as adding 100
lists:
ronald
Ronald Oussoren added the comment:
I agree: target_len should have type Py_ssize_t.
It's probably worthwhile to check other functions as well.
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/is
Ronald Oussoren added the comment:
There is also this one in string_print:
fwrite(data, 1, (int)size, fp);
"size" is a Py_ssize_t variable with the length of the string, and is casted to
int which looses information. The exected argument to fwrite is size_t...
These two ap
Ronald Oussoren added the comment:
The attached patch should fix both issues (but doesn't contain a test, not sure
if its worthwhile to add a testcase that uses more than 4 GByte of memory)
FWIW: the corresponding code in Objects/bytesobject.c in the 3.3 and default
branches is al
Ronald Oussoren added the comment:
Great. I'll apply after running the full testsuite, and after rebooting my
machine as it doesn't really like using that much additional memory and pushed
some applications to disk :-(
--
___
Python trac
Changes by Ronald Oussoren :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Ronald Oussoren :
--
assignee: ronaldoussoren ->
___
Python tracker
<http://bugs.python.org/issue18455>
___
___
Python-bugs-list mailing list
Un
Ronald Oussoren added the comment:
IIRC the key bindings that are currently used on OSX basicly are partially
based on the key bindings on "classic macos", and partially on using the CMD
key instead of the ALT key.
It would be nice to have a clean set of key bindings for OSX that&
New submission from Ronald Oussoren:
Modules/readline.c contains a workaround for a bug in the readline emulation of
libedit: that emulation uses a different starting offset for the history than
the real readline.
In more recent versions of libedit (such as the one you can now download from
Ronald Oussoren added the comment:
(set as "crash" because the current workaround causes a crash with recent
versions of libedit)
--
keywords: +needs review, patch
stage: -> patch review
type: -> crash
___
Python tracker
<htt
New submission from Ronald Oussoren:
Modules/readline.c contains some code that improves interop with the readline
emulation in libedit. That interop code is currently guarded by '#ifdef
__APPLE__' preprocessor tests.
This should be replaced by '#if HAVE_LIBEDIT' to mak
Ronald Oussoren added the comment:
I can confirm the problem and that the patch fixes the issue.
I'll try to commit a fix later this week.
--
versions: +Python 3.4 -Python 3.2
___
Python tracker
<http://bugs.python.org/is
Ronald Oussoren added the comment:
There now is a PEP for this issue: <http://www.python.org/dev/peps/pep-0447/>.
The current version of the PEP describes a different API than documented by the
attached proposal and the prove of concept code. I'm working on an updated
imp
Ronald Oussoren added the comment:
issue18181-locallookup-only-super.txt implements the current version of PEP
447, but only for the super object. In this version of the patch normal
attribute lookup (object.__getattribute__ and PyObject_GenericGetAttr) are not
yet affected.
Another open
Ronald Oussoren added the comment:
Serhiy: you're right. I've moved the message to the correct section.
--
___
Python tracker
<http://bugs.python.o
Ronald Oussoren added the comment:
I won't backport to 3.3 or 2.7, it is highly unlikely that the API will
actually be removed anytime soon.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Ronald Oussoren added the comment:
Raymond: good to hear that using fn+F5 is not a problem for new users
--
___
Python tracker
<http://bugs.python.org/issue18
Ronald Oussoren added the comment:
I no longer particularly like my patch, although something needs to be done.
The easiest way forward is likely a (private) helper function in the readline
module that can translate simple readline configuration strings to something
that libedit understands
New submission from Ronald Oussoren:
The _elementtree extension calls PyType_Ready for most, but not all, types
defined in the extension. The attached patch calls PyType_Ready for the
ElementIter_Type.
--
components: Extension Modules, XML
files: elementtree-missing-type-ready.txt
Changes by Ronald Oussoren :
--
keywords: +needs review, patch
___
Python tracker
<http://bugs.python.org/issue18480>
___
___
Python-bugs-list mailing list
Unsub
Ronald Oussoren added the comment:
It was a pretty easy catch, the _elementtree caused a crash while I was working
on an implementation for PEP 447. The missing call to PyType_Ready helped to
make that implementation more robust :-)
I'm not entirely convinced that adding forward declara
Ronald Oussoren added the comment:
issue-18181-full-v1.txt implements support for __locallookup__ to both super
and _PyType_Lookup and should implement the entire PEP.
The patch is not yet 100% and is missing:
* Tests that add __locallookup__ to a metaclass at runtime, should
enable the
Changes by Ronald Oussoren :
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue16405>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Ronald Oussoren :
--
assignee: -> ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue18480>
___
___
Python-bugs-list mailing list
Un
Changes by Ronald Oussoren :
--
keywords: -needs review
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ronald Oussoren added the comment:
Building just the readline extension shouldn't be that hard, using a small
custom setup.py script. Then install by manually copying it to the right
location.
And no, I don't work for Apple.
--
___
Pyth
Ronald Oussoren added the comment:
As mentioned on python-dev the current behavior seems sane.
1) Just like __getitem__ and __setitem__, __contains__ raises an
exception when the key value cannot be used as a key (which normally
is a programming error)
2) There are values that compare
Ronald Oussoren added the comment:
I agree, and the thread on python-dev[1] also came to that conclusion, I'm
therefore closing this issue.
[1] http://code.activestate.com/lists/python-dev/123385/
--
resolution: -> invalid
stage: -> committed/rejected
status: ope
Ronald Oussoren added the comment:
I cannot reproduce this with a recent 2.7 build from mercurial, but can
reproduce with /usr/bin/python (2.7.2) on OSX 10.8 and python 2.7.3 on Centos
6.4 system.
--
nosy: +ronaldoussoren
versions: +Python 2.7 -Python 2.6
Ronald Oussoren added the comment:
WindowsError is not part of the documented interface of shutil, but is an
implementation detail.
"from shutil import WindowsUtil" works on Unix platforms because shutil
contains a compatibility definition:
try:
WindowsError
except
1401 - 1500 of 2445 matches
Mail list logo
