On Thu, Mar 26, 2009 at 2:42 PM, Stephen J. Turnbull wrote:
>
> +-> E --> downstream developer -+
> | |
> | +--+ V
> source -> build -> A -> B -+-> C ->
David Cournapeau writes:
> On Thu, Mar 26, 2009 at 12:02 PM, Nick Coghlan wrote:
>
> > If that perception is accurate, then any changes likely need to focus on
> > the *opposite* end of the toolchain: the part between the " > packaging spec>" and the end users.
>
> Yes - but is this part
On Thu, Mar 26, 2009 at 2:01 PM, Nick Coghlan wrote:
> Yes, that metadata is what I meant to refer to rather than zipped .egg
> files specifically. An egg is just one example of something which
> includes that metadata.
Ok, my bad. Being able to describe meta-data for installed files is
indeed s
On Thu, Mar 26, 2009 at 2:01 PM, Tarek Ziadé wrote:
> On Thu, Mar 26, 2009 at 5:32 AM, David Cournapeau wrote:
>> If distutils was split into different modules (one for the build, one
>> for the compiler/platform configuration, one for the installation),
>> which could be extended, tweaked, it wo
Tarek Ziadé wrote:
> On Thu, Mar 26, 2009 at 5:19 AM, David Cournapeau wrote:
>> Why coming from eggs and not from the build tool provided by python
>> itself (distutils) ? I don't see what eggs brings - specially since
>> the format is not even standardized.
>
> I don't think the "egg as a forma
On Thu, Mar 26, 2009 at 5:32 AM, David Cournapeau wrote:
> If distutils was split into different modules (one for the build, one
> for the compiler/platform configuration, one for the installation),
> which could be extended, tweaked, it would be much better. But the
> distutils design makes this
Guido van Rossum wrote:
> On Wed, Mar 25, 2009 at 6:22 AM, Nick Coghlan wrote:
>> It could perhaps be done by enhancing the part of the
>>> 'for' loop that gets executed upon normal termination
>>> of the iterator.
>>>
>>> for x in my_iter:
>>> do_something_with(x)
>>> else v:
>>> hand
Guido van Rossum wrote:
> On Wed, Mar 25, 2009 at 5:46 AM, Nick Coghlan wrote:
>> Having helped with that kind of rename once (and for a relatively small
>> API at that), I'd want a *really* compelling reason before ever going
>> through it again - it's messy, tedious and a really good way to burn
On Thu, Mar 26, 2009 at 5:19 AM, David Cournapeau wrote:
> On Thu, Mar 26, 2009 at 12:02 PM, Nick Coghlan wrote:
>
>> If that perception is accurate, then any changes likely need to focus on
>> the *opposite* end of the toolchain: the part between the "> packaging spec>" and the end users.
>
> Ye
On Tue, Mar 24, 2009 at 11:03 PM, Greg Ewing
wrote:
> Guido van Rossum wrote:
>
>> The way I think of it, that refactoring has nothing to do with
>> yield-from.
>
> I'm not sure what you mean by that. Currently it's
> *impossible* to factor out code containing a yield.
That's stating it a little
On Thu, Mar 26, 2009 at 12:26 PM, "Martin v. Löwis" wrote:
>> Tools like setuptools, zc.buildout, etc. seem great for developers but not
>> very good for distributions. At last year's Pycon I think there was
>> agreement from the Linux distributors that distutils, etc. just wasn't very
>> useful
On Wed, Mar 25, 2009 at 6:22 AM, Nick Coghlan wrote:
> Greg Ewing wrote:
>> Would you be happier if some syntactic way to do that
>> were provided?
>>
>> It could perhaps be done by enhancing the part of the
>> 'for' loop that gets executed upon normal termination
>> of the iterator.
>>
>> for x
ISTR that the motivation for adding new syntax is that the best you
can do using a trampoline library is still pretty cumbersome to use
when you have to write a lot of tasks and subtasks, and when using
tasks is just a tool for getting things done rather than an end goal
in itself. I agree that the
On Thu, Mar 26, 2009 at 12:02 PM, Nick Coghlan wrote:
> If that perception is accurate, then any changes likely need to focus on
> the *opposite* end of the toolchain: the part between the " packaging spec>" and the end users.
Yes - but is this part the job of python ?
> In other words: Given a
Hi,
Sorry for the cross-post, but it seemed appropriate since packaging is
being discussed in python-dev tonight,
- Here are the first results for the packaging survey:
http://tarekziade.wordpress.com/2009/03/26/packaging-survey-first-results/
- And tomorrow's Summit schedule for the packaging pa
On Mar 25, 2009, at 5:25 AM, Antoine Pitrou wrote:
Paul Moore gmail.com> writes:
3. Setuptools, unfortunately, has divided the Python distribution
community quite badly.
Wait a little bit, and it's gonna be even worse, now that buildout
and pip seem
to become popular. For example, the Tu
On Wed, Mar 25, 2009 at 5:46 AM, Nick Coghlan wrote:
> Guido van Rossum wrote:
>> Please don't do this. We need stable APIs. Trying to switch the entire
>> community to use CapWord APIs for something as commonly used as
>> datetime sounds like wasting a lot of cycles with no reason except the
>> m
>> http://bugs.python.org/setuptools/issue63
>>
>> I don't understand how that can possibly be manageable.
>>
Steve> Note that the issue contains a broken link.
Fixed. Looks like a Roundup bug.
Skip
___
Python-Dev mailing list
Py
Tools like setuptools, zc.buildout, etc. seem great for developers but
not very good for distributions. At last year's Pycon I think there was
agreement from the Linux distributors that distutils, etc. just wasn't
very useful for them.
I think distutils is different here - it not only helps c
Jeff Hall wrote:
> Someone asked for the input of "ordinary users" (i.e. non developers)
> which, unfortunately, most of the people on this list don't fall in. My
> experience with setuptools is that it's poorly documented and assumes a
> level of sophistication that isn't always there. While this
s...@pobox.com wrote:
> Barry> In fact, I think it /has/ to. I'll go further and say that I'm
> Barry> very wary of using easy_install and the like to install
> Barry> non-distro provided packages into the system Python.
>
> Give that man a ceegar. The pyjamas author seems to have
On Thu, Mar 26, 2009 at 3:29 AM, Tarek Ziadé wrote:
> On Thu, Mar 26, 2009 at 3:26 AM, Stephen J. Turnbull
> wrote:
>> Tennessee Leeuwenburg writes:
>> > GSOC?
>>
>> No. This is territory that nobody knows how to mentor yet, ya know?
>> Try it now, and the poor student is likely to find him or
On Thu, Mar 26, 2009 at 3:26 AM, Stephen J. Turnbull wrote:
> Tennessee Leeuwenburg writes:
> > GSOC?
>
> No. This is territory that nobody knows how to mentor yet, ya know?
> Try it now, and the poor student is likely to find him or herself at
> the center of a firestorm!
No, we wil
>
> Maybe
Tennessee Leeuwenburg writes:
> GSOC?
No. This is territory that nobody knows how to mentor yet, ya know?
Try it now, and the poor student is likely to find him or herself at
the center of a firestorm!
Maybe next year
___
Python-Dev mailing list
Ben Finney writes:
> And the often-obscured community: those who desperately want the
> Python stuff to just behave the same way everything else on their
> system does, i.e. be managed approrpiately by the operating system
> package manager. A Python-specific packaging system which makes it
> har
Barry> In fact, I think it /has/ to. I'll go further and say that I'm
Barry> very wary of using easy_install and the like to install
Barry> non-distro provided packages into the system Python.
Give that man a ceegar. The pyjamas author seems to have a different
opinion about insta
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 25, 2009, at 6:24 PM, P.J. Eby wrote:
At 06:08 PM 3/25/2009 -0500, Barry Warsaw wrote:
I've found setuptools entry points difficult to work with for
plugins,
I'd be interested in hearing more about your specific difficulties,
although i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote:
For case one, where I want to install additional functionality into my
system Python interpreter "forever", it would be great to have my
system
manage this.
In fact, I think it /has/ to.
At 11:35 AM 3/25/2009 -0500, Olemis Lang wrote:
Yes you're right, Trac requires .egg files for local plugins installs
(... in /plugins folder ;) so that not all environments but only one
be able to use the plugin ... but that's not exactly what I'm saying,
since setuptools AFAIK *MUST* be already
At 06:08 PM 3/25/2009 -0500, Barry Warsaw wrote:
I've found setuptools entry points difficult to work with for plugins,
I'd be interested in hearing more about your specific difficulties,
although it's probably off-topic for Python-Dev. Perhaps via the
distutils-sig, since we don't have a pl
At 01:29 PM 3/25/2009 -0400, Terry Reedy wrote:
Paul Moore wrote:
2009/3/25 Tarek Ziadé :
Since setuptools came on the scene, I can state with some certainty
that many packages which would otherwise have been distributed as
bdist_wininst installers, now aren't. In some cases, only source
pack
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 25, 2009, at 11:37 AM, Jean-Paul Calderone wrote:
If anything, Twisted's example shows how monolithic packages are
easier
all-around than micro-packages. We basically have the release
infrastructure
to release Twisted in many smaller piec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 25, 2009, at 11:35 AM, Olemis Lang wrote:
Yes you're right, Trac requires .egg files for local plugins installs
(... in /plugins folder ;) so that not all environments but only one
be able to use the plugin ... but that's not exactly what I'm
I would suggest there may be three use cases for Python installation tools.
Bonus -- I'm not a web developer! :)
Case One: Developer wishing to install additional functionality into the
system Python interpreter forever
Case Two: Developer wishing to install additional functionality into the
system
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 25, 2009, at 11:16 AM, David Cournapeau wrote:
It fails for software I am directly involved in, or maybe the layer
just below: for example, there is no way for me to get a python 2.6 on
my distribution (Ubuntu), so I cannot easily test the py
2009/3/25 Terry Reedy :
> Is it possible to write an egg to bdist converter (or vice versa)?
No idea. But would it help? Distributors would still only provide one
or the other, so when only an egg is available, I'd still have to
convert it - which is certainly pretty simple, but so is python
setup
Paul Moore writes:
> If you would, I'd appreciate it. Sometimes I feel that the
> distutils/setuptools discussions need better input from the
> non-web-developer community. And even more so from the "not a
> developer, just a user" community!
And the often-obscured community: those who desperate
Yes,
I'll try to blog today the initial list of topics that will be
discussed during the Summit,
Regards
Tarek
2009/3/25 Jesse Noller :
> Yes it's on the agenda
>
> On Mar 25, 2009, at 12:46 PM, s...@pobox.com wrote:
>
>> Is setuptools/distutils/whatever on the agenda for the tomorrow's language
Hi all,
just a quick note -- anyone who has an idea for a core Python Google
Summer of Code project, has not had that project panned on this list ;),
and is willing to act as a CONTACT for students who want to apply (not
necessarily a mentor!) should make sure that those ideas are posted on
the wi
Sounds better than being hit by a bus, though! :)
2009/3/24 Guido van Rossum :
> I've received several emails recently indicating that someone is
> trying to get me unsubscribed from python-dev. I'm sure they're just
> pranksters, but just in case they succeed, if I seem to be absent for
> a reall
GSOC?
On Thu, Mar 26, 2009 at 6:05 AM, Steven Bethard wrote:
> On Wed, Mar 25, 2009 at 7:08 AM, Paul Moore wrote:
> > I use Python for systems admin scripts, Windows services, and database
> > management. In my experience (and I agree, it's only one, limited, use
> > case) availability of downlo
On Wed, Mar 25, 2009 at 7:08 AM, Paul Moore wrote:
> I use Python for systems admin scripts, Windows services, and database
> management. In my experience (and I agree, it's only one, limited, use
> case) availability of download-and-run bdist_wininst installers for
> every package I used was the
Yes it's on the agenda
On Mar 25, 2009, at 12:46 PM, s...@pobox.com wrote:
Is setuptools/distutils/whatever on the agenda for the tomorrow's
language
summit? Or is there some other get-together at PyCon for this?
Skip
___
Python-Dev mailing list
P
Is setuptools/distutils/whatever on the agenda for the tomorrow's language
summit? Or is there some other get-together at PyCon for this?
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscri
Antoine Pitrou wrote:
Tarek Ziadé gmail.com> writes:
But I agree that the sizes of the packages are too small now, and it has gone
to far. Installing a web app like Plone is scary (+100 packages)
I am working on a TurboGears2-based app and I just did a count of the .egg
packages in the virtua
Paul Moore wrote:
2009/3/25 Tarek Ziadé :
Since setuptools came on the scene, I can state with some certainty
that many packages which would otherwise have been distributed as
bdist_wininst installers, now aren't. In some cases, only source
packages are provided (on the basis that easy_install
Curt Hagenlocher writes:
> The variation that goes through assert.c should write to stderr for a
> console-mode application, so it's reasonable to assume that we're
> hitting the other code path -- and that Mark's suggestion to use
> CrtSetReportMode would address the issue.
Which is pretty much
On Wed, 25 Mar 2009 11:34:43 -0400, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Antoine Pitrou wrote:
Tarek Ziadé gmail.com> writes:
But I agree that the sizes of the packages are too small now, and it has gone
to far. Installing a web app like Plone is scary (+100 packa
On Wed, Mar 25, 2009 at 11:04 AM, P.J. Eby wrote:
> At 10:11 AM 3/25/2009 -0500, Olemis Lang wrote:
>>
>> ... but Trac plugins *do require* egg files ... (AFAIK after reading
>> Trac docs and implementation of plugin upload from /admin/plugins, egg
>> cache for plugins ... and so on ...) and this
On Thu, Mar 26, 2009 at 12:37 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Barry Warsaw wrote:
>
>> Maybe there's a difference between being a Zope user and using zope
>> packages? I think it's great that I can pick and choose
>> zope.interfaces and other packages
At 10:11 AM 3/25/2009 -0500, Olemis Lang wrote:
... but Trac plugins *do require* egg files ... (AFAIK after reading
Trac docs and implementation of plugin upload from /admin/plugins, egg
cache for plugins ... and so on ...) and this is what I was talking
about ... apps (e.g. Trac) depending *tod
Barry Warsaw wrote:
> Tools like setuptools, zc.buildout, etc. seem great for developers but
> not very good for distributions. At last year's Pycon I think there was
> agreement from the Linux distributors that distutils, etc. just wasn't
> very useful for them.
>
It's decent for modules but ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
> Maybe there's a difference between being a Zope user and using zope
> packages? I think it's great that I can pick and choose
> zope.interfaces and other packages in my not-Zope project. But if I'm
> deploying actual Zope
Someone asked for the input of "ordinary users" (i.e. non developers) which,
unfortunately, most of the people on this list don't fall in. My experience
with setuptools is that it's poorly documented and assumes a level of
sophistication that isn't always there. While this is fine in a lot of
arena
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Antoine Pitrou wrote:
> Tarek Ziadé gmail.com> writes:
>> But I agree that the sizes of the packages are too small now, and it has gone
>> to far. Installing a web app like Plone is scary (+100 packages)
>
> I am working on a TurboGears2-based app an
On Wed, Mar 25, 2009 at 5:25 AM, Antoine Pitrou wrote:
>
> I'm not a Windows user, but I suppose it boils down to whether people are
> comfortable with the command-line or not (which even many Windows /developers/
> aren't). Since having GUIs for everything is part of the Windows philosophy,
> it'
On Wed, Mar 25, 2009 at 9:31 AM, P.J. Eby wrote:
> At 08:32 AM 3/25/2009 -0500, Olemis Lang wrote:
>>
>> Sometimes it also happens that, once one such build/packaging systems
>> is adopted, it is difficult to switch to using another one, since apps
>> (... and plugins systems ...) are frequently h
At 07:40 AM 3/25/2009 -0700, Guido van Rossum wrote:
Well, sorry, but this complex layered interdependent architecture is
one of the *causes* of confusion -- apart from you nobody knows what
is what exactly,
I'll pick a minor nit here... buildout, pip, and a wide variety of
other tools and fr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 25, 2009, at 9:02 AM, Tarek Ziadé wrote:
Yes but this means that you have to wait for the next version of the
"big" package
when a bug is corrected or a feature added, or you need to patch it.
(or maybe use the namespace trick to override it)
Paul Moore gmail.com> writes:
>
> Another division (Not one I'll try to blame on setuptools, though )
>
> Some people find larger, stable, unified packages more useful. Others
> find fine-grained, rapidly developing packages more useful.
>
> It sounds like Antoine and I fall into the former ca
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 25, 2009, at 9:01 AM, Nick Coghlan wrote:
And a package based solution that satisfies everyone (or even a
significant majority), be they on Windows, OS X, .deb based
Linux, .rpm
based Linux, some other Linux or *nix, be they a mere user or
On Wed, Mar 25, 2009 at 8:36 AM, Tarek Ziadé wrote:
> On Wed, Mar 25, 2009 at 1:25 PM, Antoine Pitrou wrote:
>> Paul Moore gmail.com> writes:
>>>
>>> 3. Setuptools, unfortunately, has divided the Python distribution
>>> community quite badly.
>>
>> Wait a little bit, and it's gonna be even worse
On Wed, Mar 25, 2009 at 7:31 AM, P.J. Eby wrote:
> Please note that entry points are not coupled to easy_install. They have a
> documented file format and API that's *distributed* with setuptools, but is
> not dependent on it and does not require .egg files, either. There's
> nothing stopping an
2009/3/25 Tarek Ziadé :
> On Wed, Mar 25, 2009 at 3:08 PM, Paul Moore wrote:
>>
>> Hence my comment about "dividing the community". From my limited
>> perspective, it's about no longer having a standard Windows binary
>> distribution format used by all, not about some sort of ideological
>> battle
At 08:32 AM 3/25/2009 -0500, Olemis Lang wrote:
Sometimes it also happens that, once one such build/packaging systems
is adopted, it is difficult to switch to using another one, since apps
(... and plugins systems ...) are frequently hard-coupled to the pkg
sys «exotic features» and support (...
2009/3/25 Tarek Ziadé :
>> People should really stop splitting their work into micro-libraries (with
>> such
>> ludicrous names as "AddOns" or "Extremes", I might add (*)), and myriads of
>> separately-packaged plugins (the repoze stuff). The Twisted approach is much
>> saner, where you have a coh
At 12:25 PM 3/25/2009 +, Antoine Pitrou wrote:
Paul Moore gmail.com> writes:
>
> 3. Setuptools, unfortunately, has divided the Python distribution
> community quite badly.
Wait a little bit, and it's gonna be even worse, now that buildout
and pip seem
to become popular. For example, the Tu
At 06:03 PM 3/25/2009 +1200, Greg Ewing wrote:
I wanted a way of writing suspendable functions that
can call each other easily. (You may remember I
originally wanted to call it "call".) Then I noticed
that it would also happen to provide the functionality
of earlier "yield from" suggestions, so I
On Wed, Mar 25, 2009 at 3:08 PM, Paul Moore wrote:
>
> Hence my comment about "dividing the community". From my limited
> perspective, it's about no longer having a standard Windows binary
> distribution format used by all, not about some sort of ideological
> battles. Sorry for being unclear.
Ar
Daniel (ajax) Diniz wrote:
> I feel we should make the tracker more useful for core developers,
> volunteers and end-users. I also think having a clear workflow helps a
> lot. Yet, I'd rather have a tracker that allowed users with different
> interpretations to work as they feel most comfortable th
2009/3/25 Tarek Ziadé :
> I can't hear that setuptools has divided the Python community. It has provided
> solutions to real problems we had in web development. It's unperfect,
> and it has to be
> fixed and integrated into Python. But it should not be done outside Python
> imho.
It's quite possi
On Wed, Mar 25, 2009 at 2:45 PM, Antoine Pitrou wrote:
> Tarek Ziadé gmail.com> writes:
>>
>> But I agree that the sizes of the packages are too small now, and it has gone
>> to far. Installing a web app like Plone is scary (+100 packages)
>
> I am working on a TurboGears2-based app and I just di
Stephen J. Turnbull wrote:
> "Batteries included"
> is the status quo for the (C) Python project, and I personally don't
> see a strong reason to change that policy until those who favor a
> package-manager-based solution have a package manager that satisfies
> them!
Beautifully put :)
And a pack
Tarek Ziadé gmail.com> writes:
>
> But I agree that the sizes of the packages are too small now, and it has gone
> to far. Installing a web app like Plone is scary (+100 packages)
I am working on a TurboGears2-based app and I just did a count of the .egg
packages in the virtualenv. There are 45
Nick Coghlan wrote:
> With those two ideas combined, the PEP's "yield from" expansion could
> then look like:
>
> for x in EXPR:
> _v = yield x
> if _v is not None:
> continue _v
> else _r:
> RESULT = _r
Oops, got a little carried away there. Obviously, that doesn't handle
t
On Wed, Mar 25, 2009 at 1:25 PM, Antoine Pitrou wrote:
> Paul Moore gmail.com> writes:
>>
>> 3. Setuptools, unfortunately, has divided the Python distribution
>> community quite badly.
>
> Wait a little bit, and it's gonna be even worse, now that buildout and pip
> seem
> to become popular. For
On Wed, Mar 25, 2009 at 7:25 AM, Antoine Pitrou wrote:
> Paul Moore gmail.com> writes:
>>
>> 3. Setuptools, unfortunately, has divided the Python distribution
>> community quite badly.
>
> Wait a little bit, and it's gonna be even worse, now that buildout and pip
> seem
> to become popular. For
Greg Ewing wrote:
> Would you be happier if some syntactic way to do that
> were provided?
>
> It could perhaps be done by enhancing the part of the
> 'for' loop that gets executed upon normal termination
> of the iterator.
>
> for x in my_iter:
> do_something_with(x)
> else v:
> hand
2009/3/25 Kristján Valur Jónsson :
>
> I'm going to poke my contacts at Microsoft and ask them if there is
> a way to disable popups like this for a process that runs unattended
> and/or is running as a windows service.
MSVC has shipped with runtime library source since the 16-bit days, so
the eas
Guido van Rossum wrote:
> Please don't do this. We need stable APIs. Trying to switch the entire
> community to use CapWord APIs for something as commonly used as
> datetime sounds like wasting a lot of cycles with no reason except the
> mythical "PEP 8 conformance". As I said, it's a pity we didn'
Paul Moore gmail.com> writes:
>
> 3. Setuptools, unfortunately, has divided the Python distribution
> community quite badly.
Wait a little bit, and it's gonna be even worse, now that buildout and pip seem
to become popular. For example, the TurboGears people are considering switching
from setupt
2009/3/25 Steve Holden :
> As far as memory serves, Mike built the installers precisely by using
> distutils to build Windows installers. He then had to suffer criticism
> from people who suggested this was inappropriately complex for pure
> Python modules.
>
> In so far as "end users" won't wish
I'm going to poke my contacts at Microsoft and ask them if there is a way to
disable popups like this for a process that runs unattended and/or is running
as a windows service.
There is, and Curt pointed out one strategy for achieving this without
losing the checks it provides...
> Curt's
On 25/03/2009 7:58 PM, David Bolen wrote:
Mark Hammond writes:
The issue was that Python unconditionally changed the behaviour of the
CRT, not only during the test suite.
Hmm... I was more or less referring to the state of the py3k tree as
of, say, r57823 back in 2007.
I was referring to t
Right.
In fact, having embedded python25.dll into an app once, I'm inclined to think
that there is a lot of stuff that should be moved from that dll into
python.exe, like argument parsing, path magic, and so on. Py_Initialize()
really is designed in terms of python.exe
Anyway,
What I was trying
Mark Hammond writes:
> The issue was that Python unconditionally changed the behaviour of the
> CRT, not only during the test suite.
Hmm... I was more or less referring to the state of the py3k tree as
of, say, r57823 back in 2007. It appeared to just add access to the
necessary functions in th
On 25/03/2009 10:05 AM, David Bolen wrote:
Kristján Valur Jónsson writes:
Now, I know that this msvc behaviour can be disabled, but it was
decided that it was not appropriate to meddle with runtime flags of
the whole process for python.
I must have missed that discussion, but I can't see wha
87 matches
Mail list logo
