Re: [Python-Dev] to rename or not...

On 31 Jul, 2013, at 10:09, Antoine Pitrou wrote: > Le Wed, 31 Jul 2013 08:15:50 +0200, > Ronald Oussoren a écrit : >> >> Because of this I'd like to introduce a new API in plistlib that >> fixes both problems. In particular: >> >> * Add 'load&#

Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Silence warning about set but unused variable inside compile_atom() in

On 31 Jul, 2013, at 23:50, christian.heimes wrote: > http://hg.python.org/cpython/rev/0e09588a3bc2 > changeset: 84939:0e09588a3bc2 > parent: 84937:809a64ecd5f1 > parent: 84938:83a55ca935f0 > user:Christian Heimes > date:Wed Jul 31 23:48:04 2013 +0200 > summary: > Si

Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Silence warning about set but unused variable inside compile_atom() in

On 1 Aug, 2013, at 9:49, Christian Heimes wrote: > Am 01.08.2013 09:03, schrieb Ronald Oussoren: >> >> On 31 Jul, 2013, at 23:50, christian.heimes >> wrote: >> >>> http://hg.python.org/cpython/rev/0e09588a3bc2 >>> changeset: 84939:0e0

Re: [Python-Dev] PEP 8 modernisation

On 1 Aug, 2013, at 16:34, Alexander Shorin wrote: > Hi Nick, > > On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan wrote: >> 9. Explicit guideline not to assign lambdas to names (use def, that's >> what it's for) > > Even for propose to fit chars-per-line limit and/or to remove > duplicates (espec

Re: [Python-Dev] PEP 8 modernisation

e same byte code. The only differences are that the lambda saves two characters in typing, and the "def" variant has a more useful value in its __name__ attribute. IMHO The lambda variant also looks uglier (even with the def variant on a single line). Ronald > -- > ,,,^..^,,, > > &

Re: [Python-Dev] PEP 8 modernisation

n one place, such as the key argument to sorted. By the time you assign a name to the function and give it unittests you may as well use a def-statement and let the function know it its own name. Ronald > > -- > ,,,^..^,,, > > > On Thu, Aug 1, 2013 at 6:53 PM, Ronald Oussor

Re: [Python-Dev] PEP 447: add type.__locallookup__

On 9 Sep, 2013, at 20:23, Jan Kaliszewski wrote: > Is '__locallookup__' a really good name? In Python, *local* -- especially in > context of *lookups* -- usually associates with locals() i.e. a namespace of > a function/method execution frame or a namespace of a class, during > *definition* o

Re: [Python-Dev] PEP 447: add type.__locallookup__

27;ll get much more useful feedback by waiting. >> >> >> On Mon, Sep 9, 2013 at 7:30 AM, Ethan Furman > <mailto:et...@stoneleaf.us>> wrote: >> >>On 07/30/2013 11:17 PM, Ronald Oussoren wrote: >> >> >>And something I forg

Re: [Python-Dev] PEP 447: add type.__locallookup__

On 9 Sep, 2013, at 23:18, Mark Shannon wrote: > On 09/09/13 15:30, Ethan Furman wrote: >> On 07/30/2013 11:17 PM, Ronald Oussoren wrote: >>> >>> And something I forgot to ask: is anyone willing to be the >>> BDFL-Delegate for >>> PEP 447? >>

Re: [Python-Dev] PEP 447: add type.__locallookup__

> On 12 sep. 2013, at 17:30, "R. David Murray" wrote: > >> On Thu, 12 Sep 2013 16:42:39 +0200, Ronald Oussoren >> wrote: >> >>> On 9 Sep, 2013, at 20:23, Jan Kaliszewski wrote: >>> >>> Is '__locallookup__' a really

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

On Sep 18, 2013, at 03:36 PM, Antoine Pitrou wrote:Le Wed, 18 Sep 2013 14:54:32 +0200, "Martin v. Löwis" a écrit :Am 18.09.13 08:43, schrieb Gregory P. Smith:> Just drop support for 10.6 with Python 3.4. Problem solved. People> on that old of a version of the OS can build thei

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

On Sep 18, 2013, at 03:03 PM, "Martin v. Löwis" wrote:Am 15.09.13 00:56, schrieb Ryan:+1. A 10.6-only build makes sense. I'd like to support Russell's point: this could put a burden on everyone releasing extension modules to also provide two binary releases, which e.g. would then mess up downloads

Re: [Python-Dev] PEP 447: add type.__locallookup__

On 13 Sep, 2013, at 12:42, Nick Coghlan wrote: > Perhaps "__getdescriptor__" would work as the method name? Yes, it can > technically return a non-descriptor, but the *primary* purpose is to > customise the retrieval of objects that will be checked to see if they're > descriptors. It *won't*

Re: [Python-Dev] PEP 447: add type.__locallookup__

On 13 Sep, 2013, at 14:23, Steven D'Aprano wrote: > On Fri, Sep 13, 2013 at 08:42:46PM +1000, Nick Coghlan wrote: >> Perhaps "__getdescriptor__" would work as the method name? Yes, it can >> technically return a non-descriptor, > > So technically that name is, um, what's the term... oh yes, "a

Re: [Python-Dev] PEP 447: add type.__locallookup__

On 13 Sep, 2013, at 18:19, Steve Dower wrote: > From: Steven D'Aprano >> On Fri, Sep 13, 2013 at 04:26:06AM +, Steve Dower wrote: >> >>> Last I checked, looking up in the instance dict us exactly what it >>> does. Even the example you posted is doing that. >> >> The example from the PEP sh

Re: [Python-Dev] PEP 447: add type.__locallookup__

On 14 Sep, 2013, at 8:30, Nick Coghlan wrote: [... interesting text that I'll respond to later ...] > > So my proposed name is based on the idea that what Ronald is after > with the PEP is a hook that *only* gets invoked when the interpreter > is doing this hunt for descriptors, but *not* for

Re: [Python-Dev] PEP 447: add type.__locallookup__

On 19 Sep, 2013, at 12:00, Paul Moore wrote: > On 19 September 2013 10:32, Ronald Oussoren wrote: >> The first time a method is called the bridge looks for an Objective-C >> selector >> with the same name and adds that to the class dictionary. This works fine >> f

Re: [Python-Dev] PEP 447: add type.__locallookup__

On 19 Sep, 2013, at 12:12, Nick Coghlan wrote: > > On 19 Sep 2013 20:00, "Paul Moore" wrote: > > > > On 19 September 2013 10:32, Ronald Oussoren wrote: > > > The first time a method is called the bridge looks for an Objective-C > > > selector

Re: [Python-Dev] PEP 447: add type.__locallookup__

On 14 Sep, 2013, at 8:30, Nick Coghlan wrote: > > >>> but the *primary* purpose is to >>> customise the retrieval of objects that will be checked to see if they're >>> descriptors. >> >> If that's the case, the PEP should make that clear. > > Technically, that's what "Currently object.__geta

[Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

Hi, It’s getting a tradition for me to work on PEP 447 during the EuroPython sprints and disappear afterwards. Hopefully I can manage to avoid the latter step this year… Last year the conclusion appeared to be that this is an acceptable PEP, but Mark Shannon had a concern about a default imple

Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

> On 24 Jul 2016, at 12:37, Nick Coghlan wrote: > > On 23 July 2016 at 22:26, Ronald Oussoren wrote: >> I’m currently working on getting the patch in 18181 up-to-date w.r.t. the >> current trunk, the patch in the issue no longer applies cleanly. After that >> I’ll

Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

On 24 Jul 2016, at 13:06, Ronald Oussoren <ronaldousso...@mac.com> wrote:…But on the other hand, that’s why wanted to use PyObjC to validatethe PEP in the first place.I’ve hit a fairly significant issue with this, PyObjC’s super contains more magic than just this magic that would be fixed

Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

> On 24 Jul 2016, at 13:06, Ronald Oussoren <mailto:ronaldousso...@mac.com>> wrote: > … > But on the other hand, that’s why wanted to use PyObjC to validate > the PEP in the first place. I’ve hit a fairly significant issue with this, PyObjC’s super contains more magic

Re: [Python-Dev] Making sure dictionary adds/deletes during iteration always raise exception

> On 13 Dec 2016, at 17:52, Eric V. Smith wrote: > > >> On Dec 13, 2016, at 11:42 AM, Raymond Hettinger >> wrote: >> >> >>> On Dec 13, 2016, at 1:51 AM, Max Moroz wrote: >>> >>> Would it be worth ensuring that an exception is ALWAYS raised if a key >>> is added to or deleted from a dictio

Re: [Python-Dev] Document C API that is not part of the limited API

> On 27 Dec 2016, at 20:04, Serhiy Storchaka wrote: > > From the documentation: > > https://docs.python.org/3/c-api/stable.html > >In the C API documentation, API elements that are not part of the limited > API are marked as "Not part of the limited API." > > But they don't. > > I prepa

Re: [Python-Dev] Document C API that is not part of the limited API

> On 30 Dec 2016, at 15:33, Nick Coghlan wrote: > > On 29 December 2016 at 06:41, Steve Dower <mailto:steve.do...@python.org>> wrote: > On 28Dec2016 1145, Brett Cannon wrote: > On Tue, 27 Dec 2016 at 12:15 Ronald Oussoren <mailto:ronaldousso...@mac.com> &g

Re: [Python-Dev] Can we use "designated initializer" widely in core modules?

> On 18 Jan 2017, at 02:16, Victor Stinner wrote: > > 2017-01-18 1:59 GMT+01:00 INADA Naoki : >> I think mixing two forms is OK only if new form is used only at bottom. >> (like keyword arguments are allowed after all positional arguments in >> Python function calling) >> >> Complete rewriting

Re: [Python-Dev] Remove embedded expat library?

> On 9 Jun 2017, at 18:03, Ned Deily wrote: > > On Jun 9, 2017, at 08:43, Victor Stinner wrote: > >> I expect that all Linux distributions build Python using >> --with-system-expat. It may become the default? What about macOS and >> other operating systems? > > The current default is --with-s

Re: [Python-Dev] Remove embedded expat library?

> On 11 Jun 2017, at 12:10, Victor Stinner wrote: > > Le 11 juin 2017 09:38, "Ronald Oussoren" <mailto:ronaldousso...@mac.com>> a écrit : > I don’t think it would be a good idea to rely on the system provided libexpat > on macOS, as Apple is not exactly fa

Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)

> On 6 Sep 2017, at 00:03, Larry Hastings wrote: > > > > I've written a PEP proposing a language change: > https://www.python.org/dev/peps/pep-0549/ > > The TL;DR summary: add support for property objects to modules. I've already > posted a protot

Re: [Python-Dev] RELEASED Python 3.0.1

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: S/M

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

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 number

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

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 arc

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

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 sam

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

On 14 Feb, 2009, at 19:44, Ned Deily wrote: In article <499707a0.7000...@v.loewis.de>, "Martin v. Lowis" 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 not present on

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

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

Re: [Python-Dev] Closing outdated Mac issues

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

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

On 27 Feb, 2009, at 1:57, Ned Deily wrote: In article , "Russell E. Owen" 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 then it would fail to work with a locally installed Tcl/Tk: Python

Re: [Python-Dev] "setuptools has divided the Python community"

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 built

Re: [Python-Dev] Python 2.6 64-bit Mac Release

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 i

Re: [Python-Dev] PyDict_SetItem hook

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 debu

Re: [Python-Dev] Shorter float repr in Python 3.1?

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 i

Re: [Python-Dev] RELEASED Python 2.6.2

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 pre-announceme

Re: [Python-Dev] RELEASED Python 2.6.2

er hard to support both 8.4 and 8.5 in the same installer. Ronald -- Russell On Apr 16, 2009, at 5:35 AM, Ronald Oussoren wrote: 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 do

Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces

For what it's worth, the OSX API's seem to behave as follows: * If you create a file with an non-UTF8 name on a HFS+ filesystem the system automaticly encodes the name. That is, open(chr(255), 'w') will silently create a file named '%FF' instead of the name you'd expect on a unix system.

Re: [Python-Dev] PEP 383: Non-decodable Bytes in System Character Interfaces

On 30 Apr, 2009, at 21:33, Piet van Oostrum wrote: Ronald Oussoren (RO) wrote: RO> For what it's worth, the OSX API's seem to behave as follows: RO> * If you create a file with an non-UTF8 name on a HFS+ filesystem the RO> system automaticly encodes the name. RO&

Re: [Python-Dev] PEP 376 : Changing the .egg-info structure

On 17 May, 2009, at 15:04, MRAB wrote: Alexander Shigin wrote: В Сбт, 16/05/2009 в 23:15 +0100, MRAB пишет: FYI, on RISC OS '/' is a valid filename character and '.' is used as the directory separator. I'd probably say that TAB is s reasonable character to use, even though it's OK in POSIX;

Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata

I'm -1 on changing the name. For better or worse setuptools is the elephant in the room w.r.t. package management and it would IMHO be better to stay compatible (even if the stdlib only implements a subset of setuptools/pkg_resources) Ronald On 5 jul 2009, at 23:10, Nick Coghlan wrote:

Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata

On 6 Jul, 2009, at 9:53, Tarek Ziadé wrote: 2009/7/6 Ronald Oussoren : I'm -1 on changing the name. For better or worse setuptools is the elephant in the room w.r.t. package management and it would IMHO be better to stay compatible (even if the stdlib only implements a subs

Re: [Python-Dev] PEP 376 - Open questions

On 6 Jul, 2009, at 20:38, Paul Moore wrote: - Should distribution names be case insensitive on case insensitive filesystems? For comparison, module/package names are always case sensitive even on case insensitive systems. I'd then go for case sensitive names for distributions as well, just

Re: [Python-Dev] Python 2.6.3

On 9 Sep, 2009, at 19:29, Ned Deily wrote: Without trying to put Ronald on the spot (too much!), it would be a good idea to get his assessment where things stand wrt 2.6 on 10.6 before setting a final release date. MacOS X 10.6 support should be stable now, except for a critical issue wit

Re: [Python-Dev] Python 2.6.3

On 10 Sep, 2009, at 18:23, Ned Deily wrote: In article <9d506035-7c2d-4929-a134-e88eeb7b7...@python.org>, Barry Warsaw wrote: On Sep 9, 2009, at 1:29 PM, Ned Deily wrote: In article <11a6545d-7204-4f61-b55b-1cc77cb56...@python.org>, Barry Warsaw wrote: I still want to release by the 25th

Re: [Python-Dev] Python 2.6.3

On 16 Sep, 2009, at 14:52, Barry Warsaw wrote: On Sep 15, 2009, at 9:53 AM, Ronald Oussoren wrote: The IDLE issue is IMHO a release blocker, as is issue 6851. So that leaves 4 release blockers for 2.6.3. Three of these are assigned to Ronald. Ronald are you sure you will have time to

Re: [Python-Dev] Python 2.7 Mac universal builds seem broken on trunk

On 26 Sep, 2009, at 14:46, Barry Scott wrote: I'm working with http://svn.python.org/projects/python/trunk on Mac OS X 10.6.1 using Apples xcode gcc 4.2.1. When I run the following commands: ./configure --enable-framework --with-universal-archs=32-bit | tee build.config.log make

Re: [Python-Dev] Python 2.7 Mac universal builds seem broken on trunk

On 29 Sep, 2009, at 17:28, M.-A. Lemburg wrote: Ronald Oussoren wrote: On 26 Sep, 2009, at 14:46, Barry Scott wrote: I'm working with http://svn.python.org/projects/python/trunk on Mac OS X 10.6.1 using Apples xcode gcc 4.2.1. When I run the following commands: ./configure --e

Re: [Python-Dev] Python 2.7 Mac universal builds seem broken on trunk

On 29 Sep, 2009, at 18:17, M.-A. Lemburg wrote: Ronald Oussoren wrote: Use: ./configure --enable-framework --enable-universalsdk=/ The --with-universal-archs flag selects whichs architectures should be included when you build a universal binary, defaulting to 32-bit. The Python

Re: [Python-Dev] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

On Friday, 02 October, 2009, at 04:07AM, "INADA Naoki" wrote: >I found this hg's issue. >http://mercurial.selenic.com/bts/msg8375 > >I think below fix is not enabled on Mac OS X. >http://svn.python.org/view/python/trunk/Include/pyport.h?view=diff&pathrev=43219&r1=36792&r2=36793 > >I can't confi

Re: [Python-Dev] Old libc's isspace() bug on FreeBSD brings back on Mac OS X?

On 3 Oct, 2009, at 1:40, INADA Naoki wrote: Confirmed on 10.6 for 2.6.3 and 2.7a0. For 3.2a0 both asserts fail. OK. `s = '\xa0'` should be `s = b'\xa0'`. Should I file a bug? Please do, that helps us remember that the issue exists. Ronald -- Naoki INADA __

Re: [Python-Dev] a new setuptools release?

On 6 Oct, 2009, at 21:56, Olemis Lang wrote: Is it possible to fork `setuptools` somehow ? This way : Yes, see Ronald smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Pytho

Re: [Python-Dev] please consider changing --enable-unicode default to ucs4

On 7 Oct, 2009, at 20:05, M.-A. Lemburg wrote: If we do go for a change, we should use sizeof(wchar_t) as basis for the new default - on all platforms that provide a wchar_t type. I'd be -1 on that. Sizeof(wchar_t) is 4 on OSX, but all non-Unix API's that deal with Unicode text use ucs16.

Re: [Python-Dev] Python 2.6.4rc1

On 7 Oct, 2009, at 20:53, Brett Cannon wrote:I just tried building out of svn and a ton of tests that rely on urllib failed because the _scproxy module wasn't built and it unconditionally imports it under darwin. Turns out that it requires the Mac toolbox glue to be built which I always skip since

Re: [Python-Dev] please consider changing --enable-unicode default to ucs4

On 7 Oct, 2009, at 22:13, M.-A. Lemburg wrote: Ronald Oussoren wrote: On 7 Oct, 2009, at 20:05, M.-A. Lemburg wrote: If we do go for a change, we should use sizeof(wchar_t) as basis for the new default - on all platforms that provide a wchar_t type. I'd be -1 on that. Sizeof(wchar_

Re: [Python-Dev] Python 2.6.4rc1

On 7 Oct, 2009, at 23:09, Barry Warsaw wrote: On Oct 7, 2009, at 3:46 PM, Brett Cannon wrote: On Wed, Oct 7, 2009 at 12:42, Ronald Oussoren wrote: On 7 Oct, 2009, at 20:53, Brett Cannon wrote: I just tried building out of svn and a ton of tests that rely on urllib failed because

Re: [Python-Dev] Replacing IDLE

On 10 Nov, 2009, at 17:20, anatoly techtonik wrote: > On Tue, Nov 10, 2009 at 12:10 AM, "Martin v. Löwis" > wrote: >>> >>> Anatoly's question is actually a fair one for python-dev - we're the >>> ones that *ship* Idle, so it is legitimate to ask our reasons for >>> continuing to do so. >> >>

Re: [Python-Dev] Replacing IDLE

On 11 Nov, 2009, at 2:48, anatoly techtonik wrote: > On Tue, Nov 10, 2009 at 6:44 PM, Ronald Oussoren > wrote: >> >> What's so bad about IDLE that you'd like to replace it? > > That was exactly my previous question. You don't use IDLE either, so >

Re: [Python-Dev] Python 2.6.5

On 3 Feb, 2010, at 21:27, Zvezdan Petkovic wrote: > On Feb 3, 2010, at 3:07 PM, Martin v. Löwis wrote: > >>> This patch is still waiting a review and backporting from trunk. >>> >>> http://mail.python.org/pipermail/python-dev/2009-October/092771.html >>> >>> Can we get it in? >> >> Only if on

Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))

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

Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))

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

Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))

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

