Re: [Python-Dev] Another mercurial repo

2010-02-23 Thread Barry Warsaw 
On Feb 23, 2010, at 01:04 AM, Dirkjan Ochtman wrote:

>On Tue, Feb 23, 2010 at 00:57, "Martin v. Löwis"  wrote:
>> Can I use that to filter out distutils2 commits?
>
>Well, I don't think we'll do commit emails for distutils2 or
>unittest2, only for benchmarks (to python-checkins, anyway). I'll make
>sure that you can filter something out by repository.

I think we should have commit emails for all projects hosted on
hg.python.org.  Those emails should perhaps go to different mailing lists, but
post-commit emails are a great way for community members to follow the
developments of our various projects.

-Barry



signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Another mercurial repo

2010-02-23 Thread Barry Warsaw 
On Feb 23, 2010, at 01:56 AM, Tarek Ziadé wrote:

>Let me know if it fits your maintenance process. if so I'll ask for a
>mailing list for this particular repo.

Ask and ye shall receive :)

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial move?

2010-02-23 Thread Frank Wierzbicki 
On Mon, Feb 22, 2010 at 6:12 PM, Guido van Rossum  wrote:
> In that case congrats on beating us to the punch!
>
> Let us know how it goes.
Will, do, thanks!

-Frank
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Another mercurial repo

2010-02-23 Thread Dirkjan Ochtman 
On Tue, Feb 23, 2010 at 08:32, Barry Warsaw  wrote:
> I think we should have commit emails for all projects hosted on
> hg.python.org.  Those emails should perhaps go to different mailing lists, but
> post-commit emails are a great way for community members to follow the
> developments of our various projects.

I definitely agree that there should be post-push mails for every
repo, it's just a matter of what list to send them too, since
python-checkins may not be the right one for each repo hosted there.

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Using git to checkout Python

2010-02-23 Thread Neil Schemenauer 
For those interested, I updated my instructions for using the git
repositories on svn.python.org.  They are now on the Python wiki:

http://wiki.python.org/moin/Git

Regards,

  Neil
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.1 and 2.7 break format() when used with complex (sometimes)

2010-02-23 Thread Eric Smith 

The root cause of this problem is object.__format__, which is basically:

def __format__(self, fmt):
  return str(self).__format__(fmt)

So here we're changing the type of the object (to str) but still keeping 
the same format string. That doesn't make any sense: the format string 
is type specific. I think the correct thing to do here is to make it an 
error if fmt is non-empty. In 2.7 and 3.2 I can make this a 
PendingDeprecationWarning, then in 3.3 a DeprecationWarning, and finally 
make it an error in 3.4.


I have this implemented in issue 7994 with a PendingDeprecationWarning. 
Unless someone objects I'm going to document it and apply the patch.


Eric.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Platform extension for distutils on other interpreters than CPython

2010-02-23 Thread Maciej Fijalkowski 
Hello.

I would like to have a feature on platform module (or sys or
somewhere) that can tell distutils or distutils2 that this platform
(be it PyPy or Jython) is not able to compile any C module. The
purpose of this is to make distutils bail out in more reasonable
manner than a compilation error in case this module is not going to
work on anything but CPython.

What do you think?

Cheers,
fijal
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Platform extension for distutils on other interpreters than CPython

2010-02-23 Thread Daniel Stutzbach 
On Tue, Feb 23, 2010 at 12:50 PM, Maciej Fijalkowski wrote:

> I would like to have a feature on platform module (or sys or
> somewhere) that can tell distutils or distutils2 that this platform
> (be it PyPy or Jython) is not able to compile any C module. The
> purpose of this is to make distutils bail out in more reasonable
> manner than a compilation error in case this module is not going to
> work on anything but CPython.
>

Also, it would be nice if the package could tell distutils that the
compilation is option, in order to support modules where the C version
simply replaces functions for speed.
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Platform extension for distutils on other interpreters than CPython

2010-02-23 Thread Frank Wierzbicki 
On Tue, Feb 23, 2010 at 1:50 PM, Maciej Fijalkowski  wrote:
> Hello.
>
> I would like to have a feature on platform module (or sys or
> somewhere) that can tell distutils or distutils2 that this platform
> (be it PyPy or Jython) is not able to compile any C module. The
> purpose of this is to make distutils bail out in more reasonable
> manner than a compilation error in case this module is not going to
> work on anything but CPython.
FWIW this would be helpful for Jython too.

-Frank
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Platform extension for distutils on other interpreters than CPython

2010-02-23 Thread Tarek Ziadé 
On Tue, Feb 23, 2010 at 1:50 PM, Maciej Fijalkowski  wrote:
> Hello.
>
> I would like to have a feature on platform module (or sys or
> somewhere) that can tell distutils or distutils2 that this platform
> (be it PyPy or Jython) is not able to compile any C module. The
> purpose of this is to make distutils bail out in more reasonable
> manner than a compilation error in case this module is not going to
> work on anything but CPython.
>
> What do you think?

