Re: [Python-Dev] Non-Core project: IDLE

[Mark Summerfield]

On 2009-03-25, Guilherme Polo wrote:
> On Tue, Mar 24, 2009 at 4:26 AM, Mark Summerfield  
wrote:
> > On 2009-03-23, Guilherme Polo wrote:
> >> On Mon, Mar 23, 2009 at 5:39 PM, Terry Reedy  wrote:
> >> > Guilherme Polo wrote:
> >> >> On Wed, Mar 18, 2009 at 8:53 PM, Terry Reedy  
wrote:
> >> >>> IDLE needs lots of attention -- more than any one experienced person
> >> >>> is likely to have
> >> >>
> >> >> I'm willing to step up as a student for this but I still have to
> >> >> write a good proposal for it.
> >> >> My actual concern is about mentor availability, is someone around
> >> >> interested on being an IDLE mentor ?
> >> >
> >> > If I could, I would, and would have said so.  But I have only read
> >> > about tk and have not actually used it.  If I did decide to dive into
> >> > it, you'd be mentoring me ;-).  What I can and would do is give ideas
> >> > for changes, read and comment on a proposal, and user test patched
> >> > versions.
> >>
> >> That is very nice Terry. Do you have some specific ideas that you want
> >> to share publicly (or in private) about IDLE ? Your expectations about
> >> what should be addressed first, or areas that should be improved.. you
> >> know, anything.
> >
> > I have one suggestion that I think might be widely appreciated:
> >
> > Add somewhere in the configuration dialog when users can enter a block
> > of Python code to be executed at startup and whenever Restart Shell is
> > executed.
> >
> > Use case: for people who use IDLE for calculations/experiments they
> > might like to always have certain module imported. For me personally, it
> > would be:
> >
> >import os
> >import re
> >import sys
> >from math import *
> >
> > but of course the whole point is that people can write any code they
> > like. (Some people might want to do various from __future__ imports in
> > Python 2.6 to get various Python 3 features for example.)
> >
> > I know that you can use the -c option, but that only works at startup,
> > not every time you Restart Shell.
>
> Looks like a good suggestion to me, Mark.
> I would recommend adding it as a feature request on the typical place
> (bugs.python.org) because although I could just go and do it, I
> believe you are aware that new features in IDLE are subject to
> approval or disapproval by other members involved with IDLE. Hope you
> understand my position.
[snip]

Added as issue 5594.


-- 
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
C++, Python, Qt, PyQt - training and consultancy
"Programming in Python 3" - ISBN 0137129297

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

Re: [Python-Dev] bdist_linux (was: setuptools has divided the Python community)

[Martin v. Löwis]

I think that each OS community should maintain its own tool, that complies
to the OS standard (wich has its own evolution cycle)

Of course this will be possible as long as Distutils let the system
packager find/change the metadata in an easy way.


In the specific case of RPMs, I still think that a distutils command
is the right solution. It may be that bdist_rpm is a bit too general,
and that bdist_fedora and bdist_suse might be more useful.

It all comes down to whether the .spec file is written manually or not.
*If* it is written manually, there is IMO no need to have the packager's
metadata readily available. Whoever writes the spec file can also look
at setup.py. OTOH, if the spec file is automatically generated, I can't
see why a bdist_ command couldn't do that - and a bdist_ command can
easily get at all the package (meta) data it needs.

So in this case, I think separate access to the meta-data
isn't needed/doesn't help.

For bdist_deb, things might be different, as the packager will certainly
want to maintain parts of the debian/ directory manually; other parts
would be generated. However, I still believe that a bdist_ command would
be appropriate (e.g. bdist_dpkg). As I understand Matthias Klose, the
tricky part here is that the packaging sometimes wants to reorganize
the files in a different layout, and for that, it needs to know what
files have what function (documentation, regular package, test suite,
etc). If that file classification isn't provided by the package author,
then there would be still a manually-maintained step to reorganize the
files.

The same is potentially true for RPM: if the files need to be layout
differently than the package author intended, automatic generation
of the spec file will also fail.


I think this is the same rationale for debian packages. Right now people tend
to use external tools like stdeb and they are OK with it (but still
gets problems extracting stuff out of Python packages at this point)


Explicit is better than implicit: What is your list of problems with stdeb?