Re: [Python-Dev] Very Strange Argument Handling Behavior

On Friday, April 16, 2010, at 04:57PM, "Antoine Pitrou" wrote: >Mark Dickinson gmail.com> writes: >> >> Okay; I'll open an issue for deprecation in 3.2 and removal in 3.3. >> >> Can this sneak in under the 'incorrect language semantics' exemption >> for PEP 3003 (the moratorium PEP)? If no

Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)

On 14 Apr, 2010, at 23:37, Michael Foord wrote: > 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

Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)

On 15 Apr, 2010, at 0:12, Zvezdan Petkovic wrote: > 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 compatibil

Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)

On 15 Apr, 2010, at 6:36, Martin v. Löwis wrote: > 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 -

Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)

On 18 Apr, 2010, at 17:17, Martin v. Löwis wrote: > Ronald Oussoren wrote: >> On 15 Apr, 2010, at 6:36, Martin v. Löwis wrote: >> >>> Greg Ewing wrote: >>>> Michael Foord wrote: >>>>> Building Python requires, I believe, the XCode development

Re: [Python-Dev] Automatic installer builds (was Re: Fwd: Broken link to download (Mac OS X))

On 18 Apr, 2010, at 17:20, Martin v. Löwis wrote: >> We can certainly start by just trying to automate the execution of >> build-installer, something I suspect can be completely controlled from >> the master side, and then uploading the resulting dmg file. I'd be >> happy to help coordinate any

