On Apr 14, 2010, at 5:19 PM, Brett Cannon wrote:
> I see the confusion. I think Martin meant more about open issues that
> required discussion, not simply issues that had a patch ready to go.
Ach. I hit 'send' too soon. I also wanted to say: it seemed quite clear to me
that Martin specifical
On Apr 14, 2010, at 5:19 PM, Brett Cannon wrote:
> I see the confusion. I think Martin meant more about open issues that
> required discussion, not simply issues that had a patch ready to go.
I'm curious - if one isn't supposed to ping the mailing list every time, how
does one ask the tracker "
Greg Ewing wrote:
> Michael Foord wrote:
>> Building Python requires, I believe, the XCode development tools to be
>> installed. Even then, building a full version of Python - with *all*
>> the C extensions that are part of a Python release - is not a trivial
>> task.
>
> What's non-trivial about
Bill Janssen writes:
> > Fink or MacPorts are often a practical necessity.
>
> Fink is deadly, MacPorts much more benign, in my experience. Which is
> several years out-of-date, before I realized I didn't need either one of
> them, and before the UNIX community started adding configure patc
On Apr 15, 2010, at 08:33 AM, Nick Coghlan wrote:
>Brett Cannon wrote:
>> And just a quick suggestion: can we standardize what
>> imp.source_to_path() and friend are supposed to return if the
>> interpreter doesn't support bytecode? I will probably have to rely on
>> that for something so it would
s...@pobox.com wrote:
> Now that I think about it, it might not be sufficient to just hide those
> directories from the environment. The Python setup.py file has
> unconditional hard-coded references to /sw, /opt/local and /usr/local. That
I added that to my virus scanner: check any setup.py fi
Brett Cannon wrote:
> And just a quick suggestion: can we standardize what
> imp.source_to_path() and friend are supposed to return if the
> interpreter doesn't support bytecode? I will probably have to rely on
> that for something so it would be best to say now whether it should be
> None or raise
On Apr 14, 2010, at 4:40 PM, Martin v. Löwis wrote:
>> I think you just need to supply to configure
>>
>> MACOSX_DEPLOYMENT_TARGET=10.4
>>
>> and have the appropriate SDK installed with Xcode.
>
> Wouldn't that break 10.3 compatibility (seel below)?
I was replying to your point about 10.4 bui
On 14 April 2010 18:36, Steve Holden wrote:
> I spent some considerable effort last year ensuring the developer
> community was well-supplied with MS developer licenses that give access
> to any necessary tools. Was I wasting my time?
Definitely not - my offer is at least in part based on the fac
Martin v. Löwis wrote:
> The same is true for any other operating system, though: you need to
> install the compiler tool chain (sometimes, you need to buy it first),
> and compiling Python with all extensions is not a trivial task.
Even on Linux, it takes a bit of fiddling. I finally remembered t
Martin v. Löwis wrote:
>> I seem to recall there was some issue (aside from the current lack of a
>> reliable OS X buildbot) that prevented us from regularly grabbing the
>> head of the tree and using it to automatically build the Windows and Mac
>> installers (to check that the installers could ac
Paul Moore writes:
> On 14 April 2010 07:37, Paul Rudin wrote:
>> "Martin v. Löwis" writes:
>>
>>> The major difference in the "do it yourself" attitude is that Mac user
>>> get a compiler for free, as part of the operating system release,
>>> whereas for Windows, they have to pay for it (leavi
On 14/04/2010 23:32, Greg Ewing wrote:
Michael Foord wrote:
Building Python requires, I believe, the XCode development tools to
be installed. Even then, building a full version of Python - with
*all* the C extensions that are part of a Python release - is not a
trivial task.
What's non-trivi
Michael Foord wrote:
Building Python requires, I
believe, the XCode development tools to be installed. Even then,
building a full version of Python - with *all* the C extensions that are
part of a Python release - is not a trivial task.
What's non-trivial about it? I usually find that the nor
On Wed, Apr 14, 2010 at 13:41, Chris Jerdonek wrote:
> On Wed, Apr 14, 2010 at 1:32 PM, Brett Cannon wrote:
> > There is no need to email python-dev about individual patches just to get
> > them looked at. There is a mailing list that we all subscribe to that
> send
> > an email on all new issues
Martin v. Löwis wrote:
> > Michael Foord wrote:
> >
> >> Building the Mac installer requires volunteer time which I'm not sure
> >> that more hardware will fix - compiling a full build of Python for Mac
> >> OS X (with all the Python modules like Tkinter etc) requires expertise
> >> which only
Martin v. Löwis wrote:
> > I'd be happy to help where I can, too. All my automated testing of
> > UpLib (Windows, Ubuntu, Fedora, OS X) is done on Apple servers running
> > OS X and VirtualBox and Hudson, so I've got some experience there.
>
> Would you be interested in operating a build slave?
On Wed, 14 Apr 2010 14:06:44 -0400, Eric Smith wrote:
> "Steve Holden" wrote:
>> I spent some considerable effort last year ensuring the developer
>> community was well-supplied with MS developer licenses that give access
>> to any necessary tools. Was I wasting my time?
>
> In my case it was not
On Wed, Apr 14, 2010 at 1:32 PM, Brett Cannon wrote:
> There is no need to email python-dev about individual patches just to get
> them looked at. There is a mailing list that we all subscribe to that send
> an email on all new issues and another one on every change to any issue. You
> should only
> I think you just need to supply to configure
>
> MACOSX_DEPLOYMENT_TARGET=10.4
>
> and have the appropriate SDK installed with Xcode.
Wouldn't that break 10.3 compatibility (seel below)?
>> Unfortunately, Apple manages to break compatibility and portability
>> with every release, which makes
> How would that work? Creation of the OSX installer is not integrated
> in the regular Makefiles but is a separate script.
Again by setting up another builder (and assigning it to either the same
or a different slave). Instead of the regular configure/make/make
test/make clean builder, this one
On Tue, Apr 13, 2010 at 20:54, Chris Jerdonek wrote:
> Here is another patch for review:
>
> http://bugs.python.org/issue8370
>
> This is a trivial fix to the 2.6 and 2.7 documentation.
>
>
There is no need to email python-dev about individual patches just to get
them looked at. There is a mailing
>> I ran a Mac OSX buildbot for the community buildbots for awhile but
>> never did figure out at the time how to get it to fire up on
>> reboot. Â That was a few years ago. Â I think today that would easily
>> be accomplished with an @reboot crontab entry. Â Dunno if that was
>
On 14 Apr, 2010, at 20:46, Martin v. Löwis wrote:
>> Speaking of which... I have a mac-mini that could be used for a
>> buildbot. How much work is needed to kickstart a buildbot, taking
>> into account that I'd prefer to have a buildbot with different
>> configure-flags that the default unix buil
On Wed, Apr 14, 2010 at 14:03, "Martin v. Löwis" wrote:
> Paul Rudin wrote:
> > "Martin v. Löwis" writes:
> >
> >> The major difference in the "do it yourself" attitude is that Mac user
> >> get a compiler for free, as part of the operating system release,
> >> whereas for Windows, they have to
On Apr 14, 2010, at 3:37 PM, Martin v. Löwis wrote:
> I'm not sure whether 10.5 would be sufficient - it may be that you need to go
> back to 10.4 (*).
I think you just need to supply to configure
MACOSX_DEPLOYMENT_TARGET=10.4
and have the appropriate SDK installed with Xcode.
I belie
On 14 Apr, 2010, at 19:41, s...@pobox.com wrote:
>
>Ronald> Creating the Mac installer is easy: just run
>Ronald> Mac/BuildScript/build-installer.py on an OSX 10.5 system where a
>Ronald> local version of Tcl/Tk 8.4 is installed in
>Ronald> /Library/Frameworks. The system should
On Apr 14, 2010, at 3:30 PM, Simon Brunning wrote:
> On 14 April 2010 20:02, wrote:
>> I ran a Mac OSX buildbot for the community buildbots for awhile but never
>> did figure out at the time how to get it to fire up on reboot. That was a
>> few years ago. I think today that would easily be a
On 14/04/2010 21:37, "Martin v. Löwis" wrote:
[snip...]
Unfortunately the Mac installer build script doesn't seem to run at all
on Mac OS X 10.6 (at least not on my machine), but hopefully the
situation is clarified so that one of us who does still have Mac OS X
10.5 will be able to build the i
> Right - but we were discussing this in the context of barrier to entry,
> particularly to new users. We don't impose this requirement for Windows
> users though - we provide binary installers.
>
> I *know* we're a volunteer organisation (etc), but it is good for us to
> be aware of our process w
On 14 April 2010 20:02, wrote:
> I ran a Mac OSX buildbot for the community buildbots for awhile but never
> did figure out at the time how to get it to fire up on reboot. That was a
> few years ago. I think today that would easily be accomplished with an
> @reboot crontab entry. Dunno if that
On 14/04/2010 20:21, "Martin v. Löwis" wrote:
Mac users definitely *do* expect installers. Building Python requires, I
believe, the XCode development tools to be installed. Even then,
building a full version of Python - with *all* the C extensions that are
part of a Python release - is not a triv
> (ISTM the same might be true should people ever decide to once again build a
> Solaris installer. /opt/sfw is currently searched for Berkeley DB include
> files.)
And rightly so (likewise for Fink). Primarily, the script is there to
help people installing Python; packaging Python can be more di
>>From what I recall, the PC build process is pretty much routine (I
> can't recall how much it's scripted, and how much it's manual, but
> well-documented and simple, steps). I don't know what extra is needed
> to build the final installer, but I'd be willing to have a go at
> testing the existing
> How about as a first step the release build process include a check for
> broken links before committing the web content for a new release?
You'd have to convince the release manager to add a step to the release
process.
Given that the release process has already too many steps, he is
probably
> Michael Foord wrote:
>
>> Building the Mac installer requires volunteer time which I'm not sure
>> that more hardware will fix - compiling a full build of Python for Mac
>> OS X (with all the Python modules like Tkinter etc) requires expertise
>> which only a few people have.
>
> That's nuts.
> Making the Windows binary build process automatic and robust is challenging
> if you hate Windows (like I do). Martin also made the point that it's
> been broken forever, so people don't seem to care :). ISTR Martin just
> makes them manually.
That's true. In particular, people had been askin
> I'd be happy to help where I can, too. All my automated testing of
> UpLib (Windows, Ubuntu, Fedora, OS X) is done on Apple servers running
> OS X and VirtualBox and Hudson, so I've got some experience there.
Would you be interested in operating a build slave?
Regards,
Martin
_
Ned Deily wrote:
> That *is* something that the PSF could help with. I
> would be happy to help with that myself, although my time to do so will
> be very limited for the next few weeks.
The PSF still has a machine that was donated by Apple that once used to
be a build slave. Unfortunately, tha
Paul Rudin wrote:
> "Martin v. Löwis" writes:
>
>> The major difference in the "do it yourself" attitude is that Mac user
>> get a compiler for free, as part of the operating system release,
>> whereas for Windows, they have to pay for it (leaving alone VS Express
>> for the moment).
>
> JOOI wh
Martin> On the slave, you need to install buildbot, and create a slave
Martin> configuration; it would the be good if the slave process would
Martin> somehow get restarted automatically after a system reboot (I
Martin> think there are recipes for that out there).
A static IP addre
Bill> In any case, they shouldn't be needed on buildbots maintained by
Bill> the PSF.
Sure. My question was related to humans building binary distributions
though. Unless that becomes fully automated so the release manager can just
push a button and have it built on and as-yet-nonexiste
C. Titus Brown wrote:
> If Georg, Benjamin,
> Martin, or Ronald are interested, please just tell me (or Steve, or the PSF
> board, or ...) what you want and I'll work on getting it funded.
For me, my company provides all the infrastructure I need (tools,
bandwidth, hardware, etc). I agreed, in ret
> Probably fine on your personal Mac. And the build scripts can probably
> mask those out on their own.
For a private Python installation, it doesn't actually hurt to have them
on disk. The binaries may be linked with strange libraries, but it
should work since the libraries themselves are also o
> Speaking of which... I have a mac-mini that could be used for a
> buildbot. How much work is needed to kickstart a buildbot, taking
> into account that I'd prefer to have a buildbot with different
> configure-flags that the default unix build (that is, I want to test
> a framework build that is a
> Sure - but probably not your average Python-on-Mac user. Or at least a
> good proportion of them, particularly newbies who we are keen to keep
> the experience of obtaining Python simple. First download and then
> install 1gigabyte of developer tools (seriously) requiring registration,
> then com
> I seem to recall there was some issue (aside from the current lack of a
> reliable OS X buildbot) that prevented us from regularly grabbing the
> head of the tree and using it to automatically build the Windows and Mac
> installers (to check that the installers could actually be created,
> preven
> I personally think the Mac is pretty important, as one of the big three
> consumer operating systems...
[...]
> I don't know what to do about motivation but if there are barriers that
> we can lower, please let me know.
For example, you could volunteer to produce OSX binaries in a timely
manner
> I assumed that creation of installer binaries for a release depends on
> having the release manager or a lieutenant have access to the given
> platform (Windows, OS/X) and tools, For instance, the RM or lieutenant
> might only have access to such a platform part-time (e.g., only while at
> work,
> Mac users definitely *do* expect installers. Building Python requires, I
> believe, the XCode development tools to be installed. Even then,
> building a full version of Python - with *all* the C extensions that are
> part of a Python release - is not a trivial task.
The same is true for any othe
On Apr 14, 2010, at 09:52 AM, Isaac Morland wrote:
>I have one wording suggestion which I hope isn't bikeshedding: up above, I
>think the sentence containing "pyc files will contain a magic string"
>would be clearer if it made it clear that the file *names*, not (just?)
>the file contents, will
In my case it was not a waste of time. I use MSDN for dev and testing. Just not
for release building.
"Steve Holden" wrote:
>Paul Moore wrote:
>> On 14 April 2010 07:37, Paul Rudin wrote:
>>> "Martin v. Löwis" writes:
>>>
The major difference in the "do it yourself" attitude is that Mac
On Wed, Apr 14, 2010 at 12:36, Steve Holden wrote:
> Paul Moore wrote:
> > On 14 April 2010 07:37, Paul Rudin wrote:
> >> "Martin v. Löwis" writes:
> >>
> >>> The major difference in the "do it yourself" attitude is that Mac user
> >>> get a compiler for free, as part of the operating system re
s...@pobox.com wrote:
>
> Ronald> Creating the Mac installer is easy: just run
> Ronald> Mac/BuildScript/build-installer.py on an OSX 10.5 system where a
> Ronald> local version of Tcl/Tk 8.4 is installed in
> Ronald> /Library/Frameworks. The system should also not have fink or
>
On Apr 14, 2010, at 01:36 PM, Steve Holden wrote:
>I spent some considerable effort last year ensuring the developer
>community was well-supplied with MS developer licenses that give access
>to any necessary tools. Was I wasting my time?
At the time I didn't care because I had no access to anythi
Ronald> Creating the Mac installer is easy: just run
Ronald> Mac/BuildScript/build-installer.py on an OSX 10.5 system where a
Ronald> local version of Tcl/Tk 8.4 is installed in
Ronald> /Library/Frameworks. The system should also not have fink or
Ronald> darwinports and a clean
Paul Moore wrote:
> On 14 April 2010 07:37, Paul Rudin wrote:
>> "Martin v. Löwis" writes:
>>
>>> The major difference in the "do it yourself" attitude is that Mac user
>>> get a compiler for free, as part of the operating system release,
>>> whereas for Windows, they have to pay for it (leaving
On 14/04/2010 19:25, Steve Holden wrote:
Michael Foord wrote:
On 14/04/2010 06:13, Ned Deily wrote:
In article,
Steve Holden wrote:
Why is it unavoidable that the Mac build will languish behind others?
Are we supporting MacOs or aren't we? If we are, why isn't the crea
Michael Foord wrote:
> On 14/04/2010 06:13, Ned Deily wrote:
>> In article,
>> Steve Holden wrote:
>>
>>
>>> Why is it unavoidable that the Mac build will languish behind others?
>>> Are we supporting MacOs or aren't we? If we are, why isn't the creation
>>> of the build a part of the release
Michael Foord wrote:
> On 14/04/2010 18:49, Steve Holden wrote:
> > Bill Janssen wrote:
> >
> >> Michael Foord wrote:
> >>
> >>
> Isn't that just a matter of having the recipe written down somewhere?
>
>
> >>> Yes, that would be nice. :-) Preferably a recipe th
> > What happened to the big-ass computer farm for Python which was
> > being put together by someone at (I think) Michigan State?
>
> That sounds a lot like Snakebite (www.snakebite.org), which is
> still... uhhh, a work in progress ;-)
Actually, for those that are interested, here's a copy of t
On Wed, Apr 14, 2010 at 06:52:46PM +0200, Michael Foord wrote:
> On 14/04/2010 18:49, Steve Holden wrote:
>> Bill Janssen wrote:
>>
>>> Michael Foord wrote:
>>>
>>>
> Isn't that just a matter of having the recipe written down somewhere?
>
>
Yes, that would be n
On Wednesday, April 14, 2010, at 04:47PM, "Nick Coghlan"
wrote:
>Martin v. Löwis wrote:
>>> Wasn't that problem fixed weeks ago? The installer image has been
>>> available there since several days after the release. And the link
>>> seems fine now.
>>
>> The inherent problem remains. There
On Wed, Apr 14, 2010 at 09:37:34AM -0700, Bill Janssen wrote:
> Michael Foord wrote:
>
> > > Isn't that just a matter of having the recipe written down somewhere?
> > >
> >
> > Yes, that would be nice. :-) Preferably a recipe that doesn't involve
> > Macports or Fink which some of us are all
On 14/04/2010 18:49, Steve Holden wrote:
Bill Janssen wrote:
Michael Foord wrote:
Isn't that just a matter of having the recipe written down somewhere?
Yes, that would be nice. :-) Preferably a recipe that doesn't involve
Macports or Fink which some of us are allergic to
Bill Janssen wrote:
> Michael Foord wrote:
>
>>> Isn't that just a matter of having the recipe written down somewhere?
>>>
>> Yes, that would be nice. :-) Preferably a recipe that doesn't involve
>> Macports or Fink which some of us are allergic to.
>
> Yes, ditto the MacPorts/Fink allergy.
> What happened to the big-ass computer farm for Python which was
> being put together by someone at (I think) Michigan State?
That sounds a lot like Snakebite (www.snakebite.org), which is still...
uhhh, a work in progress ;-) We've run into an issue recently that's
thwarted progress, but that'l
Michael Foord wrote:
> > Isn't that just a matter of having the recipe written down somewhere?
> >
>
> Yes, that would be nice. :-) Preferably a recipe that doesn't involve
> Macports or Fink which some of us are allergic to.
Yes, ditto the MacPorts/Fink allergy.
All we need is a script, r
On 14 April 2010 17:04, Barry Warsaw wrote:
> From the RM perspective, what I would really like to see is updates to
> the release.py script to check dependencies and automate as much as possible,
> as well as updates to PEP 101 for any process steps that can't be automated.
>
> This goes for both
On 14/04/2010 16:53, Nick Coghlan wrote:
Michael Foord wrote:
Changing the error message to provide more useful information, possibly
including the original traceback, would certainly avoid the potential
for incompatibility. I'd be interested in seeing what other folks here
on python-dev thi
On 14/04/2010 18:01, s...@pobox.com wrote:
Michael> Mac users definitely *do* expect installers. Building Python
Michael> requires, I believe, the XCode development tools to be
Michael> installed.
XCode is free, and I suspect many people have it (I do).
Sure - but probabl
Michael> Mac users definitely *do* expect installers. Building Python
Michael> requires, I believe, the XCode development tools to be
Michael> installed.
XCode is free, and I suspect many people have it (I do).
Michael> Even then, building a full version of Python - with *all* th
On Apr 14, 2010, at 10:51 AM, s...@pobox.com wrote:
>Steve> Why is it unavoidable that the Mac build will languish behind
>Steve> others? Are we supporting MacOs or aren't we? If we are, why
>Steve> isn't the creation of the build a part of the release process?
>
>Steve> Clearly i
Ned> ... since there are no OS X buildbots that test that configuration.
Ned> But, at the moment, there aren't any OS X buildbots at all, are
Ned> there? That *is* something that the PSF could help with
What happened to the big-ass computer farm for Python which was being put
tog
On 14/04/2010 17:41, Michael Foord wrote:
[snip...]
A Mac OS X machine (and location to keep it) for the buildbots is a
*big* need however.
At least two. You want Leopard and Snow Leopard, too.
Well - an XServe that we can run virtualisation on would be the
*ideal* solution. I think the X s
Steve> I do think it makes us look bad to have one supported platform
Steve> lag the others, but it wasn't obvious to me whether hardware
Steve> alone was the reason. If it is, the fix should be relatively
Steve> simple.
I can't believe it's a hardware issue. Probably half the pe
Steve> Why is it unavoidable that the Mac build will languish behind
Steve> others? Are we supporting MacOs or aren't we? If we are, why
Steve> isn't the creation of the build a part of the release process?
Steve> Clearly it's not a priority given that nobody has seen fit to (or
On 14/04/2010 17:36, Bill Janssen wrote:
Michael Foord wrote:
Building the Mac installer requires volunteer time which I'm not sure
that more hardware will fix - compiling a full build of Python for Mac
OS X (with all the Python modules like Tkinter etc) requires expertise
which only a few
Michael Foord wrote:
> Building the Mac installer requires volunteer time which I'm not sure
> that more hardware will fix - compiling a full build of Python for Mac
> OS X (with all the Python modules like Tkinter etc) requires expertise
> which only a few people have.
That's nuts. Why isn't t
Ned Deily wrote:
> In article <4bc54f4f.4090...@v.loewis.de>,
> "Martin v. Lowis" wrote:
>
> > > Wasn't that problem fixed weeks ago? The installer image has been
> > > available there since several days after the release. And the link
> > > seems fine now.
> >
> > The inherent problem re
On Thu, Apr 15, 2010 at 12:47:50AM +1000, Nick Coghlan wrote:
> Martin v. L?wis wrote:
> >> Wasn't that problem fixed weeks ago? The installer image has been
> >> available there since several days after the release. And the link
> >> seems fine now.
> >
> > The inherent problem remains. There
Michael Foord wrote:
> Changing the error message to provide more useful information, possibly
> including the original traceback, would certainly avoid the potential
> for incompatibility. I'd be interested in seeing what other folks here
> on python-dev think.
Without looking at the details, my
Martin v. Löwis wrote:
>> Wasn't that problem fixed weeks ago? The installer image has been
>> available there since several days after the release. And the link
>> seems fine now.
>
> The inherent problem remains. There is no binary for 2.7b1, for example.
> The last binaries produced in the
Michael Foord wrote:
> Yes, I mean on the release page. The issue is that the download links on
> the sidebar / front page go straight to the latest release page. If
> there isn't yet a Mac installer available, and no alternative link to
> get the previous version, it leaves Mac users with no obvio
Isaac Morland wrote:
> I have one wording suggestion which I hope isn't bikeshedding: up above,
> I think the sentence containing "pyc files will contain a magic string"
> would be clearer if it made it clear that the file *names*, not (just?)
> the file contents, will contain the magic tag.
That'
On Apr 14, 2010, at 06:39 AM, C. Titus Brown wrote:
>Separately, I'd be happy to put forward a proposal to the PSF to fund RMs and
>their lieutenants with a Mac or a PC, whichever they needed to keep things
>moving. It's the least "we" can do, IMO, and hardware is just not that
>expensive compare
On Tue, 13 Apr 2010, Barry Warsaw wrote:
I am attaching the latest revision of PEP 3147 to this message, which is
also available here:
http://www.python.org/dev/peps/pep-3147/
[]
PEP: 3147
Title: PYC Repository Directories
[]
Further, pyc files will contain a magic string that diff
On Wed, Apr 14, 2010 at 07:36:25AM +0200, "Martin v. L?wis" wrote:
> >> In a wider sense of "to support", MacOS is certainly supported by
> >> Python. There is everything in the source code that you need to make
> >> Python run on a Mac. Just download the sources and compile them yourself.
> >>
> >
On 14/04/2010 13:58, Barry Warsaw wrote:
On Apr 14, 2010, at 02:45 PM, Michael Foord wrote:
Can we amend that to having some placeholder text saying that the Mac
installer is not yet available and a link to the previous available
version please. That can then be replaced with the normal lin
On Wed, Apr 14, 2010 at 06:33:03AM -0400, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Martin v. L?wis wrote:
> > Tres Seaver wrote:
> >> Steve Holden wrote:
> >>> Why is it unavoidable that the Mac build will languish behind others?
> >>> Are we supporting MacOs or are
On Apr 14, 2010, at 02:45 PM, Michael Foord wrote:
>Can we amend that to having some placeholder text saying that the Mac
>installer is not yet available and a link to the previous available
>version please. That can then be replaced with the normal link once the
>Mac installer is uploaded.
Yo
On 14/04/2010 13:46, Barry Warsaw wrote:
On Apr 14, 2010, at 10:56 AM, Michael Foord wrote:
The problem is the process that creates a new release with a 404 link to
the Mac installer with no explanation. The 2.6.5 release (as always)
caused several requests to webmaster from Mac users unabl
On Apr 14, 2010, at 07:04 AM, Nick Coghlan wrote:
>Yeah, the only time it uses byte-compiled files is if the original
>source is missing. Setting __cached__ to None for that case as well
>sounds like a reasonable starting point.
Cool, thanks.
-Barry
signature.asc
Description: PGP signature
On Apr 13, 2010, at 04:44 PM, Guido van Rossum wrote:
>Give me a couple of days; but I don't expect any problems given how
>the earlier discussion went. If you didn't hear from me by Friday go
>ahead and merge.
Thanks Guido.
-Barry
signature.asc
Description: PGP signature
__
On Apr 14, 2010, at 10:56 AM, Michael Foord wrote:
>The problem is the process that creates a new release with a 404 link to
>the Mac installer with no explanation. The 2.6.5 release (as always)
>caused several requests to webmaster from Mac users unable to download
>Python - which is a further
On Wed, Apr 14, 2010 at 4:12 AM, Michael Foord
wrote:
> On 14/04/2010 12:54, Chris Jerdonek wrote:
>>
>> On Wed, Apr 14, 2010 at 2:07 AM, Michael Foord
>> wrote:
>>
>>>
>>> I'm still not convinced that this isn't a backwards incompatible change -
>>> up
>>> until now, however horrible it may be,
On 14/04/2010 12:54, Chris Jerdonek wrote:
On Wed, Apr 14, 2010 at 2:07 AM, Michael Foord
wrote:
I'm still not convinced that this isn't a backwards incompatible change - up
until now, however horrible it may be, TestLoader.loadTestsFromName only
raised an AttributeError when it failed to
On 14 April 2010 07:37, Paul Rudin wrote:
> "Martin v. Löwis" writes:
>
>> The major difference in the "do it yourself" attitude is that Mac user
>> get a compiler for free, as part of the operating system release,
>> whereas for Windows, they have to pay for it (leaving alone VS Express
>> for t
On Wed, Apr 14, 2010 at 2:07 AM, Michael Foord
wrote:
> I'm still not convinced that this isn't a backwards incompatible change - up
> until now, however horrible it may be, TestLoader.loadTestsFromName only
> raised an AttributeError when it failed to load a test. Changing it to allow
> it propag
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin v. Löwis wrote:
> Tres Seaver wrote:
>> Steve Holden wrote:
>>> Why is it unavoidable that the Mac build will languish behind others?
>>> Are we supporting MacOs or aren't we? If we are, why isn't the creation
>>> of the build a part of the rele
1 - 100 of 106 matches
Mail list logo