Regards,
Martin

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

Re: [Python-Dev] bdist_linux (was: setuptools has divided the Python community)

[David Cournapeau]

2009/3/29 "Martin v. Löwis" :
>> I think that each OS community should maintain its own tool, that complies
>> to the OS standard (wich has its own evolution cycle)
>>
>> Of course this will be possible as long as Distutils let the system
>> packager find/change the metadata in an easy way.
>
> In the specific case of RPMs, I still think that a distutils command
> is the right solution. It may be that bdist_rpm is a bit too general,
> and that bdist_fedora and bdist_suse might be more useful.
>
> It all comes down to whether the .spec file is written manually or not.
> *If* it is written manually, there is IMO no need to have the packager's
> metadata readily available. Whoever writes the spec file can also look
> at setup.py. OTOH, if the spec file is automatically generated, I can't
> see why a bdist_ command couldn't do that - and a bdist_ command can
> easily get at all the package (meta) data it needs.
>
> So in this case, I think separate access to the meta-data
> isn't needed/doesn't help.
>
> For bdist_deb, things might be different, as the packager will certainly
> want to maintain parts of the debian/ directory manually; other parts
> would be generated. However, I still believe that a bdist_ command would
> be appropriate (e.g. bdist_dpkg). As I understand Matthias Klose, the
> tricky part here is that the packaging sometimes wants to reorganize
> the files in a different layout, and for that, it needs to know what
> files have what function (documentation, regular package, test suite,
> etc). If that file classification isn't provided by the package author,
> then there would be still a manually-maintained step to reorganize the
> files.

Maybe I don't understand what is meant by metadata, but I don't
understand why we can't provide the same metadata as autotools, so
that distutils could be customized from the command line to put data
where they belong (according to each OS convention). So that making a
FHS compliant package would be as simple as

python setup.py distutils --datadir=bla --htmldir=foo 

I spent some time looking at cabal this afternoon ("haskell
distutils"), and from my current understanding, that's exactly what
they are doing:

http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.html#pkg-descr

This way, if some metadata are not provided by upstream, the
downstream packager can fix it, and send patches upstream so that
other packagers benefit from it.

(FWIW, from the reading of cabal documentation, it looks like cabal
provides everything I would like distutils to provide: static
metadata, good documentation, sane handling of options, etc... Maybe
that's something worth looking into as inspiration for
improving/fixing distutils)

cheers,

David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Stephen J. Turnbull]

Antoine Pitrou writes:
 > Lennart Regebro  gmail.com> writes:
 > > 
 > > The people who use pythonlibraries are programmers. It can be expected
 > > that they are comfortable with the command line.
 > 
 > You probably haven't met lots of Windows (so-called) programmers...

Hey, the "(so-called)" should be avoided.  You'll lose your audience.

And it has very little to do with the issue at hand.  It's certainly
true that a lot of code is produced by people working in the Windows
environment who are somewhere between uncomfortable and totally at a
loss when faced with a shell prompt.  Whether they're "real"
programmers or "so-called" programmers, we believe that Python will
help them produce the best programs they're capable of, no?  Better
programs are a good thing, yes?  So they should (FSVO "should" not
necessarily implying Python-Dev should do something about it) have a
programming environment that enables their style of work.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Are buffer overflows in modules deleted in py3k ignorable?

[Gregory P. Smith]

It'd be worthy of fixing in 2.6 since the module exists.  Though honestly...
who cares about Irix?

On Sat, Mar 28, 2009 at 8:53 PM, R. David Murray wrote:

> I'm reviewing http://bugs.python.org/issue2591, which is marked as
> 'security' because it is a potential buffer overflow.  almodule.c has
> been dropped in py3k, so my impulse is to close the bug as "won't fix".
> But I thought I should check in to find out what the policy is before
> doing that since it is a 'security' bug.
>
> --
> R. David Murray http://www.bitdance.com
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bdist_linux

[Martin v. Löwis]

Maybe I don't understand what is meant by metadata, but I don't
understand why we can't provide the same metadata as autotools


Likewise, *this* I do not understand. In what way does autotools
*provide* metadata? I can understand that it *uses* certain metadata,
but it doesn't *provide* them...


So that making a
FHS compliant package would be as simple as