Re: [Python-Dev] Fwd: Broken link to download (Mac OS X)

On 24 Apr, 2010, at 18:15, Michael Foord wrote: > On 18/04/2010 15:13, Ronald Oussoren wrote: >> On 14 Apr, 2010, at 23:37, Michael Foord wrote: >> >> >>> On 14/04/2010 23:32, Greg Ewing wrote: >>> >>>> Michael Foord wrote: >>

Re: [Python-Dev] please take a look at buildbot result [was: Broken link to download (Mac OS X)]

On 29 Apr, 2010, at 16:39, Bill Janssen wrote: > Ned Deily wrote: > >> In article <19399.11323.946604.992...@montanaro.dyndns.org>, >> s...@pobox.com wrote: >> >>>Ned> Any idea what type of machine it is and where it is currently >>>Ned> located? >>> >>> I seem to recall it is/was a G

Re: [Python-Dev] please take a look at buildbot result [was: Broken link to download (Mac OS X)]

On 29 Apr, 2010, at 20:47, R. David Murray wrote: > On Thu, 29 Apr 2010 11:28:47 -0700, Bill Janssen wrote: >> 8 skips unexpected on darwin: >>test_aepack test_applesingle test_gdb test_macos test_macostools >>test_readline test_scriptpackages test_ttk_guionly >> >> Why is the skip of "t

