On 19 November 2011 23:11, Vinay Sajip wrote:
> Michael Foord voidspace.org.uk> writes:
>
> > That works fine in Python 3 (mock.Mock does it):
> >
> > >>> class Foo(object):
> > ... @property
> > ... def __class__(self):
> > ... return int
> > ...
> > >>> a = Foo()
> > >>> isinstance(a, i
Michael Foord voidspace.org.uk> writes:
> That works fine in Python 3 (mock.Mock does it):
>
> >>> class Foo(object):
> ... @property
> ... def __class__(self):
> ... return int
> ...
> >>> a = Foo()
> >>> isinstance(a, int)
> True
> >>> a.__class__
>
>
> There must be something else g
On 19/11/2011 22:06, Vinay Sajip wrote:
I was looking through the errors which occur when running the test suite of
Django's py3k branch under Python 3, and one particular set of errors caught my
eye which is unrelated to the bytes/str dance. These errors occur in some Django
utility code, which
In article
,
Dirkjan Ochtman wrote:
> On Sat, Nov 19, 2011 at 20:41, Petri Lehtinen wrote:
> >> Generally speaking, it's more useful for the checkin metadata to
> >> reflect who actually did the checkin, since that's the most useful
> >> information for the tracker and buildbot integration.
> >
On Sat, Nov 19, 2011 at 20:41, Petri Lehtinen wrote:
>> Generally speaking, it's more useful for the checkin metadata to
>> reflect who actually did the checkin, since that's the most useful
>> information for the tracker and buildbot integration.
>
> At least in git, the commit metadata contains
Nick Coghlan wrote:
> Generally speaking, it's more useful for the checkin metadata to
> reflect who actually did the checkin, since that's the most useful
> information for the tracker and buildbot integration.
At least in git, the commit metadata contains both author and
committer (at least if t
On Sat, Nov 19, 2011 at 2:52 AM, Nick Coghlan wrote:
> On Sat, Nov 19, 2011 at 6:42 PM, Stefan Behnel wrote:
>> Hi,
>>
>> I recently got some patches accepted for inclusion in 3.3, and each time,
>> the patch metadata (such as my name and my commit comment) were stripped by
>> applying the patch
On Sat, Nov 19, 2011 at 6:42 PM, Stefan Behnel wrote:
> Hi,
>
> I recently got some patches accepted for inclusion in 3.3, and each time,
> the patch metadata (such as my name and my commit comment) were stripped by
> applying the patch manually, instead of hg importing it. This makes it clear
> i
On Sat, 19 Nov 2011 09:42:49 +0100
Stefan Behnel wrote:
>
> I didn't see this mentioned in the dev-guide. Is it being considered the
> Right Way To Do It?
That said, to answer your question more generally, I think it's simply
how we worked with SVN, and we haven't found any compelling reason to
On Sat, 19 Nov 2011 09:42:49 +0100
Stefan Behnel wrote:
> Hi,
>
> I recently got some patches accepted for inclusion in 3.3, and each time,
> the patch metadata (such as my name and my commit comment) were stripped by
> applying the patch manually, instead of hg importing it. This makes it
> c
On Sat, 19 Nov 2011 03:31:09 +0100
Victor Stinner wrote:
> > I haven't seen any strong objections, so I would like to go ahead and
> > commit PEP 3155 (*) soon. Is anyone against it?
>
> I'm not against it, but I have some questions.
>
> Does you a working implementing?
I suppose the question i
Hi,
I recently got some patches accepted for inclusion in 3.3, and each time,
the patch metadata (such as my name and my commit comment) were stripped by
applying the patch manually, instead of hg importing it. This makes it
clear in the history who eventually reviewed and applied the patch, b
On Sat, Nov 19, 2011 at 4:48 PM, Serhiy Storchaka wrote:
> 19.11.11 01:54, Antoine Pitrou написав(ла):
>>
>> Well, the other propositions still seem worse to me. "Qualified" is
>> reasonably accurate, and "qualname" is fairly short and convenient (I
>> would hate to type "__qualifiedname__" or "__
13 matches
Mail list logo
