Re: [Python-Dev] Patch for trunk test_winsound.py (fixes my buildbot)

[Nick Coghlan]

Nick Coghlan wrote:
> While the patches are appreciated, please submit them to the tracker at 
> bugs.python.org rather than mailing them directly to this list.

This comment doesn't apply to your recent posts - looks like those have 
all been checked in already ;)

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.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] Patch for trunk test_winsound.py (fixes my buildbot)

[Nick Coghlan]

Trent Nelson wrote:
> winsound.Beep fails for me on the 'x86 2k8 trunk' build slave, which
> is a virtual Windows Server 2008 instance running under Hyper-V.  Not
> surprisingly, there's not a single audio-related device on this
> system.  The attached patch to test_winsound.py incorporates the
> _have_soundcard() checks to the BeepTest class, which fixes the
> problem for me.  (I've also tested the patch on a Vista system (that
> does have a soundcard) and everything works as expected.)

Trent,

While the patches are appreciated, please submit them to the tracker at 
bugs.python.org rather than mailing them directly to this list.

Regards,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.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] [Python-ideas] new super redux (better late than never?)

[Facundo Batista]

2008/3/5, Guido van Rossum <[EMAIL PROTECTED]>:

(Bringing this from python-ideas, Guido is talking about PEP 3135)

> Ehhh! The PEP's "reference implementation" is useless and probably
>  doesn't even work. The actual implementation is completely different.
>  If you want to help, a rewrite of the PEP to match reality would be
>  most welcome!

Guido, I know that in this fight-for-reality some of the PEPs for Py3
are not correct.

Which is the plan to handle this? Will the original authors fix them?
And if not, will these PEP be marked as "Caution: non compliant with
reality" or something?

PEPs are a great tool, one of the Python assets, and it's a pity that
we may not trust them...

Regards,

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
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] [Python-ideas] new super redux (better late than never?)

[Nick Coghlan]

Facundo Batista wrote:
> 2008/3/5, Guido van Rossum <[EMAIL PROTECTED]>:
> 
> (Bringing this from python-ideas, Guido is talking about PEP 3135)
> 
>> Ehhh! The PEP's "reference implementation" is useless and probably
>>  doesn't even work. The actual implementation is completely different.
>>  If you want to help, a rewrite of the PEP to match reality would be
>>  most welcome!
> 
> Guido, I know that in this fight-for-reality some of the PEPs for Py3
> are not correct.
> 
> Which is the plan to handle this? Will the original authors fix them?
> And if not, will these PEP be marked as "Caution: non compliant with
> reality" or something?
> 
> PEPs are a great tool, one of the Python assets, and it's a pity that
> we may not trust them...

Some PEPs (252/253 come to mind) already carry such warnings. The 
wording in those two PEPs suggests that this warning was added by the 
PEP editors after the fact:

[Editor's note: the ideas described in this PEP have been incorporated 
   into Python.  The PEP no longer accurately describes the implementation.]

In other cases we have gone back and fixed the PEP to match the 
implementation (e.g. PEP 343 was updated to reflect changes that 
happened prior to 2.5 release).

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.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] Documentation for ability to execute zipfiles & directories

[Nick Coghlan]

Georg Brandl wrote:
> Steve Holden schrieb:
>> Paul Moore wrote:
>>> On 04/03/2008, Nick Coghlan <[EMAIL PROTECTED]> wrote:
 Do we need a new appendix to the tutorial which goes into detail about
 the CPython interpreter's command line options, environment variables
 and details on what can be executed?
>>> There is a Python man page, which covers the command line usage.
>>> However, it's separate from the documentation, and it isn't bundled
>>> with the Windows installers - both of which are a real pain (for me,
>>> at least).
>>>
>>> I'd suggest taking the man page, adding the information about
>>> executing zip files and directories, and putting the whole lot into
>>> the formal documentation.
> 
> Look no further: http://docs.python.org/dev/using/cmdline.html

Thanks Georg, that looks like exactly the right place - I'll try to get 
that updated before the next alpha.

