Re: [Python-Dev] Python install layout and the PATH on win32
On 17/03/2012 12:25 PM, Carl Meyer wrote: Hi Mark, On 03/16/2012 05:53 PM, Mark Hammond wrote: * All executables and scripts go into the root of the Python install. This directory is largely empty now - it is mainly a container for other directories. This would solve the problem of needing 2 directories on the PATH and mean existing tools which locate the executable would work fine. I hate to seem like I'm piling on now after panning your last brainstorm :-), but... this would be quite problematic for virtualenv users, many of whom do rely on the fact that the virtualenv "stuff" is confined to within a limited set of known subdirectories, and they can overlay a virtualenv and their own project code with just a few virtualenv directories vcs-ignored. I would prefer either the status quo or the proposed cross-platform harmonization. Yeah, fair enough. I should have indicated it was 1/2 tongue-in-cheek, but figured it worth throwing it out there anyway :) OTOH, the part that wasn't tongue-in-cheek was the part that said "why not change the other platforms instead of windows" (then wait for the inevitable replies), then "so those same reasons apply to Windows too" - eg "fleets of torch wielding windows admins" :) Breaking the few tools I'm concerned about vs asking Van etc to continue taking the pain he feels isn't going to mean the end of the world for any of us. So given the stakes in this particular discussion aren't that high, I'll try and summarize the thread over the next few days (or someone can beat me to it if they prefer) and we can ask someone semi-impartial to make a decision. I'd be happy to nominate MvL if he feels so inclined (even though I haven't asked him). Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] lzma
liblzma-dev has solved my problem. Thank you, Senthil. On Fri, Mar 16, 2012 at 7:38 PM, Senthil Kumaran wrote: > > On Fri, Mar 16, 2012 at 07:30:31PM -0700, Andrew Svetlov wrote: >> When I build python from sources I have no lzma support (module _lzma >> cannot be built). >> > > I have liblzma-dev, liblzma2 and lzma packages installed on ubuntu. I > am able to build and import lzma module. > > Thanks, > Senthil > > -- Thanks, Andrew Svetlov ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] lzma
On Fri, Mar 16, 2012 at 07:30:31PM -0700, Andrew Svetlov wrote: > When I build python from sources I have no lzma support (module _lzma > cannot be built). > I have liblzma-dev, liblzma2 and lzma packages installed on ubuntu. I am able to build and import lzma module. Thanks, Senthil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] lzma
When I build python from sources I have no lzma support (module _lzma cannot be built). There are lzma packages installed in my Ubuntu 11.10 box: lzma, lzma-dev and lzma-sources. I can see lib files (headers are also can be found in linux-headers): andrew@tiktaalik ~/p/cpython> locate lzma.so /usr/lib/liblzma.so.2 /usr/lib/liblzma.so.2.0.0 I can live with that but if somebody can point me the way to build python with lzma support please do. -- Thanks, Andrew Svetlov ___ Python-Dev mailing list Python-Dev@python.org 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 install layout and the PATH on win32
On 3/16/2012 6:25 PM, Carl Meyer wrote: Hi Mark, On 03/16/2012 05:53 PM, Mark Hammond wrote: * All executables and scripts go into the root of the Python install. This directory is largely empty now - it is mainly a container for other directories. This would solve the problem of needing 2 directories on the PATH and mean existing tools which locate the executable would work fine. I hate to seem like I'm piling on now after panning your last brainstorm :-), but... this would be quite problematic for virtualenv users, many of whom do rely on the fact that the virtualenv "stuff" is confined to within a limited set of known subdirectories, and they can overlay a virtualenv and their own project code with just a few virtualenv directories vcs-ignored. I would prefer either the status quo or the proposed cross-platform harmonization. Yes, it seems fruitless to make directory structure changes without achieving cross-platform consistency. ___ Python-Dev mailing list Python-Dev@python.org 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 install layout and the PATH on win32
Hi Mark, On 03/16/2012 05:53 PM, Mark Hammond wrote: > * All executables and scripts go into the root of the Python install. > This directory is largely empty now - it is mainly a container for other > directories. This would solve the problem of needing 2 directories on > the PATH and mean existing tools which locate the executable would work > fine. I hate to seem like I'm piling on now after panning your last brainstorm :-), but... this would be quite problematic for virtualenv users, many of whom do rely on the fact that the virtualenv "stuff" is confined to within a limited set of known subdirectories, and they can overlay a virtualenv and their own project code with just a few virtualenv directories vcs-ignored. I would prefer either the status quo or the proposed cross-platform harmonization. Carl signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org 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 install layout and the PATH on win32
On 17/03/2012 12:07 PM, Brian Curtin wrote: On Fri, Mar 16, 2012 at 19:53, Mark Hammond wrote: For the sake of brain-storming, how about this: * All executables and scripts go into the root of the Python install. This directory is largely empty now - it is mainly a container for other directories. This would solve the problem of needing 2 directories on the PATH and mean existing tools which locate the executable would work fine. How are existing tools locating the executable which would break with a change to bin? As I posted on the tracker, the way which pops in my mind would be to look for "C:\\Python%d%d" % (x, y) but that's already pretty broken. As I just replied in the tracker :) They typically look up the InstallPath key in the registry and look for python.exe there - see the link to that activate.bat file I posted early in the thread. The people I talked to at PyCon about this were Dino from Microsoft and he nudged the guy next to him to ask the same question (I seem to remember this guy worked for an IDE) -- both of them just wanted to be sure they can still find python.exe's location via the registry, which will be fine. I think we'll add a key to go along with InstallPath - BinaryPath probably makes sense. While I wouldn't object to that, it would seem redundant - if the whole point of this is to standardize the locations, then looking for "bin/python.exe" relative to the existing InstallPath key should also be reliable and hopefully permanent. At the risk of repeating myself too many times, my concern is with 3rd party tools who (a) will break with the new scheme and need to be updated and (b) even after updating will still need the burden of supporting both the old and the new schemes. I simply don't see the benefit that makes this worthwhile. * If cross-platform consistency was desired, then we could consider making other platforms match this. However, if there are issues which might prevent this happening for other platforms (eg, the risk of breaking other 3rd party tools, conventions on the platform ,etc) then it might be worth conceding these considerations apply equally to the Windows installs and we just live with this platform difference. I don't think we're going to defeat the Unix army with their fleets of distro packagers and torch wielding purists. If anyone's going to move, my money's on Windows. Right - but why? Who wins? Where is the evidence of the pain this has caused people over the last 18 years or so since Windows has been doing this? Mark ___ Python-Dev mailing list Python-Dev@python.org 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 install layout and the PATH on win32
On Fri, Mar 16, 2012 at 19:53, Mark Hammond wrote: > For the sake of brain-storming, how about this: > > * All executables and scripts go into the root of the Python install. This > directory is largely empty now - it is mainly a container for other > directories. This would solve the problem of needing 2 directories on the > PATH and mean existing tools which locate the executable would work fine. How are existing tools locating the executable which would break with a change to bin? As I posted on the tracker, the way which pops in my mind would be to look for "C:\\Python%d%d" % (x, y) but that's already pretty broken. The people I talked to at PyCon about this were Dino from Microsoft and he nudged the guy next to him to ask the same question (I seem to remember this guy worked for an IDE) -- both of them just wanted to be sure they can still find python.exe's location via the registry, which will be fine. I think we'll add a key to go along with InstallPath - BinaryPath probably makes sense. > * If cross-platform consistency was desired, then we could consider making > other platforms match this. However, if there are issues which might > prevent this happening for other platforms (eg, the risk of breaking other > 3rd party tools, conventions on the platform ,etc) then it might be worth > conceding these considerations apply equally to the Windows installs and we > just live with this platform difference. I don't think we're going to defeat the Unix army with their fleets of distro packagers and torch wielding purists. If anyone's going to move, my money's on Windows. ___ Python-Dev mailing list Python-Dev@python.org 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 install layout and the PATH on win32
On 14/03/2012 6:43 AM, VanL wrote: Following up on conversations at PyCon, I want to bring up one of my personal hobby horses for change in 3.3: Fix install layout on Windows, with a side order of making the PATH work better. ... For the sake of brain-storming, how about this: * All executables and scripts go into the root of the Python install. This directory is largely empty now - it is mainly a container for other directories. This would solve the problem of needing 2 directories on the PATH and mean existing tools which locate the executable would work fine. * If cross-platform consistency was desired, then we could consider making other platforms match this. However, if there are issues which might prevent this happening for other platforms (eg, the risk of breaking other 3rd party tools, conventions on the platform ,etc) then it might be worth conceding these considerations apply equally to the Windows installs and we just live with this platform difference. Mark ___ Python-Dev mailing list Python-Dev@python.org 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 install layout and the PATH on win32
On 17/03/2012 7:22 AM, Carl Meyer wrote: ... I don't want to make the internal layout of a virtualenv differ from the system Python layout on the same platform, which (IIUC) was Mark's proposal. Just to be clear, I made that suggestion in an effort to keep both myself and Van - that the Python executable would remain in the same place for installed Pythons in the interests of b/w compat, but change it in the virtual env in an effort to keep Van happy when working in such environments. I now fully concede that was a dumb idea :) Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
OK, how about using encoding=bytes (yes, the type object!)? Or 'bytes' ?
--Guido van Rossum (sent from Android phone)
On Mar 16, 2012 2:19 PM, "Merlijn van Deen" wrote:
> Hi Guido,
>
> Let me start with thanking you for your long reply. It has clarified
> some points to me, but I am still not certain about some others. I
> hope I can clarify why I'm confused about this issue in the following.
>
> First of all, let me clarify that I wrote my original mail not as 'the
> guy who wants to serialize stuff' but as 'the guy who wonders what the
> best way to implement it in python is'. Of course, 'not' is a
> reasonable answer to that question.
>
> On 13 March 2012 23:08, Guido van Rossum wrote:
> > That was probably written before Python 3. Python 3 also dropped the
> > long-term backwards compatibilities for the language and stdlib. I am
> > certainly fine with adding a warning to the docs that this guarantee
> > does not apply to the Python 2/3 boundary. But I don't think we should
> > map 8-bit str instances from Python 2 to bytes in Python 3.
>
> Yes, backwards compatibility was dropped, but the current pickle
> module tries to work around this by using a module mapping [1] and
> aids in loading 8-bit str instances by asking for an encoding [2].
> Last, but not least, we can /write/ old version pickles, for which
> the same module mapping is used, but in reverse. As such, the module
> suggests in many ways that it should be possible to interchange
> pickles between python 2 and python 3.
>
> > My snipe was mostly in reference to the many other things that can go
> > wrong with pickled data as your environment evolves (...)
> I understand your point. However, my interpretation of this issue
> always was 'if you only pickle built-in types, you'll be fine' - which
> is apparently wrong.
>
>
> Essentially - my point is this: considering the pickle module is
> already using several compatibility tricks and considering I am not
> the only one who would like to read binary data from a pickle in
> python 3 - even though it might not be the 'right' way to do it - what
> is there /against/ adding the possibility?
>
> Last but not least, this is what people are now doing instead: [1]
>s = pickle.load(f, encoding='latin1')
>b = s.encode('latin1')
>print(zlib.decompress(b))
>
> Which hurts my eyes.
>
> In any case - again, thanks for taking the time to respond. I hope I
> somewhat clarified why I was/am somewhat confused on the issue, and
> the reasons why I think that it is still a good idea ;-)
>
> Best,
> Merlijn
>
> [1] http://hg.python.org/cpython/file/8b2668e60aef/Lib/_compat_pickle.py
> [2] http://docs.python.org/dev/library/pickle.html#module-interface
> [3]
> http://stackoverflow.com/questions/4281619/unpicking-data-pickled-in-python-2-5-in-python-3-1-then-uncompressing-with-zlib
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
Hi Guido,
Let me start with thanking you for your long reply. It has clarified
some points to me, but I am still not certain about some others. I
hope I can clarify why I'm confused about this issue in the following.
First of all, let me clarify that I wrote my original mail not as 'the
guy who wants to serialize stuff' but as 'the guy who wonders what the
best way to implement it in python is'. Of course, 'not' is a
reasonable answer to that question.
On 13 March 2012 23:08, Guido van Rossum wrote:
> That was probably written before Python 3. Python 3 also dropped the
> long-term backwards compatibilities for the language and stdlib. I am
> certainly fine with adding a warning to the docs that this guarantee
> does not apply to the Python 2/3 boundary. But I don't think we should
> map 8-bit str instances from Python 2 to bytes in Python 3.
Yes, backwards compatibility was dropped, but the current pickle
module tries to work around this by using a module mapping [1] and
aids in loading 8-bit str instances by asking for an encoding [2].
Last, but not least, we can /write/ old version pickles, for which
the same module mapping is used, but in reverse. As such, the module
suggests in many ways that it should be possible to interchange
pickles between python 2 and python 3.
> My snipe was mostly in reference to the many other things that can go
> wrong with pickled data as your environment evolves (...)
I understand your point. However, my interpretation of this issue
always was 'if you only pickle built-in types, you'll be fine' - which
is apparently wrong.
Essentially - my point is this: considering the pickle module is
already using several compatibility tricks and considering I am not
the only one who would like to read binary data from a pickle in
python 3 - even though it might not be the 'right' way to do it - what
is there /against/ adding the possibility?
Last but not least, this is what people are now doing instead: [1]
s = pickle.load(f, encoding='latin1')
b = s.encode('latin1')
print(zlib.decompress(b))
Which hurts my eyes.
In any case - again, thanks for taking the time to respond. I hope I
somewhat clarified why I was/am somewhat confused on the issue, and
the reasons why I think that it is still a good idea ;-)
Best,
Merlijn
[1] http://hg.python.org/cpython/file/8b2668e60aef/Lib/_compat_pickle.py
[2] http://docs.python.org/dev/library/pickle.html#module-interface
[3]
http://stackoverflow.com/questions/4281619/unpicking-data-pickled-in-python-2-5-in-python-3-1-then-uncompressing-with-zlib
___
Python-Dev mailing list
Python-Dev@python.org
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 install layout and the PATH on win32
Hi Van, On 03/16/2012 08:08 AM, Lindberg, Van wrote: >> Changing the directory name is in fact a new and different (and much >> more invasive) special case, because distutils et al install scripts >> there, and that directory name is part of the distutils install scheme. >> Installers don't care where the Python binary is located, so moving it >> in with the other scripts has very little impact. > > So would changing the distutils install scheme in 3.3 - as defined and > declared by distutils - lead to a change in your code? > > Alternatively stated, do you independently figure out that your > virtualenv is on Windows and then put things in Scripts, etc, or do you > use sysconfig? If sysconfig gave you different (consistent) values > across platforms, how would that affect your code? Both virtualenv and PEP 405 pyvenv figure out the platform at venv-creation time, and hard-code certain information about the correct layout for that platform (Scripts vs bin, as well as lib/pythonx.x vs Lib), so the internal layout of the venv matches the system layout on that platform. The key fact is that there is then no special-casing necessary when code runs within the virtualenv (particularly installer code); the same install scheme that would work in the system Python will also Just Work in the virtualenv. I'm not concerned about changes to distutils/sysconfig install schems to make them more compatible across platforms from the POV of virtualenv; we can easily update the current platform-detection code to do the right thing depending on both platform and Python version. I do share Éric's concern about whether distutils' legacy install schemes would be updated or not, and how this would affect backwards compatibility for older installer code, but that's pretty much orthogonal to virtualenv/pyvenv. I don't want to make the internal layout of a virtualenv differ from the system Python layout on the same platform, which (IIUC) was Mark's proposal. Hope that clarifies, Carl signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Raising assertions on wrong element types in ElementTree
On Fri, 16 Mar 2012 15:49:33 -0400, Terry Reedy wrote: > On 3/16/2012 11:33 AM, R. David Murray wrote: > > On Fri, 16 Mar 2012 09:38:49 +0200, Eli Bendersky wrote: > >> 1. The behavior of append, insert and extend should be similar in this > >> respect > >> 2. AssertionError is not the customary error in such case - TypeError > >> is much more suitable > >> 3. The C implementation of ElementTree actually raises TypeError in > >> all these methods, by virtue of using PyArg_ParseTuple > >> 4. The Python implementation (at least in 3.2) actually doesn't raise > >> even AssertionError in extend - this was commented out > > > Our usual approach in cases like this is to not change it in the maint > > releases. Why risk breaking someone's code for no particular benefit? > > If you want some extra work you could add it as a deprecation warning, > > I suppose. > > The deprecation warning would be that ignoring the error is deprecated > ;-). I think this would be a good idea since it would only appear when > someone is checking for how to change their code for 3.3. Yes :). But concretely the deprecation warning is that if anyone has code that for some reason *works* with the python version of ElementTree while passing in a non-Element (duck typing?), that will no longer be allowed in 3.3. So it does seem worthwhile to do that. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Raising assertions on wrong element types in ElementTree
On 3/16/2012 11:33 AM, R. David Murray wrote: On Fri, 16 Mar 2012 09:38:49 +0200, Eli Bendersky wrote: 1. The behavior of append, insert and extend should be similar in this respect 2. AssertionError is not the customary error in such case - TypeError is much more suitable 3. The C implementation of ElementTree actually raises TypeError in all these methods, by virtue of using PyArg_ParseTuple 4. The Python implementation (at least in 3.2) actually doesn't raise even AssertionError in extend - this was commented out The suggestion for 3.3 (where compatibility between the C and Python implementations gets even more important, since the C one is now being imported by default when available) is to raise TypeError in all 3 methods in the Python implementation, to match the C implementation, and to modify the documentation accordingly. There may appear to be a backwards compatibility here, since the doc of extend mentions raising AssertionError - but as said above, the doc is wrong, so no regressions in the code are be expected. Does that sound reasonable (for 3.3)? Yes. Third yes. Does it make sense to also fix this in 3.2/2.7? Or fix only the documentation? Or not touch them at all? I have no opinion about 2.7 as I have not checked what it currently says and does. In the 3.2 docs, we should remove the erroneous assertion about AssertionError. I think it would be good to also say that CElementTree raises TypeError for erroneous input but ElementTree does not and the the latter mistake is fixed in 3.3. Messy reality makes for messy docs. Our usual approach in cases like this is to not change it in the maint releases. Why risk breaking someone's code for no particular benefit? If you want some extra work you could add it as a deprecation warning, I suppose. The deprecation warning would be that ignoring the error is deprecated ;-). I think this would be a good idea since it would only appear when someone is checking for how to change their code for 3.3. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org 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 install layout and the PATH on win32
On 3/16/2012 12:22 PM, Lindberg, Van wrote: env/ bin/ python pip easy_install my_script In http://bugs.python.org/issue14302 Brian Curtin claims "After talks at PyCon with several people, python.exe will live in C:\Python33\bin rather than C:\Python33 to come more in line with the Unix layout. This will also simplify another issue with the Path option for the 3.3 installer as well as packaging's target directory for top-level scripts (used to be Scripts/, will be bin/)." -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
On Fri, Mar 16, 2012 at 9:20 AM, Tres Seaver wrote: > On 03/16/2012 10:57 AM, Guido van Rossum wrote: >> On Thu, Mar 15, 2012 at 9:48 PM, Tres Seaver >> wrote: >>> On 03/13/2012 06:49 PM, Nick Coghlan wrote: On Wed, Mar 14, 2012 at 8:08 AM, Guido van Rossum wrote: > If you can solve your problem with a suitably hacked Unpickler > subclass that's fine with me, but I would personally use this > opportunity to change the app to some other serialization > format that is perhaps less general but more robust than pickle. > I've been bitten by too many pickle-related problems to > recommend pickle to anyone... It's fine for in-memory storage of (almost) arbitrary objects (I use it to stash things in a memory backed sqlite DB via SQLAlchemy) and for IPC, but yeah, for long-term cross-version persistent storage, I'd be looking to something like JSON rather than pickle. >>> >>> Note the Zope ecosystem (including Plone) is an *enoromous* >>> installed base[1] using pickle for storage of data over many years >>> and multiple versions of Python: until this point, it has always >>> been possible to arrange for old pickles to work (e.g., by providing >>> aliases for missing module names, etc.). >>> >>> ]1] tens of thousands of Zope-based sites in production, including >>> very high-profile ones: http://plone.org/support/sites >> >> Don't I know it. :-) >> >> So do you need any help porting to Python 3 or not? The OP didn't >> mention Zope. > > ZODB is actually the biggest / most important non-ported items in the > Zope ecosystem. We are close to a pure-Python version of persistent and > it's pickle cache, and have some work done toward pure-Python BTrees. I take that as meaning "no, we don't need help, it's all under control." -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org 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 install layout and the PATH on win32
On 3/16/2012 11:57 AM, Glenn Linderman wrote: > So I think I'm finally beginning to see the underlying reason why Van is > desiring this consistency: It is not that he wants to check in his > installation of Python, but that he wants to check in his installation > of his packages and scripts into a source control environment, and then > be able to check out that source control environment into an > installation of Python on another machine of a different architecture. > In an environment where a source control system is pervasive and well > used, this would be an effective deployment alternative to developing a > packaging/distribution solution using distutils, distutels2, packaging, > easy_install, eggs, or peanuts, or any other such scheme. > > But! > > Source control environments don't lend themselves to being used for > anything except exact replication of file and directory structure, so > when the different architectures have different directory structures, > this deployment technique cannot easily work except, as Van has > discussed, by tweaking the development machine's environment to match > that of the deployment machines... and that only works in the case where > the deployment happens to only one architecture, and the development > machine can be tweaked to match... but deploying to multiple machine > having different architectures and directory structures would be > impossible using the source control deployment technique, because of the > different directory structures. This is exactly correct.CIRCULAR 230 NOTICE: To ensure compliance with requirements imposed by U.S. Treasury Regulations, Haynes and Boone, LLP informs you that any U.S. tax advice contained in this communication (including any attachments) was not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein. CONFIDENTIALITY NOTICE: This electronic mail transmission is confidential, may be privileged and should be read or retained only by the intended recipient. If you have received this transmission in error, please immediately notify the sender and delete it from your system. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2012-03-09 - 2012-03-16) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3337 (+19) closed 22779 (+75) total 26116 (+94) Open issues with patches: 1423 Issues opened (69) == #10484: http.server.is_cgi fails to handle CGI URLs containing PATH_IN http://bugs.python.org/issue10484 reopened by v+python #12568: Add functions to get the width in columns of a character http://bugs.python.org/issue12568 reopened by pitrou #14202: The docs of xml.dom.pulldom are almost nonexistent http://bugs.python.org/issue14202 reopened by eric.araujo #14243: NamedTemporaryFile unusable under Windows http://bugs.python.org/issue14243 opened by dabrahams #14245: float rounding examples in FAQ are outdated http://bugs.python.org/issue14245 opened by zbysz #14249: unicodeobject.c: aliasing warnings http://bugs.python.org/issue14249 opened by skrah #14250: for string patterns regex.flags is never equal to 0 http://bugs.python.org/issue14250 opened by py.user #14254: IDLE - shell restart during readline does not reset readline http://bugs.python.org/issue14254 opened by serwy #14255: tempfile.gettempdir() didn't return the path with correct case http://bugs.python.org/issue14255 opened by åå.ç½ #14260: re.groupindex available for modification and continues to work http://bugs.python.org/issue14260 opened by py.user #14261: Cleanup in smtpd module http://bugs.python.org/issue14261 opened by maker #14262: Allow using decimals as arguments to `timedelta` http://bugs.python.org/issue14262 opened by cool-RR #14263: switch_index_if_fails fails on py2 http://bugs.python.org/issue14263 opened by tarek #14264: Comparison bug in distutils2.version http://bugs.python.org/issue14264 opened by tarek #14265: Fully qualified test name in failure output http://bugs.python.org/issue14265 opened by michael.foord #14266: pyunit script as shorthand for python -m unittest http://bugs.python.org/issue14266 opened by michael.foord #14268: _move_file is broken because of a bad mock http://bugs.python.org/issue14268 opened by tarek #14269: SMTPD server does not enforce client starting mail transaction http://bugs.python.org/issue14269 opened by fruitnuke #14270: Can't install a project in a specific directory http://bugs.python.org/issue14270 opened by mlhamel #14273: distutils2: logging handler not properly initialized http://bugs.python.org/issue14273 opened by tarek #14274: pysetup does not look at requires.txt http://bugs.python.org/issue14274 opened by tarek #14275: pysetup create doesn't handle install requirements http://bugs.python.org/issue14275 opened by janjaapdriessen #14276: installing latest version of a project http://bugs.python.org/issue14276 opened by janjaapdriessen #14277: time.monotonic docstring does not mention the time unit return http://bugs.python.org/issue14277 opened by nicholas.riley #14279: packaging.pypi should support flat directories of distribution http://bugs.python.org/issue14279 opened by j1m #14280: packaging.pypi should not require checksums http://bugs.python.org/issue14280 opened by j1m #14285: Traceback wrong on ImportError while executing a package http://bugs.python.org/issue14285 opened by ms4py #14286: xxlimited.obj: unresolved external symbol __imp__PyObject_New http://bugs.python.org/issue14286 opened by skrah #14287: sys.stdin.readline and KeyboardInterrupt on windows http://bugs.python.org/issue14287 opened by miwa #14288: Make iterators pickleable http://bugs.python.org/issue14288 opened by krisvale #14290: Importing script as module causes ImportError with pickle.load http://bugs.python.org/issue14290 opened by rj3d #14292: OS X installer build script doesn't set $CXX, so it ends up as http://bugs.python.org/issue14292 opened by nicholas.riley #14293: Message methods delegated via __getattr__ inaccessible using s http://bugs.python.org/issue14293 opened by Brian.Jones #14294: Requirements are not properly copied into metatdata of dist-in http://bugs.python.org/issue14294 opened by Preston #14295: PEP 417: adding mock module http://bugs.python.org/issue14295 opened by michael.foord #14296: Compilation error on CentOS 5.8 http://bugs.python.org/issue14296 opened by Alzakath #14297: Custom string formatter doesn't work like builtin str.format http://bugs.python.org/issue14297 opened by PaulMcMillan #14299: OS X installer build script: permissions not ensured http://bugs.python.org/issue14299 opened by nicholas.riley #14300: dup_socket() on Windows should use WSA_FLAG_OVERLAPPED http://bugs.python.org/issue14300 opened by sbt #14301: xmlrpc client transport and threading problem http://bugs.python.org/issue14301 opened by kees #14302: Move python.exe to bin/ http://bugs.python.org/issue14302 opened by brian.curtin #14303: Incorrect documentation
Re: [Python-Dev] Python install layout and the PATH on win32
On 3/16/2012 9:22 AM, Lindberg, Van wrote: On 3/16/2012 10:53 AM, Paul Moore wrote: > The only way I can read this to make sense is that you somehow > consider the Python installation as part of your development > environment (you mentioned source control earlier in the thread - > surely you don't manage your Python installation in source control - > binaries, stdlib, etc?). I can't see why you would do this, and it > certainly doesn't seem like a reasonable thing to do to me. > > Can you clarify? I don't check in the python binary itself, nor the stdlib, but I*do* check in the whole "installation", including the binaries directory. I like having my deploy environment exactly match my develop environment. So I think I'm finally beginning to see the underlying reason why Van is desiring this consistency: It is not that he wants to check in his installation of Python, but that he wants to check in his installation of his packages and scripts into a source control environment, and then be able to check out that source control environment into an installation of Python on another machine of a different architecture. In an environment where a source control system is pervasive and well used, this would be an effective deployment alternative to developing a packaging/distribution solution using distutils, distutels2, packaging, easy_install, eggs, or peanuts, or any other such scheme. But! Source control environments don't lend themselves to being used for anything except exact replication of file and directory structure, so when the different architectures have different directory structures, this deployment technique cannot easily work except, as Van has discussed, by tweaking the development machine's environment to match that of the deployment machines... and that only works in the case where the deployment happens to only one architecture, and the development machine can be tweaked to match... but deploying to multiple machine having different architectures and directory structures would be impossible using the source control deployment technique, because of the different directory structures. If Van stated this goal in this thread, I missed it, and I think it is the missing link in the discussions. If I'm wrong, apologies for the noise. ___ Python-Dev mailing list Python-Dev@python.org 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 install layout and the PATH on win32
On 3/16/2012 10:53 AM, Paul Moore wrote: > The only way I can read this to make sense is that you somehow > consider the Python installation as part of your development > environment (you mentioned source control earlier in the thread - > surely you don't manage your Python installation in source control - > binaries, stdlib, etc?). I can't see why you would do this, and it > certainly doesn't seem like a reasonable thing to do to me. > > Can you clarify? I don't check in the python binary itself, nor the stdlib, but I *do* check in the whole "installation", including the binaries directory. I like having my deploy environment exactly match my develop environment. So if I do have an executable program, I put it in the binaries directory and check it in. My .hgignore includes "python", "python.exe", pip, easy_install, etc. - things that are "owned by the installation - but it includes everything else. As for the stdlib, I don't check that in, so that portion of the proposal (standardize lib naming) is nice to have, but not essential to me. For example, in the following environment: env/ bin/ python pip easy_install my_script lib/ [stuff] data/ [stuff] src/ my_package I would include bin/my_script, src/, and data/ in my version control. This breaks cross-platform development if "bin" is named "Scripts". CIRCULAR 230 NOTICE: To ensure compliance with requirements imposed by U.S. Treasury Regulations, Haynes and Boone, LLP informs you that any U.S. tax advice contained in this communication (including any attachments) was not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein. CONFIDENTIALITY NOTICE: This electronic mail transmission is confidential, may be privileged and should be read or retained only by the intended recipient. If you have received this transmission in error, please immediately notify the sender and delete it from your system. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/16/2012 10:57 AM, Guido van Rossum wrote: > On Thu, Mar 15, 2012 at 9:48 PM, Tres Seaver > wrote: >> On 03/13/2012 06:49 PM, Nick Coghlan wrote: >>> On Wed, Mar 14, 2012 at 8:08 AM, Guido van Rossum >>> wrote: If you can solve your problem with a suitably hacked Unpickler subclass that's fine with me, but I would personally use this opportunity to change the app to some other serialization format that is perhaps less general but more robust than pickle. I've been bitten by too many pickle-related problems to recommend pickle to anyone... >>> >>> It's fine for in-memory storage of (almost) arbitrary objects (I >>> use it to stash things in a memory backed sqlite DB via >>> SQLAlchemy) and for IPC, but yeah, for long-term cross-version >>> persistent storage, I'd be looking to something like JSON rather >>> than pickle. >> >> Note the Zope ecosystem (including Plone) is an *enoromous* >> installed base[1] using pickle for storage of data over many years >> and multiple versions of Python: until this point, it has always >> been possible to arrange for old pickles to work (e.g., by providing >> aliases for missing module names, etc.). >> >> ]1] tens of thousands of Zope-based sites in production, including >> very high-profile ones: http://plone.org/support/sites > > Don't I know it. :-) > > So do you need any help porting to Python 3 or not? The OP didn't > mention Zope. ZODB is actually the biggest / most important non-ported items in the Zope ecosystem. We are close to a pure-Python version of persistent and it's pickle cache, and have some work done toward pure-Python BTrees. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9jaEsACgkQ+gerLs4ltQ4bQACfcRxaeRMLnmDRzWL2c537VLvC xsMAn2Cjql4Wvavr0MNyQxS58Af4EwMf =UT5J -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: PEP 417: Adding unittest.mock
On Mar 16, 2012, at 4:54 AM, Nick Coghlan wrote: > Don't forgot you also have the option of splitting out a separate > HOWTO tutorial section, leaving the main docs as a pure API reference. > (I personally find that style easier to use than the ones which try to > address both needs in the main module docs). +1 The commingling of extensive examples with regular docs has made it difficult to lookup functionality in argparse for example. In contrast, the logging module's howtos were split-out to good effect. Raymond___ Python-Dev mailing list Python-Dev@python.org 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 install layout and the PATH on win32
On 16 March 2012 15:17, Lindberg, Van wrote: > This is not a "we should be consistent" argument - I know that would > never fly. I do cross-platform dev all the time (develop on Windows and > Mac, deploy on Linux) and so this bites me *every single time* I want to > get a consistent layout between these three. That could be because I > want my deployment environment to match my development environment(s), > it could be because I need to introspect the layout to find some data, > or because I want to check in an entire environment into source control. The only way I can read this to make sense is that you somehow consider the Python installation as part of your development environment (you mentioned source control earlier in the thread - surely you don't manage your Python installation in source control - binaries, stdlib, etc?). I can't see why you would do this, and it certainly doesn't seem like a reasonable thing to do to me. Can you clarify? Paul. ___ Python-Dev mailing list Python-Dev@python.org 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 install layout and the PATH on win32
Hi, Le 16/03/2012 16:17, Lindberg, Van a écrit : > On 3/16/2012 3:38 AM, Paul Moore wrote: >> 1. The incompatibilities between platforms is precisely the problem >> that sysconfig is designed to solve, isn't it? So tools in Python will >> either use sysconfig (and be correct regardless of layout) or should >> be encouraged to change to use sysconfig (so they are >> layout-independent). > Right. I want to change the default layout in sysconfig.cfg. A few notes: - sysconfig was extracted from distutils to the top level in 2.7 and 3.2, but distutils does not use it (due to the Great Revert two years ago after it was decided at PyCon to freeze distutils and start distutils2); there are unfortunately a few subtle differences between the install schemes in sysconfig and distutils. So even if virtualenv uses sysconfig in 2.7/3.2+, I’m not sure that the venv’s pip will install distutils-based projects in the right places. - packaging uses only sysconfig.cfg - I think a change to distutils install schemes in 3.3 would violate the freeze. Regards ___ Python-Dev mailing list Python-Dev@python.org 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 install layout and the PATH on win32
On 3/16/2012 3:38 AM, Paul Moore wrote: > On 16 March 2012 00:12, Carl Meyer wrote: >> Changing the directory name is in fact a new and different (and much >> more invasive) special case, because distutils et al install scripts >> there, and that directory name is part of the distutils install scheme. >> Installers don't care where the Python binary is located, so moving it >> in with the other scripts has very little impact. This is very interesting, as it seems to argue against Mark's point. If moving the Python binary is not an issue here, then would this change make it any more/less of an issue? > 1. The incompatibilities between platforms is precisely the problem > that sysconfig is designed to solve, isn't it? So tools in Python will > either use sysconfig (and be correct regardless of layout) or should > be encouraged to change to use sysconfig (so they are > layout-independent). Right. I want to change the default layout in sysconfig.cfg. > 2. The differences in layout between a installed Python, uninstalled > builds and virtualenvs, on the same platform, are more annoying in > practice than any cross-platform differences (at least for me). But > again, these are known issues that can be dealt with easily enough > (trivially via sysconfig from within Python). These differences are a major pain for me - and it doesn't make sense that they should need to be worked around each and every time. > If I were "tidying up", I would consider renaming Scripts to "bin" on > Windows, and putting the Python executables in there (so there's only > one directory to add to PATH, and it uses the common name "bin" rather > than a name that implies that it doesn't contain exes). But that > offers no practical benefit... This is not a "we should be consistent" argument - I know that would never fly. I do cross-platform dev all the time (develop on Windows and Mac, deploy on Linux) and so this bites me *every single time* I want to get a consistent layout between these three. That could be because I want my deployment environment to match my development environment(s), it could be because I need to introspect the layout to find some data, or because I want to check in an entire environment into source control. This is not purely aesthetics - this is an issue I deal with all the time. Thanks, VanCIRCULAR 230 NOTICE: To ensure compliance with requirements imposed by U.S. Treasury Regulations, Haynes and Boone, LLP informs you that any U.S. tax advice contained in this communication (including any attachments) was not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein. CONFIDENTIALITY NOTICE: This electronic mail transmission is confidential, may be privileged and should be read or retained only by the intended recipient. If you have received this transmission in error, please immediately notify the sender and delete it from your system. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Raising assertions on wrong element types in ElementTree
On Fri, 16 Mar 2012 09:38:49 +0200, Eli Bendersky wrote: > 1. The behavior of append, insert and extend should be similar in this respect > 2. AssertionError is not the customary error in such case - TypeError > is much more suitable > 3. The C implementation of ElementTree actually raises TypeError in > all these methods, by virtue of using PyArg_ParseTuple > 4. The Python implementation (at least in 3.2) actually doesn't raise > even AssertionError in extend - this was commented out > > The suggestion for 3.3 (where compatibility between the C and Python > implementations gets even more important, since the C one is now being > imported by default when available) is to raise TypeError in all 3 > methods in the Python implementation, to match the C implementation, > and to modify the documentation accordingly. > > There may appear to be a backwards compatibility here, since the doc > of extend mentions raising AssertionError - but as said above, the doc > is wrong, so no regressions in the code are be expected. > > Does that sound reasonable (for 3.3)? Yes. > Does it make sense to also fix this in 3.2/2.7? Or fix only the > documentation? Or not touch them at all? Our usual approach in cases like this is to not change it in the maint releases. Why risk breaking someone's code for no particular benefit? If you want some extra work you could add it as a deprecation warning, I suppose. --David ___ Python-Dev mailing list Python-Dev@python.org 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 install layout and the PATH on win32
Carl - > Changing the directory name is in fact a new and different (and much > more invasive) special case, because distutils et al install scripts > there, and that directory name is part of the distutils install scheme. > Installers don't care where the Python binary is located, so moving it > in with the other scripts has very little impact. So would changing the distutils install scheme in 3.3 - as defined and declared by distutils - lead to a change in your code? Alternatively stated, do you independently figure out that your virtualenv is on Windows and then put things in Scripts, etc, or do you use sysconfig? If sysconfig gave you different (consistent) values across platforms, how would that affect your code? Thanks, VanCIRCULAR 230 NOTICE: To ensure compliance with requirements imposed by U.S. Treasury Regulations, Haynes and Boone, LLP informs you that any U.S. tax advice contained in this communication (including any attachments) was not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein. CONFIDENTIALITY NOTICE: This electronic mail transmission is confidential, may be privileged and should be read or retained only by the intended recipient. If you have received this transmission in error, please immediately notify the sender and delete it from your system. ___ Python-Dev mailing list Python-Dev@python.org 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 install layout and the PATH on win32
On 3/15/2012 6:19 PM, Mark Hammond wrote:
[At least I think that is your proposal - can you confirm that the
directory layouts in your proposal exactly match the directory
layouts in virtual envs on all other platforms? ie, that
inconsistencies like the python{py_version_short} suffix will not
remain?]
Yes, that is the ideal.
Also, I'm still yet to see what exactly becomes "easier" in your
model? As you mention, most Python code will not care; distutils and
other parts of the stdlib will "do the right thing" - and indeed,
already do for Windows.
Again, I have stated my use case - cross platform development where the
tools use the directory layout in some way, or where the environment
should be checked into source control.
It is a shame this wasn't done as part of py3k in the first place.
But I assume you would be looking at Python 3.4 for this, right?
No, I would like this for 3.3.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
On Thu, Mar 15, 2012 at 9:48 PM, Tres Seaver wrote: > On 03/13/2012 06:49 PM, Nick Coghlan wrote: >> On Wed, Mar 14, 2012 at 8:08 AM, Guido van Rossum >> wrote: >>> If you can solve your problem with a suitably hacked Unpickler >>> subclass that's fine with me, but I would personally use this >>> opportunity to change the app to some other serialization format >>> that is perhaps less general but more robust than pickle. I've been >>> bitten by too many pickle-related problems to recommend pickle to >>> anyone... >> >> It's fine for in-memory storage of (almost) arbitrary objects (I use >> it to stash things in a memory backed sqlite DB via SQLAlchemy) and >> for IPC, but yeah, for long-term cross-version persistent storage, >> I'd be looking to something like JSON rather than pickle. > > Note the Zope ecosystem (including Plone) is an *enoromous* installed > base[1] using pickle for storage of data over many years and multiple > versions of Python: until this point, it has always been possible to > arrange for old pickles to work (e.g., by providing aliases for missing > module names, etc.). > > ]1] tens of thousands of Zope-based sites in production, including very > high-profile ones: http://plone.org/support/sites Don't I know it. :-) So do you need any help porting to Python 3 or not? The OP didn't mention Zope. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org 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 405 (built-in virtualenv) status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/16/2012 04:46 AM, Lennart Regebro wrote: > On Fri, Mar 16, 2012 at 05:55, Tres Seaver > wrote: >> ExtensionClass and Acquisition would fit the bill, except they >> aren't ported to Python3 (Acquisition needs the headers from >> ExtensionClass). > > And there were no plans to port them either, really. :-) Only Zope 2 > uses them afaik? Or? I don't know of plans to port them, or even how hard the port would be. The "headers needed" problem is a tricky one, and they do exercise it. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9jRRUACgkQ+gerLs4ltQ4cpwCgnLehMsKDV8BKMkix+ZitRnPA LHgAnRLZdjc7+I9/rkepO6iNXEBg7uQo =JmOT -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: PEP 417: Adding unittest.mock
On Thu, Mar 15, 2012 at 6:27 AM, Michael Foord wrote: > On the topic of docs mock documentation is about eight pages long. My > intention was to strip this down to just the api documentation, along with a > link to the docs on my site for further examples and so on. I was encouraged > here at the sprints to include the full documentation instead (minus the mock > library comparison page and the front page can be cut down). So this is what > I am now intending to include. It does mean the mock documentation will be > "extensive". Don't forgot you also have the option of splitting out a separate HOWTO tutorial section, leaving the main docs as a pure API reference. (I personally find that style easier to use than the ones which try to address both needs in the main module docs). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org 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 405 (built-in virtualenv) status
On Fri, Mar 16, 2012 at 05:55, Tres Seaver wrote: > ExtensionClass and Acquisition would fit the bill, except they aren't > ported to Python3 (Acquisition needs the headers from ExtensionClass). And there were no plans to port them either, really. :-) Only Zope 2 uses them afaik? Or? //Lennart ___ Python-Dev mailing list Python-Dev@python.org 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 install layout and the PATH on win32
On 16 March 2012 00:12, Carl Meyer wrote: > Changing the directory name is in fact a new and different (and much > more invasive) special case, because distutils et al install scripts > there, and that directory name is part of the distutils install scheme. > Installers don't care where the Python binary is located, so moving it > in with the other scripts has very little impact. Two thoughts: 1. The incompatibilities between platforms is precisely the problem that sysconfig is designed to solve, isn't it? So tools in Python will either use sysconfig (and be correct regardless of layout) or should be encouraged to change to use sysconfig (so they are layout-independent). And tools *not* in Python will be platform-specific anyway (I assume no-one is writing Perl scripts to manipulate their Python installation :-)) 2. The differences in layout between a installed Python, uninstalled builds and virtualenvs, on the same platform, are more annoying in practice than any cross-platform differences (at least for me). But again, these are known issues that can be dealt with easily enough (trivially via sysconfig from within Python). If I were "tidying up", I would consider renaming Scripts to "bin" on Windows, and putting the Python executables in there (so there's only one directory to add to PATH, and it uses the common name "bin" rather than a name that implies that it doesn't contain exes). But that offers no practical benefit, and as Mark says does break existing code, so I don't think it's worth it. If you can get Guido to lend you the time machine keys, I'd support putting it in from Python 1.5 onwards :-) Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Raising assertions on wrong element types in ElementTree
Eli Bendersky, 16.03.2012 08:38: > The Element class in ElementTree > (http://docs.python.org/py3k/library/xml.etree.elementtree.html) has > some methods for adding new children: append, insert and extend. > Currently the documentation states that extend raises AssertionError > when something that's not an Element is being passed to it, and the > others don't mention mention this case. AssertionError is clearly the wrong thing to raise for user input. > There are a number of problems with this: > > 1. The behavior of append, insert and extend should be similar in this respect > 2. AssertionError is not the customary error in such case - TypeError > is much more suitable > 3. The C implementation of ElementTree actually raises TypeError in > all these methods, by virtue of using PyArg_ParseTuple > 4. The Python implementation (at least in 3.2) actually doesn't raise > even AssertionError in extend - this was commented out > > The suggestion for 3.3 (where compatibility between the C and Python > implementations gets even more important, since the C one is now being > imported by default when available) is to raise TypeError in all 3 > methods in the Python implementation, to match the C implementation, > and to modify the documentation accordingly. +1 Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Raising assertions on wrong element types in ElementTree
Hi, [Terry suggested in http://bugs.python.org/issue13782 to raise this dilemma to python-dev. I concur.] The Element class in ElementTree (http://docs.python.org/py3k/library/xml.etree.elementtree.html) has some methods for adding new children: append, insert and extend. Currently the documentation states that extend raises AssertionError when something that's not an Element is being passed to it, and the others don't mention mention this case. There are a number of problems with this: 1. The behavior of append, insert and extend should be similar in this respect 2. AssertionError is not the customary error in such case - TypeError is much more suitable 3. The C implementation of ElementTree actually raises TypeError in all these methods, by virtue of using PyArg_ParseTuple 4. The Python implementation (at least in 3.2) actually doesn't raise even AssertionError in extend - this was commented out The suggestion for 3.3 (where compatibility between the C and Python implementations gets even more important, since the C one is now being imported by default when available) is to raise TypeError in all 3 methods in the Python implementation, to match the C implementation, and to modify the documentation accordingly. There may appear to be a backwards compatibility here, since the doc of extend mentions raising AssertionError - but as said above, the doc is wrong, so no regressions in the code are be expected. Does that sound reasonable (for 3.3)? Does it make sense to also fix this in 3.2/2.7? Or fix only the documentation? Or not touch them at all? Thanks in advance, Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
