On 15 Apr, 2009, at 22:47, Russell E. Owen wrote:
Thank you for 2.6.2.
I see the Mac binary installer isn't out yet (at least it is not
listed
on the downloads page). Any chance that it will be compatible with 3rd
party Tcl/Tk?
The Mac installer is late because I missed the
On 14 Apr, 2009, at 18:09, Mark Dickinson wrote:
Okay, I think I might have fixed up the float endianness detection for
universal builds on OS X. Ned, any chance you could give this
another try with an updated version of the py3k-short-float-repr
branch?
One thing I don't understand:
Is
On 3 Apr, 2009, at 0:57, Guido van Rossum wrote:
The primary use case is some kind of trap on assignment. While this
cannot cover all cases, most non-local variables are stored in dicts.
List mutations are not in the same league, as use case.
I have a slightly different use-case than a
On 1 Apr, 2009, at 8:45, Peck, Jon wrote:
Apparently the Mac Python 2.6.1 Installer image does not include 64-
bit binaries. Is this going to change? Is there some technical
reason why these are not included? We are hoping to support that in
our next 64-bit release.
The 2.6 installer
On 27 Mar, 2009, at 7:49, M.-A. Lemburg wrote:
On 2009-03-27 04:19, Guido van Rossum wrote:
- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead let third party tools
On 27 Feb, 2009, at 1:57, Ned Deily wrote:
In article rowen-8731e0.13531325022...@news.gmane.org,
Russell E. Owen ro...@u.washington.edu wrote:
I want to follow up on this a bit. In the past if the Mac Python
installer was built on a machine that did NOT have a locally
installed
Tcl/Tk
On 15 Feb, 2009, at 21:13, Daniel (ajax) Diniz wrote:
Hi,
In the discussion of a feature request for MacPython[1], the OP
(hhas) said:
As of Python 2.6/3.0, all Mac-specific modules are deprecated/
eliminated
from the standard library and there are no longer any plans to
submit
On 14 Feb, 2009, at 20:15, Martin v. Löwis wrote:
Ronald Oussoren wrote:
On 14 Feb, 2009, at 19:04, Martin v. Löwis wrote:
A single installer could support both 32-bit on 10.4 and 64-bit on
10.5, but I don't think that's very useful because there are
changes
in the low-level unix API's
On 14 Feb, 2009, at 9:55, Martin v. Löwis wrote:
Any chance of getting a Mac installer for this one?
Chances are non-zero, yes.
I had hoped to build one last night, but got home way later than I had
planned. The installer is building as I type this.
Ronald
smime.p7s
Description:
On 14 Feb, 2009, at 12:22, Ned Deily wrote:
Speaking of an OS X installer for 3.0.1, over the last few weeks I
have
been working on tidying up the OS X installer build process. While
the
basic OS X build/installer process is good, some cruft has accumulated
over the past years and a
On 14 Feb, 2009, at 13:05, Martin v. Löwis wrote:
2. Release an installer built for 10.4 and higher.
pros: one size fits all
cons: no 64-bit support, known bugs in 10.4 wrt locale support, etc
Why is it that such an installer couldn't include 64-bit support?
Wouldn't 10.4 just ignore
On 14 Feb, 2009, at 19:04, Martin v. Löwis wrote:
A single installer could support both 32-bit on 10.4 and 64-bit on
10.5, but I don't think that's very useful because there are changes
in the low-level unix API's that could result in different behaviour
of a 32-bit and 64-bit script on the
On 14 Feb, 2009, at 19:44, Ned Deily wrote:
In article 499707a0.7000...@v.loewis.de,
Martin v. Lowis mar...@v.loewis.de wrote:
That said, the difference between a binary capable of running on
10.4+ and one running 10.3+ is minimal. I introduced weak-linking
for
a number of symbols that are
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 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.
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
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
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.
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 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]
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
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've got a file Lib
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
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.
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
, 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 17:56, Guido van Rossum wrote:
Thanks! The sooner the better given that tonight (PST
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
py3k or 25 branches, I get a series of errors when setup.py tries to
build the _OSA module. On OSX 10.4
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!
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
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 following
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(/tmp/dupa, w)
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
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 to a linux box
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 stdin, line 1
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 specific to
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 too,
but often it doesn't, and when it doesn't
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
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
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
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
wouldn't be
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
due to
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 processors could
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 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 don't like all these
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 powerpc
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
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
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 least
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
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
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 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
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 signature
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
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 directly to
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,
or to
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
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
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_MSG_CHECKING
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, but I
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 width is not
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 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 with
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 (optionally
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 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
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
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 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 issue)
On Jul 5, 2006, at 7:35 AM, Ronald Oussoren wrote:
On Jul 4, 2006, at 11:21 PM, Neal Norwitz wrote:
Ronald, Bob,
I know Skip found and fixed his problem, however, is this problem
likely to affect other users? Is there anything we can do to help
alleviate/diagnose this problem?
I'll
On Jul 4, 2006, at 11:21 PM, Neal Norwitz wrote:
Ronald, Bob,
I know Skip found and fixed his problem, however, is this problem
likely to affect other users? Is there anything we can do to help
alleviate/diagnose this problem?
I'll either enhance configure or roll back my change to
On Jul 1, 2006, at 5:32 AM, [EMAIL PROTECTED] wrote:
Just upgraded my Mac to OSX 10.4.7 yesterday. svn up'd Python
trunk, then
make clean ; configure ; make and I see that building the zlib
module
fails:
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-
fused-madd
On Jul 1, 2006, at 8:46 PM, Martin v. Löwis wrote:
Ronald Oussoren wrote:
What I don't understand yet is why your copy of libz doesn't have
inflateCopy.
What I don't understand is that configure does not detect that.
You may be onto something there. Skip, do you have another copy
On 26-jun-2006, at 23:03, J. Jeffrey Close wrote:
[Bleh, sorry about the subject line on my first post.
Forgot to edit it before I sent.]
Hi all,
I have been trying for some time to build Python 2.4.x
from source on OS X 10.4.6. I've found *numerous*
postings on various mailing lists
On Wednesday, June 21, 2006, at 09:43AM, Thomas Heller [EMAIL PROTECTED]
wrote:
Ronald Oussoren schrieb:
will have a look.
It is a platform bug, RTLD_LOCAL doesn't work on 10.3. The following C
snippet fails with the same error as ctypes: FAIL: dlcompat: unable to
open this file
On 20-jun-2006, at 20:06, Thomas Heller wrote:
Trent Mick schrieb:
Thomas and others,
Has anyone else seen failures in test_ctypes on older Mac OS X/
PowerPC?
Results are below. This is running a build of the trunk from last
night:
./configure make ./python.exe
On 20-jun-2006, at 20:50, Ronald Oussoren wrote:
On 20-jun-2006, at 20:06, Thomas Heller wrote:
Trent Mick schrieb:
Thomas and others,
Has anyone else seen failures in test_ctypes on older Mac OS X/
PowerPC?
Results are below. This is running a build of the trunk from last
night
On 17-jun-2006, at 6:44, Nick Coghlan wrote:
Bob Ippolito wrote:
There's a similar issue in that if sys.prefix contains a colon,
Python
is also busted:
http://python.org/sf/1507224
Of course, that's not a Windows issue, but it is everywhere else. The
offending code in that case is
Hi,
As I mentioned earlier I'd like to get patch 1446489 (support for
zip64 extensions in the zipfile module) in python 2.5. The patch
should be perfectly safe, it comes with unittests and a documentation
update. I'm also using this version of zipfile in (closed-source)
projects to handle
On 13-jun-2006, at 15:08, Aahz wrote:
On Tue, Jun 13, 2006, Ronald Oussoren wrote:
There are two backward incompatbile changes, both minor. First of all
ZipInfo will lose the file_offset attribute because calculating it
when opening a zipfile is very expensive (it basically requires a
full
On 9-jun-2006, at 20:22, Martin v. Löwis wrote:
Ronald Oussoren wrote:
How hard is the feature freeze? Would it be possible to update the
Carbon bindings after beta1? Given Apple's focus on backward
compatibility the update should only add new functionality, not
remove existing functions
On 10-jun-2006, at 21:32, Aahz wrote:
On Sat, Jun 10, 2006, Ronald Oussoren wrote:
Hopefully Python 2.5 will see more testing on the mac because there
will be prompt binary releases of the betas this time around.
If there is in fact a binary beta release for OS X, there will
definitely
On Friday, June 09, 2006, at 03:34PM, Georg Brandl [EMAIL PROTECTED] wrote:
Paul Moore wrote:
On 6/9/06, Aahz [EMAIL PROTECTED] wrote:
There was also discussion of a change to the way quit works in
interactive mode. I see no record of it, so I guess that's not going in,
either.
It's
On 9-jun-2006, at 8:23, Neal Norwitz wrote:
It's June 9 in most parts of the world. The schedule calls for beta 1
on June 14. That means there's less than 4 days until the expected
code freeze. Please don't rush to get everything in at the last
minute. The buildbots should remain green
On 9-jun-2006, at 17:34, Thomas Heller wrote:
The other question is about feature freeze on external libraries.
Is it strictly forbidden to add new features in ctypes during the
(Python) beta period?
Now that you mention the feature freeze...
The tools that generate the Carbon bindings on
On 4-jun-2006, at 13:14, [EMAIL PROTECTED] wrote:
I saw a thread here a couple days ago about a bunch of old Mac
cruft going
away. I recall wastemodule.c being mentioned. Now building it is
failing
for me (Mac OSX 10.4.6). Was it only wounded but not killed? The
first
couple of
On 4-jun-2006, at 15:40, [EMAIL PROTECTED] wrote:
I recall wastemodule.c being mentioned. Now building it is failing
for me (Mac OSX 10.4.6). Was it only wounded but not killed?
Ronald It that a new failure?
Yes. I svn up and rebuild at least once a week.
The failure was the result
On 2-jun-2006, at 5:31, Neal Norwitz wrote:
I was about to remove Mac/IDE scripts, but it looks like there might
be more stuff that is OS 9 related and should be removed. Other
possibilities look like (everything under Mac/):
Demo/* this is a bit more speculative
IDE scripts/*
On 30-mei-2006, at 22:32, Tom Cato Amundsen wrote:
optparse
Using unicode strings with non-ascii chars.[1]
I'm working around this by subclassing OptionParser. Below is a
workaround I use in GNU Solfege. Should something like this be
included in python 2.5?
Could you please
On Wednesday, May 31, 2006, at 03:06PM, Tim Peters [EMAIL PROTECTED] wrote:
Would someone augment the warnings module to make testing
more reasonable?
What's required? I know of two things:
1. There's no advertised way to save+restore the internal
filter list, or to remove a filter
On 27-mei-2006, at 8:49, Martin v. Löwis wrote:
Ronald Oussoren wrote:
Some time ago a warning was introduced for directories on sys.path
that don't contain an __init__.py but have the same name as a
package/
module that is being imported.
Is it intentional that this triggers
Hi,
The current version of setup.py looks for the sqlite header files in
a number of sqlite-specific directories before looking into the
default inc_dirs. I'd like to revert that order because that would
make it possible to override the version of sqlite that gets picked
up. Any
On 26-mei-2006, at 22:22, Ross Cohen wrote:
AIUI, kqueue actually isn't implemented for PTYs on OS X, whereas
poll(2) is. Given this, I don't think kqueue is actually strictly
better. Although hopefully Apple will get their act together and
fix this deficiency.
Ok, I'm not
Hi,
Some time ago a warning was introduced for directories on sys.path
that don't contain an __init__.py but have the same name as a package/
module that is being imported.
Is it intentional that this triggers for toplevel imports? These
warnings are triggered in the build process for
Hi,
I'm trying to port ctypes to darwin/x86 (aka the new intel macs),
which went pretty smooth. I am running into some odd behaviour of
distutils now that I'm trying to port those changes to the trunk.
ctypes uses libffi, which contains source files in various platform-
specific
301 - 400 of 439 matches
Mail list logo
