Re: [Python-Dev] Updating turtle.py
On 2 June 2014 14:03, Stephen J. Turnbull wrote: > Raymond Hettinger writes: > > It's a bummer, but in mature code, almost every idea that occurs to > > a beginner is something that makes the code worse in some way -- > > that isn't always true but it happens often enough to be > > discouraging. > > This is precisely why style-checking in the core may be a good idea > for interns: assume the code is *good* code (it probably is), don't > mess with the algorithms, but make the code "look right" according to > project standards. The risk you cite is still there, but much less. > It shows them what Pythonicity looks like at a deeper level than the > relatively superficial[1] guidelines in PEP 8. The problem from my perspective is that the standard library contains code where it's either old enough to predate the evolution of the conventions now documented in PEP 8, or else we declared some code (especially test code) "good enough" for inclusion because we *really* wanted the functionality it provided (the original ipaddr tests come to mind - I suspect that tracker issue is one of the specific cases Raymond is thinking of as well). Even if we had unlimited reviewer resources (which we don't), mechanical code cleanups tend to fall under the "if it ain't broke, don't fix it" guideline. That then sets us up for a conflict between folks just getting started and trying to be helpful, and those of us that are of the school of thought that sees a difference between "cleaning code up to make it easier to work on a subsequent bug fix or feature request" and "cleaning code up for the sake of cleaning it up". The latter is generally a bad idea, while the former may be a good idea, but it can be hard to explain the difference to folks that are more familiar with code bases started in the modern era where the ability to easily run automated tests and code analysis on every commit is almost assumed, rather than being seen as an exceptional situation. There's a reason the desire to "throw it out and start again with a clean slate" is a common trait amongst developers: green field programming is genuinely *more fun* than maintenance programming in most cases. I believe Raymond's concern (and mine) is that if the challenges of maintenance programming aren't made clear to potential contributors up front, they're going to be disappointed when their patches that might be fine for a green field project, or as part of the development of a particular feature or fix, are instead rejected as imposing too much risk for not enough gain when considered in isolation. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updating turtle.py
Am 01.06.14 00:21, schrieb Terry Reedy: >>> Responding today, I cautioned that clean-up only patches, such as she >>> apparently would like to start with, are not in favor. >> >> I would not say that. I recall that I asked Gregor to make a number of >> style changes before he submitted the code, and eventually agreed to the >> code when I thought it was "good enough". However, continuing on that >> path sounds reasonable to me. > > I am not sure what you mean by 'that path', to be continued on. The path of improving the coding style of the turtle module. >> I'd suggest that it is less work to restrict cleanup >> to 3.5, and then deal with any forward-porting of bug fixing when it >> actually happens. > > This would make it non-trivial for any patch hitting a difference. Indeed. OTOH, it's simpler for anybody doing the code cleanup to do it only on one branch. Regards, Martin ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should standard library modules optimize for CPython?
2014-06-01 10:11 GMT+02:00 Steven D'Aprano : > My feeling is that the CPython standard library should be written for > CPython, Right. PyPy, Jython and IronPython already have their "own" standard library when they need a different implement. PyPy: "lib_pypy" directory (lib-python is the CPython stdlib): https://bitbucket.org/pypy/pypy/src/ac52eb7059d0b8d001a2103774917cf7396f/lib_pypy/?at=default Jython: "Lib" directory (lib-python is the CPython stdlib): https://bitbucket.org/jython/jython/src/9cd9ab75eadea898e2e74af82ae414925d6a1135/Lib/?at=default IronPython: "IronPython.Modules" directory: http://ironpython.codeplex.com/SourceControl/latest#IronPython_Main/Languages/IronPython/IronPython.Modules/ See for example the _fsum.py module of Jython: https://bitbucket.org/jython/jython/src/9cd9ab75eadea898e2e74af82ae414925d6a1135/Lib/_fsum.py?at=default Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updating turtle.py
Nick Coghlan writes: > Even if we had unlimited reviewer resources (which we don't), Raymond said "interns". We at least have a mentor. > There's a reason the desire to "throw it out and start again with a > clean slate" is a common trait amongst developers: You mean the Cascade of Attention-Deficit Teenagers development model? > I believe Raymond's concern (and mine) is that if the challenges of > maintenance programming aren't made clear to potential contributors > up front, So make it clear when the assignment is given. Remember, the point I'm making is that it's an investment for the intern, not for Python. If their code eventually gets relegated to a branch the may never ever get merged, that's a learning experience too -- they may have been told, and *thought* they signed up for that up front, but it's different when you actually get told, "it could be useful, but on balance let's not touch this code" or even "the 'owner' of the code doesn't have time to look at changes". It's not something I suggest as a "rite of initiation" for *all* interns. I just think it would be overkill to prohibit it in principle -- I have a couple of (non-Python) interns who would benefit from the exercise (their projects are greenfield code, so they have no "model code" to start from). It wasn't clear to me whether Raymond meant to go that far as a general prohibition. Regards, ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should standard library modules optimize for CPython?
On Mon, Jun 2, 2014 at 10:43 AM, Victor Stinner wrote: > 2014-06-01 10:11 GMT+02:00 Steven D'Aprano : >> My feeling is that the CPython standard library should be written for >> CPython, > > Right. PyPy, Jython and IronPython already have their "own" standard > library when they need a different implement. > > PyPy: "lib_pypy" directory (lib-python is the CPython stdlib): > https://bitbucket.org/pypy/pypy/src/ac52eb7059d0b8d001a2103774917cf7396f/lib_pypy/?at=default it's for stuff that's in CPython implemented in C, not a reimplementation of python stuff. we patched the most obvious CPython-specific hacks, but it's a loosing battle, you guys will go way out of your way to squeeze extra 2% by doing very obscure hacks. > > Jython: "Lib" directory (lib-python is the CPython stdlib): > https://bitbucket.org/jython/jython/src/9cd9ab75eadea898e2e74af82ae414925d6a1135/Lib/?at=default > > IronPython: "IronPython.Modules" directory: > http://ironpython.codeplex.com/SourceControl/latest#IronPython_Main/Languages/IronPython/IronPython.Modules/ > > See for example the _fsum.py module of Jython: > https://bitbucket.org/jython/jython/src/9cd9ab75eadea898e2e74af82ae414925d6a1135/Lib/_fsum.py?at=default > > Victor > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updating turtle.py
On 6/2/2014 3:12 AM, Nick Coghlan wrote: Even if we had unlimited reviewer resources (which we don't), mechanical code cleanups tend to fall under the "if it ain't broke, don't fix it" guideline. That then sets us up for a conflict between folks just getting started and trying to be helpful, and those of us that are of the school of thought that sees a difference between "cleaning code up to make it easier to work on a subsequent bug fix or In the case of turtle, Jessica said from the beginning that code cleanup would be for the purpose of understanding the code and making it easier to do bug fixes and enhancements. feature request" and "cleaning code up for the sake of cleaning it up". As you know, many outsiders think that we take PEP 8 more seriously than we do. The latter is generally a bad idea, while the former may be a good idea, Lita seemed to quickly understand that being able to test a bug fix is more important than making it look pretty. In any case, I believe she is doing something else until we hear from Gregor or otherwise decide how to proceed with turtle. > but it can be hard to explain the difference to folks that are more familiar with code bases started in the modern era where the ability to easily run automated tests and code analysis on every commit is almost assumed, rather than being seen as an exceptional situation. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should standard library modules optimize for CPython?
Maciej Fijalkowski, 02.06.2014 10:48: > On Mon, Jun 2, 2014 at 10:43 AM, Victor Stinner wrote: >> 2014-06-01 10:11 GMT+02:00 Steven D'Aprano : >>> My feeling is that the CPython standard library should be written for >>> CPython, >> >> Right. PyPy, Jython and IronPython already have their "own" standard >> library when they need a different implement. >> >> PyPy: "lib_pypy" directory (lib-python is the CPython stdlib): >> https://bitbucket.org/pypy/pypy/src/ac52eb7059d0b8d001a2103774917cf7396f/lib_pypy/?at=default > > it's for stuff that's in CPython implemented in C, not a > reimplementation of python stuff. we patched the most obvious > CPython-specific hacks, but it's a loosing battle, you guys will go > way out of your way to squeeze extra 2% by doing very obscure hacks. Thus my proposal to compile the modules in CPython with Cython, rather than duplicating their code or making/keeping them CPython specific. I think reducing the urge to reimplement something in C is a good thing. Stefan ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] use cases for "python-config" versus "pkg-config python"
Hi,
following up myself with a patch proposal:
On 05/28/2014 04:51 PM, Michael Haubenwallner wrote:
> Stumbling over problems on AIX (Modules/python.exp not found) building
> libxml2 as python module
> let me wonder about the intended use-cases for 'python-config' and
> 'pkg-config python'.
>
> FWIW, I can see these distinct use cases here, and I'm kindly asking if I got
> them right:
>
> * Build an application containing a python interpreter (like python$EXE
> itself):
> + link against libpython.so
> + re-export symbols from libpython.so for python-modules (platform-specific)
> + This is similar to build against any other library, thus
> = 'python.pc' is installed (for 'pkg-config python').
>
> * Build a python-module (like build/lib.-/*.so):
> + no need to link against libpython.so, instead
> + expect symbols from libpython.so to be available at runtime,
> platform-specific either as
> + undefined symbols at build-time (Linux, others), or
> + a list of symbols to import from "the main executable" (AIX)
> + This is specific to python-modules, thus
> = 'python-config' is installed.
>
Based on these use-cases, I'm on a trip towards a patch improving AIX support
here,
where the attached one is a draft against python-tip (next step is to have
python-config
not print $LIBS, but $LINKFORMODULE only).
Thoughts?
Thank you!
/haubi/
diff -r dc3afbee4ad1 Makefile.pre.in
--- a/Makefile.pre.in Mon Jun 02 01:32:23 2014 -0700
+++ b/Makefile.pre.in Mon Jun 02 19:57:54 2014 +0200
@@ -87,6 +87,9 @@
SGI_ABI= @SGI_ABI@
CCSHARED= @CCSHARED@
LINKFORSHARED= @LINKFORSHARED@
+BLINKFORSHARED=@BLINKFORSHARED@
+LINKFORMODULE= @LINKFORMODULE@
+BLINKFORMODULE=@BLINKFORMODULE@
ARFLAGS= @ARFLAGS@
# Extra C flags added for building the interpreter object files.
CFLAGSFORSHARED=@CFLAGSFORSHARED@
@@ -540,7 +543,7 @@
# Build the interpreter
$(BUILDPYTHON):Modules/python.o $(LIBRARY) $(LDLIBRARY) $(PY3LIBRARY)
- $(LINKCC) $(PY_LDFLAGS) $(LINKFORSHARED) -o $@ Modules/python.o
$(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)
+ $(LINKCC) $(PY_LDFLAGS) $(BLINKFORSHARED) -o $@ Modules/python.o
$(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)
platform: $(BUILDPYTHON) pybuilddir.txt
$(RUNSHARED) $(PYTHON_FOR_BUILD) -c 'import sys ; from sysconfig import
get_platform ; print(get_platform()+"-"+sys.version[0:3])' >platform
@@ -666,7 +669,7 @@
fi
Modules/_testembed: Modules/_testembed.o $(LIBRARY) $(LDLIBRARY) $(PY3LIBRARY)
- $(LINKCC) $(PY_LDFLAGS) $(LINKFORSHARED) -o $@ Modules/_testembed.o
$(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)
+ $(LINKCC) $(PY_LDFLAGS) $(BLINKFORSHARED) -o $@ Modules/_testembed.o
$(BLDLIBRARY) $(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST)
# Importlib
@@ -1310,7 +1313,7 @@
# pkgconfig directory
LIBPC= $(LIBDIR)/pkgconfig
-libainstall: all python-config
+libainstalldirs:
@for i in $(LIBDIR) $(LIBPL) $(LIBPC); \
do \
if test ! -d $(DESTDIR)$$i; then \
@@ -1319,6 +1322,16 @@
elsetrue; \
fi; \
done
+
+# resolve Makefile variables eventually found in configured python.pc values
+$(DESTDIR)$(LIBPC)/python-$(VERSION).pc: Misc/python.pc Makefile
libainstalldirs
+ @echo "Resolving more values for $(LIBPC)/python-$(VERSION).pc"; \
+ if test set = "$${PYTHON_PC_CONTENT:+set}"; \
+ then echo '$(PYTHON_PC_CONTENT)' | tr '@' '\n' > $@; \
+ else PYTHON_PC_CONTENT="`awk -v ORS='@' '{print $0}' < Misc/python.pc`"
$(MAKE) $@ `grep = Misc/python.pc`; \
+ fi
+
+libainstall: all python-config libainstalldirs
$(DESTDIR)$(LIBPC)/python-$(VERSION).pc
@if test -d $(LIBRARY); then :; else \
if test "$(PYTHONFRAMEWORKDIR)" = no-framework; then \
if test "$(SHLIB_SUFFIX)" = .dll; then \
@@ -1338,7 +1351,6 @@
$(INSTALL_DATA) Modules/Setup $(DESTDIR)$(LIBPL)/Setup
$(INSTALL_DATA) Modules/Setup.local $(DESTDIR)$(LIBPL)/Setup.local
$(INSTALL_DATA) Modules/Setup.config $(DESTDIR)$(LIBPL)/Setup.config
- $(INSTALL_DATA) Misc/python.pc $(DESTDIR)$(LIBPC)/python-$(VERSION).pc
$(INSTALL_SCRIPT) $(srcdir)/Modules/makesetup
$(DESTDIR)$(LIBPL)/makesetup
$(INSTALL_SCRIPT) $(srcdir)/install-sh $(DESTDIR)$(LIBPL)/install-sh
$(INSTALL_SCRIPT) python-config.py $(DESTDIR)$(LIBPL)/python-config.py
@@ -1540,6 +1552,7 @@
-rm -rf build platform
-rm -rf $(PYTHONFRAMEWORKDIR)
-rm -f python-config.py python-config
+ -rm -f Misc/python.pc
# Make things extra clean, before making a distribution:
# remove all generated files, even Makefile[.pre]
@@ -1612,7 +1625,7 @@
.PHONY: frameworkinstallmaclib frameworkinstallapps frameworkinstallunixtools
.PHONY: frameworkaltinstallunixtools recheck au
Re: [Python-Dev] use cases for "python-config" versus "pkg-config python"
Patches sent to python-dev are typically ignored. Could you open an issue on bugs.python.org and upload it there? On Mon Jun 02 2014 at 2:20:43 PM, Michael Haubenwallner < [email protected]> wrote: > Hi, > > following up myself with a patch proposal: > > On 05/28/2014 04:51 PM, Michael Haubenwallner wrote: > > Stumbling over problems on AIX (Modules/python.exp not found) building > libxml2 as python module > > let me wonder about the intended use-cases for 'python-config' and > 'pkg-config python'. > > > > FWIW, I can see these distinct use cases here, and I'm kindly asking if > I got them right: > > > > * Build an application containing a python interpreter (like python$EXE > itself): > > + link against libpython.so > > + re-export symbols from libpython.so for python-modules > (platform-specific) > > + This is similar to build against any other library, thus > > = 'python.pc' is installed (for 'pkg-config python'). > > > > * Build a python-module (like build/lib.-/*.so): > > + no need to link against libpython.so, instead > > + expect symbols from libpython.so to be available at runtime, > platform-specific either as > > + undefined symbols at build-time (Linux, others), or > > + a list of symbols to import from "the main executable" (AIX) > > + This is specific to python-modules, thus > > = 'python-config' is installed. > > > > Based on these use-cases, I'm on a trip towards a patch improving AIX > support here, > where the attached one is a draft against python-tip (next step is to have > python-config > not print $LIBS, but $LINKFORMODULE only). > > Thoughts? > > Thank you! > /haubi/ > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > brett%40python.org > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] use cases for "python-config" versus "pkg-config python"
Am 02.06.2014 20:11, schrieb Michael Haubenwallner: > Hi, > > following up myself with a patch proposal: > > On 05/28/2014 04:51 PM, Michael Haubenwallner wrote: >> Stumbling over problems on AIX (Modules/python.exp not found) building >> libxml2 as python module >> let me wonder about the intended use-cases for 'python-config' and >> 'pkg-config python'. >> >> FWIW, I can see these distinct use cases here, and I'm kindly asking if I >> got them right: >> >> * Build an application containing a python interpreter (like python$EXE >> itself): >> + link against libpython.so >> + re-export symbols from libpython.so for python-modules >> (platform-specific) >> + This is similar to build against any other library, thus >> = 'python.pc' is installed (for 'pkg-config python'). >> >> * Build a python-module (like build/lib.-/*.so): >> + no need to link against libpython.so, instead >> + expect symbols from libpython.so to be available at runtime, >> platform-specific either as >> + undefined symbols at build-time (Linux, others), or >> + a list of symbols to import from "the main executable" (AIX) >> + This is specific to python-modules, thus >> = 'python-config' is installed. >> > > Based on these use-cases, I'm on a trip towards a patch improving AIX support > here, > where the attached one is a draft against python-tip (next step is to have > python-config > not print $LIBS, but $LINKFORMODULE only). > > Thoughts? there is http://bugs.python.org/issue15590 I think it is worth improving, together with adding documentation, and maybe distinguishing the two use cases linking for a module or an embedded interpreter. Matthias ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
