"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 why ignore the express versions
>> 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.
>>
> And yet we don't regard the Windows release as complete until you have
> bui
Martin v. Löwis wrote:
>> Why is it unavoidable that the Mac build will languish behind others?
>
> Because of lack of volunteers, and expertise (i.e. the experts lack time).
>
>> Are we supporting MacOs or aren't we?
>
> We aren't. Strictly speaking, "we" (python-dev) "support" nothing (in
> th
> 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 2.7 testing process were for 2.
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 release process?
>
>> Clearly it's not a priority given that nobody has seen fi
> Why is it unavoidable that the Mac build will languish behind others?
Because of lack of volunteers, and expertise (i.e. the experts lack time).
> Are we supporting MacOs or aren't we?
We aren't. Strictly speaking, "we" (python-dev) "support" nothing (in
the sense that "we" can promise a suppo
Guido van Rossum wrote:
> On Tue, Mar 16, 2010 at 2:32 PM, Steven D'Aprano wrote:
>> But mixed arithmetic runs into the problem, what do you want the result
>> type to be? Given (say) decimal+float, returning either a Decimal or a
>> float will be the wrong thing to do some of the time, so better
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 process?
>
> Clearly it's not a priority given that nobody has seen fit to (or
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 release process?
>
>> Clearly it's not a priority given that nobody has seen fi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 process?
>
> Clearly it's not a priority given t
Here is another patch for review:
http://bugs.python.org/issue8370
This is a trivial fix to the 2.6 and 2.7 documentation.
Thanks,
--Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
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 process?
Clearly it's not a priority given that nobody has seen fit to (or had
time to) reply to this mail in three weeks
Hi folks,
I have a patch to the unittest module for review here:
http://bugs.python.org/issue7559#msg102801
(There have already been a couple rounds of discussion on how to best
fix this.)
This is my first patch, so any feedback is appreciated.
Thanks,
--Chris
_
Hi,
Python3 refuses to start with LANG=C if it's installed in a non-ASCII
directory. I wrote a patch fixing this issue, but it changes a lot of code and
I would like your opinion.
The main part changes import to use surrogateescape everywhere (find_module,
load_source_module, null importer, zi
On Tue, Apr 13, 2010 at 1:21 PM, 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/
>
> I think the PEP is ready for pronouncement, and the patch is pretty much ready
> for merging into
> That said, it's easier to add components and keywords than it is to
> add a new selection box. I know how to do the former but not (yet)
> the latter.
It's not too difficult, either: edit schema.py to change the database
(roundup will automatically sync with the database), then edit
html/issue.
Barry Warsaw wrote:
> On Apr 14, 2010, at 12:17 AM, Nick Coghlan wrote:
>
>> Barry Warsaw wrote:
>>> On Apr 13, 2010, at 11:13 PM, Nick Coghlan wrote:
>> Sounds reasonable. I ask because the various functions in runpy will
>> also need to cover setting that value properly.
>
> Right. I'm looking
It seems the Python (core) project needs some more mentors,
to really match the proposals that we got. I don't want to post a list
of proposals here, so if you are willing to potentially mentor a
project, please join the soc2010-mentors list ASAP and/or contact Arc Riley.
Doing so would neither be
On Tue, Apr 13, 2010 at 12:12 PM, Daniel Stutzbach
wrote:
> I don't know what benchmarks were used to write dictnotes.txt, but moving
> forward I would recommend implementing your changes on trunk (i.e., Python
> 2.x) and running the Unladen Swallow Benchmarks, which you can get from the
> link be
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/
I think the PEP is ready for pronouncement, and the patch is pretty much ready
for merging into py3k. The only thing that I can think of that is not
implemented
Brian Curtin writes:
> The tests are run on a native Win32 build as compiled by VS2008. The
> functionality is Win32 specific and wouldn't work on Cygwin, so the tests
> are skipped there. I believe Cygwin is used for kicking off the tests and
> other buildbot stuff, but they don't actually run t
On 4/13/2010 10:17 AM, Anand Balachandran Pillai wrote:
>>I am surprised to see that the bug-tracker
>> doesn't have an OS classifier or ability to add
>> tags ? Since a number of issues reported seem to
>
> There is one. In the Components you can do a multip
On Wed, 14 Apr 2010 00:21:07 +1000, Nick Coghlan wrote:
> Stephen J. Turnbull wrote:
> > > While there is some Windows and Mac specific code, treating them as
> > > separate components seems fairly unintuitive.
> >
> > Not always unintuitive. There are some features only available on a
> > par
On Tue, 13 Apr 2010 19:47:16 +0530, Anand Balachandran Pillai
wrote:
> On Tue, Apr 13, 2010 at 6:24 PM, Nick Coghlan wrote:
>
> > Senthil Kumaran wrote:
> > > On Mon, Apr 12, 2010 at 07:06:29PM +0530, Anand Balachandran Pillai
> > wrote:
> > >>I am surprised to see that the bug-trac
On Sat, Apr 10, 2010 at 1:06 PM, Reid Kleckner wrote:
> Looking at dictnotes.txt, I can see that people have experimented with
> taking advantage of cache locality. I was wondering what benchmarks
> were used to glean these lessons before I write my own. Python
> obviously has very particular w
On Apr 14, 2010, at 12:17 AM, Nick Coghlan wrote:
>Barry Warsaw wrote:
>> On Apr 13, 2010, at 11:13 PM, Nick Coghlan wrote:
>>
>>> barry.warsaw wrote:
+It is recommended that when nothing sensible can be calculated,
+implementations should set the `__cached__` attribute to `None`.
>>> W
Stephen J. Turnbull wrote:
> > While there is some Windows and Mac specific code, treating them as
> > separate components seems fairly unintuitive.
>
> Not always unintuitive. There are some features only available on a
> particular platform, then "component" sort of makes sense. OTOH,
> ther
Barry Warsaw wrote:
> On Apr 13, 2010, at 11:13 PM, Nick Coghlan wrote:
>
>> barry.warsaw wrote:
>>> +It is recommended that when nothing sensible can be calculated,
>>> +implementations should set the `__cached__` attribute to `None`.
>> What (if anything) should we set __cached__ to in __main__?
On Tue, Apr 13, 2010 at 6:24 PM, Nick Coghlan wrote:
> Senthil Kumaran wrote:
> > On Mon, Apr 12, 2010 at 07:06:29PM +0530, Anand Balachandran Pillai
> wrote:
> >>I am surprised to see that the bug-tracker
> >> doesn't have an OS classifier or ability to add
> >> tags ? Since a number
Nick Coghlan writes:
> they're available? Or even a separate OS field with "Windows, Mac OS X,
> Linux, *BSD, Other" as the options?
XEmacs has a multilink field "platform". The default is "Any or all"
(mislabeled N/A), and values include hardware (currently x86, PPC,
other), OS (POSIX, Window
On Apr 13, 2010, at 11:13 PM, Nick Coghlan wrote:
>barry.warsaw wrote:
>> +It is recommended that when nothing sensible can be calculated,
>> +implementations should set the `__cached__` attribute to `None`.
>
>What (if anything) should we set __cached__ to in __main__?
Good catch. Right now (in
barry.warsaw wrote:
> +It is recommended that when nothing sensible can be calculated,
> +implementations should set the `__cached__` attribute to `None`.
What (if anything) should we set __cached__ to in __main__?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
Jesus Cea wrote:
> On 04/13/2010 12:47 AM, Antoine Pitrou wrote:
>> Jesus Cea jcea.es> writes:
>>> 4. Modify client libraries to accept a new optional socket-like object
>>> as an optional parameter. This would allow things like transparent
>>> compression or encryption, or to replace the socket c
Senthil Kumaran wrote:
> On Mon, Apr 12, 2010 at 07:06:29PM +0530, Anand Balachandran Pillai wrote:
>>I am surprised to see that the bug-tracker
>> doesn't have an OS classifier or ability to add
>> tags ? Since a number of issues reported seem to
>
> There is one. In the Components yo
Jesus Cea wrote:
About controversial... keepalive are usually sent only when the
connection is 100% idle for a while, when "while" can be >15 minutes, so
the load should be "none" for regular connections.
I guess the concern would be that the keepalive probe itself
is subject to uncertain dela
Nick Coghlan wrote:
I'm not sure what build you're getting that behaviour on, but my svn
build of 2.6 has a __class__ attribute for traceback objects,
It's 2.6.1. Guess it's been fixed since then.
--
Greg
___
Python-Dev mailing list
Python-Dev@python
36 matches
Mail list logo
