On 14 Feb, 2013, at 20:03, Chris Withers wrote:
> On 14/02/2013 12:15, Ronald Oussoren wrote:
>>
>>> buzzkill:virtualenvs chris$ /src/Python-3.3.0/python.exe
>>> Python 3.3.0 (default, Jan 23 2013, 09:56:03)
>>> [GCC 4.2.1 Compatible Apple Clang 3.0 (tags/Apple/clang-211.12)] on darwin
>>> Type
In article <511d350b.1080...@simplistix.co.uk>,
Chris Withers wrote:
> On 14/02/2013 12:15, Ronald Oussoren wrote:
> >
> >> buzzkill:virtualenvs chris$ /src/Python-3.3.0/python.exe
> >> Python 3.3.0 (default, Jan 23 2013, 09:56:03)
> >> [GCC 4.2.1 Compatible Apple Clang 3.0 (tags/Apple/clang-211
On 14/02/2013 12:15, Ronald Oussoren wrote:
buzzkill:virtualenvs chris$ /src/Python-3.3.0/python.exe
Python 3.3.0 (default, Jan 23 2013, 09:56:03)
[GCC 4.2.1 Compatible Apple Clang 3.0 (tags/Apple/clang-211.12)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Victor Stinner writes:
>
> Q: The PEP may break applications.
> A: Most developers agree that it is (very) unlikely. If file
> descriptor inherance matters, subprocess must be used (because it
> rocks!) with pass_fds.
But that doesn't cover the case for programs that don't fork and really
just
Sorry, I just thought that:
if '>' in rawdata[j:]
would do a search, that is, that the implementation of "in" would just
reuse/call the implementation of "find" and that the position returned would be
used as:
-1: not in
!= -1: in
which seemed to me like the easy implementation of "in". That's
Hi,
I read again all emails related to PEP 433. There are different
opposition to this change and I tried to make a summary.
My question is: how can I move this PEP forward (accept, defer or
reject it)? Can I accept it myself, or do we need a global agreement,
or should someone else decide for th
On 14 Feb, 2013, at 10:18, Chris Withers wrote:
> Hi All,
>
> I've run into "some issues" installing lxml for python 3.3 on my mac:
>
>
> One of the stumbling blocks I've hit is that I built python 3.3 from source
> (./configure && make && make altinstall), and it used clang:
>
> buzzkill:v
Hi Greg,
On Wed, Feb 13, 2013 at 10:17 PM, Greg Ewing
wrote:
> If it's that unreliable, why was it ever implemented
> in the first place?
I was young and loved hacks and python-dev felt that it was a good
idea at the time
(http://mail.python.org/pipermail/python-dev/2004-August/046686.html).
A
On 14/02/2013 09:18, Chris Withers wrote:
Hi All,
I've run into "some issues" installing lxml for python 3.3 on my mac:
(forgot the links)
https://mailman-mail5.webfaction.com/pipermail/lxml/2013-February/006730.html
https://mailman-mail5.webfaction.com/pipermail/lxml/2013-February/006731.htm
Hi All,
I've run into "some issues" installing lxml for python 3.3 on my mac:
One of the stumbling blocks I've hit is that I built python 3.3 from
source (./configure && make && make altinstall), and it used clang:
buzzkill:virtualenvs chris$ /src/Python-3.3.0/python.exe
Python 3.3.0 (defaul
Le Wed, 13 Feb 2013 20:50:51 +,
Richard Oudkerk a écrit :
> On 13/02/2013 7:25pm, Antoine Pitrou wrote:
> > I think resurrecting objects from __del__ is crazy, so IMO what you
> > suggest is fine.
>
> You mean like subprocess.Popen.__del__? I quite agree.
Ouch. I didn't know about that.
Re
11 matches
Mail list logo
