Re: [Python-Dev] Committing PEP 3155
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 "__qualified_name__" in full). >> In the same vein, we have __repr__ which may seem weird at first >> sight :) > > What about __reprname__? Antoine only mentioned 'repr' as being an abbreviation for 'representation', just as 'qualname' will be an abbreviation for 'qualified name'. The "less ambiguous repr()" use case is just one minor aspect of the new qualified names, even if it's the most immediately visible, so using 'repr' in the attribute name would give people all sorts of wrong ideas about the scope of its utility. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] patch metadata - to use or not to use?
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, but less visible who wrote it (except for the entry in Misc/NEWS). I didn't see this mentioned in the dev-guide. Is it being considered the Right Way To Do It? Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Committing PEP 3155
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 is about a working implementation :) http://hg.python.org/features/pep-3155 > Do you have a patch for issue #9276 using __qualname__? Maybe not a > fully working patch, but a proof-of-concept? No. That's part of PEP 3154. > Could you add examples on instances? I suppose that it gives the same > result than classes: > >C.__qualname__ == C().__qualname__ >C.f.__qualname__ == C().f.__qualname__ No. You have to use C().__class__.__qualname__. Same as C().__class__.__name__, really. > Le 19/11/2011 00:15, Barry Warsaw a écrit : > > I'd like the PEP to explain why this is a better solution than > > re-establishing introspectability that was available through > > unbound methods. > > __qualname__ works also on nested functions. Is it a new feature? Or was > it already possible in Python 2 to compute the qualified name? It's a new feature indeed. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch metadata - to use or not to use?
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 > clear in the history who eventually reviewed and applied the patch, but > less visible who wrote it (except for the entry in Misc/NEWS). > > I didn't see this mentioned in the dev-guide. Is it being considered the > Right Way To Do It? It is common to add minor things to the patch when committing (such as a redacted NEWS entry, or a ACKS entry), in which cases you can't import it anyway. Often the name of the contributor is added to NEWS *and* to the commit message. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch metadata - to use or not to use?
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 change. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch metadata - to use or not to use?
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 > in the history who eventually reviewed and applied the patch, but less > visible who wrote it (except for the entry in Misc/NEWS). > > I didn't see this mentioned in the dev-guide. Is it being considered the > Right Way To Do It? 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. The question of did the original patch does matter in terms of giving appropriate credit (which is covered by NEWS and the commit message), but who did the checkin matters for immediate workflow reasons (i.e. who is responsible for dealing with any buildbot breakage, objections on python-dev, objections on the tracker, etc). One of the key aspects of having push rights is that we're the ones that take responsibility for the state of the central repo - if we stuff it up and break the build (either because we missed something on review, or due to cross-platform issues), that's *our* problem, not usually something the original patch contributor needs to worry about. We do have a guideline that says to always use the "--no-commit" flag with "hg import" and then run the tests before committing, so that may answer your question about whether or not it's an official policy. (That said, I don't know if the devguide actually says that explicitly anywhere - it's just reflected in the various workflow examples, as well as in the mailing list discussions that helped craft those examples) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch metadata - to use or not to use?
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 manually, instead of hg importing it. This makes it clear >> in the history who eventually reviewed and applied the patch, but less >> visible who wrote it (except for the entry in Misc/NEWS). >> >> I didn't see this mentioned in the dev-guide. Is it being considered the >> Right Way To Do It? > > 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. The question of > did the original patch does matter in terms of giving appropriate > credit (which is covered by NEWS and the commit message), but who did > the checkin matters for immediate workflow reasons (i.e. who is > responsible for dealing with any buildbot breakage, objections on > python-dev, objections on the tracker, etc). > > One of the key aspects of having push rights is that we're the ones > that take responsibility for the state of the central repo - if we > stuff it up and break the build (either because we missed something on > review, or due to cross-platform issues), that's *our* problem, not > usually something the original patch contributor needs to worry about. Well, it doesn't hurt to keep the patch author in the loop about those -- they may know their patch best and they may even learn something new, which might make their future patches better! Of course if they *don't* know how to fix an issue (e.g. if it's a platform-specific thing) then they shouldn't be blamed. > We do have a guideline that says to always use the "--no-commit" flag > with "hg import" and then run the tests before committing, so that may > answer your question about whether or not it's an official policy. > (That said, I don't know if the devguide actually says that explicitly > anywhere - it's just reflected in the various workflow examples, as > well as in the mailing list discussions that helped craft those > examples) I agree with this, but I also want to make sure the author of the patch always gets proper recognition (after all that's what motivates people to contribute!). I think that their name should always be in the description if it's not in the committer field. Use your best judgment or qualifying terms for patches that are co-productions of committer and original author. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch metadata - to use or not to use?
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 they differ). Maybe mercurial has this too? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch metadata - to use or not to use?
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 both author and > committer (at least if they differ). Maybe mercurial has this too? It does not. Personally, I find it more appropriate to have the original patch author in the "official" metadata, mostly because I personally find it very satisfying to see my name in the changelog on hgweb and the like. My own experience with that makes me think that it's probably helpful in engaging contributors. Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch metadata - to use or not to use?
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. > > At least in git, the commit metadata contains both author and > > committer (at least if they differ). Maybe mercurial has this too? > It does not. > > Personally, I find it more appropriate to have the original patch > author in the "official" metadata, mostly because I personally find it > very satisfying to see my name in the changelog on hgweb and the like. > My own experience with that makes me think that it's probably helpful > in engaging contributors. As Nick pointed out, it's important that who did the checkin is recorded for python-dev workflow reasons. Ensuring that the original patch submitter is mentioned in the commit message and, as appropriate, in any Misc/NEWS item seems to me an appropriate and sufficient way to give that recognition. The NEWS file will eventually get installed on countless systems around the world: hard to beat that! WRT the original commit message, a more flexible approach to applying patches is to use "hg qimport" rather than "hg import". It is then possible to edit the patch, make the necessary changes to Misc/NEWS, edit the original patch commit comment using "hg qrefresh -e" and then commit the patch with "hg qfinish". -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3, new-style classes and __class__
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 supplies a SimpleLazyObject (new-style) class [1]. This implements a proxy, which is initialised using a callable. The callable returns the object to be wrapped, and it's called when needed to set up the wrapped instance. The SimpleLazyObject needs to pretend to be the class of the wrapped object, e.g. for equality tests. This pretending is done by declaring __class__ as a property in SimpleLazyObject which fetches and returns the __class__ attribute of the wrapped object. This approach doesn't work in Python 3, however: the property named __class__ doesn't show up in the class dict of SimpleLazyObject, and moreover, there are restrictions on what you can set __class__ to - e.g. Python complains if you try and set a __class__ attribute on the instance to anything other than a new-style class. What's the simplest way in Python 3 of implementing the equivalent approach to pretending to be a different class? Any pointers appreciated. 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 going on here. All the best, Michael Foord Thanks and regards, Vinay Sajip [1] http://goo.gl/1Jlbj ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3, new-style classes and __class__
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 going on here.
>
Michael, thanks for the quick response. Okay, I'll dig in a bit further: the
definition in SimpleLazyObject is
__class__ = property(new_method_proxy(operator.attrgetter("__class__")))
so perhaps the problem is something related to the specifics of the definition.
Here's what I found in initial exploration:
--
Python 2.7.2+ (default, Oct 4 2011, 20:06:09)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from django.utils.functional import SimpleLazyObject
>>> fake_bool = SimpleLazyObject(lambda: True)
>>> fake_bool.__class__
>>> fake_bool.__dict__
{'_setupfunc': at 0xca9ed8>, '_wrapped': True}
>>> SimpleLazyObject.__dict__
dict_proxy({
'__module__': 'django.utils.functional',
'__nonzero__': ,
'__deepcopy__': ,
'__str__': ,
'_setup': ,
'__class__': ,
'__hash__': ,
'__unicode__': ,
'__bool__': ,
'__eq__': ,
'__doc__': '\n A lazy object initialised from any function.\n\n
Designed for compound objects of unknown type. For builtins or
objects of\n known type, use django.utils.functional.lazy.\n ',
'__init__':
})
--
Python 3.2.2 (default, Sep 5 2011, 21:17:14)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from django.utils.functional import SimpleLazyObject
>>> fake_bool = SimpleLazyObject(lambda : True)
>>> fake_bool.__class__
>>> fake_bool.__dict__
{
'_setupfunc': at 0x1c36ea8>,
'_wrapped':
}
>>> SimpleLazyObject.__dict__
dict_proxy({
'__module__': 'django.utils.functional',
'__nonzero__': ,
'__deepcopy__': ,
'__str__': ,
'_setup': ,
'__hash__': ,
'__unicode__': ,
'__bool__': ,
'__eq__': ,
'__doc__': '\n A lazy object initialised from any function.\n\n
Designed for compound objects of unknown type. For builtins or
objects of\n known type, use django.utils.functional.lazy.\n ',
'__init__':
})
--
In Python 3, there's no __class__ property as there is in Python 2,
the fake_bool's type isn't bool, and the callable to set up the wrapped
object never gets called (which is why _wrapped is not set to True, but to
an anonymous object - this is set in SimpleLazyObject.__init__).
Puzzling!
Regards,
Vinay Sajip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3, new-style classes and __class__
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, int)
> > True
> > >>> a.__class__
> >
> >
> > There must be something else going on here.
> >
>
> Michael, thanks for the quick response. Okay, I'll dig in a bit further:
> the
> definition in SimpleLazyObject is
>
> __class__ = property(new_method_proxy(operator.attrgetter("__class__")))
>
> so perhaps the problem is something related to the specifics of the
> definition.
> Here's what I found in initial exploration:
>
> --
> Python 2.7.2+ (default, Oct 4 2011, 20:06:09)
> [GCC 4.6.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from django.utils.functional import SimpleLazyObject
> >>> fake_bool = SimpleLazyObject(lambda: True)
> >>> fake_bool.__class__
>
> >>> fake_bool.__dict__
> {'_setupfunc': at 0xca9ed8>, '_wrapped': True}
> >>> SimpleLazyObject.__dict__
> dict_proxy({
>'__module__': 'django.utils.functional',
>'__nonzero__': ,
>'__deepcopy__': ,
>'__str__': ,
>'_setup': ,
>'__class__': ,
>'__hash__': ,
>'__unicode__': ,
>'__bool__': ,
>'__eq__': ,
>'__doc__': '\n A lazy object initialised from any function.\n\n
>Designed for compound objects of unknown type. For builtins or
>objects of\n known type, use django.utils.functional.lazy.\n ',
>'__init__':
> })
> --
> Python 3.2.2 (default, Sep 5 2011, 21:17:14)
> [GCC 4.6.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from django.utils.functional import SimpleLazyObject
> >>> fake_bool = SimpleLazyObject(lambda : True)
> >>> fake_bool.__class__
>
> >>> fake_bool.__dict__
> {
>'_setupfunc': at 0x1c36ea8>,
>'_wrapped':
> }
> >>> SimpleLazyObject.__dict__
> dict_proxy({
>'__module__': 'django.utils.functional',
>'__nonzero__': ,
>'__deepcopy__': ,
>'__str__': ,
>'_setup': ,
>'__hash__': ,
>'__unicode__': ,
>'__bool__': ,
>'__eq__': ,
>'__doc__': '\n A lazy object initialised from any function.\n\n
>Designed for compound objects of unknown type. For builtins or
>objects of\n known type, use django.utils.functional.lazy.\n ',
>'__init__':
> })
> --
>
> In Python 3, there's no __class__ property as there is in Python 2,
> the fake_bool's type isn't bool, and the callable to set up the wrapped
> object never gets called (which is why _wrapped is not set to True, but to
> an anonymous object - this is set in SimpleLazyObject.__init__).
>
>
The Python compiler can do strange things with assignment to __class__ in
the presence of super. This issue has now been fixed, but it may be what is
biting you:
http://bugs.python.org/issue12370
If this *is* the problem, then see the workaround suggested in the issue.
(alias super to _super in the module scope and use the old style super
calling convention.)
Michael
> Puzzling!
>
> Regards,
>
> Vinay Sajip
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>
>
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