>> I've always found it rather counter-intuitive that you have to go to the 
>> Library Reference manual to find information about Python's built-in 
>> types, for example. I though the whole point of libraries was that they 
>> *aren't* built in, and represent baggage that should only be carried on 
>> necessary trips.
> 
> You speak my mind. For ages I've wanted to put the builtins together with
> the language reference into a new document called "Python Core Language".
> I've just never had the time to draft a serious proposal.

I borrowed the keys to Guido's time machine:

http://svn.python.org/view/sandbox/trunk/userref/

It hasn't been updated for a lot of the 2.6/3.0 features as yet, but it 
may be a decent basis for what you're considering here.

(and all credit to this thread for motivating me to actually get those 
files cleaned up and into the sandbox - I've been thinking about doing 
it for ages, but never got around to it).

(For MS Office users, you may need to get OpenOffice.org or similar in 
order to read the Open Document Format files)

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.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] Windows buildbots randomly die with twisted ConnectionLost errors?

[Thomas Heller]

Trent Nelson schrieb:
> I've started to see my build slave dying every so often with a
> twisted error half way through tests: ... test_htmlparser 
> test_httplib
> 
> remoteFailed: [Failure instance: Traceback (failure with no frames):
> twisted.internet.error.ConnectionLost: Connection to the other side
> was lost in a non-clean fashion. ]
> 
> Examples: 
> http://www.python.org/dev/buildbot/all/x86%20W2k8%20trunk/builds/46/step-test/0
>  
> http://www.python.org/dev/buildbot/all/x86%20W2k8%20trunk/builds/36/step-test/0
> 
> 
> I'm not sure if I should read into the fact that it's occurring after
> networking-oriented tests like test_httplib and test_ftplib.  Running
> rt.bat on the resulting build manually doesn't indicate any errors in
> these tests.  Have other Windows buildbot owners seen this?
> 
> Trent.

I have not observed this behaviour on my buildbots.  Have you looked into
the twistd.log logfile?

Thomas

___
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] Python XML Validator

[Mike Meyer]

On Wed, 05 Mar 2008 13:01:14 +1300 Greg Ewing <[EMAIL PROTECTED]> wrote:

> Mike Meyer wrote:
> > Trying to install it from the repository is a PITA, because
> > it uses both the easyinstall and Pyrex
> 
> It shouldn't depend on Pyrex as long as it's distributed
> with the generated C files. If it's not, that's an
> oversight on the part of the distributor.

Sorry I wasn't clear. "from the repository" means building from
sourced checked out of the source repository, not from a
distribution.

  http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
___
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] Python XML Validator

[Mike Meyer]

On Tue, 04 Mar 2008 15:44:32 -0800 Ned Deily <[EMAIL PROTECTED]> wrote:

> In article <[EMAIL PROTECTED]>,
>  Mike Meyer <[EMAIL PROTECTED]> wrote:
> > On Thu, 28 Feb 2008 23:42:49 + (UTC) Medhat Gayed 
> > <[EMAIL PROTECTED]> wrote:
> > > lxml is good but not written in python and difficult to install and 
> > > didn't 
> > > work
> > > on MacOS X.
> > lxml is built on top of libxml2/libxslt, which are bundled with most
> > Unix-like OS's (including Mac OS X), or available in their package
> > systems. Trying to install it from the repository is a PITA, because
> > it uses both the easyinstall and Pyrex (later Cython) packages - which
> > aren't bundled with anything. On the other hand, if it's in the
> > package system (I no longer have macports installed anywhere, but
> > believe it was there at one time), that solves all those problems. I
> > believe they've excised the easyinstall source dependencies, though.
> [...]
> > If you just want an xml module in the standard library that's more
> > complete, I'd vote for the source distribution of lxml, as that's C +
> > Python and built on top of commonly available libraries. The real
> > issue would be making current lxml work with the "outdated" versions
> > of those libraries found in current OS distributions.
> 
> I'm not sure what you perceive to be the problems with easy_install on 
> OSX; I find it makes life *much* simpler for managing python packages.

I don't, but the real issue is that it's been considered - and
rejected - for inclusion in the standard library multiple times. The
OPs request was for a validating XML parser in the standard
library. Any third party code that requires easy_install won't be
acceptable.