python setup.py distutils --datadir=bla --htmldir=foo 


What's the meaning of the distutils command?

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bdist_linux

[David Cournapeau]

On Sun, Mar 29, 2009 at 10:42 PM, "Martin v. Löwis"  wrote:
>
>> Maybe I don't understand what is meant by metadata, but I don't
>> understand why we can't provide the same metadata as autotools
>
> Likewise, *this* I do not understand. In what way does autotools
> *provide* metadata? I can understand that it *uses* certain metadata,
> but it doesn't *provide* them...

It does not provide them to external tools, true. Let me rephrase
this: why cannot distutils use and provide metadata corresponding to
the different categories as available in autotools ? It provides both
customization from the command line and a relatively straightforward
way to set which files go where.

Last time this point was discussed on distutils-sig, the main worry
came from people who do not care about tagging things appropriately. I
don't think it is a big problem, because people already do it in
setup.py, or distutils can do it semi automatically (it already has
different categories for .py, .pyc, data files, libraries). Also,
since packagers have to do it anyway, I think they would prefer
something which enable them to send those changes upstream instead of
every OS packager having to do it.

>> python setup.py distutils --datadir=bla --htmldir=foo 
>
> What's the meaning of the distutils command?

Sorry, this should read python setup.py install ...

cheers,

David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Are buffer overflows in modules deleted in py3k ignorable?

[R. David Murray]

On Sun, 29 Mar 2009 at 08:35, Gregory P. Smith wrote:

It'd be worthy of fixing in 2.6 since the module exists.  Though honestly...
who cares about Irix?


Guido commented on the ticket and closed it, so I closed the other two like it.

--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] pyc files, constant folding and borderline portability issues

[Antoine Pitrou]

Hello,

There are a couple of ancillary portability concerns due to optimizations which
store system-dependent results of operations between constants in pyc files:

- Issue #5057: code like '\U00012345'[0] is optimized away and its result stored
as a constant in the pyc file, but the result should be different in UCS-2 and
UCS-4 builds.
- Issue #5593: code like 1e16+2. is optimized away and its result stored as
a constant (again), but the result can vary slightly depending on the internal
FPU precision.

These problems have probably been there for a long time and almost no one seems
to complain, but I thought I'd report them here just in case.

Regards

Antoine.


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

Re: [Python-Dev] pyc files, constant folding and borderline portability issues

[Guido van Rossum]

On Sun, Mar 29, 2009 at 9:42 AM, Antoine Pitrou  wrote:
> There are a couple of ancillary portability concerns due to optimizations 
> which
> store system-dependent results of operations between constants in pyc files:
>
> - Issue #5057: code like '\U00012345'[0] is optimized away and its result 
> stored
> as a constant in the pyc file, but the result should be different in UCS-2 and
> UCS-4 builds.

Why would anyone write such code (disregarding the \U escape problem)?
So why do we bother optimizing this?

> - Issue #5593: code like 1e16+2. is optimized away and its result stored 
> as
> a constant (again), but the result can vary slightly depending on the internal
> FPU precision.

I would just not bother constant folding involving FP, or only if the
values involved have an exact representation in IEEE binary FP format.

> These problems have probably been there for a long time and almost no one 
> seems
> to complain, but I thought I'd report them here just in case.

I would expect that constant folding isn't nearly effective in Python
as in other (less dynamic) languages because it doesn't do anything
for NAMED constants. E.g.

MINUTE = 60

def half_hour():
return MINUTE*30

This should be folded to "return 1800" but doesn't because the
compiler doesn't know that MINUTE is a constant.

Has anyone ever profiled the effectiveness of constant folding on
real-world code? The only kind of constant folding that I expect to be
making a diference is things like unary operators, since e.g. "x = -2"
is technically an expression involving a unary minus.

ISTM that historically, almost every time we attempted some new form
of constant folding, we introduced a bug.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] python core project

[garg vikas]

    hi everybody , i am going to do the project  on nose compatibility with
core-python testing infrastructure. so i have written the abstract for this 
project if someone want
to mentor this project plesae contact me ?

 Core Python Testing Infrastructure | Nose 
compatibility 
         
ABSTRACT
 :-

