On 26 Jul, 2010,at 12:00 PM, Michael Foord wrote:On 26/07/2010 04:42, Guido van Rossum wrote:
> On Sun, Jul 25, 2010 at 8:31 PM, Peter Portante
> wrote:
>
>> FWIW: We use Python at Tabblo, straddled across Python 2.5.4 and 2.6.5. They
>> work. And they work well. But we make light use of thr
On 24 Jul, 2010, at 23:29, Alexander Belopolsky wrote:
> Furthermore, I just tried to use it on my OSX laptop and it
> crashed after I searched for pydoc and clicked on the first entry.
> (Another issue is that search window pops under the terminal window.)
Could you please file a bug for this?
On 28 Jul, 2010,at 12:56 PM, Michael Foord wrote:On 28/07/2010 11:50, Nick Coghlan wrote:
> On Tue, Jul 27, 2010 at 12:33 AM, Ronald Oussoren
> wrote:
>
>> In my opinion the GIL is a weak point of CPython and it would be nice if it
>> could be fixed. That is however
On 31 Jul, 2010, at 13:57, Michael Foord wrote:
> On 31/07/2010 12:46, Michael Foord wrote:
>> [snip...]
>> If PEP 376 goes ahead then we could keep the user plugin
>
> I meant "keep the user config file".
Speaking of which... Your documentation says it's named ~/unittest.cfg, could
you make
On 1 Aug, 2010, at 17:22, Éric Araujo wrote:
>> Speaking of which... Your documentation says it's named ~/unittest.cfg,
>> could you make this a file in the user base (that is, the prefix where
>> 'setup.py install --user' will install files)?
>
> Putting .pydistutils.cfg .pypirc .unittest2.cfg
On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:
>
> On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
>
>>
>> On 1 Aug, 2010, at 17:22, Éric Araujo wrote:
>>
>>>> Speaking of which... Your documentation says it's named ~/unittest.cfg,
>>&g
On 02 Aug, 2010,at 11:48 AM, Michael Foord wrote:
On 02/08/2010 07:18, Ronald Oussoren wrote:
On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:
On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
On 1 Aug, 2010, at 17:22, Éric Araujo wrote
On 02 Aug, 2010,at 01:00 PM, Michael Foord wrote:
> The only apple one that is actually used is the .CFUserTextEncoding
> file, I have an .Xcode in my home as well but that is empty and last
> updated in 2007. AFAIK current versions of Xcode store preferences in
> ~/Library/Preferences. Most of
On 2 Aug, 2010, at 16:24, R. David Murray wrote:
> (Ronald, the text version of your message was very difficult to sort
> through and read, because all of the quoting information was lost.
> Just thought you'd want to know.)
I'll stop using the mobile-me webmail client for lists, it seems to mes
On 2 Aug, 2010, at 2:03, Tarek Ziadé wrote:
> On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord
> wrote:
>> On 02/08/2010 00:46, Tarek Ziadé wrote:
>>>
>>> [snip...]
I don't think that unittest would use a distutils2 (or pkgutil) supplied
API
for activation.
>>>
>>> But
On 7 Aug, 2010, at 10:24, Hirokazu Yamamoto wrote:
> This is the idea just popped up. :-)
>
> #define SIG(name) if (sig_num != SIG##name)
>SIG(ABRT) SIG(FPE) SIG(ILL) SIG(INT) SIG(SEGV) SIG(TERM) {
> PyErr_SetString(PyExc_ValueError, "signal number out of range");
> return NU
On 8 Aug, 2010, at 6:15, Greg Ewing wrote:
> Aaargh, I think I've found out what the problem is.
>
> I'm using framework builds on MacOSX. I have two experimental
> builds of Python 3.1 around, plus a standard one installed in
> /Library. It's picking up the version of Python.framework in
> /Lib
On 11 Aug, 2010, at 16:21, Tim Golden wrote:
> Thanks to whoever's been working on the new Summary lists on the Issue
> Tracker.
> The "Followed by you" / "Created by you" / "Assigned to you" are just what
> the doctor ordered.
I'm not quite happy about them because these reports include closed
On 28 Aug, 2010, at 12:29, Martin v. Löwis wrote:
>
> - wide-unicode: this is a tricky one. I'm tempted to say that the
> stable ABI should always use a Py_UNICODE that matches the platform's
> wchar_t. Alternative proposals are welcome.
Sizeof(wchar_t) is 4 on OSX, but the Apple frameworks us
On 20 Sep, 2010,at 04:31 PM, Tom Browder wrote:Continuing on with investigating Python 2.7 build problems, one
problem I just discovered is a different installation on one 64-bit
system (Debian Lenny) versus another (Ubuntu 10.04.1 LTS).
I used gcc-4.5.1 on both systems, with no *PY* environment
On 6 Oct, 2010, at 22:26, Arnaud Bergeron wrote:
> If you build python (at least 2.6.5, but probably other versions as
> well) in a universal setup using the following command (or similar)
> while the machine currently has 10.6 installed:
>
> ./configure --with-universal-archs=
> --enable-univer
On 08 Oct, 2010,at 11:38 AM, Michael Foord wrote: On 08/10/2010 09:41, Chris Withers wrote:
4. Return the case of a filename in some arbitrarily-chosen
canonical form which does not depend on the file system? AFAIK this is what the function is supposed to do: return a platform-dependent
On Jul 27, 2006, at 6:20 PM, Georg Brandl wrote:
> Georg Brandl wrote:
>> The UUID test suite, which wasn't run by regrtest.py until now, is
>> now failing on some buildbots (and my machine). This should be fixed
>> before releasing something.
>
> Okay, after fixing the test on my machine (locale
On Wednesday, August 02, 2006, at 01:02PM, Werkhoven J.P. van (Sjaak) <[EMAIL
PROTECTED]> wrote:
>> Hi,
>>
>> I have got a problem with importing global variables. For instance I have
>> got two files:
Your message is off-topic for python-dev, this list is for the development OF
python, not
On Aug 3, 2006, at 9:43 PM, Nick Maclaren wrote:
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
That's my experience as well. In my opinion, the purpose of round()
is most commonly described as "to make an integer". So it should
yield an integer.
Grrk. No, that logic is flawed.
There are algori
On 5-sep-2006, at 6:24, Neal Norwitz wrote:
> There are 3 bugs currently listed in PEP 356 as blocking:
> http://python.org/sf/1551432 - __unicode__ breaks on
> exception classes
> http://python.org/sf/1550938 - improper exception w/
> relative import
> http://python.or
On Sep 17, 2006, at 2:51 PM, Jack Howarth wrote:
I am curious if there are any plans to support
the functionality provided by lipo on MacOS X to
create a python release that could operate at either
32-bit or 64-bit on Darwin ppc and Darwin intel?
We already support universal binaries for
On Sep 17, 2006, at 6:53 PM, Martin v. Löwis wrote:
Ronald Oussoren schrieb:
One problem is that python's configure script detects the sizes of
various types and those values will be different on 32-bit and 64-bit
flavours.
FWIW, the PC build "solves" this problem by p
On Sep 17, 2006, at 8:03 PM, Josiah Carlson wrote:
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Out of curiosity: how do the current universal binaries deal with
this
issue?
If I remember correctly, usually you do two completely independant
compile runs (optionally on the same machine wit
On Sep 17, 2006, at 8:35 PM, Martin v. Löwis wrote:
Josiah Carlson schrieb:
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Out of curiosity: how do the current universal binaries deal with
this
issue?
If I remember correctly, usually you do two completely independant
compile runs (optionall
On Sep 17, 2006, at 8:56 PM, Martin v. Löwis wrote:
One of the announced features of osx 10.5 is 64-bit support
throughout
the system and I definitely want to see if we can get 4-way universal
support on such systems. As I don't have a system that is capable of
running 64-bit code I'm not
On Sep 17, 2006, at 9:29 PM, Jack Jansen wrote:
Just wondering: is it a good idea in the first place to create a
universal 32/64 bit Python on MacOSX?
On MacOS you don't pay a penalty or anything for running in 32-bit
mode on any current hardware, so the choice of whether to use 32 or
64 bits
On Sep 17, 2006, at 9:37 PM, Jack Howarth wrote:
Martin,
I believe if you use the Xcode project management the
Universal binary creation is automated. Currently they
support the i386/ppc binaries but once Leopard comes
out you will see i386/x86_64/ppc/ppc64 binaries for
shared libraries.
On Friday, September 22, 2006, at 08:38AM, Neal Norwitz <[EMAIL PROTECTED]>
wrote:
>On 9/21/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>>
>> Well, to be strictly anal, while the result of
>>
>> (size_t)-123
>>
>> is defined, the result of casting /that/ back to a signed type of the
>> same w
On Friday, September 29, 2006, at 02:22PM, Neal Becker <[EMAIL PROTECTED]>
wrote:
>It seems (I haven't looked at source) that os.unlink() will close the file?
>
>If so, please make this optional. It breaks the unix idiom for making a
>temporary file.
>
>(Yes, I know there is a tempfile module,
On Sep 30, 2006, at 11:13 PM, Scott David Daniels wrote:
Christos Georgiou wrote:
Does anyone know why this happens? I can't find any information
pointing to
this being deliberate.
I just upgraded to 2.5 on Windows (after making sure I can build
extensions
with the freeware VC++ Toolkit
Hi,
Someone reported on the pythonmac list that HAVE_UINTPTR_T wasn't
defined in pyconfig.h while it should have been defined. I'm looking
into this and am now wondering whether the configure snipped below is
correct:
AC_MSG_CHECKING(for uintptr_t support)
have_uintptr_t=no
AC_TRY_COMPILE
On Oct 1, 2006, at 10:54 AM, Ronald Oussoren wrote:
Hi,
Someone reported on the pythonmac list that HAVE_UINTPTR_T wasn't
defined in pyconfig.h while it should have been defined. I'm
looking into this and am now wondering whether the configure
snipped below is correct:
AC_MS
On Oct 12, 2006, at 10:25 PM, Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 12, 2006, at 3:27 PM, Anthony Baxter wrote:
Mostly it is easy for me, with the one huge caveat. As far as I
know, the Mac
build is a single command to run for Ronald, and the Doc build
simi
On Oct 12, 2006, at 11:53 PM, Alexey Borzenkov wrote:
On 10/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Please consider also exposing _wspawnvp, depending on whether path
argument is a Unicode object or not. See PEP 277 for guidance.
Since this would go into 2.6, support for Windows 95
On Friday, October 13, 2006, at 01:10PM, Anthony Baxter <[EMAIL PROTECTED]>
wrote:
>On Friday 13 October 2006 20:35, Bob Ippolito wrote:
>> With most consumer connections it's a lot faster to download than to
>> upload. Perhaps it would save you a few minutes if the contributors
>> uploaded dir
On Friday, October 13, 2006, at 12:36PM, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
>To be fair, (thanks to Ronald) the Mac build is entirely automated by
>a script with the caveat that you should be a little careful about
>what your environment looks like (e.g. don't install fink or macports,
>o
On Oct 15, 2006, at 9:41 PM, Bob Ippolito wrote:
On 10/15/06, Barry Scott <[EMAIL PROTECTED]> wrote:
This may be down to my lack of knowledge of Mac OS X development.
I want to build my python extension for Python 2.3, 2.4 and 2.5 on
the same Mac.
Build Python 2.3 and Python 2.4 has been work
On Oct 21, 2006, at 8:03 PM, [EMAIL PROTECTED] wrote:
Followup #2...
Yesterday I whittled my problems with test_sqlite on my OSX g5 to
test_ctypes and test_sqlite:
./python.exe Lib/test/regrtest.py -l -f tests
test_ctypes
test_sqlite
test test_sqlite failed -- errors occurred;
Patch http://www.python.org/sf/1580674 fixes readlink's behaviour
w.r.t. Unicode strings: without this patch this function uses the
system default encoding instead of the filesystem encoding to convert
Unicode objects to plain strings. Like os.listdir, os.readlink will
now return a Unicode
On Oct 22, 2006, at 12:54 PM, Ronald Oussoren wrote a message with an
annoyingly large subject...
Sorry about that, I guess it's time to book a course on basic
computer usage :-(
Ronald
smime.p7s
Description: S/MIME cryptographic sign
On Oct 24, 2006, at 11:09 AM, Jack Jansen wrote:
Look at packages such as win32, PyObjC, ctypes, bridges between
Python and other languages, etc. That's where implementors are
tempted to bend the rules of Official APIs for the benefit of
serious optimizations.
PyObjC should be safe in
On Oct 28, 2006, at 1:50 AM, Martin v. Löwis wrote:
Steven Bethard schrieb:
Jack Howarth asked about creating universal binaries for OS X that
would support 32-bit or 64-bit on both PPC and x86. Ronald Oussoren
pointed out that the 32-bit part of this was already supported, but
indicated that
On Oct 31, 2006, at 6:38 PM, Thomas Heller wrote:
This mechanism is probably a hack because it'n not possible to add
C accessible
fields to type objects, on the other hand it is extensible (in
principle, at least).
I better start rewriting PyObjC then :-). PyObjC stores some addition
i
On Nov 2, 2006, at 9:35 PM, Thomas Heller wrote:
Ronald Oussoren schrieb:
On Oct 31, 2006, at 6:38 PM, Thomas Heller wrote:
This mechanism is probably a hack because it'n not possible to add
C accessible
fields to type objects, on the other hand it is extensible (in
principle, at
On 7Nov 2006, at 12:20 AM, Greg Ewing wrote:
Also, if we do our own directory caching, the question
is when to invalidate the cache.
I think I'd be happy with having to do that explicitly.
I expect the vast majority of Python programs don't
need to track changes to the set of importable mo
Hi,
I'm having problems with updating the sandbox.
ilithien:~/Python/sandbox-trunk ronald$ svn cleanup
ilithien:~/Python/sandbox-trunk ronald$ svn up
Aimport_in_py/mock_importer.py
Uimport_in_py/test_importer.py
Uimport_in_py/importer.py
svn: Failed to add file 'decimal-c/new_dt/roun
On Friday, November 24, 2006, at 08:21PM, "Thomas Heller" <[EMAIL PROTECTED]>
wrote:
>I'd like to ask for help with an issue which I do not know
>how to solve.
>
>Please see this bug http://python.org/sf/1563807
>"ctypes built with GCC on AIX 5.3 fails with ld ffi error"
>
>Apparently this is a
On Thursday, November 30, 2006, at 03:49PM, "Talin" <[EMAIL PROTECTED]> wrote:
>Barry Warsaw wrote:
>>> On the "easy_install" naming front, how about "layegg"?
>>
>> I think I once proposed "hatch" but that may not be quite the right
>> word (where's Ken M when you need him? :).
>
>I really do
On 4 Jan, 2007, at 17:56, Fred L. Drake, Jr. wrote:
On Thursday 04 January 2007 11:33, Martin v. Löwis wrote:
For the python subdirectory, there is the issue that the framework
includes in OSX magically look for python.framework when searching
for
python/foo.h, which they find, so that may
On Friday, January 05, 2007, at 02:30PM, "Fredrik Lundh" <[EMAIL PROTECTED]>
wrote:
>Talin wrote:
>
>> Rather than fixing on a standard markup, I would like to see support for
>> a __markup__ module variable which specifies the specific markup
>> language that is used in that module. Doc process
On 20 Feb, 2007, at 10:47, Raymond Hettinger wrote:
>
> The other area where I expected to hear wailing and gnashing of
> teeth is users
> compiling with third-party extensions that haven't been updated to
> a Py_ssize_t
> API and still use longs. I would have expected some instability
>
On 5 Mar, 2007, at 19:58, [EMAIL PROTECTED] wrote:
>
> amk> Any ideas for fixing this problem?
>
> Not a one.
>
> amk> Tangentially related:
> amk> At PyCon, there was general agreement that exposing a read-
> only
> amk> Bazaar/Mercurial/git/whatever version of the repository
On 16 Mar, 2007, at 23:37, Stephen Hansen wrote:
>
> That may actually be a genuinely useful approach:
>
> splitext(name, ignore_leading_dot=False, all_ext=False)
>
> ... that's perfect. I updated my patch to do it that way! :)
I don't agree. "all_ext=True" is won't do the right thing in a
si
On 20 Mar, 2007, at 15:54, Phillip J. Eby wrote:
At 09:24 AM 3/20/2007 +0100, Ronald Oussoren wrote:
I don't agree. "all_ext=True" is won't do the right thing in a
significant subset of filenames
Yes, that's understood. The problem is that splitext() in general
On 20 Mar, 2007, at 19:24, Phillip J. Eby wrote:
What I don't understand is why 'ignore_leading_dot==False' is
considered to be a valid usecase at all, except for the fact that
os.path.splitext did this until py2.5. I'm definitely in the camp
that considers '.profile' not to have an extension
On 29 Mar, 2007, at 11:37, Greg Ewing wrote:
Has anyone found a way of persuading distutils to
pass MacOSX -framework options properly when linking?
Using extra_link_args doesn't work, because they need
to be at the beginning of the command line to work
properly, but extra_link_args gets put a
On 30 Mar, 2007, at 7:27, Greg Ewing wrote:
> Ronald Oussoren wrote:
>
>> What's wrong with adding -framework flags to the end? I do this
>> all the time and have yet to run into problems.
>
> I don't know what's wrong. Sometimes it works for me t
On Monday, April 30, 2007, at 06:28AM, "Neal Norwitz" <[EMAIL PROTECTED]> wrote:
>PEP 11 notes that Mac OS 9 support was unsupported in 2.4. There are
>still quite a few places that we check for sys.platform == 'mac'.
>There are also (at least) 2 modules (macpath and macurl2path) that
>look spec
On 27 Apr, 2007, at 20:39, Facundo Batista wrote:
- and (and), or (or), xor (xor) [CD]: Takes two logical operands, the
result is the logical operation applied between each digit.
"and" and "or" are keywords, you can't have methods with those names:
>>> def and(l, r): pass
File "", line
On 04 Mar, 2011,at 02:21 PM, Nick Coghlan wrote:
For *nix, I think there is a simple way forward that is an improvement
over where things stand now. For Windows, I don't think we can do much
better than the status quo and for Mac OS X... I think Apple will do
whatever Apple feel like doing :) Appl
On 4 Mar, 2011, at 19:56, R. David Murray wrote:
> On Fri, 04 Mar 2011 15:50:01 +0000, Ronald Oussoren
> wrote:
>> On 04 Mar, 2011,at 02:21 PM, Nick Coghlan wrote:
>>
>> For *nix, I think there is a simple way forward that is an improvement
>> over where th
On 4 Mar, 2011, at 16:35, Martin v. Löwis wrote:
>
>
> I'd still like the PEP to tell me whether it's python3w.exe or
> pythonw3.exe (and yes, that's bikeshedding - so somebody just tell
> me). It would also be good if the PEP took a position on providing
> pythonXY.exe binaries on Windows (with
On 15 Mar, 2011, at 19:31, Greg Ewing wrote:
> Martin v. Löwis wrote:
>
>> "There must be at least a one-year transition period between the
>> release of the transitional version of Python and the release
>> of the backwards incompatible version.
>
> I still think this is going to result in rud
On 16 Mar, 2011, at 9:56, Nick Coghlan wrote:
>
> Interestingly, there is no definite time frame on the deprecation
> warnings in that discussion. It was just the standard "deprecation in
> X.Y means removal in X.Y+1" that lead to 3.2 no longer providing the
> PyCObject API.
Speaking of deprecat
On 14 Apr, 2011, at 15:09, Ricardo Kirkner wrote:
> Hi all,
>
> I recently stumbled upon an issue with a class in the mro chain not
> calling super, therefore breaking the chain (ie, further base classes
> along the chain didn't get called).
> I understand it is currently a requirement that all
On 14 Apr, 2011, at 18:10, Michael Foord wrote:
> On 14/04/2011 17:02, Raymond Hettinger wrote:
>> On Apr 14, 2011, at 8:34 AM, P.J. Eby wrote:
>>
>>> At 03:55 PM 4/14/2011 +0100, Michael Foord wrote:
Ricardo isn't suggesting that Python should always call super for you, but
when you
On 17 May, 2011, at 17:36, Tarek Ziadé wrote:
> Hello
>
> I am about to merge packaging in the stdlib, and we will continue our
> work there :)
>
> The impact is:
>
> - addition of Lib/packaging
> - addition of test/test_packaging.py
> - changes in Lib/sysconfig.py
> - addition of Lib/sysconfi
On 26 May, 2011, at 16:10, Eric Smith wrote:
>
>
>> and make silent the Clang Static Analyzer :-)
>
> I care less about that than maintainability and future-proofing.
Have to looked at the patch? The patch and resulting code look sane to me, and
if anything at most of the updated segments loo
On 14 Jun, 2011, at 11:15, Jannis Leidel wrote:
>
> On 14.06.2011, at 01:46, Carl Meyer wrote:
>
>>
>> In fact, the only new-OS-version adjustment I can recall virtualenv
>> needing to make is when Debian introduced dist-packages -- but even that
>> doesn't really apply, as that was distro-pac
On Wednesday, May 23, 2007, at 12:40PM, <[EMAIL PROTECTED]> wrote:
>
>Nick> If you type "pydoc re" at the moment then it says in it
>
>Nick> MODULE DOCS
>Nick> http://www.python.org/doc/current/lib/module-re.html
>
>Nick> which is pretty much useless to me when ssh-ed in t
On 26 May, 2007, at 6:45, Darrin Thompson wrote:
First of all 1000 apologies if this is the wrong list. Please redirect
me if necessary.
I'm attempting to build python 2.5.1 fat binaries on OSX and
statically link to a newer sqlite than what ships with OSX. (3.3.17).
I'm getting "Bus Error" e
Please create a patch for this in the tracker to ensure that this patch doesn't
get lost.
Ronald
On Tuesday, August 21, 2007, at 10:47AM, "Hrvoje Nik?i?" <[EMAIL PROTECTED]>
wrote:
>On Mon, 2007-08-20 at 20:27 +0200, Maciej Fijalkowski wrote:
>> import thread
>>
>> while 1:
>> f = open("/
On Tuesday, October 09, 2007, at 12:29PM, "Greg Ewing" <[EMAIL PROTECTED]>
wrote:
>A while back I wrote about a problem I was having with
>the ordering of -framework options in distutils compilation
>commands. Well, now I've discovered something even stranger.
>
>When distutils executes the foll
On 9 Oct, 2007, at 23:11, Greg Ewing wrote:
Ronald Oussoren wrote:
Is that the system supplied version of Python?
No, it's my own installation of 2.3, but it's installed
as a framework in /Library/Frameworks.
My guess is MACOSX_DEPLOYMENT_TARGET: this is set in the
> e
An extension module I use makes extensive use of the PyGILState API's
in callback functions for C APIs. Some of the functions that use the
PyGILState APIs are used in the tp_dealloc of methods. This seems
cause problems when objects are cleaned up during interpreter
shutdown: when an obje
On 4 Dec, 2007, at 22:49, Guido van Rossum wrote:
> On OSX 10.5 with Xcode 3.0, whenever I build either the trunk or the
> py3k or 25 branches, I get a series of errors when setup.py tries to
> build the _OSA module. On OSX 10.4 it builds fine. Can anybody help?
> I don't even know what OSA is!
hes update a generated file, but as it is virtually
impossible to regenerate these files at the moment that should be
perfectly safe.
Ronald
>
>
> --Guido
>
> On Dec 5, 2007 12:08 PM, Ronald Oussoren <[EMAIL PROTECTED]>
> wrote:
>>
>> On 5 Dec, 2007, at
revision 59369).
Ronald
>
>
> --Guido
>
> On Dec 4, 2007 11:19 PM, Ronald Oussoren <[EMAIL PROTECTED]>
> wrote:
>>
>> On 4 Dec, 2007, at 22:49, Guido van Rossum wrote:
>>
>>> On OSX 10.5 with Xcode 3.0, whenever I build either the trunk or the
>>>
On 17 Jan, 2008, at 8:55, Christian Heimes wrote:
The PEP 370 (http://www.python.org/dev/peps/pep-0370) "per user site
packages directory" has several open questions:
* Are the directories for Windows, Mac and Unix fine?
The Mac directories look fine to me.
Is it worthwhile to note in the P
On 17 Jan, 2008, at 9:40, [EMAIL PROTECTED] wrote:
On 07:55 am, [EMAIL PROTECTED] wrote:
The PEP 370 (http://www.python.org/dev/peps/pep-0370) "per user site
packages directory" has several open questions:
* Are the directories for Windows, Mac and Unix fine?
* Mac: Should framework and
On 17 Jan, 2008, at 14:22, [EMAIL PROTECTED] wrote:
On 12:02 pm, [EMAIL PROTECTED] wrote:
On 17 Jan, 2008, at 9:40, [EMAIL PROTECTED] wrote:
On 07:55 am, [EMAIL PROTECTED] wrote:
The framework build of Python definitly targets the upper layer of
the OSX stack, not just the Unix core. This
On 17 Jan, 2008, at 14:22, [EMAIL PROTECTED] wrote:
As long as the default installation location is still ~/Library/
Python/ X.Y for framework builds I wouldn't mind too much.
Is there a default "installation" location? When we started this
part of the discussion, it was just which paths
Hi,
I've just filed issue2114 (http://bugs.python.org/issue2114) because
test_decimal.py fails on OSX 10.3 with Python 2.5.2c1 (using the
python.org build that will be released soon). The same test passes on
OSX 10.4 and 10.5 (both Intel and PPC) using the exact same binaries.
IIRC the 2.5.
On 14 Feb, 2008, at 17:48, Mark Dickinson wrote:
On Thu, Feb 14, 2008 at 11:21 AM, Ronald Oussoren <[EMAIL PROTECTED]
> wrote:
Hi,
I've just filed issue2114 (http://bugs.python.org/issue2114) because
test_decimal.py fails on OSX 10.3 with Python 2.5.2c1.
It looks like you'v
On 11 Mar, 2008, at 18:01, Stefan Behnel wrote:
Mike Meyer wrote:
On Tue, 11 Mar 2008 14:55:04 +0100 Stefan Behnel
<[EMAIL PROTECTED]> wrote:
(weird places these threads come up at, but now that it's here...)
Mike Meyer wrote:
On Tue, 04 Mar 2008 15:44:32 -0800 Ned Deily <[EMAIL PROTECTED]>
On 20 Apr, 2006, at 22:07, Martin v. Löwis wrote:
Guido van Rossum wrote:
This is another area where API standardization is
important; as soon as modules are loaded out of a zip file, the
traditional approach of looking relative to os.path.dirname(__file__)
no longer works.
2. standardize on
On 22 Mar, 2008, at 2:44, A.M. Kuchling wrote:
On Fri, Mar 21, 2008 at 06:41:00PM -0400, Phillip J. Eby wrote:
I'm making the assumption that the author(s) of PEP 262 had good
reason for including what they did, rather than assuming that we
should start the entire process over from scratch.
T
On 5 Apr, 2008, at 21:17, [EMAIL PROTECTED] wrote:
I just noticed this error message during configure:
checking whether gcc accepts -Olimit 1500... no
checking whether gcc supports ParseTuple __format__... no
checking whether pthreads are available without options... yes
checking wh
My two cents: the link to pythonmac.org should be removed, especially
for downloading an installer for Python. The main 2.5.x download pages
already have a binary installer for OSX (10.3.9 or later), the copy on
pythonmac.org is just that: an (outdated) copy of the installer on the
main p
On 30 Dec, 2008, at 22:59, Benjamin Peterson wrote:
Seems that there are two ways to go.
Put back the Carbon and MacOS modules into 3.0.
Use Python 2 to build the python 3 package.
I've converted it back to 2.x for the time being. Eventually, I think
some 3.x bindings should be released.
Fo
On 2 Jan, 2009, at 20:51, Bill Janssen wrote:
Nicko van Someren wrote:
On 30 Dec 2008, at 13:45, Barry Scott wrote:
...
Since I've been building 3.0 for a while now I looked at the script.
build-install.py seems to have been half converted to py 3.0.
Going full 3.0 was not hard but then th
On 18 Jan, 2009, at 18:10, Barry Scott wrote:
While the build should be fixed for 2.6+ (I'll send a patch), note
that
bundlebuilder is gone in 3.0.
What is the replacement for bundlebuilder for 3.0? Lack of
bundlebuilder becomes a serious porting problem for me.
I deliver pysvn WOrkbench
On 24 Jan, 2009, at 22:03, s...@pobox.com wrote:
I'm working on issue 4111 which will add dtrace support to Python when
requested by the builder and when supported by the platform
(currently just
Solaris and Mac OSX I believe).
Sun and Apple have quite different ways to generate the code
On 2 Aug, 2011, at 4:22, R. David Murray wrote:
> On Tue, 02 Aug 2011 01:22:03 +0200, stefan.krah
> wrote:
>> http://hg.python.org/cpython/rev/68b5f87566fb
>> changeset: 71683:68b5f87566fb
>> branch: 3.2
>> parent: 71679:1f9ca1819d7c
>> user:Stefan Krah
>> date:Tue
On 6 Oct, 2011, at 14:57, Amaury Forgeot d'Arc wrote:
> Hi,
>
> with the new Unicode API, there are many checks like:
> +if (PyUnicode_READY(*filename))
> +goto handle_error;
>
> Every time I read it, I get it wrong:
> "If filename is ready, then fail"
> then I have to rem
On 17 Jan, 2012, at 11:59, anatoly techtonik wrote:
>
>
> If you track this more closely, you'll notice there are four issues
> (surprises) from the user point of view:
> 1. print() buffers output on Python3
> 2. print() also buffers output on Python2, but only on Linux
> 3. there is some usele
On 7 May, 2012, at 11:52, Martin v. Löwis wrote:
>> 3) Symlink the interpreter rather than copying. I include this here for
>> the sake of completeness, but it's already been rejected due to
>> significant problems on older Windows' and OS X.
>
> That sounds the right solution to me. PEP 405 spe
On 10 Jul, 2012, at 18:41, Marc Abramowitz wrote:
> Anyone know how to build and run tests on an OS X build with
> —enable-framework, without installing the framework? I want to test
> that something works in my tree without polluting /Library/Frameworks
> with stuff that could mess up future tes
On 18 Jul, 2012, at 7:53, mar...@v.loewis.de wrote:
>> What is the status of LLVM nowadays? Is it not a good solution to
>> write a portable JIT?
>
> I don't think it is. It is still slow and memory hungry. The fact that
> the version that Apple ships with Xcode still miscompiles Python 3.3
> te
201 - 300 of 469 matches
Mail list logo