I think lxml is the best Python XML library that meets his
requirements, and it would make my life a lot easier if it were part
of the standard library. However, the authors tend to require recent
versions of libxml2 and libxslt, which means recent versions of lxml
won't build and/or work with the libraries bundled with many Unix and
Unix-like systems - including OSX. Which means you wind up having to
build those yourself if you want a recent version of lxml, even if
you're using a system that includes lxml in it's package system.


> Be that as it may, since the release of lxml 2.0, the project has 
> updated the lxml website with useful information about source 
> installations and, in particular, OSX source installations:
> 
> 
> 
> IIRC, here's what worked for me on Leopard (10.5.2) using the python.org 
> 2.5.2, though it should work fine with the Apple-supplied 2.5.1:

This is similar to what I went through with 1.3.6 on Tiger, but I used
MacPorts. On Leopard, 1.3.6 builds out of the box. Just do "sudo
python setup.py install" and you're done. That's probably the easiest
way to get a validating xml parser on OS X at this time.

 http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
___
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] Windows buildbots randomly die with twisted ConnectionLost errors?

[Trent Nelson]

Had a chat with some Twisted/buildbot folk and they can confirm they've seen it 
as well on Windows.  They've given me a few things to look into.  Out of 
interest, how are you running your buildbot?  Via the command line in an 
interactive desktop session, as a service, or as a scheduled task, or some 
other way?


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Thomas Heller [EMAIL 
PROTECTED]
Sent: 05 March 2008 10:03
To: python-dev@python.org
Subject: Re: [Python-Dev] Windows buildbots randomly die with twisted 
ConnectionLost errors?

Trent Nelson schrieb:
> I've started to see my build slave dying every so often with a
> twisted error half way through tests: ... test_htmlparser
> test_httplib
>
> remoteFailed: [Failure instance: Traceback (failure with no frames):
> twisted.internet.error.ConnectionLost: Connection to the other side
> was lost in a non-clean fashion. ]
>
> Examples:
> http://www.python.org/dev/buildbot/all/x86%20W2k8%20trunk/builds/46/step-test/0
>
> http://www.python.org/dev/buildbot/all/x86%20W2k8%20trunk/builds/36/step-test/0
>
>
> I'm not sure if I should read into the fact that it's occurring after
> networking-oriented tests like test_httplib and test_ftplib.  Running
> rt.bat on the resulting build manually doesn't indicate any errors in
> these tests.  Have other Windows buildbot owners seen this?
>
> Trent.

I have not observed this behaviour on my buildbots.  Have you looked into
the twistd.log logfile?

Thomas

___
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/tnelson%40onresolve.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

Re: [Python-Dev] [Python-ideas] new super redux (better late than never?)

[Guido van Rossum]

On Wed, Mar 5, 2008 at 3:56 AM, Facundo Batista
<[EMAIL PROTECTED]> wrote:
> 2008/3/5, Guido van Rossum <[EMAIL PROTECTED]>:
>
>  (Bringing this from python-ideas, Guido is talking about PEP 3135)
>
>
>  > Ehhh! The PEP's "reference implementation" is useless and probably
>  >  doesn't even work. The actual implementation is completely different.
>  >  If you want to help, a rewrite of the PEP to match reality would be
>  >  most welcome!
>
>  Guido, I know that in this fight-for-reality some of the PEPs for Py3
>  are not correct.
>
>  Which is the plan to handle this? Will the original authors fix them?
>  And if not, will these PEP be marked as "Caution: non compliant with
>  reality" or something?
>
>  PEPs are a great tool, one of the Python assets, and it's a pity that
>  we may not trust them...

PEP 3135 is the only one that is grossly wrong. It should be fixed. I
originally planned to do so myself (since I wrote the implementation)
but find I don't have the time. Volunteers welcome!

Regarding the OP's idea that started this thread, it's a waste of time.

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

Re: [Python-Dev] Windows buildbots randomly die with twisted ConnectionLost errors?

[Thomas Heller]