Re: [Python-Dev] please take a look at buildbot result [was: Broken link to download (Mac OS X)]

On 29 Apr, 2010, at 20:28, Bill Janssen wrote: > Michael Foord wrote: > >> Well - I have nine failing tests on trunk for Mac OS X with Snow Leopard. >> >> 9 tests failed: >>test_cmd_line test_imp test_import test_posix test_pydoc >>test_runpy test_urllib2 test_urllib2_localnet test_war

Re: [Python-Dev] Running Clang 2.7's static analyzer over the code base

On 5 May, 2010, at 22:56, Brett Cannon wrote: > I am done running the analysis over trunk. I will not svnmerge these changes > into py3k as the amount of time and effort that would take equates to running > the static analyzer again just before 3.2 is released and possibly catching > more chan

Re: [Python-Dev] PEP 7 updated

On 9 May, 2010, at 20:33, Antoine Pitrou wrote: > > Hello, > > The untabification of C files didn't produce any noticeable problem on > the buildbots. I've updated PEP 7 with the mention that all C files > should be 4-space indented, and removed the obsolete wording about > some files being in

Re: [Python-Dev] configuring the buildbot to skip some tests?

On 13 May, 2010, at 20:41, Martin v. Löwis wrote: > Bill Janssen wrote: >> Martin v. Löwis wrote: >> >>> Bill Janssen wrote: I've got parc-tiger-1 up and running again. It's failing on test_tk, which makes sense, because it's running as a background twisted process, and thus can

