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
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
> 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, 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
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 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.
_
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
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
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:
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
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 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
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
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
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
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
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 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 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 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
> 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
==
> 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
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 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 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
"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
26 matches
Mail list logo
