On 10 August 2012 06:48, "Martin v. Löwis" wrote:
> Actually, there appears to be a glitch in the network setup: it appears
> that connections to localhost are not possible in your zone. The tests
> fail with an assertion
>
> self.assertEqual(cm.exception.errno, errno.ECONNREFUSED)
> AssertionErro
Hi,
On 8 August 2012 11:30, Stefan Krah wrote:
> Could someone with access to a SPARC machine (perhaps with a modern version
> of Debian-sparc) grab a clone from http://hg.python.org/cpython/ and run
> the test suite?
One more thing that might be interesting, the OpenCSW project provides
access
On 9 August 2012 08:11, Antoine Pitrou wrote:
> Le 09/08/2012 01:26, Floris Bruynooghe a écrit :
>> Also, would it make sense to support OpenCSW more out of the box?
>> Currently we carry some patches for setup.py in order to pick up e.g.
>> sqlite from /opt/csw etc. Would
On 9 August 2012 08:22, "Martin v. Löwis" wrote:
> Am 09.08.12 01:26, schrieb Floris Bruynooghe:
>
>> According to the instructions this
>> is the point where I ask for a slave name and password.
>
>
> Sent in a private message.
Thanks, it seems to be work
On 8 August 2012 18:56, Antoine Pitrou wrote:
> Le 08/08/2012 15:25, "Martin v. Löwis" a écrit :
>
>>
>> Of course, when somebody has access to SPARC hardware, *and* they
>> have some interest that Python 3.3 works on it, they should test it.
>> But testing it as a favor to the community is IMO ir
Oh sorry, having read the thread this spawned from I see you're taking
about MS Windows singed binaries. Something I know next to nothing
about, so ignore my babbling.
On 23 June 2012 11:52, Floris Bruynooghe wrote:
> On 22 June 2012 17:56, Donald Stufft wrote:
>> On Friday, Ju
On 22 June 2012 17:56, Donald Stufft wrote:
> On Friday, June 22, 2012 at 12:54 PM, Alexandre Zani wrote:
>
> Key distribution is the real issue though. If there isn't a key
> distribution infrastructure in place, we might as well not bother with
> signatures. PyPI could issue x509 certs to packag
On 14 June 2012 11:25, Antoine Pitrou wrote:
> Honestly, I think the best option would be to deprecate .pyo files as
> well as the useless -O option. They only cause confusion without
> providing any significant benefits.
+1
But what happens to __debug__ and assert statements? I think it
should
[resent since I accidentally dropped the list]
Hi,
On 19 April 2012 15:55, Barry Warsaw wrote:
> I'll make this change to the PEP. I'm not entirely sure the Yes/No examples
> are great illustrations of this change in wording though. Here's the diff so
> far (uncommitted):
>
> diff -r 34076bfed
On 17 April 2012 16:36, Barry Warsaw wrote:
> On Apr 17, 2012, at 08:25 AM, R. David Murray wrote:
>
>>On Tue, 17 Apr 2012 08:53:43 +0200, Matej Cepl wrote:
>>> On 16.4.2012 18:10, Nam Nguyen wrote:
>>> > a_list[pos + 1 : -1]
>>>
>>> or other way around
>>>
>>> a_list[pos+1:-1]
>>
>>
>>That's wha
On 28 April 2011 23:07, Guido van Rossum wrote:
> On Thu, Apr 28, 2011 at 2:53 PM, Raymond Hettinger
> wrote:
>>
>> On Apr 28, 2011, at 1:27 PM, Holger Krekel wrote:
>>
>>> On Thu, Apr 28, 2011 at 6:59 PM, Guido van Rossum wrote:
On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé
wrote:
>
On 4 April 2011 19:07, Glyph Lefkowitz wrote:
>
> On Apr 4, 2011, at 2:00 PM, Guido van Rossum wrote:
>
>> On Mon, Apr 4, 2011 at 10:05 AM, fwierzbi...@gmail.com
>> wrote:
>>> As a re-implementor of ast.py that tries to be node for node
>>> compatible, I'm fine with #1 but would really like to ha
On 24 March 2011 02:16, Michael Foord wrote:
> On 24/03/2011 02:06, Jesus Cea wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 23/03/11 20:56, Georg Brandl wrote:
>>>
>>> For 3.3, I'd like to revive the tradition of listing planned large-scale
>>> changes in the PEP.
>>
>> I
On 3 February 2011 15:38, Michael Urman wrote:
> Technically this is a problem with the component generation in Python,
> and for that in particular, a move to WiX could be very helpful. They
> have stable component code generation which keys off of location,
> name, platform, etc., but only works
On 6 December 2010 18:55, "Martin v. Löwis" wrote:
> Am 06.12.2010 14:40, schrieb Floris Bruynooghe:
>> On 6 December 2010 09:18, "Martin v. Löwis" wrote:
>>>> Also, it is not clear what to do about distributions/OSs
>>>> without any officia
On 6 December 2010 09:18, "Martin v. Löwis" wrote:
>> Also, it is not clear what to do about distributions/OSs
>> without any official EOL or life cycles.
>
> Here my proposal stands: 10 years, by default.
How about max(EOL, 10years)? That sounds like it could be a useful guideline.
(Personally
On 10 November 2010 04:12, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
>
> > > Module writers who compound the error by expecting to be imported
> > > this way, thereby bogarting the global namespace for their own
> > > purposes, should be fish-slapped. ;)
> >
> > Be prepared to fish-sl
Hi
Sorry for the late response
On 8 October 2010 13:02, Fred Drake wrote:
> I'm in favor of add a top-level setup module that can be invoked using
> "python -m setup ...".
I'd say +1 for this option. It has the advantage that it's very clear
which python environment you're installing (or whate
On 29 September 2010 22:25, Nick Coghlan wrote:
> On Wed, Sep 29, 2010 at 11:40 PM, Barry Warsaw wrote:
>> I don't think it should be in the gc module, but I would prefer it be enabled
>> and controlled through a separate module, rather than something Python does
>> automatically for your conveni
On Thu, May 27, 2010 at 01:46:07PM +1200, Greg Ewing wrote:
> On 27/05/10 00:31, Brian Quinlan wrote:
>
> >You have two semantic choices here:
> >1. let the interpreter exit with the future still running
> >2. wait until the future finishes and then exit
>
> I'd go for (1). I don't think it's unr
Hi
On Sun, May 23, 2010 at 10:47:08AM +1000, Brian Quinlan wrote:
> Jesse, the designated pronouncer for this PEP, has decided to keep
> discussion open for a few more days.
>
> So fire away!
In thread.py the module automatically registers a handler with atexit.
I don't think I'm alone in thinki
On Thu, May 20, 2010 at 11:55:02AM +0900, Stephen J. Turnbull wrote:
> Giampaolo Rodolà writes:
> > >>> class A:
> > ... def echo(self, x):
> > ... return x
> > ...
> > >>> a = A()
> > >>> a.echo()
> > Traceback (most recent call last):
> > File "", line 1, in
> > TypeEr
On Sun, Feb 28, 2010 at 09:45:56PM +0100, Baptiste Carvello wrote:
> However, making a difference between zipimport and the filesystem
> importer means the application will stop working if I unzip the
> library zip file, which is surprising. Unzipping the zip file can be
> handy when debugging a bu
On Sun, Feb 28, 2010 at 11:07:27PM +1000, Nick Coghlan wrote:
> Michael Foord wrote:
> >> Can't it look for a .py file in the source directory first (1st stat)?
> >> When it's there check for the .pyc in the cache directory (2nd stat,
> >> magic number encoded in filename), if it's not check for .p
On Sun, Feb 28, 2010 at 02:51:16PM +1300, Greg Ewing wrote:
> Floris Bruynooghe wrote:
> >(But even then I'm not
> >convinced that would double the stat calls for normal users, only for
> >those who only ship .pyc files)
>
> It would increase the number of sta
On Sat, Feb 27, 2010 at 10:56:13AM -0500, Barry Warsaw wrote:
> On Feb 26, 2010, at 10:59 PM, Michael Foord wrote:
>
> >There are several companies who currently ship bytecode only. (There was
> >someone on the IronPython mailing list only last week asking if
> >IronPython could support pyc file
On Mon, Feb 08, 2010 at 12:51:22PM +, Antoine Pitrou wrote:
> Do some people actually rely on the fact that changing the current directory
> will also change the import path?
On the interactive prompt, yes. But I guess that's a habit that could
be easily un-learnt.
Regards
Floris
--
Debi
On Wed, Feb 03, 2010 at 06:14:44PM +1100, Ben Finney wrote:
> Barry Warsaw writes:
>
> > I suppose this is going to be very subjective, but in skimming the
> > thread it seems like most people like putting the byte code cache
> > artifacts in subdirectories (be they siblings or folder-per-folder)
On Tue, Jan 26, 2010 at 04:40:29AM -0800, Yingjie Lan wrote:
> I googled c.l.py but found
> few pages (one link said it is a dead list, but anyway),
> would you care give the information
> where to join it?
comp.lang.python newsgroup, see: http://python.org/community/lists/
Regards
Floris
--
Hello Collin
On Mon, Jan 25, 2010 at 05:27:38PM -0800, Collin Winter wrote:
> On Mon, Jan 25, 2010 at 1:25 PM, Floris Bruynooghe
> wrote:
> > On Mon, Jan 25, 2010 at 10:14:35AM -0800, Collin Winter wrote:
> >> I'm working on a patch to completely remove all traces o
On Mon, Jan 25, 2010 at 11:48:56AM -0800, Jeffrey Yasskin wrote:
> On Mon, Jan 25, 2010 at 10:44 AM, Tres Seaver wrote:
> > Collin Winter wrote:
> >
> >> For reference, what are these "obscure platforms" where static
> >> initializers cause problems?
> >
> > It's been a long while since I had to d
On Mon, Jan 25, 2010 at 10:14:35AM -0800, Collin Winter wrote:
> I'm working on a patch to completely remove all traces of C++ with
> configured with --without-llvm. It's a straightforward change, and
> should present no difficulties.
Great to hear that, thanks for caring.
> For reference, what a
On Sat, Jan 23, 2010 at 10:09:14PM +0100, Cesare Di Mauro wrote:
> Introducing C++ is a big step, also. Aside the problems it can bring on some
> platforms, it means that C++ can now be used by CPython developers. It
> doesn't make sense to force people use C for everything but the JIT part. In
> t
On Wed, Jan 20, 2010 at 02:27:05PM -0800, Collin Winter wrote:
> Platform Support
>
[...]
> In order to support hardware and software platforms where LLVM's JIT
> does not work, Unladen Swallow provides a ``./configure
> --without-llvm`` option. This flag carves out any part of Unl
On Fri, Jan 08, 2010 at 10:11:51AM +0100, "Martin v. Löwis" wrote:
> Nicholas Bastin wrote:
> > I think this problem probably needs to move over to distutils-sig, as
> > it doesn't seem to be specific to the way that Python itself uses
> > distutils.
>
> I'm fairly skeptical that anybody on distut
On Mon, Dec 14, 2009 at 11:39:02PM -0500, David Lyon wrote:
> On Tue, 15 Dec 2009 15:24:36 +1100, Mark Hammond
>
> wrote:
> But under windows, an application developer might (as in probably
> would) like to install an application in \Program Files\someapp
> rather than hidden in the
On Thu, Dec 10, 2009 at 05:41:01AM +, Michael Mysinger wrote:
> Floris Bruynooghe gmail.com> writes:
>
> > On Tue, Dec 08, 2009 at 08:53:18PM -0800, Michael Mysinger wrote:
> > > I don't know what notation this versioning schema was trying for,
> > > e
On Tue, Dec 08, 2009 at 08:53:18PM -0800, Michael Mysinger wrote:
> Technical question:
>
> I don't know what notation this versioning schema was trying for, especially
> in regards to what the +'s mean:
> N.N[.N]+[abc]N[.N]+[.postN+][.devN+]
> Am I missing something here? You could maybe explain
On Sun, Nov 15, 2009 at 11:27:29PM -0500, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Tarek Ziadé wrote:
> > On Sun, Nov 15, 2009 at 3:35 AM, Christian Heimes wrote:
> > [..]
> >> Do we really want to change distutils to solve a problem of a third
> >> party packaging
On Fri, Nov 13, 2009 at 06:10:16PM -0600, Robert Kern wrote:
> If you want one idea that would make my use of PyPI much more
> pleasant and informative, it would be to add a "Repository-URL"
> entry to the recommended PyPI metadata so that I could always start
> looking at the code in one click.
+
On Wed, Nov 04, 2009 at 03:54:44PM -0700, Zooko O'Whielacronx wrote:
> It occurred to me to wonder why I haven't investigated how hard it
> would be to make my Python packages Python-3-compatible. That's right
> -- I haven't even looked closely. I couldn't even tell you off the
> top of my head w
On Thu, Oct 01, 2009 at 09:58:59AM +0100, Paul Moore wrote:
> (Question - is it *ever* possible for a Unix program to have invalid
> file descriptors 0,1 and 2? At startup - I'm assuming anyone who does
> os.close(1) knows what they are doing!)
Normally you don't close fd 0, 1 & 2 but rather redir
On Mon, Sep 28, 2009 at 07:28:39AM -0700, Steven Bethard wrote:
> Ok, sounds like there are a number of supporters for keeping getopt
> around and just deprecating optparse. For those who'd like to keep
> getopt around, I have a few questions:
>
> * Would you be opposed to a note in the getopt doc
On Mon, Sep 28, 2009 at 06:59:45AM +0300, Yuvgoog Greenle wrote:
> -1 for deprecating getopt. getopt is super-simple and especially useful for
> c programmers learning python.
>
> +1 for argparse.+1 for eventual deprecation of optparse - optparse and
> argparse have a very similar syntax and havin
On Wed, Sep 23, 2009 at 09:49:16AM +0200, M.-A. Lemburg wrote:
> While it's a good idea to put up some form of meta-data
> into an index, I wonder why you are using setup.cfg
> for this.
>
> setup.cfg has traditionally been used to configure distutils,
> not to define meta-data. As such you wouldn
On Thu, Jul 23, 2009 at 10:34:30AM +0200, M.-A. Lemburg wrote:
> Python 2.6 has two standard places for installing packages:
>
> 1. In the stdlib site-packages/ subdir
>
> 2. In the user home dir's .local/lib/python2.6/site-packages dir
And is missing a 3rd one. The sysadmin who wants to instal
On Wed, Jul 22, 2009 at 07:08:26PM -0400, Glenn Maynard wrote:
> On Wed, Jul 22, 2009 at 5:22 PM, M.-A. Lemburg wrote:
> > Maybe I've misunderstood some important detail, but how will
> > their "change" help with anything other than making their
> > distribution a non-standard Python installation ?
On Sat, Mar 22, 2008 at 04:42:36PM +0100, "Martin v. Löwis" wrote:
>> I speak for Debian, so for Debian: yes. The setup.py would have to be
>> pretty bad for a packager to not use it. There is no reason to
>> re-write upstream's installation procedure as you would have to figure
>> out which file
On Sat, Mar 22, 2008 at 03:14:05PM +0100, "Martin v. Löwis" wrote:
>>> Essentially, one would have to contribute patches to all the
>>> distributions (we care about, at least), and then nag the respective
>>> maintainers to include these patches.
>>
>> Not true. You just need to make sure that "
On Sat, Mar 22, 2008 at 12:33:49PM +0100, "Martin v. Löwis" wrote:
> > The data isn't for them to use to meet their use cases, it's for them to
> > *provide* so that Python tools don't stomp on, uninstall, or otherwise
> > interfere with files installed by the system. In other words, for
> > sy
On Fri, Mar 21, 2008 at 10:04:45PM -0400, Phillip J. Eby wrote:
> At 02:31 AM 3/22/2008 +0100, Martin v. Löwis wrote:
> >However, I'm extremely skeptical that this can ever succeed
> >to the degree that whoever provides RPMs, .debs, or MSI
> >files will actually use such data, as they will find tha
On Mon, Nov 21, 2005 at 12:14:26PM +0100, Armin Rigo wrote:
> Hi Brett, hi Floris,
>
> On Sat, Nov 19, 2005 at 04:12:28PM -0800, Brett Cannon wrote:
> > Just for everyone's FYI while we are talking about profilers, Floris
> > Bruynooghe (who I am cc'ing on t
Hello
On Mon, Nov 21, 2005 at 12:14:30PM +0100, Armin Rigo wrote:
> On Sun, Nov 20, 2005 at 08:55:49PM -0500, Tim Peters wrote:
> > We should note that hotshot didn't intend to reduce total time
> > overhead. What it's aiming at here is to be less disruptive (than
> > profile.py) to the code bein
53 matches
Mail list logo