Trent Nelson schrieb:
> Had a chat with some Twisted/buildbot folk and they can confirm
> they've seen it as well on Windows.  They've given me a few things to
> look into.  Out of interest, how are you running your buildbot?  Via
> the command line in an interactive desktop session, as a service, or
> as a scheduled task, or some other way?

>From the command line in interactive sessions.

Thomas

___
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] Python XML Validator

[Bob Kline]

Mike Meyer wrote:
> I think lxml is the best Python XML library that meets his
> requirements, and it would make my life a lot easier if it were part
> of the standard library.

+1 (!)

-- 
Bob Kline
http://www.rksystems.com
mailto:[EMAIL PROTECTED]

___
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] Patch for trunk test_winsound.py (fixes my buildbot)

[Neal Norwitz]

On Wed, Mar 5, 2008 at 2:18 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
>  > While the patches are appreciated, please submit them to the tracker at
>  > bugs.python.org rather than mailing them directly to this list.
>
>  This comment doesn't apply to your recent posts - looks like those have
>  all been checked in already ;)

Just to follow up on what Nick said, you should submit patches to the
tracker.  While it's usually pretty easy to submit really small things
like this to the mailing list, it has two negative effects: 1)
clutters the mailing list with trivial things many people may not care
about, 2) it can easily be lost/forgotten.

Typically the only reason we post an actual patch on python-dev is to
spawn wider discussion.  Generally, patches should be posted as links
to the tracker rather than inline.  But keep the patches coming!

Cheers,
n
___
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] BSDDB3

[Martin v. Löwis]

> That said, it is my aim to keep bsddb in stdlib, providing a stable and
> featureful module. I think keeping bsddb development inside python svn
> is not appropiate.

I think it would be helpful if you could analyze the crashes that bsddb
caused on Windows. Just go back a few revisions in the subversion tree
to reproduce the crashes.

These were particularly bad since they invoked the CRT abort() inside
bsddb, namely inside __db_win32_mutex_unlock, which, in debug mode, 
would __db_panic with "Win32 unlock failed: lock already unlocked".

This problem has now been worked-around, by reformulating the test cases
so that the situation doesn't occur anymore, but IMO, it should not be
possible for an extension module to cause an interpreter abort.

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] Windows buildbots randomly die with twisted ConnectionLost errors?

[Martin v. Löwis]

> I'm not sure if I should read into the fact that it's occurring after
> networking-oriented tests like test_httplib and test_ftplib.  Running
> rt.bat on the resulting build manually doesn't indicate any errors in
> these tests.  Have other Windows buildbot owners seen this?

Notice that it also occurs in other steps, e.g.

http://www.python.org/dev/buildbot/all/x86%20W2k8%20trunk/builds/50/step-compile/0

Please understand that the basic principle of buildbot is that the 
slaves connect to the master, and that the master relies on the
slaves keeping the connection up.

Could it be that you are behind some firewall infrastructure which 
suddenly decides that certain TCP connections are idle/expired/closed?
In that case, the firewall might reject further messages from the
master, causing the master to believe that the connection was lost.

In that case, the slave should send repeated keepalive messages
(or the firewall be reconfigured to not close connections to
dinsdale:buildbot). It seem buildbot already has support for
keepalives, although the frequency might be too low.

In any case, you should check the twistd log files around the time
of the connection loss whether it shows any problems from the
client side as well.

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] Documentation reorganization

[Greg Ewing]

Adam Olsen wrote:
> The term "Displays" is pretty obscure as well,

Hmmm, I'd call them "constructor expressions" or some such.

-- 
Greg
___
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] Documentation reorganization

[Greg Ewing]

Georg Brandl wrote:
> Adam Olsen schrieb:
>
>>Another example is the use of BNF, which although dominant in its
>>field, it provides a steep learning curve for most programmers.
> 
> We could of course accompany each BNF-described item with an example.

An alternative to BNF would be syntax diagrams. They're
just as formal, and can be a lot easier to read.

-- 
Greg
___
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] Compiler used to build Python for Windows

[Greg Ewing]

Steven Bethard wrote:
> Is this mainly a request to use more open source tools?  Because if
> the concern is just cost, Python 2.6 and 3.0 compile with the free
> Microsoft Visual Studio 2008 Express editions.