Python is improving day by day by providing more features and facilites
to python programmers,but the developers of core-python has week
testing infrastructure, but as they are well known of the python code
so they can use their own hackish testing ,but "testing the core-python
code" is great problem for the new developers who want to participate
in developing core-python and are new to this core-python code.So
"core-python Testing Framework" requires improvements which can be
provided by using "nose - unit test discovery and execution framework"
which provides you selectively execute certain tests, capture and
collate error output, and add coverage and profiling information in
addition to finding and running your tests.so nose has such great
features but it has not campatible with core-python testing suit.So
that is my aim of project to provide nose framework to "core-python
testing suit".nose also provides one more good feature, that is plugins
support means you can write your plugins which helps in providing 

1. support for testing suits which are not compatible with nose
2. improve the functionality of nose to provide features to your testing 
infrastructure.
 
  
second aim of this project is not going to change anything of
core-python testing infrastructure or with nose but this project will
be an bridge between nose and core-python which will include nose
-plugins and wrappers for providing beautiful features like tag-based
execution,code-coverage and many more features to the core-python
testing infrastructure.it will make testing of code more relevent,make
easy fixing of bugs and as with its tag-based execution property will
help in running selective tests and which will also help in lowering
testing time.It's code-coverage property will make help in finding all
untested places in "code of core-python". 
   My email:- 
vikas_it_...@yahoo.co.in
Thanks
vikas garg



  Add more friends to your messenger and enjoy! Go to 
http://messenger.yahoo.com/invite/___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Evaluated cmake as an autoconf replacement

[Jeffrey Yasskin]

I've heard some good things about cmake — LLVM, googletest, and Boost
are all looking at switching to it — so I wanted to see if we could
simplify our autoconf+makefile system by using it. The biggest wins I
see from going to cmake are:
 1. It can autogenerate the Visual Studio project files instead of
needing them to be maintained separately
 2. It lets you write functions and modules without understanding
autoconf's mix of shell and M4.
 3. Its generated Makefiles track header dependencies accurately so we
might be able to add private headers efficiently.

However, after trying it out during PyCon and looking over the
previous attempt at
, I
can't recommend switching to it.

 A. It has no equivalent of autoheader, so we'd have to maintain
pyconfig.h.in by hand.
 B. It does not allow the CMakeLists.txt file control the --help