+1

I think we could have a global variable in sys, called "dont_compile",
distutils would look at
before it tris to compile stuff, exactly like how it does for pyc file
(sys.dont_write_bytecode)

Regards
Tarek
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Platform extension for distutils on other interpreters than CPython

2010-02-23 Thread Tarek Ziadé 
On Tue, Feb 23, 2010 at 2:03 PM, Daniel Stutzbach
 wrote:
> On Tue, Feb 23, 2010 at 12:50 PM, Maciej Fijalkowski 
> wrote:
>>
>> I would like to have a feature on platform module (or sys or
>> somewhere) that can tell distutils or distutils2 that this platform
>> (be it PyPy or Jython) is not able to compile any C module. The
>> purpose of this is to make distutils bail out in more reasonable
>> manner than a compilation error in case this module is not going to
>> work on anything but CPython.
>
> Also, it would be nice if the package could tell distutils that the
> compilation is option, in order to support modules where the C version
> simply replaces functions for speed.

There's an option called "optional" in the Extension class right now
that will silent any compilation failures (like gcc not being there),
so your project still installs.

That's basically what people now can use when they have a pure Python
fallback version they
want to provide in case the C version cannot be built for any reason.

Tarek


-- 
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Platform extension for distutils on other interpreters than CPython

2010-02-23 Thread Tarek Ziadé 
On Tue, Feb 23, 2010 at 2:10 PM, Tarek Ziadé  wrote:
> On Tue, Feb 23, 2010 at 1:50 PM, Maciej Fijalkowski  wrote:
>> Hello.
>>
>> I would like to have a feature on platform module (or sys or
>> somewhere) that can tell distutils or distutils2 that this platform
>> (be it PyPy or Jython) is not able to compile any C module. The
>> purpose of this is to make distutils bail out in more reasonable
>> manner than a compilation error in case this module is not going to
>> work on anything but CPython.
>>
>> What do you think?
>
> +1
>
> I think we could have a global variable in sys, called "dont_compile",
> distutils would look at
> before it tris to compile stuff, exactly like how it does for pyc file
> (sys.dont_write_bytecode)

Or... wait : we already know if we are using CPython, or Jython
reading sys.platform.

So I could simply not trigger the compilation in case sys.platform is
one of the CPythons
and keep in distutils side a list of the platform names, Extension is
incompatible with.

That makes me wonder : why don't we have a sys.implementation variable ?
(cython/jython/pypi), since we can have several values for cython in
sys.platform


Tarek
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Platform extension for distutils on other interpreters than CPython

2010-02-23 Thread Maciej Fijalkowski 
On Tue, Feb 23, 2010 at 2:27 PM, Tarek Ziadé  wrote:
> On Tue, Feb 23, 2010 at 2:10 PM, Tarek Ziadé  wrote:
>> On Tue, Feb 23, 2010 at 1:50 PM, Maciej Fijalkowski  wrote:
>>> Hello.
>>>
>>> I would like to have a feature on platform module (or sys or
>>> somewhere) that can tell distutils or distutils2 that this platform
>>> (be it PyPy or Jython) is not able to compile any C module. The
>>> purpose of this is to make distutils bail out in more reasonable
>>> manner than a compilation error in case this module is not going to
>>> work on anything but CPython.
>>>
>>> What do you think?
>>
>> +1
>>
>> I think we could have a global variable in sys, called "dont_compile",
>> distutils would look at
>> before it tris to compile stuff, exactly like how it does for pyc file
>> (sys.dont_write_bytecode)
>
> Or... wait : we already know if we are using CPython, or Jython
> reading sys.platform.
>
> So I could simply not trigger the compilation in case sys.platform is
> one of the CPythons
> and keep in distutils side a list of the platform names, Extension is
> incompatible with.
>
> That makes me wonder : why don't we have a sys.implementation variable ?
> (cython/jython/pypi), since we can have several values for cython in
> sys.platform
>
>
> Tarek
>

That's pypy. pypi is something else. sys.platform is not any good,
since for example PyPy, and possibly any other python implementation
that is not CPython, but it's not tied to any particular platform
(like parrot) would say "linux2" or "win32".

sys.implementation sounds good, but it'll also require a list in
stdlib what's fine and what's not fine and a flag sounds like
something that everyone can set, not asking to be listed in stdlib.

How about sys.implementation.supports_extensions?

Cheers,
fijal
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Platform extension for distutils on other interpreters than CPython

2010-02-23 Thread Tarek Ziadé 
On Tue, Feb 23, 2010 at 2:44 PM, Maciej Fijalkowski  wrote:
> On Tue, Feb 23, 2010 at 2:27 PM, Tarek Ziadé  wrote:
>> On Tue, Feb 23, 2010 at 2:10 PM, Tarek Ziadé  wrote:
>>> On Tue, Feb 23, 2010 at 1:50 PM, Maciej Fijalkowski  
>>> wrote:
 Hello.

 I would like to have a feature on platform module (or sys or
 somewhere) that can tell distutils or distutils2 that this platform
 (be it PyPy or Jython) is not able to compile any C module. The
 purpose of this is to make distutils bail out in more reasonable
 manner than a compilation error in case this module is not going to
 work on anything but CPython.

 What do you think?