I don't think it's only about cost, it's about not
being reliant on tools that appear and disappear at
the whim of Microsoft. Their "free" compilers only
last until the next version, then they become
unavailable. So it can still be a problem finding
exactly the right version to match your Python
installation, if you missed the window of opportunity
to download it.

-- 
Greg
___
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] Compiler used to build Python for Windows

[Steve Holden]

Greg Ewing wrote:
> Steven Bethard wrote:
>> Is this mainly a request to use more open source tools?  Because if
>> the concern is just cost, Python 2.6 and 3.0 compile with the free
>> Microsoft Visual Studio 2008 Express editions.
> 
> I don't think it's only about cost, it's about not
> being reliant on tools that appear and disappear at
> the whim of Microsoft. Their "free" compilers only
> last until the next version, then they become
> unavailable. So it can still be a problem finding
> exactly the right version to match your Python
> installation, if you missed the window of opportunity
> to download it.
> 
Yes, it would be nice to be able to avoid "Microsoft Version Churn" 
without having to spring for the commercial versions of Visual Studio.

Mingw tends to be rather more stable (though not itself without the 
occasional library compatibility issue), and more freely available.

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.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] Hello

[andrew rainwater]

Hello to all I am a new member.
___
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] Optimizing with.

[Jeffrey Yasskin]

I've got a patch in http://bugs.python.org/issue2179 that optimizes
the bytecode generated by a with statement by tucking the
context_manager.__exit__ method onto the stack. It saves 2 opcodes, 8
bytes, and about .5us for each with block at the cost of an extra
stack entry for the duration of the block. Since it's the first time
I've touched the core of the compiler and interpreter, I'm hoping that
someone can take a look before I check it in.

Thanks!
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] Compiler used to build Python for Windows

[Alexey Borzenkov]

On Thu, Mar 6, 2008 at 3:52 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
>  Mingw tends to be rather more stable (though not itself without the
>  occasional library compatibility issue), and more freely available.

Not all extensions can be built using mingw (pywin32 comes to mind
immediately). And while you can almost easily (but not very easily,
since you need to patch libmoldname yourself and then update your spec
file) change runtime used by mingw, you cannot do so with Visual
Studio. Besides, this would require spec-editing on both, build
machines, as well as user machines (otherwise you get extensions that
depend on both msvcrt.dll and msvcrXX.dll), this is a complication
too. Runtime compatibility could be a potential problem (or maybe not,
if WITH_PYMALLOC maybe fixes that?), so official mingw port (as much
as I'd like for one to be there) does not seem feasible to me in any
future, Python is already too far on the needle of Visual Studio. :(

The biggest problem would also be with some extensions' setup.py. Many
extensions I've seen hardwire to distutils.msvccompiler in one way or
another. If official python would shift to mingw, they would suddenly
break.

I think the best lesson here is Tcl. Because it uses stubs mechanism,
you don't need to depend on tclXX.dll, you don't deal with really
direct implementation details, you don't care about runtimes,
everything is much easier. Maybe it's possible (and not too late) for
Python to somehow embrace such mechanism?
___
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] BSDDB3 (was: Re: Buildbots for trunk are all red)

[Gregory P. Smith]

On 3/4/08, Jesus Cea <[EMAIL PROTECTED]> wrote:

> That said, it is my aim to keep bsddb in stdlib, providing a stable and
> featureful module. I think keeping bsddb development inside python svn
> is not appropiate. Currently (I could change idea), my approach will be
> keeping pybssdb as a separate project and sync with python SVN from time
> to time. Mainly to take advantage of buildbot architecture and, of
> course, to be able to release python with current bindings.
>
> Since I have no python commit access, this seems a sensible approach.
> And I could do frequent pybssdb releases (let say, every couple of
> months) without waiting for a full python release (current approach).


That makes sense.  I also agree with Neal's comments, merging back into
python in reasonable sized chunks is good.  Don't worry about commit access
for now, I'll do the initial pybsddb back into python trunk merges until we
get that setup.  I've merged the python trunk changes that others have made
back into the pybsddb tree.

PS: I have tried to sign the Python Contributor Agreement, but I am not
> sure about current pybsddb license terms. Help welcomed.


The current bsddb license first and foremost is the Python license.  If I
read the comments in the _bsddb file correctly I believe you could also call
it a MIT style license.  Keep things simple, just write "Python License" on
your contributor form and submit it.

-gps
___
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] [Python-checkins] r61264 - in python/trunk: Lib/test/test_os.py Misc/NEWS