output. This appears to be an intentional decision
(http://www.cmake.org/pipermail/cmake-promote/2006-May/95.html).
To replace it, they have an interactive mode (which asks you about
each possible option) and a -LH flag (which runs the whole configure
process and then tells you about the flags you could have set if you
knew about them).
 C. It does not allow the CMakeLists.txt file to see the command line,
so we can't stay backward compatible with the configure script, and
we'd have to replace flags like --with-pydebug with
-Dpydebug:bool=true. We could write a separate configure script to
mitigate this and the previous problem, but we'd have to keep that in
sync with CMakeLists.txt manually.
 D. It doesn't have an expression language, so to replace
ac_md_system=`echo $ac_sys_system |
   tr -d '[/ ]' | tr '[[A-Z]]' '[[a-z]]'`
  you have to write:
string(REGEX REPLACE "[/ ]" "" ac_md_system ${ac_sys_system})
string(TOLOWER ${ac_md_system} ac_md_system)

So, at the very least, it doesn't look like a big enough win to
justify switching, and may not be a win at all.


The other popular configure+make replacement is scons. The biggest
objection to scons before even looking at it is that it requires a
working Python interpreter in order to build Python, causing a
bootstrap problem. However, Brett Cannon and I talked, and we think
this is surmountable. First, nearly every desktop system comes with a
Python interpreter, which would avoid the bootstrap for ordinary
development. Second, we need a cross compilation story anyway for
embedded systems, and the same mechanism could be used to get Python
onto a new desktop platform. Third, Jython and IronPython are pretty
mature and either can run scons now or should be able to run it after
some relatively easy tweaks. They could be used to build CPython on a
new platform. I don't intend to look into scons myself any time soon,
but I'd be interested in anyone's experiences who does try it.

Jeffrey
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Evaluated cmake as an autoconf replacement

[Aahz]

Nice report!  Thanks!
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it."  --Brian W. Kernighan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Evaluated cmake as an autoconf replacement

[Antoine Pitrou]

Jeffrey Yasskin  gmail.com> writes:
> 
> The other popular configure+make replacement is scons.

I can only give uninformed information (!) here, but in one company I worked
with, the main project decided to switch from scons to cmake due to some huge
performance problems in scons. This was in 2005-2006, though, and I don't know
whether things have changed.

If you want to investigate Python-based build systems, there is waf (*), which
apparently started out as a fork of scons (precisely due to the aforementioned
performance problems). Again, I have never tried it.

(*) http://code.google.com/p/waf/

Regards

Antoine.


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

Re: [Python-Dev] Evaluated cmake as an autoconf replacement

[David Cournapeau]

On Mon, Mar 30, 2009 at 2:59 AM, Antoine Pitrou  wrote:
> Jeffrey Yasskin  gmail.com> writes:
>>
>> The other popular configure+make replacement is scons.
>
> I can only give uninformed information (!) here, but in one company I worked
> with, the main project decided to switch from scons to cmake due to some huge
> performance problems in scons. This was in 2005-2006, though, and I don't know
> whether things have changed.

They haven't - scons is still slow. Python is not that big, though
(from a build POV) ?

I would think the bootstrap problem to be much more significant. I
don't find the argument "many desktop have already python" very
convincing - what if you can't install it, for example ? AFAIK, scons
does not run on jython or ironpython.

>
> If you want to investigate Python-based build systems, there is waf (*), which
> apparently started out as a fork of scons (precisely due to the aforementioned
> performance problems). Again, I have never tried it.

Waf is definitely faster than scons - something like one order of
magnitude. I am yet very familiar with waf, but I like what I saw -
the architecture is much nicer than scons (waf core amount of code is
almost ten times smaller than scons core), but I would not call it a
mature project yet.

About cmake: I haven't looked at it recently, but I have a bit of hard
time believing python requires more from a build system than KDE. The
lack of autoheader is not accurate, if
only because kde projects have it:

http://www.cmake.org/Wiki/CMake_HowToDoPlatformChecks

Whether using it compared to the current system is really a win for
python, I have no idea.

David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Evaluated cmake as an autoconf replacement

[Antoine Pitrou]

David Cournapeau  gmail.com> writes:
> 
> I would think the bootstrap problem to be much more significant. I
> don't find the argument "many desktop have already python" very
> convincing - what if you can't install it, for example ?

I agree. I had to build Python once on a corporate AIX box without any modern
facilities. If it had needed anything else than a standard C compiler, I
couldn't have done it.

> About cmake: I haven't looked at it recently, but I have a bit of hard
> time believing python requires more from a build system than KDE.

What are the compilation requirements for cmake itself? Does it only need a
standard C compiler and library, or are there other dependencies?


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

Re: [Python-Dev] Evaluated cmake as an autoconf replacement

[David Cournapeau]

On Mon, Mar 30, 2009 at 3:18 AM, Antoine Pitrou  wrote:

> What are the compilation requirements for cmake itself? Does it only need a
> standard C compiler and library, or are there other dependencies?

CMake is written in C++. IIRC, that's the only dependency.

cheers,

David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Evaluated cmake as an autoconf replacement

[Jeffrey Yasskin]

On Sun, Mar 29, 2009 at 1:14 PM, David Cournapeau  wrote:
> About cmake: I haven't looked at it recently, but I have a bit of hard
> time believing python requires more from a build system than KDE. The
> lack of autoheader is not accurate, if
> only because kde projects have it:
>
> http://www.cmake.org/Wiki/CMake_HowToDoPlatformChecks

That page says, "... So we write a source file named config.h.in...".
The purpose of autoheader is to write that file automatically. I might
have missed something, but you'll have to provide a more precise link.

The problems I found were enough to convince me that it wasn't worth
continuing to a full translation of configure.in and Makefile.pre.in.
If you or someone else wants to do that translation, I'd be happy to
look at the result in case it turns out not to be as inconvenient as I
currently expect.

Jeffrey
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Test failures under Windows?

[David Bolen]

David Bolen  writes:

>>From what I can see though, the tools/buildbot/test.bat file no longer
> adds the -n option that it used to, although I'm unclear on why it
> might have been removed.  Perhaps this was just a regression that was
> accidentally missed, as it appears to have disappeared during a large
> merger from trunk to the py3k branch mid-2008 (r64273) when the batch
> file line ending was changed to CRLF.
>
> It would be nice to also have this in the other active release branches.

This thread sort of died out ... would there be any objections to
restoring the -n option in the buildbot test.bat file for Windows
buildbots?

I just went through clearing a ton of popups again on my build slave,
but in the end had to again manually kill off all the individual
python_d processes, as the popups just seemed to keep getting created
anew.

I don't know why they are happening so frequently now when there was a
reasonable period when they weren't an issue (something about new I/O
support in 3.x perhaps?), but without preventing them it seems the
Windows build slaves are going to become (if not already) quite a bit
less useful.  Don't know about anyone else's but I can't watch mine
7x24.