Re: [Python-Dev] red buildbots on 2.7

On 21 Jun, 2010, at 22:25, Antoine Pitrou wrote: > Le lundi 21 juin 2010 à 21:13 +0100, Michael Foord a écrit : >> >> If OS X is a supported and important platform for Python then fixing all >> problems that it reveals (or being willing to) should definitely not be >> a pre-requisite of provid

Re: [Python-Dev] red buildbots on 2.7

On 22 Jun, 2010, at 3:38, Alexander Belopolsky wrote: > On Mon, Jun 21, 2010 at 6:16 PM, "Martin v. Löwis" wrote: >>> The test_posix failure is a regression from 2.6 (but it only shows up on >>> some machines - it is caused by a fairly braindead implementation of a >>> couple of posix apis by Ap

Re: [Python-Dev] red buildbots on 2.7

On 22 Jun, 2010, at 19:05, Alexander Belopolsky wrote: > On Tue, Jun 22, 2010 at 12:39 PM, Ronald Oussoren > wrote: > .. >> Both are valid fixes, both have both advantages and disadvantages. >> >> Your proposal: >> * Reverts to the behavior in 2.6 >

Re: [Python-Dev] os.getgroups() on MacOS X Was: red buildbots on 2.7

On 23 Jun, 2010, at 16:48, Alexander Belopolsky wrote: > On Wed, Jun 23, 2010 at 2:08 AM, Ronald Oussoren > wrote: > .. >>> >>>> * [Ronald's proposal] results in posix.getgroups not reflecting results of >>>> posix.setgroups >>>> &

Re: [Python-Dev] os.getgroups() on MacOS X Was: red buildbots on 2.7

On 24 Jun, 2010, at 3:26, Bill Janssen wrote: > See also http://gimper.net/viewtopic.php?f=18&t=3185. That's because setgroups(3) is limited to 16 groups (that is, the kernel doesn't support more than 16 groups at all). Ronald smime.p7s Description: S/MIME cryptographic signature __

Re: [Python-Dev] thoughts on the bytes/string discussion

On 27 Jun, 2010, at 11:48, Greg Ewing wrote: > Stefan Behnel wrote: >> Greg Ewing, 26.06.2010 09:58: >>> Would there be any sanity in having an option to compile >>> Python with UTF-8 as the internal string representation? >> It would break Py_UNICODE, because the internal size of a unicode chara

Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library

On 11 Jul, 2010, at 6:23, Guilherme Polo wrote: > 2010/7/10 Miki Tebeka : >> Hello Tal, >> >>> I would like to propose removing IDLE from the standard library. >> -1. >> One of the biggest "selling points" for me when switching to python was the >> "out of the box" working IDE with REPL, syntax

Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library

On 11 Jul, 2010, at 1:05, Tal Einat wrote: > Hello, > > I would like to propose removing IDLE from the standard library. > > I have been using IDLE since 2002 and have been doing my best to help > maintain and further develop IDLE since 2005. > > In recent years IDLE has received negligible i

Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library

On 11 Jul, 2010, at 10:57, Tal Einat wrote: > > When I ran into bugs I fixed them and submitted a patch. I have also > done so for quite a few bugs reported by others. However, there are > currently several bugs in the tracker which nobody is taking any > notice of. IIRC most of the recent bugs a

Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library

On 11 Jul, 2010, at 15:24, Kevin Walzer wrote: > On 7/11/10 5:03 AM, Ronald Oussoren wrote: >> > >> >> The OSX issues al seem to be related to general Tk or Tkinter bugs >> on OSX. I know to little about Tk and Tkinter to seriously work on >> tho

Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library

On 11 Jul, 2010, at 19:35, Bill Janssen wrote: > Tal Einat wrote: > >> Although several people say that they think having IDLE in the stdlib >> is important, the fact is that IDLE is considered quite unimportant by >> most of the Python community. Having IDLE in the stdlib may be >> convenient

Re: [Python-Dev] versioned .so files for Python 3.2

On 22 Jul, 2010, at 15:40, Barry Warsaw wrote: > > > Abstract > > > PEP 3147 [1]_ described an extension to Python's import machinery that > improved the sharing of Python source code, by allowing more than one > byte compilation file (.pyc) to be co-located with each source file. > >

Re: [Python-Dev] Distutils reverted in py3k

On 22 Jul, 2010, at 14:01, Tarek Ziadé wrote: > Note that I'll revert Doc/distutils as well, but I need to check first > with Ronald a few Mac OS X points. Not just a few point, the revert completely broke universal builds on OSX. I'm working on a fix. Ronald > ___

Re: [Python-Dev] Distutils reverted in py3k

On 23 Jul, 2010, at 10:12, Ronald Oussoren wrote: > > On 22 Jul, 2010, at 14:01, Tarek Ziadé wrote: > >> Note that I'll revert Doc/distutils as well, but I need to check first >> with Ronald a few Mac OS X points. > > Not just a few point, the revert complete

Re: [Python-Dev] Distutils reverted in py3k

On 23 Jul, 2010, at 10:47, Tarek Ziadé wrote: > 2010/7/23 Ronald Oussoren : >> >> On 23 Jul, 2010, at 10:12, Ronald Oussoren wrote: >> >>> >>> On 22 Jul, 2010, at 14:01, Tarek Ziadé wrote: >>> >>>> Note that I'll revert Doc/di

Re: [Python-Dev] versioned .so files for Python 3.2

On 23 Jul, 2010, at 11:02, Barry Warsaw wrote: > On Jul 22, 2010, at 03:58 PM, Ronald Oussoren wrote: > >> I guess this is not an explicit goal of this PEP, but the structure is >> very close to supporting multiple system architectures at the same >> time. I regularly

Re: [Python-Dev] versioned .so files for Python 3.2

On 23 Jul, 2010, at 11:54, Barry Warsaw wrote: > On Jul 23, 2010, at 11:48 AM, Ronald Oussoren wrote: > >>> I'd be open to adding the >>> platform name to the tag, but I'd probably define it as part of the >>> implementation field, e.g. foo.cpython-

Re: [Python-Dev] versioned .so files for Python 3.2

On 23 Jul, 2010, at 23:19, Barry Warsaw wrote: > On Jul 23, 2010, at 12:54 PM, Barry Warsaw wrote: > >> On Jul 23, 2010, at 11:48 AM, Ronald Oussoren wrote: >> >>>> I'd be open to adding the >>>> platform name to the tag, but I'd probably def

<    1   2   3   4   5   >