[Trent Nelson]

Hurrah, 'x86 W2k8 trunk' has just experienced its first green build and test!  
Thanks to everyone that committed the various patches I sent out in such a 
timely fashion.

Martin, does this mean I can have a slave set up for x64 now? }:>

Trent.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:python-checkins-
> [EMAIL PROTECTED] On Behalf Of martin.v.loewis
> Sent: 06 March 2008 01:55
> To: [EMAIL PROTECTED]
> Subject: [Python-checkins] r61264 - in python/trunk:
> Lib/test/test_os.py Misc/NEWS
>
> Author: martin.v.loewis
> Date: Thu Mar  6 07:55:22 2008
> New Revision: 61264
>
> Modified:
>python/trunk/Lib/test/test_os.py
>python/trunk/Misc/NEWS
> Log:
> Patch #2232: os.tmpfile might fail on Windows if the user has no
> permission to create files in the root directory.
> Will backport to 2.5.

___
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] Compiler used to build Python for Windows

[Martin v. Löwis]

> I think the best lesson here is Tcl. Because it uses stubs mechanism,
> you don't need to depend on tclXX.dll, you don't deal with really
> direct implementation details, you don't care about runtimes,
> everything is much easier. Maybe it's possible (and not too late) for
> Python to somehow embrace such mechanism?

It would be possible, but it would be a fairly large project. You would
have to remove a lot of things from the Python header files, and that
would cause significant breakage in existing extension modules.

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] Documentation for ability to execute zipfiles & directories

[Georg Brandl]

Nick Coghlan schrieb:
> Georg Brandl wrote:
>> Steve Holden schrieb:
>>> Paul Moore wrote:
 On 04/03/2008, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Do we need a new appendix to the tutorial which goes into detail about
> the CPython interpreter's command line options, environment variables
> and details on what can be executed?
 There is a Python man page, which covers the command line usage.
 However, it's separate from the documentation, and it isn't bundled
 with the Windows installers - both of which are a real pain (for me,
 at least).

 I'd suggest taking the man page, adding the information about
 executing zip files and directories, and putting the whole lot into
 the formal documentation.
>> 
>> Look no further: http://docs.python.org/dev/using/cmdline.html
> 
> Thanks Georg, that looks like exactly the right place - I'll try to get 
> that updated before the next alpha.

Great! Feel free to add anything you think would make it a more complete
document.

>>> I've always found it rather counter-intuitive that you have to go to the 
>>> Library Reference manual to find information about Python's built-in 
>>> types, for example. I though the whole point of libraries was that they 
>>> *aren't* built in, and represent baggage that should only be carried on 
>>> necessary trips.
>> 
>> You speak my mind. For ages I've wanted to put the builtins together with
>> the language reference into a new document called "Python Core Language".
>> I've just never had the time to draft a serious proposal.
> 
> I borrowed the keys to Guido's time machine:
> 
> http://svn.python.org/view/sandbox/trunk/userref/
> 
> It hasn't been updated for a lot of the 2.6/3.0 features as yet, but it 
> may be a decent basis for what you're considering here.
> 
> (and all credit to this thread for motivating me to actually get those 
> files cleaned up and into the sandbox - I've been thinking about doing 
> it for ages, but never got around to it).

Thanks, I'll certainly look at them!

Georg

___
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] [Python-checkins] r61264 - in python/trunk: Lib/test/test_os.py Misc/NEWS

[Martin v. Löwis]

Trent Nelson wrote:
> Hurrah, 'x86 W2k8 trunk' has just experienced its first green build
> and test!  Thanks to everyone that committed the various patches I
> sent out in such a timely fashion.
> 
> Martin, does this mean I can have a slave set up for x64 now? }:>

Versprochen ist versprochen :-)

I'll send you the details.

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