-- David

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

[Python-Dev] Python 2.6.2

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'd like to release Python 2.6.2 the week after the conference.  I've  
talked to a few people here about it and the general consensus is that  
we do one brown-paper-bag-avoiding release candidate first.  Looking  
at the calendar, I propose the following schedule:


Monday April 6: 2.6.2 rc1
Friday April 10: 2.6.2 final

As usual, I plan on freezing the tree to create the Subversion tags at  
UTC 2200 or 6pm US/Eastern the day before the release to give Martin  
time to build the Windows installers.  If you have stuff to get into  
2.6.2, please do so before rc1.  You'll need to get approval from me  
for all changes between 2.6.2rc1 and 2.6.2 final.


Please let me know if this schedule does not work for you.
Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSc/t63EjvBPtnXfVAQLL1QQAs1MQKs4x4Zvg5kMyzfcM/7Gtl7OmB8it
dYVz0F0xuaWoNrAVxWrSnnIA4jaorZtWGk7/E0pn2kJ1oDdZdyqYQa0T86pKh1q0
n8/2ml8jNph92SlWK8UvgijK92x21rTBO1DZ+KJPJ0JYuCD2QTOTJY25MGk9M5LV
k8E5IzSr7R0=
=3Ezw
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Evaluated cmake as an autoconf replacement

[Neil Hodgson]

Jeffrey Yasskin:

>  1. It can autogenerate the Visual Studio project files instead of
> needing them to be maintained separately

   I have looked at a couple of build tools (scons was probably one)
that generate Visual Studio project files in the past and they
produced fairly poor project files, which would compile the code but
wouldn't be as capable as project files created by hand. Its been a
while so I can't remember the details. The current Python project
files are hierarchical, building several DLLs and an EXE and I think
this was outside the scope of the tools I looked at.

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

Re: [Python-Dev] Evaluated cmake as an autoconf replacement

[Christian Heimes]

Jeffrey Yasskin wrote:

>  1. It can autogenerate the Visual Studio project files instead of
> needing them to be maintained separately

I'm familiar with the Unix and the Windows build system. More than a
year ago I went to a great deal of work to migrate the Windows builds
from VS 7.1 to VS 9.0. I'm in doubt that any automatic tool can create
configuration files that are as good as our hand made files.

The VS project files support debug, non debug and profile guided
optimization builds for X86 and AMD64 including cross compilation of
AMD64 binaries. The project files are using multiple inheritance to
avoid duplication of options.
The differences between Windows and Unix builds are fairly large, too.
On Windows lots of modules are built in and the remaining Python
extensions are build with VS directly. On Unix most modules are build as
shared libraries using distutils and setup.py.

In my opinion any change to an automated system is a waste of precious
developer times and makes our Windows support worse.

Christian

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

Re: [Python-Dev] Evaluated cmake as an autoconf replacement

[Jeroen Ruigrok van der Werven]

-On [20090329 19:21], Jeffrey Yasskin (jyass...@gmail.com) wrote:
>However, Brett Cannon and I talked, and we think this is surmountable.
>First, nearly every desktop system comes with a Python interpreter, which
>would avoid the bootstrap for ordinary development.

This is quite a major assumption.

Most FreeBSD, NetBSD, and OpenBSD users tend to install a minimal binary OS
(kernel plus system tools) and then proceed to install third party
applications via either ports or pkgsrc. This means that Python gets built
from scratch. So depending on Python to build Python seems a bad decision if
you care for my opinion.

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
I must be cruel, only to be kind...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com