>>>
>>> +1
>>>
>>> I think we could have a global variable in sys, called "dont_compile",
>>> distutils would look at
>>> before it tris to compile stuff, exactly like how it does for pyc file
>>> (sys.dont_write_bytecode)
>>
>> Or... wait : we already know if we are using CPython, or Jython
>> reading sys.platform.
>>
>> So I could simply not trigger the compilation in case sys.platform is
>> one of the CPythons
>> and keep in distutils side a list of the platform names, Extension is
>> incompatible with.
>>
>> That makes me wonder : why don't we have a sys.implementation variable ?
>> (cython/jython/pypi), since we can have several values for cython in
>> sys.platform
>>
>>
>> Tarek
>>
>
> That's pypy. pypi is something else. sys.platform is not any good,
> since for example PyPy, and possibly any other python implementation
> that is not CPython, but it's not tied to any particular platform
> (like parrot) would say "linux2" or "win32".
>
> sys.implementation sounds good, but it'll also require a list in
> stdlib what's fine and what's not fine and a flag sounds like
> something that everyone can set, not asking to be listed in stdlib.
>
> How about sys.implementation.supports_extensions?

I think its the other way around:

You are making the assumption that, sys knows about distutils extensions.
and there's no indication about the kind of extension here (C, etc..).

In distutils, the Extension class works with a compiler class
(ccompiler, mingwcompiler, etc)
And in theory, people could add a new compiler that works under PyPy or Jython.

So I think it's up to the Compiler class (through the Extension
instance) to decide if the environment is suitable.

For instance in the CCompiler class I can write things like:

if sys.implementation != 'cython':
warning.warn('Sorry I cannot compile this under %s' % sys.implementation)

Tarek

-- 
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Question for you

2010-02-23 Thread Connor, Craig A. 
Hello, Dave;
   My name is Craig Connor and I am a senior s/w developer at Northrop
Grumman.
I have a question for you. I have installed Boost (via the Installer),
and stored it into my 
C Drive inside a dir called:  
C:\boost_1_42

I also installed the Boost Jam into a directory called: 
   C:\boost-jam-3.1.17

I am using 2 separate compilers in my Win OS XP (SP3)
and I would like to be able to use the Python module of Boost
in order to embed Python.h into my C++ compiler.

The C++ compilers that I have are:
o Dev-cpp, and 
o Visual C++.net  (of MS Visual Studio.Net 2008).

Problem:
   When I compile a simple program, I keep getting the error:
"pyconfig.h: No such file or directory".

The program I am trying to start with is (below):
#include 
#include
#include

using namespace std;

int main( )
{
  cout << "Hello, Boost World!!" << endl;
  boost::any a(5);
  a = 7.67;
  std::cout<(a)<___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Question for you

2010-02-23 Thread Michael Foord 

Hello Connor,

I think you have the wrong email address - this is Python-dev, an email 
list for the development *of* Python.


All the best,

Michael Foord

On 23/02/2010 15:41, Connor, Craig A. wrote:


Hello, Dave;

   My name is Craig Connor and I am a senior s/w developer at Northrop 
Grumman.


I have a question for you. I have installed* Boost* (via the 
Installer), and stored it into my


C Drive inside a dir called:

* C:\boost_1_42*

I also installed the* Boost Jam* into a directory called:

* C:\boost-jam-3.1.17*

I am using 2 separate compilers in my* Win OS XP (SP3)*

and I would like to be able to use the Python module of Boost

in order to embed Python.h into my C++ compiler.

The C++ compilers that I have are:

o* Dev-cpp*, and

o* Visual C++.net*  (of* MS Visual Studio.Net 2008*).

Problem:

   When I compile a simple program, I keep getting the error: 
"*pyconfig.h: No such file or directory*".


The program I am trying to start with is (below):

*#include *

*#include*

*#include*

*using namespace std;*

*int main( )*

*{*

*  cout << "Hello, Boost World!!" << endl;*

*  boost::any a(5);*

*  a = 7.67;*

*  std::cout<(a)

Re: [Python-Dev] PEP 385 progress report

2010-02-23 Thread Benjamin Peterson 
2010/2/23 Dirkjan Ochtman :
> On Tue, Feb 23, 2010 at 01:06, "Martin v. Löwis"  wrote:
>> I thought we decided not to have a 2to3 repository at all, but let this
>> live in the Python trunk exclusively.
>
> That would be fine with me, I just remembered that Benjamin would like
> to start using hg sooner and having it as a separate repo was okay.

I would :), but Martin is correct in that we agreed to start
developing it as part of the trunk when the hg transition takes place.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com