"Martin v. Löwis" writes:
> People will never ever test nightly builds. Been there, done that.
> Instead, the nightly build process will break, and nobody will fix
> it for months (or even complain, for that matter).
Certainly seems to be past experience.
I know Martin knows this, but for other
On 10/30/2010 6:32 PM, Neil Schemenauer wrote:
I have a specific, easy to implement proposal. I would like one
more version tag added to the Roundup tracker. My proposed name is
"Python 2.7+" but I don't care what it is called.
As a tracker gardener, I disagree. I would expect such to cause m
I have a specific, easy to implement proposal. I would like one
more version tag added to the Roundup tracker. My proposed name is
"Python 2.7+" but I don't care what it is called.
It would be used to tag bug reports and patches that apply only to
the 2.x line and are considered not appropriate
On Sat, Oct 30, 2010 at 12:06 PM, Glyph Lefkowitz
wrote:
> That path (and anything below /proc, really) is a list of open file
> descriptors specifically on Linux, not "*nix". Also on linux, you can avoid
> "" by just doing "/proc/self".
> A more portable (albeit not standard) path for "what file
> I was happy to find out that the /proc system came from Plan9 because
> I always thought Plan9 was dead water. But in this particular case
> Plan9 outdid System7 in the the realm of "everything is a file" by
> making everything a file.
However, on Plan 9, /proc//fd is not a directory, but a reg
> I think size should be in TCHARs, not in bytes. (MSDN says so)
> And GetComputerName's signature differs from MSDN. (Maybe should
> use GetComputerNameExW again?)
You are right. So how about this patch?
Index: Modules/socketmodule.c
==
On Sat, Oct 30, 2010 at 3:06 PM, Glyph Lefkowitz
wrote:
>
> On Oct 30, 2010, at 2:39 PM, Jack Diederich wrote:
>
> On Fri, Oct 29, 2010 at 8:35 PM, Brett Cannon wrote:
>
> For those of you who have not noticed, Antoine committed a patch that
>
> raises a ResourceWarning under a pydebug build if a
On Oct 30, 2010, at 2:39 PM, Jack Diederich wrote:
> On Fri, Oct 29, 2010 at 8:35 PM, Brett Cannon wrote:
>> For those of you who have not noticed, Antoine committed a patch that
>> raises a ResourceWarning under a pydebug build if a file or socket is
>> closed through garbage collection instead
On Fri, Oct 29, 2010 at 8:35 PM, Brett Cannon wrote:
> For those of you who have not noticed, Antoine committed a patch that
> raises a ResourceWarning under a pydebug build if a file or socket is
> closed through garbage collection instead of being explicitly closed.
Just yesterday I discovered
On Sat, 30 Oct 2010 14:24:10 -0400
"R. David Murray" wrote:
> On Sat, 30 Oct 2010 18:36:45 +0200, Antoine Pitrou
> wrote:
> > On Sat, 30 Oct 2010 12:02:27 -0400
> > "R. David Murray" wrote:
> > >
> > > I don't disagree with this simplification, but given that you all want
> > > to pare down t
On Sat, 30 Oct 2010 18:36:45 +0200, Antoine Pitrou wrote:
> On Sat, 30 Oct 2010 12:02:27 -0400
> "R. David Murray" wrote:
> >
> > I don't disagree with this simplification, but given that you all want
> > to pare down the unittest API, I'd be interested in your opinions on
> > issue 10164. Beca
M.-A. Lemburg wrote:
> Hirokazu Yamamoto wrote:
>> Hello. I found several codes using PyMem_Free to free
>> allocated memory with PyMem_MALLOC (ie: PyUnicode_AsWideCharString)
>>
>> Is it safe?
>
> Within the interpreter: yes.
>
> In extensions: depends on the platform, but probably not.
>
> The
Hirokazu Yamamoto wrote:
> Hello. I found several codes using PyMem_Free to free
> allocated memory with PyMem_MALLOC (ie: PyUnicode_AsWideCharString)
>
> Is it safe?
Within the interpreter: yes.
In extensions: depends on the platform, but probably not.
The macros provide faster access to the C
On Sat, 30 Oct 2010 12:02:27 -0400
"R. David Murray" wrote:
>
> I don't disagree with this simplification, but given that you all want
> to pare down the unittest API, I'd be interested in your opinions on
> issue 10164. Because the assertBytesEqual method takes an optional
> argument, it seems
On Sat, 30 Oct 2010 14:51:28 +0200, Antoine Pitrou wrote:
> On Fri, 29 Oct 2010 20:14:27 -0700
> Raymond Hettinger wrote:
> >
> > I would like to simplify and clean-up the API for the unittest module
> > by de-documenting assertSetEqual(), assertDictEqual(),
> > assertListEqual, and assertTupleE
Hello. I found several codes using PyMem_Free to free
allocated memory with PyMem_MALLOC (ie: PyUnicode_AsWideCharString)
Is it safe?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
On 30/10/2010 02:41, Steven D'Aprano wrote:
Raymond Hettinger wrote:
The API for the unittest module has grown fat (the documentation
is approaching 2,000 lines and 10,000 words like a small book). I
think we can improve learnability by focusing on the most important
parts of the API.
I woul
On 2010/10/30 3:20, martin.v.loewis wrote:
Modified: python/branches/py3k/Modules/socketmodule.c
==
--- python/branches/py3k/Modules/socketmodule.c (original)
+++ python/branches/py3k/Modules/socketmodule.c Fri Oct 29 20:
Am 30.10.2010 12:12, schrieb Antoine Pitrou:
> On Sat, 30 Oct 2010 02:13:01 +0200 (CEST)
> brett.cannon wrote:
>> Author: brett.cannon
>> Date: Sat Oct 30 02:13:00 2010
>> New Revision: 85960
>>
>> Log:
>> Silence some ResourceWarning in test_mailbox by using file context managers.
>
> Unfortuna
Am 30.10.2010 14:29, schrieb Dirkjan Ochtman:
> On Sat, Oct 30, 2010 at 14:09, "Martin v. Löwis" wrote:
>> I don't feel like producing a complete list of build steps; the entire
>> process takes about four hours.
>
> So is most of this scripted, or is there just a process in your head?
Define "m
On Fri, 29 Oct 2010 20:14:27 -0700
Raymond Hettinger wrote:
>
> I would like to simplify and clean-up the API for the unittest module
> by de-documenting assertSetEqual(), assertDictEqual(),
> assertListEqual, and assertTupleEqual().
+1 from me.
Regards
Antoine.
_
On Sat, Oct 30, 2010 at 14:09, "Martin v. Löwis" wrote:
> I don't feel like producing a complete list of build steps; the entire
> process takes about four hours.
So is most of this scripted, or is there just a process in your head?
> The steps that are difficult to automate are:
> - code signin
On Sat, 30 Oct 2010 02:13:01 +0200 (CEST)
brett.cannon wrote:
> Author: brett.cannon
> Date: Sat Oct 30 02:13:00 2010
> New Revision: 85960
>
> Log:
> Silence some ResourceWarning in test_mailbox by using file context managers.
Unfortunately, these file-like objects don't support the context
man
> Right, the effort of those people is obviously the limiting factor
> here. Automating builds sounds like a good step forward. What are the
> sticky bits here? Martin, Ronald, how much of the process is not
> automated, and why is automating hard?
I don't feel like producing a complete list of bu
On Sat, Oct 30, 2010 at 05:22, Nick Coghlan wrote:
> Ultimately, the frequency of releases comes down to the burden on the
> release manager and the folks that build the binary installers. Any
> given RM is usually only responsible for one or two branches, but the
> same two people (Martin and Ron
Casey Duncan writes:
> However there are many many more users of Python 2.x than Python
> 3.x. Many may never upgrade for the life of these projects,
> because if it ain't broke, why fix it? It doesn't matter how much
> better Python 3 is than Python 2. It isn't better enough.
And the "don't
26 matches
Mail list logo
