On Wed, Oct 29, 2014 at 3:25 PM, Antoine Pitrou wrote:
> On Thu, 30 Oct 2014 01:09:45 +1000
> Nick Coghlan wrote:
> >
> > Lots of folks are happy with POSIX emulation layers on Windows, as
> > they're OK with "basically works" rather than "works like any other
> > native application". "Basically
On Wed, Oct 29, 2014 at 5:17 PM, David Cournapeau
wrote:
>
>
> On Wed, Oct 29, 2014 at 3:25 PM, Antoine Pitrou
> wrote:
>
>> On Thu, 30 Oct 2014 01:09:45 +1000
>> Nick Coghlan wrote:
>> >
>> > Lots of folks are happy with POSIX emulation layers o
Hi,
While looking at the import code of python for C extensions, I was
wondering why we pass a relative path instead of an absolute path to
LoadLibraryEx (see bottom for some context).
In python 2.7, the full path existence was even checked before calling into
LoadLibraryEx (
https://github.com/p
Thank you both for your answers.
I will go away with this modification, and see how it goes.
David
On Thu, Mar 12, 2015 at 2:41 AM, Wes Turner wrote:
>
> On Mar 11, 2015 3:36 PM, "David Cournapeau" wrote:
> >
> > Hi,
> >
> > While looking at the impor
On Mon, Oct 2, 2017 at 6:42 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
> > On Oct 2, 2017, at 12:39 AM, Nick Coghlan wrote:
> >
> > "What requests uses" can identify a useful set of
> > avoidable imports. A Flask "Hello world" app could likely provide
> > another such sample,
On Fri, May 29, 2015 at 1:28 AM, Chris Barker wrote:
> On Thu, May 28, 2015 at 9:23 AM, Chris Barker
> wrote:
>
>> Barry Warsaw wrote:
>> >> I do think single-file executables are an important piece to Python's
>> >> long-term
>> competitiveness.
>>
>> Really? It seems to me that desktop develo
Hi Steve,
I have looked into this PEP to see what we need to do on Enthought side of
things. I have a few questions:
1. Is it recommended to follow this for any python version we may provide,
or just new versions (3.6 and above). Most of our customers still heavily
use 2.7, and I wonder whether i
On Tue, Mar 1, 2016 at 5:46 PM, Steve Dower wrote:
> On 01Mar2016 0524, Paul Moore wrote:
>
>> On 1 March 2016 at 11:37, David Cournapeau wrote:
>>
>>> I am not clear about 3., especially on what should be changed. I know
>>> that
>>> for 2.7, we n
On Fri, Apr 18, 2014 at 11:28 PM, Donald Stufft wrote:
>
> On Apr 18, 2014, at 6:24 PM, Nick Coghlan wrote:
>
> > On 18 April 2014 18:17, Paul Moore wrote:
> >> On 18 April 2014 22:57, Donald Stufft wrote:
> >>> Maybe Nick meant ``pip install ipython[all]`` but I don’t actually
> know what tha
On Mon, Mar 4, 2013 at 4:34 PM, Brett Cannon wrote:
>
>
>
> On Mon, Mar 4, 2013 at 11:29 AM, Barry Warsaw wrote:
>>
>> On Mar 04, 2013, at 07:26 PM, Robert Collins wrote:
>>
>> >It is of course possible for subunit and related tools to run their
>> >own implementation, but it seems ideal to me to
Hi,
I was excited to see official dtrace support for python 3.6.0 on OS X, but
I have not been able to make it work:
1. I built my own python from sources on OS X 10.9, with the --with-dtrace
support
2. if I launch `python3.6 -q &` and then `sudo dtrace -l -P python$!`, I
get the following outpu
>
> On Jan 12, 2017, at 5:08 AM, David Cournapeau wrote:
>
> Hi,
>
> I was excited to see official dtrace support for python 3.6.0 on OS X, but
> I have not been able to make it work:
>
> 1. I built my own python from sources on OS X 10.9, with the
> --with-dtrace
Hi,
I am managing the team responsible for providing python packaging at
Enthought, and I would like to make sure we are providing a good (and
secure) out of the box experience for SSL.
My understanding is that PEP 476 is the latest PEP that concerns this
issue, and that PEP recommends using the
On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield wrote:
>
>
> > On 30 Jan 2017, at 13:53, David Cournapeau wrote:
> >
> > Are there any official recommendations for downstream packagers beyond
> PEP 476 ? Is it "acceptable" for downstream packagers to pa
On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield wrote:
>
>
> > On 30 Jan 2017, at 13:53, David Cournapeau wrote:
> >
> > Are there any official recommendations for downstream packagers beyond
> PEP 476 ? Is it "acceptable" for downstream packagers to pa
On Mon, Jan 30, 2017 at 9:14 PM, Christian Heimes
wrote:
> On 2017-01-30 22:00, David Cournapeau wrote:
> >
> >
> > On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield > <mailto:c...@lukasa.co.uk>> wrote:
> >
> >
> >
> > > On 30 Jan
On Tue, Jan 31, 2017 at 9:19 AM, Cory Benfield wrote:
>
> On 30 Jan 2017, at 21:00, David Cournapeau wrote:
>
>
>
> On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield wrote:
>
>>
>>
>> > On 30 Jan 2017, at 13:53, David Cournapeau wrote:
>> &
On Sat, Feb 21, 2009 at 6:21 AM, Barry Warsaw wrote:
> Adam Olsen reminds me that bzr 1.9 won't be supported by default in Ubuntu
> until Jaunty in April and Thomas reminds me that Debian still just has 1.5.
>
> In both those cases, you can use the PPA:
>
> https://launchpad.net/~bzr/+archive/ppa
On Sat, Feb 21, 2009 at 3:52 PM, Stephen J. Turnbull wrote:
> David Cournapeau writes:
> > On Sat, Feb 21, 2009 at 6:21 AM, Barry Warsaw wrote:
>
> > > In both those cases, you can use the PPA:
>
> > Please note that for many people in a corporate/university
&g
On Sat, Feb 21, 2009 at 9:15 PM, Stephen J. Turnbull wrote:
> "Martin v. Löwis" writes:
> > sjt sez:
>
> > > I didn't say "from source", I said "from a VCS checkout". If using a
> > > *specific* recent official release of a core tool is bureaucratically
> > > infeasible, it would IMO be very
On Tue, Mar 24, 2009 at 6:47 AM, "Martin v. Löwis" wrote:
>already the introduction of eggs made the life worse for Debian
> package maintainers, at least initially - i.e. for a few years.
It still is, FWIW,
David
___
Python-Dev mailing list
Python-De
On Tue, Mar 24, 2009 at 8:53 PM, Steve Holden wrote:
> I'm not convinced we do need a cross-platform packaging solution, so I
> may have explained my views badly. I regard application developers as
> Python users, so I did not intend to suggest that the requirement for
> stand-alone installation
2009/3/24 Toshio Kuratomi :
> Steve Holden wrote:
>
>> Seems to me that while all this is fine for developers and Python users
>> it's completely unsatisfactory for people who just want to use Python
>> applications. For them it's much easier if each application comes with
>> all dependencies inclu
On Wed, Mar 25, 2009 at 1:45 AM, Toshio Kuratomi wrote:
> David Cournapeau wrote:
>> 2009/3/24 Toshio Kuratomi :
>>> Steve Holden wrote:
>>>
>>>> Seems to me that while all this is fine for developers and Python users
>>>> it's complete
On Wed, Mar 25, 2009 at 2:20 AM, Tres Seaver wrote:
>
> Many of us using setuptools extensively tend to adopt an "isolated
> environment" strategy (e.g., pip, virtualenv, zc.buildout). We don't
> install the packages used by different applications into shared
> directories at all. Instead, each
On Wed, Mar 25, 2009 at 3:15 AM, Tres Seaver wrote:
>
>> Everytime I tried to understand what buildout was about, I was not
>> even sure it could help for my own problems at all. It seems very
>> specific to web development - I may completely miss the point ?
>
> I think so: it is largely a way
>
> This is only sortof true. You can install rpms into a local directory
> without root privileges with a commandline switch. But rpm/deb are
> optimized for system administrators so the documentation on doing this
> is not well done. There can also be code issues with doing things this
> way b
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
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
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 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
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:42 PM, Stephen J. Turnbull wrote:
>
> +-> E --> downstream developer -+
> | |
> | +--+ V
> source -> build -> A -> B -+-> C ->
On Fri, Mar 27, 2009 at 8:28 PM, Ben Finney
wrote:
>
> I would argue that the Python community has a wealth of people quite
> capable of taking on this particular task, and if it makes the core
> architecture and maintenance of ‘distutils’ simpler to remove special
> cases for binary installers,
On Fri, Mar 27, 2009 at 9:49 PM, M.-A. Lemburg wrote:
> I think that esp. the bdist_* commands help developers a lot by
> removing the need to know how to build e.g. RPMs or Windows
> installers and let distutils deal with it.
I think it is a big dangerous to build rpm/deb without knowing how to
2009/3/28 Stephen J. Turnbull :
>
> Sure, but use for internal distribution is very different from to
> problem its being asked to solve now, isn't it? IIUC, you're
> basically using RPM as an installer for a standalone application,
> where you set policy at both ends, packaging and installation.
2009/3/29 Stephen J. Turnbull :
> I really don't see how that kind of thing can be easily supported by a
> Python module maintainer, unless they're also the downstream packager.
Almost none. But in my understanding, that's not what most linux
packagers vendors ask about - they will handle the dep
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
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 underst
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
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
On Tue, Mar 31, 2009 at 2:37 AM, Alexander Neundorf
wrote:
> On Mon, Mar 30, 2009 at 12:09 AM, Neil Hodgson wrote:
> ...
>> 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 th
On Tue, Mar 31, 2009 at 3:16 AM, Alexander Neundorf
wrote:
>
> Can you please explain ? What is "those" ?
Everything in Lib. On windows, I believe this is done through project
files, but on linux at least, and I guess on most other OS, those are
handled by distutils. I guess the lack of autoconf
On Sun, Apr 5, 2009 at 6:06 PM, "Martin v. Löwis" wrote:
>> Off the top of my head, the following is needed for a successful migration:
>>
>> - Verify that the repository at http://code.python.org/hg/ is
>> properly converted.
>
> I see that this has four branches. What about all the other bran
On Tue, Apr 7, 2009 at 9:14 PM, wrote:
>
> Ondrej> ... while scons and other Python solutions imho encourage to
> Ondrej> write full Python programs, which imho is a disadvantage for the
> Ondrej> build system, as then every build system is nonstandard.
>
> Hmmm... Like distutils setup
On Tue, Apr 7, 2009 at 10:08 PM, Alexander Neundorf
wrote:
>
> What is involved in building python extensions ? Can you please explain ?
Not much: at the core, a python extension is nothing more than a
dynamically loaded library + a couple of options. One choice is
whether to take options from d
On Tue, Apr 7, 2009 at 11:58 PM, M.-A. Lemburg wrote:
>>
>> This means your proposal actually doesn't add any benefit over the
>> status quo, where you can have an __init__.py that does nothing but
>> declare the package a namespace. We already have that now, and it
>> doesn't need a new filenam
On Wed, Apr 8, 2009 at 2:24 AM, Heikki Toivonen
wrote:
> David Cournapeau wrote:
>> The hard (or rather time consuming) work is to do everything else that
>> distutils does related to the packaging. That's where scons/waf are
>> more interesting than cmake IMO, becaus
On Wed, Apr 8, 2009 at 6:42 AM, Alexander Neundorf
wrote:
> What options ?
Compilation options. If you build an extension with distutils, the
extension is built with the same flags as the ones used by python, the
options are taken from distutils.sysconfig (except for MS compilers,
which has its
On Wed, Apr 8, 2009 at 7:54 AM, Alexander Neundorf
wrote:
> On Wed, Apr 8, 2009 at 12:43 AM, Greg Ewing
> wrote:
>> David Cournapeau wrote:
>>>
>>> Having a full
>>> fledged language for complex builds is nice, I think most familiar
>>> with co
On Thu, Apr 9, 2009 at 4:45 AM, Alexander Neundorf
wrote:
> I think cmake can do all of the above (cpack supports creating packages).
I am sure it is - it is just a lot of work, specially if you want to
stay compatible with distutils-built extensions :)
cheers,
David
__
On Wed, May 6, 2009 at 6:01 PM, Tarek Ziadé wrote:
> Hello,
>
> I need some help on http://bugs.python.org/issue5941
>
> The bug is quite simple: the Distutils unixcompiler used to set the
> archiver command to "ar -rc".
>
> For quite a while now, this behavior has changed in order to be able
> to
On Thu, May 7, 2009 at 8:49 PM, Tarek Ziadé wrote:
>
> Notice that from the beginning, the unixcompiler class options are
> never used if the option has been customized
> in distutils.sysconfig and present in the Makefile, so we need to
> clean this behavior as well at some point, and document
>
On Fri, May 8, 2009 at 9:36 AM, Tarek Ziadé wrote:
> Hello,
>
> I am trying to refactor distutils.log in order to use logging but I
> have been bugged by the fact that site.py uses
> distutils.util.get_platform() in "addbuilddir".
> The problem is the order of imports at initialization time : impo
On Fri, May 8, 2009 at 7:23 AM, Tarek Ziadé wrote:
> I have fixed configure by runing autoconf, everything should be fine now
>
> Sorry for the inconvenience.
I am the one responsible for this - I did not realize that the
generated configure/Makefile were also in the trunk, and my patch did
not
On Thu, Jul 9, 2009 at 7:07 AM, Eric Smith wrote:
> Paul Moore wrote:
>>
>> 2009/7/8 P.J. Eby :
>>>
>>> If it were being driven by setuptools, I'd have just implemented it
>>> myself
>>> and presented it as a fait accompli. I can't speak to Tarek's motives,
>>> but
>>> I assume that, as stated in
On Thu, Jul 9, 2009 at 4:18 PM, Paul Moore wrote:
>>
>> There might be a library (and I call dibs on the name "distlib" :) that
>> provides support routines to parse setup.info, but there's no framework
>> involved. And no need for a plugin system.
>
> +1. Now who's going to design & write it?
I
On Wed, Jul 15, 2009 at 11:00 PM, Tarek Ziadé wrote:
> On Wed, Jul 15, 2009 at 12:10 PM, Paul Moore wrote:
>>
>> Disclaimer: I've only read the short version, so if some of this is
>> covered in the longer explanation, I apologise now.
>
> Next time I won't put a short version ;)
>
>
>>
>> PEP 376
On Thu, Jul 23, 2009 at 4:40 AM, Antoine Pitrou wrote:
>
> The size of long double is also 12 under 32-bit Linux. Perhaps mingw disagrees
> with Visual Studio
Yes, mingw and VS do not have the same long double type. This has been
the source of some problems in numpy as well, since mingw uses the
On Thu, Jul 23, 2009 at 6:49 PM, Paul Moore wrote:
> 2009/7/22 Christian Tismer :
>> Maybe the simple solution is to prevent building extensions
>> with mingw, if the python executable was not also built with it?
>> Then, all would be fine I guess.
>
> I have never had problems in practice with ext
On Mon, Jul 27, 2009 at 7:20 PM, David Lyon wrote:
> My only point is that Windows ain't no embedded system. It's not
> short on memory or disk space. If a package manager is 5 megabytes
> extra say, with it's libraries.. what's the extra download time on
> that ? compared to three days+ stuffing
On Mon, Aug 17, 2009 at 2:01 PM, David Bolen wrote:
> Chris Withers writes:
>
>> Is the Express Edition of Visual C++ 2008 suitable for compiling
>> packages for Python 2.6 on Windows?
>> (And Python 2.6 itself for that matter...)
>
> Yes - it's currently being used on my buildbot, for example, to
2009/10/6 P.J. Eby :
> At 02:22 PM 10/5/2009 +0200, Tarek Ziadé wrote:
>>
>> Setuptools development has been discontinued for a year, and does
>> patches on Distutils code. Some of these patches are sensitive to any
>> change
>> made on Distutils, wether those changes are internal or not.
>
> Setup
On Thu, Oct 8, 2009 at 5:31 PM, Tarek Ziadé wrote:
> = Virtualenv and the multiple version support in Distribute =
>
> (I am not saying "We" here because this part was not discussed yet
> with everyone)
>
> Virtualenv allows you to create an isolated environment to install
> some distribution wit
On Fri, Oct 9, 2009 at 1:35 AM, Masklinn wrote:
> On 8 Oct 2009, at 18:17 , Toshio Kuratomi wrote:
>>
>>> This is not at all how I use virtualenv. For me virtualenv is a
>>> sandbox so that I don't have to become root whenever I need to install
>>> a Python package for testing purposes
>>
>> This
On Wed, Oct 21, 2009 at 5:49 AM, Paul Moore wrote:
> 2009/10/20 Chris Withers :
>> I wouldn't have a problem if integrating with the windows package manager
>> was an optional extra, but I think it's one of many types of package
>> management that need to be worried about, so might be easier to ge
On Tue, Nov 3, 2009 at 6:13 PM, Michael Foord wrote:
> Sturla Molden wrote:
>>
>> I'd just like to mention that the scientific community is highly dependent
>> on NumPy. As long as NumPy is not ported to Py3k, migration is out of the
>> question. Porting NumPy is not a trivial issue. It might take
On Tue, Nov 3, 2009 at 8:40 PM, Antoine Pitrou wrote:
> Sturla Molden molden.no> writes:
>>
>> Porting NumPy is not a trivial issue. It might take
>> a complete rewrite of the whole C base using Cython.
>
> I don't see why they would need a rewrite.
(let me know if those numpy-specific discussio
On Tue, Nov 3, 2009 at 9:55 PM, Barry Warsaw wrote:
>
> Then clearly we can't back port features.
>
> I'd like to read some case studies of people who have migrated applications
> from 2.6 to 3.0.
+1, especially for packages which have a lot of C code: the current
documentation is sparse :) The
On Wed, Nov 4, 2009 at 3:25 AM, "Martin v. Löwis" wrote:
> But only if NumPy would drop support for 2.x, for x < 7, right?
> That would probably be many years in the future.
Yes. Today, given the choice of supporting py 3.x and dropping python
< 2.7 and continue support for 2.4, the latter is by
On Thu, Nov 5, 2009 at 4:02 AM, "Martin v. Löwis" wrote:
>
> That's not my experience. I see a change in source (say, on Django)
> available for 3.x within 5 seconds.
This is for which version of 2to3 ? I got similar experience (several
minutes), but maybe I am using 2to3 the wrong way. On my ma
On Sun, Nov 15, 2009 at 10:32 PM, Tarek Ziadé wrote:
>
> Ok. Fair enough, I'll work with them this way.
Although packagers should certainly fix the problems they introduce in
the first place, the second suggestion in the bug report would be
useful, independently on how linux distributions packag
On Sat, Feb 6, 2010 at 4:31 PM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Antoine Pitrou wrote:
>> Pascal Chambon gmail.com> writes:
>>> By the way, I'm having trouble with the "name" attribute of raw files,
>>> which can be string or integer (confusing), ambiguous
On Fri, Feb 5, 2010 at 10:28 PM, Antoine Pitrou wrote:
> Pascal Chambon gmail.com> writes:
>>
>> By the way, I'm having trouble with the "name" attribute of raw files,
>> which can be string or integer (confusing), ambiguous if containing a
>> relative path, and which isn't able to handle the new
On Fri, Feb 26, 2010 at 1:51 PM, Meador Inge wrote:
> Hi All,
>
> Recently some discussion began in the issue 3132 thread
> (http://bugs.python.org/issue3132) regarding
> implementation of the new struct string syntax for PEP 3118. Mark Dickinson
> suggested that I bring the discussion on over to
On Thu, Mar 25, 2010 at 9:39 PM, Jesus Cea wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/25/2010 12:22 PM, Nick Coghlan wrote:
>> "Not a Number" is not a single floating point value. Instead each
>> instance is a distinct value representing the precise conditions that
>>
On Fri, Mar 26, 2010 at 10:19 AM, P.J. Eby wrote:
> At 11:57 AM 3/26/2010 +1100, Steven D'Aprano wrote:
>>
>> But they're not -- they're *signals* for "your calculation has gone screwy
>> and the result you get is garbage", so to speak. You shouldn't even think of
>> a specific NAN as a piece of s
On Sat, Mar 27, 2010 at 8:16 AM, Raymond Hettinger
wrote:
>
> On Mar 26, 2010, at 2:16 PM, Xavier Morel wrote:
>
> How about raising an exception instead of creating nans in the first place,
> except maybe within specific contexts (so that the IEEE-754 minded can get
> their nans working as they c
On Sun, Mar 28, 2010 at 9:28 AM, Robert Kern wrote:
> On 2010-03-27 00:32 , David Cournapeau wrote:
>>
>> On Sat, Mar 27, 2010 at 8:16 AM, Raymond Hettinger
>> wrote:
>>>
>>> On Mar 26, 2010, at 2:16 PM, Xavier Morel wrote:
>>>
>>> How a
On Mon, Mar 29, 2010 at 10:45 PM, anatoly techtonik wrote:
> On Mon, Mar 29, 2010 at 12:15 PM, Tarek Ziadé wrote:
>> [..]
>>> distutils is not a `package management` tool, because it doesn't know
>>> anything even about installed packages, not saying anything about
>>> dependencies.
>>
>> At this
On Mon, Apr 5, 2010 at 11:54 PM, wrote:
> for a college project, I proposed to create a compiler for python. I've
> read something about it and maybe I saw that made a bad choice. I hear
> everyone's opinion respond.
Depending on your taste, you may want to tackle something like a
static analyse
On Thu, Apr 15, 2010 at 3:54 AM, wrote:
>
> Bill> In any case, they shouldn't be needed on buildbots maintained by
> Bill> the PSF.
>
> Sure. My question was related to humans building binary distributions
> though. Unless that becomes fully automated so the release manager can just
> pus
On Tue, Apr 20, 2010 at 9:19 PM, Phil Thompson
wrote:
> When I build my C++ extension on Windows (specifically PyQt with MinGW)
> against Python v2.6.5 it fails to run under v2.6.4. The same problem exists
> when building against v3.1.2 and running under v3.1.1.
>
> The error message is...
>
> Imp
On Tue, Apr 27, 2010 at 5:10 AM, Piotr Ożarowski wrote:
> if there's no other way (--install-data is ignored right now, and I know
> you're doing a great work to change that, thanks BTW), one could always
> use it in *one* place and later import the result in other parts of
> the code (instead of
Hi,
I would like to modify the code of the bdist installers, but I don't
see any VS project for VS 9.0. How are the wininst-9.0*exe built ?
thanks,
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
On Thu, Jul 1, 2010 at 1:22 PM, "Martin v. Löwis" wrote:
>> I would like to modify the code of the bdist installers, but I don't
>> see any VS project for VS 9.0. How are the wininst-9.0*exe built ?
>
> See PC/bdist_wininst.
Hm, my question may not have been clear: *how* is the wininst-9.0
built
On Thu, Jul 1, 2010 at 2:00 PM, "Martin v. Löwis" wrote:
>>> See PC/bdist_wininst.
>>
>> Hm, my question may not have been clear: *how* is the wininst-9.0
>> built from the bdist_wininst sources ? I see 6, 7.0, 7.1 and 8.0
>> versions of the visual studio build scripts, but nothing for VS 9.0.
>
>
On Sat, Jul 3, 2010 at 6:37 AM, Brett Cannon wrote:
> On Fri, Jul 2, 2010 at 12:25, anatoly techtonik wrote:
>> I planned to publish this proposal when it is finally ready and tested
>> with an assumption that Subversion repository will be online and
>> up-to-date after Mercurial migration. But r
On Sat, Jul 3, 2010 at 9:34 AM, Brett Cannon wrote:
> On Fri, Jul 2, 2010 at 17:17, David Cournapeau wrote:
>> On Sat, Jul 3, 2010 at 6:37 AM, Brett Cannon wrote:
>>> On Fri, Jul 2, 2010 at 12:25, anatoly techtonik wrote:
>>>> I planned to publish this proposa
On Sat, Jul 3, 2010 at 2:26 PM, Reid Kleckner wrote:
> Hey folks,
>
> I'm trying to test out a patch to add a timeout in subprocess.py on
> Windows, so I need to build Python with Visual Studio. The docs say
> the files in PCBuild/ work with VC 9 and newer. I downloaded Visual
> C++ 2010 Express
On Thu, Jul 22, 2010 at 10:08 PM, stefan brunthaler
wrote:
>> Is the source code under an open source non-copyleft license?
>>
> I am (unfortunately) not employed or funded by anybody, so I think
> that I can license/release the code as I see fit.
If you did this work under your PhD program, you
On Fri, Jul 30, 2010 at 10:23 PM, Michael Foord
wrote:
> For those of you who found this document perhaps just a little bit too long,
> I've written up a *much* shorter intro to the plugin system (including how
> to get the prototype) on my blog:
>
> http://www.voidspace.org.uk/python/weblog/a
On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou wrote:
> On Tue, 03 Aug 2010 10:28:07 +0200
> "M.-A. Lemburg" wrote:
>> >
>> > Don't forget system packaging tools like .deb, .rpm, etc., which do not
>> > generally take kindly to updating such things. For better or worse, the
>> > filesystem *is*
On Tue, Aug 3, 2010 at 11:35 PM, Michael Foord
wrote:
> On 03/08/2010 15:19, David Cournapeau wrote:
>>
>> On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou
>> wrote:
>>
>>>
>>> On Tue, 03 Aug 2010 10:28:07 +0200
>>> "M.-A. Lemburg"
On Tue, Aug 10, 2010 at 11:06 PM, wrote:
> On Mon, Aug 09, 2010 at 06:55:29PM -0400, Terry Reedy wrote:
>> On 8/9/2010 2:47 PM, Sturla Molden wrote:
>> >> Terry Reedy:
>> >
>> >> MingW has become less attractive in recent years by the difficulty
>> >> in downloading and installing a current v
On Wed, Aug 11, 2010 at 10:21 PM, Sturla Molden wrote:
>
> "David Cournapeau":
>> Autotools only help for posix-like platforms. They are certainly a big
>> hindrance on windows platform in general,
>
> That is why mingw has MSYS.
I know of MSYS, but it is
On Fri, Aug 13, 2010 at 7:29 AM, Antoine Pitrou wrote:
> On Thu, 12 Aug 2010 18:14:44 -0400
> Glyph Lefkowitz wrote:
>>
>> On Aug 12, 2010, at 6:30 AM, Tim Golden wrote:
>>
>> > I don't care how many stats we're doing
>>
>> You might not, but I certainly do. And I can guarantee you that the
>> a
On Fri, Aug 20, 2010 at 1:02 AM, Amaury Forgeot d'Arc
wrote:
> Hi,
>
> 2010/8/19 Timothy Kinney :
>> I am getting some unexpected behavior in Python 2.6.4 on a WinXP SP3 box.
>
> This mailing list is for development *of* python, not about
> development *with* python.
> Your question should be dire
On Mon, Aug 30, 2010 at 6:43 AM, Antoine Pitrou wrote:
> On Mon, 30 Aug 2010 07:31:34 +1000
> Nick Coghlan wrote:
>> Since part of the point of
>> PEP 384 is to support multiple versions of the C runtime in a single
>> process, [...]
>
> I think that's quite a maximalist goal. The point of PEP 38
On Tue, Aug 31, 2010 at 6:54 AM, Nick Coghlan wrote:
> Hmm... that last point is a bit of any issue actually, since it also
> flows the other way (changes made via the locale module won't be
> visible to any extension modules using a different C runtime). So I
> suspect mixing C runtimes is stil
1 - 100 of 135 matches
Mail list logo
