Re: [Python-Dev] Working on the Python code-base with a VIM-based setup
On Wed, Sep 01, 2010 at 06:41:00AM +0300, Eli Bendersky wrote: > I would like to ask those of you working on > Python's code with VIM about your setups - the special tweaks to VIM & > plugins you use to make working with the code as simple and effective as > possible. You have already seen Misc/Vim directory in Python distribution, have you? Shameless plug: look at my .vimrc and plugins: http://phd.pp.ru/Software/dotfiles/vimrc.html http://phd.pp.ru/Software/dotfiles/vim/ Borrow whatever you find useful. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ 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] PEP 384 status
On Wed, Sep 1, 2010 at 8:42 AM, Antoine Pitrou wrote: > After all, we don't usually try to workaround platform-specific > bugs (not as a low level such as the C API level); at worse, we mention > their existence in the docs. You persist in viewing the allowance of multiple C runtimes in a single process as a bug instead of a feature. This comes from the monolithic approach to software management in Unix systems (with the associated web of dependencies and implications for backwards compatibility management). The Windows heritage is different, allowing each application to be largely independent of everything other than the OS itself, so the execution model is also different. Windows is a supported platform for Python and to meet the promise of a stable ABI, we need to support multiple C runtimes in a single process. Since we aren't in the habit of passing low level objects around, the number of APIs affected is relatively tiny (the current tally is less than half a dozen that I know of - the two mentioned in this thread, plus a couple of of the PyRun_* APIs). There will be some cases (like file descriptors) where we just say "don't do that" but those should be fairly rare. 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] PEP 384 status
Le mercredi 01 septembre 2010 à 22:43 +1000, Nick Coghlan a écrit : > On Wed, Sep 1, 2010 at 8:42 AM, Antoine Pitrou wrote: > > After all, we don't usually try to workaround platform-specific > > bugs (not as a low level such as the C API level); at worse, we mention > > their existence in the docs. > > You persist in viewing the allowance of multiple C runtimes in a > single process as a bug instead of a feature. No, I view the fact that you can't share FILE structures as a bug. I'm sure there would be ways to have multiple C runtimes loaded in memory with compatible FILE structures (for example, by versioning the FILE structure itself, or by embedding inside the FILE structure a set of function pointers, so that fread(), fwrite() and friends always get redirected to the proper implementation). Please consider this: even without relying on PEP 384, using FILE* is /already/ dangerous; because you might compile an extension with a different compiler version than Python was compiled with. So, if we were following you, we should rip out PyObject_Print() of the whole C API, not only the limited subset which is defined by PEP 384. (now I have nothing against completely ripping out PyObject_Print() if we find out that it's not really useful...) 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] PEP 384 status
On 01/09/2010 13:54, Antoine Pitrou wrote: [snip...] Please consider this: even without relying on PEP 384, using FILE* is /already/ dangerous; because you might compile an extension with a different compiler version than Python was compiled with. So, if we were following you, we should rip out PyObject_Print() of the whole C API, not only the limited subset which is defined by PEP 384. Definitely. On Windows it is relatively common to configure distutils to compile extensions with Mingw, which is likely to have problems with FILE* from the Microsoft C runtime [1]. Michael [1] I say *likely* because I have vague memories of Mingw being able to compile against msvcrt, but I'm not sure about this. This is actually less of an issue at the moment as we are now using a Microsoft compiler for which a free version is available. This wasn't the case for a while (and still isn't for those using Python 2.5 and earlier). (now I have nothing against completely ripping out PyObject_Print() if we find out that it's not really useful...) 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] 'hasattr' is broken by design
On 24/08/2010 08:40, Michael Foord wrote: On 24/08/2010 01:25, Nick Coghlan wrote: On Tue, Aug 24, 2010 at 8:15 AM, Nick Coghlan wrote: Now, it may be worth considering an addition to the inspect module that was basically: def getattr_static(obj, attr): """Retrieve attributes without triggering dynamic lookup via the descriptor protocol, __getattr__ or __getattribute__. Note: this function may not be able to retrieve all attributes reported by dir(obj) """ try: instance_dict = object.__getattribute__(obj, "__dict__") except AttributeError: pass else: if attr in instance_dict: return instance_dict[attr] for entry in getmro(obj.__class__): try: return entry.__dict__[attr] except AttributeError: pass Second attempt with a default value parameter and correctly raising AttributeError if not found: _sentinel = object() def getattr_static(obj, attr, default=_sentinel): """Retrieve attributes without triggering dynamic lookup via the descriptor protocol, __getattr__ or __getattribute__. Note: this function may not be able to retrieve all attributes reported by dir(obj) """ try: instance_dict = object.__getattribute__(obj, "__dict__") except AttributeError: pass else: if attr in instance_dict: return instance_dict[attr] for entry in getmro(obj.__class__): try: return entry.__dict__[attr] except AttributeError: pass if default is not _sentinel: return default raise AttributeError(attr) This doesn't correctly handle the case where obj is a type object or obj uses __slots__. If I have time (currently on vacation with only intermittent internet access) I'll provide an update. I managed an updated version (with tests) during the flight home last night. I've attached it to issue 9732, along with a discussion of the caveats and ways of breaking it: http://bugs.python.org/issue9732 Michael Michael Cheers, Nick. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] 'hasattr' is broken by design
On 25 August 2010 20:57, P.J. Eby wrote: > [snip...] > As you can see, the __call__ attribute in each case is whatever the proxied > object's __call__ attribute is, even though the proxy itself has a __call__ > method, that is invoked when the proxy is called. > > This is actually pretty straightforward stuff since the introduction of > __getattribute__. > > (The code is at http://pypi.python.org/pypi/ProxyTypes, btw.) > For what it's worth this code is useful enough (and simple enough) that I would support its inclusion in the standard library. I've written proxy objects several times (for various different purposes) and this would have saved me the effort. :-) All the best, Michael Foord -- http://www.voidspace.org.uk ___ 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] PEP 384 status
On Wed, Sep 1, 2010 at 10:54 PM, Antoine Pitrou wrote: > Please consider this: even without relying on PEP 384, using FILE* > is /already/ dangerous; because you might compile an extension with a > different compiler version than Python was compiled with. So, if we were > following you, we should rip out PyObject_Print() of the whole C API, > not only the limited subset which is defined by PEP 384. > > (now I have nothing against completely ripping out PyObject_Print() if > we find out that it's not really useful...) I think it would be better if everything dealing with FILE* was a macro rather than a function, yes. The definition of the limited API is a chance to fix that without incurring the cost in backwards incompatibility that would otherwise arise. Since we have that opportunity, why not take it? 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] PEP 384 status
On Thu, 2 Sep 2010 07:04:31 +1000 Nick Coghlan wrote: > On Wed, Sep 1, 2010 at 10:54 PM, Antoine Pitrou wrote: > > Please consider this: even without relying on PEP 384, using FILE* > > is /already/ dangerous; because you might compile an extension with a > > different compiler version than Python was compiled with. So, if we were > > following you, we should rip out PyObject_Print() of the whole C API, > > not only the limited subset which is defined by PEP 384. > > > > (now I have nothing against completely ripping out PyObject_Print() if > > we find out that it's not really useful...) > > I think it would be better if everything dealing with FILE* was a > macro rather than a function, yes. The definition of the limited API > is a chance to fix that without incurring the cost in backwards > incompatibility that would otherwise arise. Since we have that > opportunity, why not take it? Maybe I've missed your answer, but what would prevent the "inline" solution from working? (a macro with the result-as-a-pointer is quite ugly) 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] r84388 - in python/branches/py3k/Doc: conf.py using/index.rst
That title isn't better though, since it doesn't cover the "using/cmdline"
document which deals with command line options, environment variables
and the like.
I agree that "Using Python" is not very descriptive though.
Georg
Am 01.09.2010 10:57, schrieb raymond.hettinger:
> Author: raymond.hettinger
> Date: Wed Sep 1 10:57:16 2010
> New Revision: 84388
>
> Log:
> More descriptive title.
>
> Modified:
>python/branches/py3k/Doc/conf.py
>python/branches/py3k/Doc/using/index.rst
>
> Modified: python/branches/py3k/Doc/conf.py
> ==
> --- python/branches/py3k/Doc/conf.py (original)
> +++ python/branches/py3k/Doc/conf.py Wed Sep 1 10:57:16 2010
> @@ -131,7 +131,7 @@
> ('tutorial/index', 'tutorial.tex',
> 'Python Tutorial', _stdauthor, 'manual'),
> ('using/index', 'using.tex',
> - 'Using Python', _stdauthor, 'manual'),
> + 'Python Setup', _stdauthor, 'manual'),
> ('whatsnew/' + version, 'whatsnew.tex',
> 'What\'s New in Python', 'A. M. Kuchling', 'howto'),
> ]
>
> Modified: python/branches/py3k/Doc/using/index.rst
> ==
> --- python/branches/py3k/Doc/using/index.rst (original)
> +++ python/branches/py3k/Doc/using/index.rst Wed Sep 1 10:57:16 2010
> @@ -1,7 +1,7 @@
> .. _using-index:
>
>
> - Using Python
> + Python Setup
>
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.
___
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] PEP 384 status
On Thu, Sep 2, 2010 at 7:19 AM, Antoine Pitrou wrote: > Maybe I've missed your answer, but what would prevent the "inline" > solution from working? Only PEP 7 (since standard support for inline is a C99 feature) On the other hand, if gcc (including cygwin/mingw) and MSVC support it (even with non-standard spellings), then that objection probably doesn't matter. > (a macro with the result-as-a-pointer is quite ugly) Agreed. 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] [Python-checkins] r84391 - in python/branches/py3k: Include/abstract.h Misc/NEWS Objects/abstract.c Objects/memoryobject.c
On Wed, Sep 1, 2010 at 10:58 PM, antoine.pitrou wrote: > Modified: python/branches/py3k/Misc/NEWS > == > --- python/branches/py3k/Misc/NEWS (original) > +++ python/branches/py3k/Misc/NEWS Wed Sep 1 14:58:21 2010 > @@ -354,6 +354,9 @@ > Build > - > > +- Issue #3101: Helper functions _add_one_to_C() and _add_one_to_F() become > + _Py_add_one_to_C() and _Py_add_one_to_F(), respectively. > + Minor point: the names are actually *_index_C and *_index_F. (the patch is right, just NEWS and the checkin comment are off) 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] r84388 - in python/branches/py3k/Doc: conf.py using/index.rst
On Thu, Sep 2, 2010 at 7:25 AM, Georg Brandl wrote: > That title isn't better though, since it doesn't cover the "using/cmdline" > document which deals with command line options, environment variables > and the like. > > I agree that "Using Python" is not very descriptive though. Python Setup and Usage? 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
